Context Engineering with Claude Code: The Spec-First Pipeline for Production Codebases
How to structure markdown specification files, linting contracts, and context boundaries to eliminate hallucinated refactors when coding with Claude Code and modern CLI agents.
Contents
- What is the problem with unstructured conversational prompting?
- How does the Spec-First Pipeline work?
- What belongs in a production feature spec?
- How do you enforce automated verification loops?
- FAQ
What is the problem with unstructured conversational prompting?
When developers ask CLI coding agents to 'Fix the user profile page' or 'Refactor our database queries', the model must guess which files to edit, what interfaces to preserve, and how to verify correctness.
This ambiguity leads to three common failure modes:
- Collateral Damage: The agent modifies unrelated utility functions, introducing silent regressions across the codebase.
- Context Saturation: The agent reads dozens of unnecessary files, exhausting its context window and forgetting the primary objective.
- Premature Completion: The agent claims a task is complete without running linters, compilers, or test suites.
flowchart TD
A[Feature Request / Bug] --> B[Draft SPEC.md in Repo]
B --> C[Review Interface & Target Files]
C --> D[Feed Spec to Claude Code / CLI Agent]
D --> E[Agent Edits Code in Target Files]
E --> F[Run Deterministic Test Suite]
F -->|Tests Fail| E
F -->|Tests Pass| G[Commit & Open PR]How does the Spec-First Pipeline work?
The Spec-First Pipeline replaces open-ended chatting with a deterministic three-stage workflow:
| Stage | Artifact | Action | Owner |
|---|---|---|---|
| 1. Specification | specs/feature-name.md | Define goal, target files, interfaces, and test commands | Human Operator / Architect |
| 2. Implementation | Staged Git Diff | Execute code changes strictly within specified boundaries | Claude Code / Coding Agent |
| 3. Verification | Test Log & Linter Output | Run automated validation suite until all checks pass | Test Runner / Linter |
What belongs in a production feature spec?
Create a dedicated markdown file in specs/ following this template before launching your agent:
# Feature Spec: User Profile Avatar Upload## 1. ObjectiveAdd client-side image resizing and S3 presigned URL upload for user profile avatars.## 2. In-Scope Files- `src/components/AvatarUpload.tsx`- `src/app/api/upload/route.ts`- `src/types/user.ts`## 3. Explicit Out-of-Scope Files (DO NOT MODIFY)- `src/app/layout.tsx`- `src/middleware.ts`- `prisma/schema.prisma`## 4. API Interface ContractPOST /api/uploadRequest: { 'filename': string, 'contentType': 'image/jpeg' | 'image/png' }Response: { 'uploadUrl': string, 'publicUrl': string }## 5. Verification Commands- `npm run lint` (Must pass with 0 warnings)- `npm run test tests/avatar-upload.test.ts`How do you enforce automated verification loops?
Once the spec is defined, launch Claude Code with clear instructions pointing directly to the specification document:
claude 'Read specs/feature-name.md and implement the requested changes strictly within the specified in-scope files. Run npm run lint and tests before finishing.'By providing explicit file targets and verification commands, the agent focuses its context window solely on the problem at hand, preventing hallucinated file creations and unwanted architectural changes.
FAQ
- Does writing a spec file slow down fast vibe coding?
No. Writing a 2-minute markdown spec saves 20 minutes of debugging broken imports, unrequested file refactors, and reverting unintended Git commits.
- How detailed should the interface contracts be in the spec?
Specify the exact TypeScript types or JSON schemas for any new API endpoints or function signatures to prevent the agent from inventing conflicting data shapes.
- Can I ask Claude Code to write the spec file first?
Yes. You can instruct the agent: 'Analyze our repository and write a draft spec to
specs/feature.mdfor adding feature X. Do not write any implementation code yet.' Review the spec, then approve execution.