What this prompt does
This prompt asks the AI to build an autonomous code generation agent that writes, tests, and fixes code for [code_language] with [framework]. The agent accepts a natural-language task, produces an implementation plan, writes code following [coding_standards], and runs [test_command] automatically. When tests fail it analyzes the error, diagnoses the root cause, applies a fix, and re-runs — up to [max_iterations] times. It auto-fixes linter issues, generates a commit message, and reads relevant files before writing so it understands existing patterns.
The structure works because the test-fix-retry loop is what turns a one-shot code generator into a self-healing agent, and the guardrails are what keep it safe. It never modifies [protected_files] and requires approval for [approval_actions], so the agent cannot quietly add dependencies or alter schema. Running inside a sandbox via [sandbox_method] with [model_provider] tool use contains side effects, making autonomous iteration something you can actually leave running. The context step — reading relevant files before writing — is what keeps generated code aligned with [coding_standards] and existing patterns rather than producing technically-correct code that ignores how the rest of the project is built.
When to use it
- You want an agent that implements a task end to end and verifies itself against
[test_command]rather than handing you untested code. - You need bounded autonomy — iterate up to
[max_iterations], then stop and report instead of looping forever. - You want hard guardrails so
[protected_files]stay untouched and[approval_actions]pause for a human. - You care about the agent matching existing patterns by reading context before writing.
- You want sandboxed execution so generated code cannot touch your host directly.
- You are building agentic workflows on top of
[model_provider]tool use and want a proven loop shape.
Example output
Expect an agent loop implementation: a planner, a code writer respecting [coding_standards], a test runner invoking [test_command], a failure-diagnosis-and-fix step capped at [max_iterations], a linter auto-fix pass, and a commit-message generator. Guardrail logic protects [protected_files] and gates [approval_actions], all wrapped in a [sandbox_method] execution environment.
Pro tips
- Keep
[max_iterations]modest — five is usually enough; an agent that loops endlessly on a hard failure burns tokens without progress. - Be generous with
[protected_files]; listing config, lockfiles, and CI explicitly is cheap insurance against an agent breaking your build. - Make
[approval_actions]cover anything irreversible or costly — new dependencies, schema changes — so a human signs off before they happen. - Ensure
[test_command]runs non-interactively and exits cleanly; a watch-mode test runner will hang the loop. - Insist the agent reads relevant files before writing; skipping the context step is why agents reinvent patterns the codebase already has.
- Use a real
[sandbox_method]like a Docker container with a mounted project dir so failed attempts cannot corrupt your working tree.
