Autonomous Coding Strategies: Guardrails & Task Decomposition for Claude Code

I want to add [feature] to this codebase.

Before implementing anything:
1. Identify all files that will need to change
2. Estimate the scope: [small <3 files] [medium 3-8 files] [large 8+ files]
3. If large, propose breaking this into phases
4. List your proposed implementation order
5. WAIT for my approval before making any changes

Phase 1: "Create the database migration and update the Prisma schema.
Show me the migration SQL before running it."

[Review, approve]

Phase 2: "Add the API endpoint using the existing pattern in server/api/routers/.
Include Zod validation. Run tests."

[Review, approve]

Phase 3: "Build the frontend component. Follow the pattern from components/forms/UserForm.tsx.
Wire it to the API. Write component tests."

[Review, approve]

For every change you propose:

1. EXPLAIN what you're changing and why
2. SHOW the exact diff you intend to make
3. IDENTIFY what could break
4. WAIT for confirmation

Do NOT:
- Make changes without showing them first
- Run database migrations without explicit approval
- Install new packages without listing them

SCOPE LIMIT: You are working on [specific feature/module].

Files you CAN modify:
- src/features/auth/
- src/shared/validation.ts

Files you MUST NOT modify (even if you think it's necessary):
- src/features/payment/ (separate team's code)
- prisma/schema.prisma (requires DBA review)
- infrastructure/ (Terraform — separate change process)

If you think a change to a restricted file is necessary, explain why and WAIT.

After making changes, you MUST:

1. Run `npm run lint` — fix ALL errors and warnings
2. Run `npm run typecheck` — fix ALL type errors
3. Run `npm run test` — ALL tests must pass
4. Run `npm run build` — must succeed

If any gate fails:
- Fix the issue in the code you wrote
- Do NOT modify existing tests to make them pass unless the test expectation is genuinely wrong
- If a gate fails for reasons unrelated to your changes, report it and WAIT

Safety rules — NEVER:

- Force-push to any branch
- Delete branches unless explicitly asked
- Run `git reset --hard` or any destructive git command
- Modify `.env`, `.env.local`, or any config containing secrets
- Run commands against production databases
- Install packages with known vulnerabilities (check `npm audit`)
- Bypass lint or type errors with `// @ts-ignore` or `// eslint-disable`

When you encounter an error:

1. READ the error message carefully
2. IDENTIFY the root cause (not just the symptom)
3. PROPOSE a fix with reasoning
4. IMPLEMENT the fix
5. VERIFY the fix resolved the issue

If your first fix doesn't work:
- Do NOT try random changes
- Re-examine your understanding of the root cause
- If stuck after 3 attempts, explain your reasoning and ask for help

If you realize a previous change was wrong:

1. SAY SO explicitly: "I made an error in [previous change]. The issue is [explanation]."
2. PROPOSE the correction
3. If the wrong change had cascading effects, trace them all before fixing

STOP and ask for human review when:

- The change affects authentication, authorization, or security
- You're modifying a database schema
- You're changing a public API contract
- The change touches billing, payments, or financial calculations
- You're uncertain about the correct approach
- The change will affect more than 5 files
- You've been working autonomously for more than 30 minutes

Before committing:

1. Review your own diff line by line
2. Remove any debug code, console.log, or commented-out blocks
3. Verify no secrets or tokens were accidentally included
4. Write a conventional commit message: `type(scope): description`
5. Present the commit for my review before pushing