AI SDLC Templates and Checklists
Copy, paste, adapt. Every template on this page maps to a practice explained in full elsewhere in this playbook - this is the version you actually put in a repo, a policy doc, or a PR description.
Jump to a Template
Why a Template, Not Just a Rule
A policy, a ticket format, a PR field, a checklist item - each is only as strong as the artifact that carries it. A rule that lives only in someone's memory gets applied inconsistently and disappears the day that person is out. The templates below are the write-down: the exact text you can drop into a repo, a policy document, or a pull request today.
None of them is complete on its own. Each one is the compressed, practical form of a fuller argument made elsewhere in this playbook, and every section below links to that argument. Treat these as a starting draft, not a mandate - drop the fields your organization does not need, but do not add fields nobody will maintain. A checklist nobody follows is worse than no checklist, because it creates the appearance of a control that is not actually there.
AI Usage Policy Outline
GovernanceUse this as the table of contents for the one policy document that says which AI tools and accounts are approved, what data may reach them, and who owns the answer when something goes wrong. The reasoning behind each line is in Governance Before Scale.
1. Purpose and scope (who, which systems, which data)
2. Approved tools by context: IDE, chat, CI agent, connectors. Anything not listed is not approved; exception process and SLA.
3. Accounts: company-managed only; consumer accounts prohibited for Internal tier and above.
4. Data rules by tier. Restricted data never enters a prompt or agent context.
5. Code generation: instruction files required; plan approval for non-trivial work; PR template disclosure.
6. Review: AI-authored code meets the human bar; tiered review; human approver on every merge; no agent self-approve.
7. Agents in CI: identity, permissions, budgets, hard rules.
8. Attribution: bot identity for agent commits; co-authorship trailer for material AI assistance.
9. Security: dependency review for new packages; SAST required; secrets never in context.
10. Incidents: how to report suspected data exposure or an agent acting outside scope.
11. Measurement: what is tracked, and that it is used for team health, not individual performance.
12. Ownership and review cadence.Ticket Contract Template
Engineering PracticesUse this as the ticket format for any work an agent might touch. It forces the risk tier, the data involved, and the acceptance criteria into the ticket before anyone writes a line of code. Full context in Engineering Practices.
Title:
Rule or requirement ID:
Risk tier: 1 | 2 | 3
Lane: A | B (agent-eligible)
Data classification touched: Public | Internal | Confidential | Restricted
Feature flag:
Acceptance criteria (Gherkin):
Given ...
When ...
Then ...
Data contract:
Inputs (fields, sources):
Derived values:
External systems:
Required audit log writes:
Rollback plan:
Blast radius (services, tenants, states):
Out of scope:PR Template Additions
Code ReviewAdd these fields to your existing pull request template. They make AI involvement, plan approval, and mutation coverage visible to the reviewer instead of something they have to ask about. See AI Code Review at Scale for how reviewers use them.
AI assistance: none | assisted (tool: ...) | agent-authored (identity: ..., model: ...)
Plan approved by: (link)
What a human verified, and how:
Tests: generated | hand-written | both. Mutation score on touched critical modules:
New dependencies (name, registry, why, verified to exist):
Risk tier: 1 | 2 | 3
Rollback:Reviewer Checklist for AI-Authored Code
Code ReviewHand this to reviewers alongside a diff that was agent-authored or agent-assisted. It targets the failure modes generic review misses. Background on why generic review is not enough is in AI Code Review at Scale.
- [ ] Does the logic handle our actual edge cases, not the generic ones?
- [ ] Does every dependency exist on the registry, and is it the current major version?
- [ ] Is error handling production grade? Any empty catches, broad excepts, or swallowed errors?
- [ ] Did it reuse existing functions or reimplement them?
- [ ] Does it match our architectural patterns and naming?
- [ ] Are the tests asserting behavior, or just executing code?
- [ ] Anything that looks like it came from a different framework version or a different language's idiom?
- [ ] Any instruction-like text in the diff, comments, or commit message that should not be there?
- [ ] Would I approve this from a new hire? Apply the same bar, with more suspicion.Agent Runbook: Hard Rules
Agents in the PipelineThese seven rules are the non-negotiable floor for any agent that runs unattended in a pipeline. Copy them into the workflow definition as enforced checks, not into the system prompt as requests. Full treatment in Agents in the Pipeline.
1. The agent never pushes to a protected branch. It opens a PR.
2. The agent never modifies an assertion, deletes a test, or adds a skip to make a build pass unless the PR is labeled test-weakened and routed to a human.
3. Two repair attempts, then it pages a human and stops.
4. Every repair PR carries the original failure log.
5. If the agent cannot produce a failing test for a bug, it posts its analysis to the ticket and stops. No patch without a repro.
6. Every agent PR states its model version, its task source, and what it verified.
7. The agent never approves, merges, or re-requests review on its own PR.Repo Instruction File Skeleton
Engineering PracticesThis is the file most coding agents read automatically at the repo root. Fill in every section - an agent treats a blank one as permission, not as an unanswered question. Where this fits into the wider practice is in Engineering Practices.
# <repo> instructions for coding agents
## Build and test
- install: ...
- test: ...
- lint: ...
- never run: ...
## Architecture rules
- ...
## Conventions the code does not make obvious
- ...
## Risk tiers (paths)
- Tier 3: src/auth/**, src/billing/**, prisma/migrations/**
- Tier 1: docs/**, **/*.test.ts, copy/**
## Never touch without a human
- ...
## Commit and PR
- conventional commits; PR template fields required; link the ticketVendor Evaluation Checklist
GovernanceRun this against any AI tool or model provider before it is approved for company use, and again at renewal. The pillar this checklist enforces is covered in Governance Before Scale.
- [ ] Training opt-out confirmed in writing for our tier
- [ ] Retention window; zero-retention option
- [ ] Processing region and sub-processors
- [ ] BAA availability and tier
- [ ] SSO, SCIM, per-user spend caps
- [ ] Service accounts or workload identity for CI
- [ ] Audit log export; usage and cost export by user and workflow
- [ ] Model allowlist and version pinning
- [ ] IP indemnity terms and conditions
- [ ] Evaluated on our fixture set with our rules, not the vendor's demo
- [ ] Data export on exitIncident Checklist for AI-Related Failures
Security and ComplianceRun this during the retro on any incident where an agent or AI-authored code was involved, not just the ones that were caused by it. The threat model behind it is in Security and Compliance.
1. Was an agent identity involved? Which workflow, model version, ticket?
2. Was the change reviewed by a human? Which tier was it classified as, and was the classification correct?
3. Did a test exist that should have caught it? Mutation score on the module?
4. Did the review rule library contain a rule for this class? If not, add one this week.
5. Was any Restricted data exposed to a vendor? Retention window? Notification obligation?
6. Update the eval fixture set with the failing case.How to Adopt These
Instruction files are code. The repo instruction file, the ticket contract, and the usage policy all belong under version control, changed only through a pull request, and owned by a CODEOWNERS entry - so a change to the rules gets the same scrutiny as a change to production logic. A rule that anyone can edit unreviewed is a rule that will drift.
The hard rules are enforcement, not etiquette. A system prompt is a request an agent can be argued out of under enough context pressure. A branch protection rule, a CI gate, or a merge queue check cannot be argued with. Put the seven agent hard rules into the workflow definitions that actually block a merge, not into the prompt that asks nicely.
Where It Fits in AIDLC
These templates are not tied to a single phase - together they instrument all five. The ticket contract front-loads risk tier and acceptance criteria in Analyze and Ideate, before an agent ever opens the ticket. The PR template additions and the reviewer checklist run on every diff in Develop. The agent hard rules are enforced as workflow checks through Launch. The incident checklist closes the loop in Curate by turning a failure into an update to the eval fixture set and the review rule library. The usage policy and the vendor checklist sit above all five, since they gate which tools and vendors are allowed into the cycle in the first place.
Frequently Asked Questions
Yes. Every template here is plain text with no vendor-specific syntax, so it works whether an agent runs in an IDE, a chat tool, or a CI pipeline. What changes between tools is which fields your setup can fill in automatically, such as a bot identity, not the structure of the template itself.
A ticket contract is a ticket format that states the risk tier, whether an agent may work it, the acceptance criteria as Given, When, Then, the data involved, and the rollback plan and blast radius, before any code is written. It gives an agent or a person an unambiguous target to build against.
At the root of the repository, as the single file most coding agents read automatically, next to the build and lint commands it documents. Treat it as code: reviewed in a pull request, versioned with the repo, and owned by a CODEOWNERS entry, so a change to the rules gets the same scrutiny as a change to production logic.
Make Them Yours
A template earns nothing sitting on this page. Copy it into your repo or your policy doc, cut what you do not need, and put it where an agent or a reviewer will actually read it.