Building Rich Context

The quality of Claude's plan is directly proportional to the context it has when planning. A plan built on "add a new API endpoint" will be generic. A plan built on "add a new API endpoint; here is our existing router structure, our auth middleware, our error handling patterns, and our test conventions" will be specific, consistent, and ready to execute. The difference is not Claude's capability — it is the information you gave it to work with.

Front-loading context means deliberately feeding Claude the information it needs before asking it to plan. Start by having Claude read the relevant files: "Read src/routes/index.ts, src/middleware/auth.ts, and src/tests/routes.test.ts." Then provide constraints: "We use Zod for validation, return RFC 7807 error responses, and every route needs a corresponding test." Then state the goal: "Now plan how to add a GET /users/:id endpoint that follows these patterns." Claude now has concrete examples, explicit constraints, and a clear objective. Its plan will match your codebase instead of defaulting to generic patterns.

There is a balance. Dumping twenty files into context before asking a simple question wastes tokens and dilutes focus. The art is providing the minimum context required for a high-quality plan. For a new feature, that means: the closest existing example, the conventions it must follow, and the constraints it must respect. For a bug fix, that means: the failing test, the relevant source file, and the error message. For a refactor, that means: the current structure and the target structure. Context is fuel — use enough to power the plan, not so much that the engine floods.