An AI coding assistant will happily produce work at whatever quality bar you fail to specify. The fix is not to hover over every output; it is to encode your standards once, as reusable prompt modules, and feed them to the assistant up front. This play presents one team's modules. Use them as a starting point to adapt, not as universal law, because every module here contains opinionated choices.

When to use this play#

Use it when AI assistants are doing real work in your codebase and you want that work to look like your team's work without per-task babysitting. Pull individual modules for focused tasks, or combine several into a standing system prompt for a project. The point is to make your standards explicit and machine-readable so the assistant inherits them instead of inventing its own.

How to run it#

Treat each module below as a composable block. Drop in the ones that apply to the task, and keep a project memory file that holds the standards and the running TODO list so context survives across sessions.

Test-driven development module#

• Write a failing test first, and confirm it actually fails before writing code.
• Add the minimal code to make it pass, then refactor.
• Favor many unit tests, fewer integration tests, and a minimal set of happy-path acceptance tests.
• Keep tests deterministic and isolated from each other.
• Everything is green before any commit.

Code-quality module#

• Prefer self-documenting code over explanatory comments.
• Keep functions small.
• Choose readability over premature optimization.
• Apply established refactoring patterns rather than improvising structure.
• Make the smallest reasonable change that solves the problem.

Infrastructure and architecture module#

Declare these up front so the assistant builds against them instead of guessing: the stack, the repository layout, accessibility and responsive requirements, infrastructure-as-code, CI/CD, container-based local development with seeded data, secrets management, and the deployment strategy.

Security and data-handling module#

• Use connection pooling for database access.
• Use structured logging with appropriate levels.
• Maintain audit tables capturing who did what and when.
• Never put personal data in logs.
• Keep secrets in a manager with rotation.
• Make all schema changes through migrations only.

Workflow module#

• Commit small and often, grouping related changes.
• Write a one-line "why" for each commit message.
• Never bypass pre-commit hooks.
• Refuse to auto-push.
• Ask rather than assume when something is ambiguous.

Collaboration module#

Treat the assistant as a peer, not an order-taker. It should push back with evidence when it disagrees, admit uncertainty instead of bluffing, and never paper over a failing test. The shared project memory file is where the standards and outstanding TODOs live, so the peer relationship has continuity.

Documentation module#

Have the assistant generate a README covering setup, dependencies, how to run the project, how to run the tests, coverage, and the stack — the things a new contributor needs to get going.

Common traps#

• Treating the modules as gospel. These are one team's opinionated choices. Adopt them wholesale without thinking and you inherit decisions that may not fit your context.
• Skipping the project memory file. Without persisted standards and TODOs, every session starts from zero and the assistant re-litigates settled decisions.
• Letting the assistant bypass hooks or auto-push. The workflow module exists to stop exactly this. An assistant that pushes on its own or skips pre-commit checks is fast in the wrong direction.
• Accepting green-looking output without confirming the test failed first. A test that never failed proves nothing. The TDD module's "confirm it fails" step is load-bearing.
• Combining every module for every task. A huge system prompt for a one-line fix wastes attention. Pull only the modules the task needs.

Signals it's working#

• Assistant output reads like your team wrote it, with little after-the-fact cleanup.
• The assistant pushes back with evidence instead of silently complying with a bad instruction.
• Commits stay small, with honest "why" messages, and hooks are never bypassed.
• The project memory file keeps standards and TODOs alive across sessions.