Skill.re
Context Management: Feeding AI the Right Information
Context Determines Output Quality
You ask the AI to implement user authentication. It gives you a solution. You try to integrate it. It doesn't match your system's architecture. You need to rewrite it. Three hours wasted.
You ask the AI the same thing, but with context: "Here's our tech stack, here's how other services are structured, here are our constraints, here's our database schema, here's what we're integrating with." It gives you a solution that drops into your codebase with minimal changes. Done in 20 minutes.
That's the difference context makes. An AI without context is pattern-matching on your question. An AI with context is reasoning about your specific system. The output quality difference isn't subtle. It's usually the difference between something useful and something that requires significant rewrites.
What counts as context? Everything that affects the answer: what you're building, why, constraints, technical architecture, existing patterns, database schema, API contracts, deployment environment, scale requirements, team skill level, business goals, integrations with other systems, security requirements, performance budgets.
The Minimal Context Failure
Bad prompt: "Implement user authentication."
You get back: A generic user authentication system. Rails Devise pattern. Sessions with cookies. Basic password validation. Works for a website.
You try to use it. But you're building an API service that handles authentication for multiple frontend clients. Cookies don't make sense. You need JWT or similar. You need refresh tokens. You need to think about CORS. You need to handle token rotation. You need to integrate with your existing users table, which has a different schema. You throw away what the AI gave you and write it yourself.
The Rich Context Success
Good prompt:
Implement user authentication for our B2B SaaS platform. Here's what you need to know:
Tech Stack:
- Backend: Node.js/Express
- Database: PostgreSQL
- Frontend: React (separate client-side app)
- Other services: Stripe billing, Segment analytics
Architecture:
- Monolithic backend (not yet microservices)
- All services share same PostgreSQL database
- API runs at api.oursystem.com
- Frontend runs at app.oursystem.com
Existing Users Table:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR UNIQUE NOT NULL,
password_hash VARCHAR NOT NULL,
company_id INTEGER REFERENCES companies(id),
created_at TIMESTAMP DEFAULT NOW(),
deleted_at TIMESTAMP -- soft delete
);
Authentication Requirements:
- Sessions must work across API requests (stateless tokens preferred)
- Support email/password login
- Support "magic link" passwordless signup
- Support Google OAuth for SSO
- Must integrate with Segment (log login events)
- Each user belongs to one company (multi-tenancy)
Security Requirements:
- Must meet SOC 2 Type II (important for enterprise customers)
- Passwords must use bcrypt with 12+ rounds
- GDPR compliance: audit log of auth attempts
- Rate limit login attempts: 5 per minute per IP
Performance Requirements:
- Authentication must complete in
You get back: A solution that actually fits your system. It uses the patterns you already have. It integrates with your existing code. It handles your specific constraints. It works with your database schema. You can use it directly.
Understanding Context Layers
Not all context is equally important. Organize it in layers:
Layer 1: System Overview (Essential)
Without this, the AI is guessing. Tech stack. Architecture. Scale. Key constraints.
Tech Stack: Node.js, PostgreSQL, Redis, React
Architecture: Monolithic backend, separate frontend SPA
Scale: 100K users, 5K requests/sec
Key Constraints: Must run on-premises, PCI-DSS compliance required
Layer 2: Relevant Integration Points (High Value)
What systems does this connect to? What are the interfaces?
Database: Use existing /app/models/User.js
API: Endpoints must follow /api/v1/* pattern
Events: Log events to Segment via /app/utils/analytics.js
Cache: Use Redis via /app/services/cache.js
Layer 3: Existing Patterns (High Value)
Show the AI how similar things are done in your codebase. It learns your patterns and follows them.
Here's how we structure middleware:
[Code example]
Here's how we handle errors:
[Code example]
Here's how we validate input:
[Code example]
Layer 4: Specific Details (Medium Value)
Database schema, API contracts, configuration. Include when relevant.
Layer 5: Business Context (Sometimes High Value)
Why are you building this? What's the business goal? This helps the AI make smart trade-offs.
We're building this because: Payment processing was our bottleneck.
This will: Reduce payment processing time from 30s to
Creating Reusable Context Templates
Explaining your system every time is tedious. Create templates you reuse. This is one of the highest-ROI investments for team productivity.
System Overview Template:
Create a markdown file your team uses as a standard preamble:
System Overview
Tech Stack
- Backend: Node.js (v20.x), Express 4.x
- Database: PostgreSQL 15
- Cache: Redis 7.x
- Frontend: React 18.x
- Deployment: Docker on AWS ECS
Architecture
[Brief diagram or description]
Scale
- Users: [current and expected]
- Requests: [current and expected]
- Data volume: [current and expected]
Key Services
- Auth service at /api/auth
- Payment service at /api/payments
- Notification service (queue-based)
Critical Constraints
- PCI-DSS compliance required
- All data must be encryptable (not hashed passwords)
- GDPR right to be forgotten must work
- Real-time payment verification required
Store this in your wiki. Use it in every architectural or implementation prompt about the system. Update it quarterly.
Code Pattern Examples Template:
Create a file with 3-5 examples of how your team structures common things: middleware, error handling, database queries, validation, authentication checks. Include real code from your repo.
When you prompt the AI to write code, include "Here's how we structure [thing] in our system: [code example]". The AI learns and follows your patterns.
Database Schema Reference:
For any prompt about database interactions, include the relevant schema. Include not just column definitions but also:
- Indexes that exist (performance matters)
- Foreign key relationships
- Soft delete patterns if you use them
- Enum columns and their values
Progressive Context Building
Don't dump all context at once if you don't need to. Start simple. If results aren't quite right, add context and iterate.
Example: Adding Payment Processing
Attempt 1: "Generate code to process a payment using Stripe."
Result: Generic Stripe integration. Works but doesn't fit your patterns.
Attempt 2: "We use this pattern for external service calls: [code example]. We log all transactions to audit table. Generate payment processing using that pattern."
Result: Better. But still missing something.
Attempt 3: "We're processing 5K payments/second. We use Redis for deduplication. Payment must be idempotent (same payment ID always gives same result). We have audit requirements: log who initiated payment, when, from what IP. Generate payment processing that handles all this."
Result: Now it's actually good because you revealed the constraint that matters: scale and idempotency.
Progressive context is smart because you only include what's necessary. If the first attempt had worked, you didn't waste time explaining details you don't need.
Common Context Mistakes
Too Much Unrelated Context: "Here's our entire architecture diagram." The AI gets lost. Include only what's relevant to the current problem.
Outdated Context: "Here's our tech stack" but you migrated three months ago. Keep context fresh. Document changes.
Missing the Actual Constraint: You mention 100 things but miss the one thing that actually matters. This is why progressive refinement helps, if results aren't right, usually you're missing a constraint.
Assuming the AI Knows Your Domain: You say "make it REST-compliant" but your domain has specific interpretation of what that means. Examples are better than principles.
Context for Analysis vs. Generation
Context for code generation is different from context for analysis.
For Generation: You need to describe the end state you want. Tech stack, patterns, constraints, existing integrations, scale requirements.
For Analysis: You need to describe the current state. What problem are you trying to solve? What have you tried? What constraints do you have? What would success look like?
Example of analysis context:
We're analyzing our payment service for performance issues.
Current state:
- Processes 5K payments/second (peak)
- Stripe API calls take 200-500ms each
- Database writes take 10-20ms each
- P99 latency is 2 seconds (should be
The Context Template Repository: Create a GitHub or wiki repo just for context templates. Document your tech stack, architecture, database schema, API contracts, code patterns, and deployment environment. Update it quarterly. When anyone needs to prompt the AI, they start with "Here's our system overview" and paste the template. This single practice can double your team's AI productivity because the AI always has context instead of guessing.
Case Study: Context Templates Doubling Productivity
A backend team of 12 engineers were all using Claude for code generation. Results were inconsistent. Some engineers got production-ready code. Others got code that didn't fit team patterns (wrong error handling, different logging approach, different database access style). The issue: each engineer was starting from scratch, explaining their tech stack and patterns to Claude every time.
The tech lead created a context template (200 lines): tech stack (Node.js, PostgreSQL, Redis), code patterns (how errors are handled, how logging works, how database queries are structured), architecture (microservices, async processing), deployment (Docker, AWS ECS). They saved it in Notion and shared with the team: "Use this as your starting context. Any time you prompt Claude, paste this first."
Results: 1) AI-generated code was consistently high quality (74% needed no changes vs. 40% previously). 2) Review time dropped 50% (reviewers recognized the patterns immediately). 3) New team members onboarded 2 weeks faster (they had a template showing team standards). 4) Time to productive AI use per engineer: 30 minutes instead of 3 days.
Financial impact: 12 engineers × 2 days × $150/hour = $4,320 saved just on faster onboarding. Code review time savings (50% reduction) = roughly 10 hours/week × 12 engineers × $50/hour = $6,000/month. Total: $72,000/year in freed capacity.
When This Goes Wrong: Stale Context Leading to Incompatible Code
A team had a tech stack document (6 months old). They said "we use PostgreSQL 13." They'd actually upgraded to PostgreSQL 15 months ago. When they prompted Claude with the old context, it sometimes generated queries using PostgreSQL 13-specific behavior that didn't work in 15. They had to manually fix generated code. Lesson: context must be fresh. Review and update quarterly. Date your context templates so people know how fresh they are.
Key Insight
Context is leverage. Good context means the AI generates code you can use. Reusable context means everyone on your team benefits. Build templates. Use them. Update them. This is foundational.
What to Do Monday Morning
- Write down your system overview. Tech stack, architecture, scale, constraints. One page. Save it.
- Pick one task you're doing with AI this week. Add detailed context instead of asking a minimal question. Notice the difference in output quality.
- Document how you structure code for one thing: middleware, error handling, database queries. Add code examples.
- Share your system overview with one teammate. Have them use it in a prompt. Get feedback on what's missing.
- Create a "context templates" document for your team. System overview, code patterns, database schema. Update it monthly.
Frequently Asked Questions
Q: Won't providing too much context confuse the AI?
Rarely. Modern LLMs handle 10K-100K tokens of context easily. The risk isn't too much context. It's unclear context or contradictory context. Clear, well-organized context is almost always better.
Q: How do I know what context is relevant?
Start with: What would I explain to a new engineer joining the team to help them understand this problem? That's roughly the context the AI needs.
Q: Should context include business goals?
Yes, often. Business goals help the AI make smart trade-offs. "We're optimizing for speed, not cost" or "Reliability > features" changes the recommendations. Include business context when it affects the technical decision.
Q: What if my context is wrong or outdated?
The AI will produce wrong output. Review your context as carefully as you'd review code. If the AI's output doesn't match your system, first suspect incorrect context. Then suspect unclear context. Then suspect the AI reasoning.
Q: Can I reuse context across prompts?
Absolutely. This is the point of templates. Use the same system overview for every architectural prompt. Use the same code patterns for every implementation prompt. Consistency means better results and less context switching.
Q: What if different team members have different context?**
That's a problem. Standardize. Create team templates so everyone starts with the same context. When someone discovers the context is incomplete or wrong, update the template so everyone benefits. This is force-multiplying.