Templates

Using these templates

The templates are in English in both editions, so the same file can go into any repository. Square brackets mark a placeholder. A checkbox, [ ], is an assertion you must back with something an auditor could open: a log, a setting, a configuration file. No organisation has validated these forms against outcomes; each section names its source chapter and evidence so you can judge each line's weight. Fill them in against the running system, not the design document: under the authority rule, what the settings allow is your level. Vendor guidance quoted below is as of October 2026.

Self-assessment grid

Use this before any pilot and again every quarter. It is the blank copy of the grid in The AI-SDLC Maturity Model, and Chapter 13, Assess Your Starting Point, walks through filling it in. Score one row per phase and task type, never per team. Two columns do most of the work. "Oracle / who can edit" applies the oracle principle: if the agent can edit the check, the row is L2 at most. "Credentials held" applies the authority rule: wherever the credentials reach further than the review column, record the higher level.

SELF-ASSESSMENT GRID        Scored by: [name]   Date: [date]   Window: last [30/90] days

PHASE         TASK TYPE        LEVEL  EVIDENCE (link)        ORACLE / WHO CAN EDIT   RISK CEILING  CREDENTIALS HELD
------------  ---------------  -----  ---------------------  ----------------------  ------------  ----------------
Requirements
Design
Coding
Review
Testing
CI/CD
Operations
Maintenance

Checks before signing:
[ ] Every LEVEL cites evidence (approval log, attribution, routing config), not opinion
[ ] Every L3 row names an oracle the agent cannot edit; otherwise it is L2
[ ] Every row's CREDENTIALS HELD reaches no further than its LEVEL; otherwise
    record the higher level and fix the credential or the review first
[ ] No row exceeds its RISK CEILING; no irreversible task is scored L4
[ ] Coding is at most one level above the lower of Review and Testing
    (a heuristic, not a law)

Agent instruction file

Use this when a repository first takes delegated agent work. It is the minimal, human-written starting file recommended in Chapter 6, Coding, where the evidence is mixed: generated or generic files cost tokens without raising success, and short, specific files written by a person make runs faster and cheaper. The sections follow the include list in Anthropic's Claude Code best practices: commands the agent cannot guess, non-default style rules, test runners, repository etiquette, project-specific architectural decisions, environment quirks and gotchas. Its editing test is in the header. The boundary tiers come from GitHub's review of more than 2,500 agents.md files: "Always do", "Ask first" and "Never do". Prose is advisory. A rule that must hold goes in a hook or a CI check, as the coding guardrails explain. The wiki compares the file formats in AGENTS.md vs CLAUDE.md vs Cursor rules vs agent skills.

# AGENTS.md   (or CLAUDE.md, .github/copilot-instructions.md)
# Written and maintained by a person. Owner: [name]. Reviewed: [date].
# Test every line: would removing it cause the agent to make mistakes?
# If not, cut it. No file-by-file description of the codebase.
# Anything that MUST hold belongs in a hook, lint rule or CI check, not here.

## Commands the agent cannot guess
- Build:            [command]
- Run all tests:    [command]
- Run one test:     [command]
- Lint and format:  [command]

## Style that differs from the language default
- [rule]

## Testing
- Test runner and where tests live: [path]
- Done means: [check that must pass before the agent stops]

## Decisions that constrain everyday code
- [rule, one line]  (reason: ADR-[n])

## Repository etiquette
- Branch names: [pattern]
- PR description must include: [what changed, why, how it was verified]
- Attribution: [label or trailer], per the provenance policy

## Environment quirks and gotchas
- [quirk]

## Boundaries
Always do:  [run the tests before finishing]
Ask first:  [new dependency] [schema change] [public API change]
Never do:   edit tests, CI config, hooks or this file to make a check pass;
            downgrade a dependency to make a build pass;
            read or use production credentials;
            [repository-specific item]

Spec template

Use this for a named, recurring task type that is too big to describe in one sentence. It is the fixed spec shape called for in Chapter 5, Requirements, Specs & Design. The middle sections follow Anthropic's description of the most useful specs, which "name the files and interfaces involved, state what is out of scope, and end with an end-to-end verification step that proves the feature works". The size gate at the top is the same guidance's rule for planning: "If you could describe the diff in one sentence, skip the plan." Acceptance criteria may be written in EARS notation, "WHEN [condition/event] THE SYSTEM SHALL [expected behavior]" (Kiro docs, as of October 2026). Two lines carry the level. The approval line is the L2 evidence. The rule that the implementing agent may not edit the acceptance criteria or the verification step is the oracle principle applied to specs. The wiki's spec-driven agent development playbook covers the tools.

SPEC: [feature name]                               ID: [spec-id]   Version: [n]
Task type: [named recurring type]
Size gate: can the diff be described in one sentence?  YES = no spec, stop here.
Drafted by: [person | agent + tool]       Owner: [person]
APPROVED BY: [name]   DATE: [date]        (no implementation before this line)

1. Problem and user
   [who needs what, and why now]

2. Acceptance criteria (testable; EARS optional)
   AC-1  WHEN [condition/event] THE SYSTEM SHALL [expected behaviour]
   AC-2  [...]

3. Files and interfaces involved
   [paths, APIs, schemas, events]

4. Decisions that apply (do not reopen)
   [ADR links]

5. Out of scope
   [what the agent must not build or change]

6. Questions raised while drafting, and their answers
   [all resolved before approval]

7. End-to-end verification step
   Proof the feature works: [command or test]
   Owned by: [person or team]   Agent may edit: NO (code owners / hook)

8. Changes after approval
   Any change to section 2 or 7 needs re-approval by: [name]

Review checklist

Use this for every human review of an agent-authored or AI-assisted change at L2, and for the changes that L3 routing still sends to a person. It collects the guardrails of Chapter 7, Code Review. Separation of duties comes from GitHub's Copilot cloud agent defaults, where the person who asked for the work cannot approve it (as of October 2026). The human-only design section exists because a review bot that "only has access to the code", as Uber says of uReview, cannot review a design. The oracle section exists because agents edit what they can reach: Elastic found its agent fixing failed version bumps by removing the bump (Elastic Search Labs, September 2025, T3; see CI/CD & Release). The last section feeds the "Not useful" ratio that the rollback-trigger sheet watches.

REVIEW CHECKLIST - agent-authored or AI-assisted change
PR: [link]   Task type: [type]   Risk tier: [tier] (rule: [rule id])

Before reading the diff
[ ] Attributed: label, trailer or agent account
[ ] Neither the author, the requester nor the authoring agent is an approver
[ ] Within the size cap ([n] lines); otherwise send back to be split
[ ] Linked spec or issue; acceptance criteria unchanged since approval
[ ] Required checks ran and passed: build, tests, static analysis, secret scan

What only a person reviews
[ ] Fits recorded design decisions (ADRs); no new architecture slipped in
[ ] Data model, compatibility and migration effects
[ ] Security-relevant paths: authentication, PII, crypto, input handling
[ ] Matches the intent of the spec, not just its letter

The oracle and the agent's controls
[ ] No test deleted, skipped or weakened; no assertion loosened
[ ] No dependency downgraded or check disabled to make a build pass
[ ] Changes to tests, CI config, hooks, or permission/MCP/rules files
    are routed to their human code owners
[ ] New dependencies exist, are in the lockfile and on the allow-list

AI reviewer findings
[ ] Each finding fixed, or dismissed with a reason
[ ] Wrong or noisy findings marked "Not useful"

Decision:  [ ] approve   [ ] request changes   [ ] route to full review
Reviewer: [name]   Minutes spent: [n]

Merge-Readiness Pack (evidence bundle)

Use this when a task type moves from L2 to L3 and a human stops reading every line. The pack is what they read instead. The name and the five criteria come from Hassan et al., who describe Merge-Readiness Packs (September 2025) as "structured evidence bundles submitted for human approval". It must show functional completeness, sound verification, exemplary software-engineering hygiene, a clear rationale and full auditability. It should also support "progressive disclosure", meaning a summary first and the evidence one level down. That paper is a conceptual proposal, not a measured practice. The fields are filled from Chapter 7, Code Review (the checks that ran, the AI reviewer's findings and their resolution, and the risk class and why), and from Chapter 11, Maintenance & Migrations (verifier log, diff summary, a sample of files). The wiki's note on decision receipts and audit covers keeping the record.

MERGE-READINESS PACK                      PR: [link]   Pack version: [n]
Task type: [type]   Risk class: [class]   Routed by rule: [rule id @ version]
Agent: [tool] [model + version]           Run log: [link]

0. SUMMARY (one screen; the reviewer starts here)
   What changed and why:          [3-5 lines]
   Approach and trade-offs:       [2-3 lines]
   Required checks:               ALL PASS / [failures]
   Oracle files touched by agent: NONE / [list = route to full review]

1. FUNCTIONAL COMPLETENESS
   Acceptance criteria from spec [id]:  AC-1 PASS  AC-2 PASS  [...]
   End-to-end verification:             [result + link]

2. SOUND VERIFICATION
   Verifiers run outside the agent's control: [list + log link]
   Tests added or changed: [list]   Tests removed or skipped: NONE / [list]
   Coverage or mutation-score change (if tracked): [value]

3. HYGIENE
   Static analysis, lint, secret scan, dependency check: [links]
   New dependencies: NONE / [list, each on the allow-list]

4. AI REVIEW
   Findings: [n]   Fixed: [n]   Dismissed with reason: [n]

5. AUDITABILITY (frozen links)
   Spec version | instruction-file commit | tool config | agent run log
   CI rounds: [n]   Retries: [n]

6. FLEET CHANGES ONLY
   Files in change: [n]   Files sampled by a person: [n] (chosen by [rule])

Human decision: [ ] approve  [ ] return   By: [name]   Date: [date]
Selected for audit sample: [ ] yes  [ ] no

Provenance policy

Use this before AI-assisted work reaches a shared repository: without attribution no phase can score above L1. It comes from Chapter 15, Scaling Across Teams, which sets out the three governance camps open-source projects have taken: ban, presumed tainted, and allow with disclosure. This template takes the third, after the Linux kernel's AI coding-assistants guide (as of October 2026, docs for 7.3.0-rc7). That guide states: "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)." It makes the human submitter responsible for "Reviewing all AI-generated code", for licence compliance, for adding their own sign-off and for "Taking full responsibility for the contribution". Its tag format is Assisted-by: LLM [TOOL1] [TOOL2], and it says "Basic development tools (git, gcc, make, editors) should not be listed." The format is still moving: the linux-next copy of the same page had no attribution section when read in October 2026. Two parts are the book's proposal, not kernel policy: naming the agent and model in the trailer, so metrics can be computed per tool, and a rule for who signs an L3 change no human typed. Licensing status is dated in Appendix B, Regulatory and Licensing Status.

PROVENANCE POLICY      Version: [n]   Owner: [name]   Effective: [date]

1. STANCE
   AI assistance is:  [ ] prohibited   [ ] allowed with disclosure
   Repositories covered: [list]    Excluded, with reason: [list]

2. DISCLOSURE
   Every commit made with AI assistance carries a trailer:
       Assisted-by: [agent]:[model-version] [TOOL1] [TOOL2]
   Do not list basic development tools (git, compiler, make, editor).
   Agent-authored pull requests also carry the label: [label]

3. SIGN-OFF AND APPROVAL ARE HUMAN-ONLY
   An agent never adds Signed-off-by, never approves a pull request,
   and never appears in CODEOWNERS.
   The human who signs off has reviewed the AI-generated code,
   checked licence compliance, and takes full responsibility.

4. WHO SIGNS A CHANGE NO HUMAN TYPED (L3 and above)
   The person who approves its Merge-Readiness Pack: [role]
   The person who started the agent run is accountable for its scope.

5. RECORDS
   Trailers, labels, agent run logs and approval logs kept for: [period]

6. REVIEW
   Next review of this policy: [date]
   Licensing and regulatory status checked against: [source, date]

Permission-envelope checklist

Use this before granting a level, and whenever an agent's tool, token or hosting changes. It turns the rows of the permission envelope in Chapter 12, Security, Permissions & Blast Radius, into checks. That envelope is itself the book's proposal, built from vendor defaults, incident fixes and the CSA and AWS control frameworks, and no organisation has published incident rates by permission level. Tick the rows for the level you claim plus the "all levels" rows. The result line is the authority rule as a calculation.

PERMISSION-ENVELOPE CHECKLIST
Agent/tool: [name]   Task class: [type]   Level claimed: [L2 / L3 / L4]
Checked against the running system by: [name]   Date: [date]

WHERE IT RUNS
 L2  [ ] Developer machine; permission prompts on; bypass and auto
         modes disabled in managed settings
 L3  [ ] Ephemeral sandbox, devbox or CI runner with filesystem AND
         network isolation
 L4  [ ] As L3, plus continuous monitoring and a kill switch
         (last tested: [date])

CREDENTIALS
     [ ] Inventory: every token the agent can reach, and what it reaches
 L2  [ ] No production credentials on the machine; secrets outside workspace
 L3  [ ] Short-lived, task-scoped, injected by a proxy, never in the sandbox
 L4  [ ] A narrow service identity for this class; no general cloud/API token

WRITE SCOPE
 L2  [ ] Workspace only; a human approves every commit
 L3  [ ] Own branch; cannot merge or approve; CI waits for human review
 L4  [ ] Auto-merges or acts only for the enumerated class, behind a
         verifier it cannot edit

NETWORK
 L2  [ ] Allow-list for package registries and documentation
 L3+ [ ] Default-deny egress plus an allow-list

IRREVERSIBLE ACTIONS
 L2  [ ] Never performed by the agent
 L3  [ ] Agent prepares the plan or migration; a human executes it
 L4  [ ] Only through APIs with undo or soft delete; backups outside the
         blast radius. If not, this class is NOT eligible for L4

UNTRUSTED INPUT (issues, web pages, tool and MCP output)
 L3  [ ] Agents Rule of Two: drops sensitive access OR external state change
 L4  [ ] Never untrusted input + sensitive access + state change together

ALL LEVELS
     [ ] Agent cannot write its permission, MCP or rules files; they sit
         under human code-owner review (sandbox-enforced at L3+)
     [ ] Lockfile and registry allow-list; unknown packages rejected
         (enforced in CI from L3)
     [ ] Gate - L2: human review + static analysis + secret scan
                L3: evidence bundle + human review of the PR
                L4: verification record per change + audit log + kill switch

RESULT
 Highest level that any row actually permits: [Ln]
 If above the level claimed, that IS the level. Fix before climbing.

Pilot scorecard

Use this for the pilot planned in Chapter 14, The 90-Day Pilot: one phase, one task type, a verifier, a baseline and a stop rule agreed before day one. The readiness block puts the environment ahead of the model. In dotnet/runtime, pull requests created after the team fixed the agent's environment succeeded 69% of the time, against 38.1% before (Microsoft .NET team, March 2026, T2; see Case Studies). Success rate uses that team's definition: merged divided by merged plus closed. Every flow line has a stability line beneath it. The cost line is the cost-per-merged-change model from Economics, Risk and Measurement, including reviewer time. The excluded list is there because a pilot judged on pull-request count can look like a success while effective output barely moves (the pilot that looked like a success). Thresholds are blank on purpose: set them from your baseline before the pilot starts.

90-DAY PILOT SCORECARD
Phase: [phase]   Task type: [one type]   Climb: L[n] to L[n+1]
Verifier (oracle): [check]   Who can edit it: [humans only - name the owners]
Owner: [name]   Start: [date]   Reviews: day 30 / day 60 / day 90
Baseline: [window before the pilot]   Comparison group: [same class, human-made]

READINESS (all ticked before day 1)
[ ] Agent runs in its real environment: builds, packages, network (tested [date])
[ ] Instruction file written by a person
[ ] Every agent change attributed
[ ] Permission-envelope checklist passed for the target level
[ ] Rollback-trigger sheet signed by: [name]

                                      Baseline  Day 30  Day 60  Day 90  Threshold
FLOW
 Success rate: merged/(merged+closed)
 Lead time to merge
 Review wait time
 Review active time
STABILITY (pairs with the flow lines)
 Reverts per merged change
 Escaped defects or incidents
 Rework: changed again within [n] days
 Human co-commit (rescue) share
COST
 Cost per merged change, incl. reviewer time
CONTEXT ONLY (never a success criterion)
 Engineers who used it at least once

NOT SUCCESS CRITERIA: self-reported speed-up; % of code written by AI;
pull-request count on its own.
Judge instruction-file, model or harness changes on several runs, never one.

DAY-90 DECISION:  [ ] climb   [ ] hold   [ ] roll back
Reason: [one paragraph]   Signed: [name]   Date: [date]

Rollback-trigger sheet

Write this before the pilot, and keep it for as long as the level is held. It belongs to Chapter 17, Measuring Success and When to Roll Back. No company has published rollback criteria for an AI coding agent, so the sheet is built on two precedents from other domains. Google's Tricorder tracks "Please fix" against "Not useful" clicks on each static analyser: "If the ratio for an analyzer goes above 10%, the Tricorder team disables the analyzer until the author(s) improve it" (Sadowski et al., CACM 2018, T2). Every row copies that shape: a signal, a threshold fixed in advance, an action. Google's SRE agents add the automatic level downgrade and the stop control. An L3 request facing "an elevated risk score or an anomalous production state" falls to L2 and goes to a human, and a "Red Button" can "pause all in-flight agentic actions" (Google SRE, undated, accessed October 2026, T3; see Operations & Incidents). NIST's AI RMF (NIST AI 100-1, MANAGE 2.4, January 2023) asks for assigned responsibilities and mechanisms "to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use"; the owner line meets it. Tricorder's 10% is a starting value from static analysis, not a validated number for AI.

ROLLBACK-TRIGGER SHEET            Signed before the pilot by: [name]  [date]
Phase / task type: [type]   Current level: L[n]   Falls back to: L[n-1]
Owner who acts on a trigger: [name]   Deputy: [name]
Stop control: [how every agent action is paused]   Last exercised: [date]

ID  SIGNAL                         THRESHOLD (fixed now)  WINDOW   ACTION
T1  "Not useful" rate on AI        above [10%] per        [2 wk]   disable that category
    review comments                category                        until fixed
T2  Reverts of agent changes       above baseline + [x]   [30 d]   back to 100% human review
T3  Escaped defect or incident     any of severity [n]    -        stop the class; level
    traced to an agent change      or worse                        down; postmortem
T4  Change failure rate (phase)    above baseline + [x]   [30 d]   level down
T5  Review wait time               above baseline x [n]   [2 wk]   throttle generation to
                                                                   review capacity
T6  Merges with no review          any rise               [1 wk]   freeze automatic routing
T7  Risk score or anomalous        automatic              live     request falls to L2;
    production state (ops)                                         page a human
T8  Envelope drift: a credential   any                    audit    revoke; re-score the row
    or setting above the level
T9  Cost per merged change         above [budget]         [1 mo]   cap usage; review the case

Re-climb only after: the fix ships, [n] clean days pass, the owner signs.
Log every firing: date | trigger | action taken | by whom | outcome