The prompt
Score 10 of 10, Excellent
Use it when You are handing a well-defined feature to Claude Code, Codex or another coding agent and want a plan first, code that fits the codebase, and tests as proof.
- {{feature}}
- {{users}}
- {{user_outcome}}
- {{location}}
- {{pattern_files}}
- {{acceptance_cases}}
- {{max_files}}
- {{off_limits}}
- {{check_commands}}
Full prompt and why it works
Prompt
Goal: Implement this feature: {{feature}}. It is for {{users}}, so that {{user_outcome}}. Context: - Where it belongs: {{location}} - Existing code to follow as the pattern for structure, naming and error handling: {{pattern_files}} - Acceptance cases, each an input or action and the result it must produce: {{acceptance_cases}} Constraints: - Before editing, read the relevant code and reply with a short plan: the files you will change or add, and any decision I need to make. Wait for my go-ahead if the plan touches more than {{max_files}} files or changes a public interface, the database schema or configuration. - Follow the existing patterns in the files named above. Do not add new dependencies, and do not refactor or reformat code the feature does not need. - Do not touch {{off_limits}}. - Use user-facing text and messages exactly as given in the acceptance cases. Done when: - Each acceptance case is covered by a test that passes, placed with the existing tests for this area and named like them (for example export_service.test.ts beside export_service.ts, or tests/test_export_service.py). - The full test suite, the linter and the type check pass: {{check_commands}} - No existing test was changed or deleted to make it pass. Verify: run the check commands, read the output and iterate until they pass. Then report in this format: Files changed (one line each on why), Tests added, the commands you ran with the last 20 lines of their output, and anything left undone. If an acceptance case is ambiguous or conflicts with how the code works today, stop and ask before choosing an interpretation.
Variables
- {{feature}}
- What the feature does, in one or two sentences.
- {{users}}
- Who uses it, for example "account admins".
- {{user_outcome}}
- What it lets them do, for example "they can send a report to their finance team without reformatting it".
- {{location}}
- The files, modules or endpoints involved, as far as you know.
- {{pattern_files}}
- One or two existing files that do something similar, for the agent to copy.
- {{acceptance_cases}}
- Concrete examples, one per line: an input or action and the exact result, for example "export with no rows: shows 'Nothing to export'".
- {{max_files}}
- The number of files above which the agent must check with you first, for example 5.
- {{off_limits}}
- Files, folders or systems that must not change, for example migrations or generated code.
- {{check_commands}}
- The commands for tests, lint and types, for example npm test && npm run lint.
Why it works
- What good looks like. Done when means every acceptance case has a passing test and the suite, linter and type check all pass, a check the agent runs rather than its own judgment.
- An example. Pointing at existing files to copy makes the new code look like the rest of the codebase instead of the agent's default style.
- If unsure. A plan comes before any edit, and the agent stops for a decision when the work grows past your file limit or a case is ambiguous.