SDLC automation templates for AI agents: a catalog of what you can automate and govern
A catalog of SDLC automation templates for AI agents: what each agent automates at the plan, design, build, test, review, release and operate stages, the guardrail that scopes it, and the evidence it leaves behind.
Every stage of the software lifecycle has a short list of jobs an AI agent can run on its own: triage, estimation, codebase mapping, ticket-to-PR implementation, test writing, review, release notes, production diagnosis. Each job needs two things around it: a guardrail that says what the agent may not do, and evidence that proves what it did. This catalog draws on the SDLC workflow library behind our assessments, the SDLC policy template and agent kit of fourteen reference agents that compile to the Statio SDK, and its agentic-sdlc-agent-kit.zip download: starting points, not production configuration.
Guardrails are external to the agent: Lyra sequence policies evaluated in the hook of every tool and model call by Alyria Beacon, monitor mode first, one record per prompt, tool call, file touch, decision and approval in the audit chain, exportable per our audit export. The governance post covers the stages and what governance means at each; here, the templates.
Plan
| Template | The agent automates | Guardrail | Evidence |
|---|---|---|---|
| Requirements analysis | Turns a brief into testable requirements with a risk read. | Implementation does not run before its acceptance criteria are reviewed; the agent cannot self-approve them. | The requirement and risk list linked to the brief. |
| Bug triage | Labels, de-duplicates and routes every incoming bug report the moment it files. | Read-only outside label and owner fields. Pages run only under the escalation rule for that severity. | Triage decision per issue: labels, duplicate target, routing. |
| Effort estimator | Sizes tickets as they enter the backlog, calibrated on similar completed work. | Estimates are advisory: no date or plan changes without the product owner. | Estimate with confidence and the calibration tickets. |
| Feedback ingestion | Files and updates backlog items from approved support channels. | After ingesting feedback, do not allow off-channel or redacted sources into tickets. | Each ticket linked to its sources. |
Design
| Template | The agent automates | Guardrail | Evidence |
|---|---|---|---|
| Codebase mapper | Regenerates architecture docs and module graphs on every merge. | Read-only over code and history; writes only to the docs it owns. | Doc and graph diff, pinned to the merged commit. |
| Architecture reviewer | Reviews each new design doc or RFC on open, posting structured feedback. | Advisory comments. High impact findings need a human to accept or reject. | The review, bound to the RFC revision it read. |
| Design and threat model | Turns requirements into a secure design and threat model before code exists. | A start gate: implementation does not run until the threat model exists and is reviewed. | The threat model, linked from the ticket. |
Build
| Template | The agent automates | Guardrail | Evidence |
|---|---|---|---|
| Ticket to PR | Implements a ticket marked ready end to end and opens a draft PR. | After the ready state, pushes run only in that repo and branch. Merge keeps human review. | Draft PR, ticket-to-diff mapping, each model and tool call. |
| Chat and issue bots | Starts an agent from a Slack mention or comment and reports back in-thread. | Authenticate the requester. Thread context cannot grant permissions the requester lacks. | The trigger, the run and what was posted back. |
| Security test writer | Covers the security and auth layers with unit and integration tests. | A gate until the security suite passes. The agent cannot weaken or skip assertions. | Suite results bound to the exact revision. |
| Dependency audit | Keeps versions pinned, current and free of known advisories, without grabbing latest. | After an advisory or license check fails, the upgrade does not merge. | Versions, advisories checked, files updated, test outcome. |
The native control you can start with today
For the ticket-to-PR template running in Claude Code, permission rules in ~/.claude/settings.json, per-project .claude/settings.json, or org managed-settings.json are the concrete guardrail:
{
"permissions": {
"deny": [
"Bash(git push:*)",
"Read(./.env)",
"Read(./.env.*)"
]
}
}
The rules cut narrower than they look: the permission docs say command patterns are not a security boundary, so Bash(git push:*) stops pushes typed as git push ..., not git -C . push origin main. The two ./.env patterns cover only the built-in Read and Edit tools on those literal paths per the coverage limits, not a Python or Node subprocess reading them or a differently named secret. For bypass forms, the sandbox enforces the OS-level complement: it restricts shell commands and their child processes, with sandbox.filesystem.denyRead for credential paths. Deny rules apply immediately from any settings level, managed-settings.json keeps them fleet-wide, and sandbox.* settings enforce from user or managed scope. What none of it tracks is the run: whether the push's code was reviewed as this task's sequence requires, what the agent read earlier, or who signed off. That judgment, cross-vendor inventory, and the evidence chain are what Alyria Beacon and its Lyra policies add.
Test
| Template | The agent automates | Guardrail | Evidence |
|---|---|---|---|
| Bug reproducer | Attaches a failing test or cannot-reproduce note to every new bug. | Test environment only; a differing environment is recorded as a limit, not a claim. | The failing test or the documented limit. |
| Test coverage expander | Opens PRs that add tests to under-tested code. | Test-only PRs. Product code changes are out of scope; weak assertions fail review. | The gap found and assertions added, per PR. |
| E2E test runner | Runs Playwright journeys and attaches video and trace to the PR. | No video and trace attached, no pass. | Video, trace and result per journey. |
| QA automator | Starts the app, exercises the changed behavior and posts a verdict per PR. | Verdicts are pass, fail or blocked with evidence; environment trouble is blocked, never pass. | The report with the revision and environment tested. |
| Load tester | Runs load tests on a schedule or before each release and flags regressions. | Approved non-production targets and resource caps. Rerun only after a baseline comparison is recorded. | Baseline versus observed numbers and the verdict. |
Review
| Template | The agent automates | Guardrail | Evidence |
|---|---|---|---|
| Code review | Leaves inline review on every PR open and update. | Advisory. A human approval still gates merge, and findings bind to the revision they covered. | Findings with revision and the checks that passed. |
| Secure code review | An independent security review of the diff, on a different model than the author. | A merge gate for changes touching auth, secrets or unsafe execution. Findings block, not suggest. | Findings, the model that found them, each block resolved. |
| Adversarial security | Tries to break the change with a concrete exploit or failing case. | Same gate and rule: no agent reviews a change it authored. | The attempt or its failure, with repro steps. |
| Completion gate | Adversarially proves the change is not done; passes only when it cannot. | A hard gate. Failure stops the pipeline. | The decision listing each step satisfied or missing. |
| PR risk assessment | Classifies the change's risk tier from checked-in rules and code signals. | The tier is computed, not chosen. New rules invalidate previously accepted tiers. | The tier with the signals behind it. |
| Human review router | Routes each change to the right reviewer, or auto-clears low-risk tiers. | Approvals scope to the risky action, not the whole task. | The routing or auto-clear decision with its tier. |
Release
| Template | The agent automates | Guardrail | Evidence |
|---|---|---|---|
| Merge closer | Confirms every gate passed and the evidence is complete, then merges or holds. | Merge denied while any gate record is stale for the current revision. | The decision and the evidence package it relied on. |
| Deployment monitor | Watches rollouts against baselines, alerts and proposes rollback on drift. | Rollback runs only under explicit approvals and stop conditions, never in a loop. | The comparison, the alert, the rollback decision. |
| Release notes | Generates notes whenever a release is tagged. | Publication needs a disclosure approval; notes distinguish shipped from merely merged. | Notes pinned to the shipped tag. |
| Docs sync | Opens doc-update PRs for doc-impacting merges. | Normal review. Claims are checked against actual behavior. | Each doc PR linked to its merge. |
Operate
| Template | The agent automates | Guardrail | Evidence |
|---|---|---|---|
| Log monitor | Watches production logs, summarizes patterns and files issues. | Redaction before anything leaves the tenant. Recurring patterns deduplicate into one issue. | The summary and issues filed, with sources. |
| Anomaly detector | Scans metrics on a schedule, detects drift and opens tickets with analysis. | Maintenance windows are recorded, not flagged. Baseline updates backtest the prior window. | Baseline, detection and backtest results. |
| Error resolver | Diagnoses new production errors from tracker events and opens fix PRs. | No production write access. The fix ships as a reviewed PR like any other. | Diagnosis, fix PR, the first release carrying it. |
Sequence state makes cheap checks smarter
Most guardrails are history rules, not permissions: a sequence policy says what may not follow what (no push after unreviewed web-search code), tracked cheaply in the hook. Worked examples are on the semantic policy examples page; the hook-fast versus boundary split is the gates post.
Picking where to start
The kit compiles the same set from 01-analysis.md through 14-dependency-audit.md plus the flow.md fourteen-agent pipeline graph; gate and review agents run on a different engine than the author. Starting five: ticket to PR, code review, secure code review, the completion gate, dependency audit. Run risky templates in monitor mode first, enforce when the evidence supports it, and add scoped human approvals where the guardrail is not enough. The evidence chain itself is the evidence post.
FAQ
Do these templates require a particular coding agent?
No. Templates are agent-neutral; the kit routes per agent by engine, model and cloud, covering Claude Code, Codex or whatever your team runs.
Can I copy the policies verbatim? The "After X, do not allow Y" phrasing maps to rules evaluated on run history; start from the examples page and tighten from recorded decisions.
Do we need all of it? No. Dependency audit and review gates pay off everywhere; the rest pay off by workload.