SDLC Audit

Static audit of a repo's development workflow against the twenty practices named in Anthropic's "The AI-Native SDLC Playbook" (claude.com/blog/the-ai-native-sdlc-playbook), producing a per-practice Covered | Partial | Gap rating with file:line evidence.

A process audit, not a code or security audit. It does not overlap ai-audit (AI-specific security surfaces in the system's own code) or repo-audit (uniqueness, philosophy coherence, docs, code quality). This checks whether the workflow that builds the repo — planning, review, testing, deployment, maintenance — matches the playbook's practices. Run from the target repo's directory; it reads that repo, never canon's own skills.

Operating constraints

• Static analysis only. Read config, docs, and history. Never run pipelines, trigger a deploy, or call an external service.
• Evidence, not inference. Every Covered or Partial rating cites a file:line (or a named file if line-level doesn't apply, e.g. "present in .github/workflows/"). A rating with no evidence is a Gap, not a guess. This applies even to a practice checking for the absence of something (e.g. an external tracker) — cite the specific file/convention that establishes the absence as deliberate (a README statement, a CONTRIBUTING.md note), not a bare narrative claim like "git is the only system observed." No named artifact to cite means the rating is Gap.
• No numeric score. Report per-practice ratings and one tally, never a percentage or letter grade — a single number hides which stage is weak.
• Scope is the dev workflow, not the product. Do not audit the application's own runtime behavior, security posture, or code quality — those are ai-audit and repo-audit's jobs.

Before auditing

Read these, stop once you can rate every practice:

1. CLAUDE.md / AGENTS.md (or equivalent agent-instructions file) — conventions, standards, recurring-mistake notes
2. .claude/settings.json (or equivalent hook/guardrail config) — build-time guardrails
3. CI/CD config (.github/workflows/, .gitlab-ci.yml, or equivalent) — automated gates, PR review automation, eval/regression jobs
4. A skills/prompts/playbooks directory if one exists — institutional knowledge encoded for reuse
5. Ticket or issue conventions (a tickets/-style dir, PR template, or issue template) — what artifact captures intent and acceptance criteria before code
6. 2–3 recent merged PRs or commits — do commits reference a ticket/plan? Is there review evidence?

If the repo has none of these (no CLAUDE.md, no CI, no ticket convention), say so explicitly and rate every practice Gap rather than inferring good practice from absence of evidence.

The twenty practices

Grouped by the playbook's own six SDLC stages, plus core principles and cross-cutting practices that apply throughout. Check for a Covered (documented + enforced), Partial (present but informal — documented without enforcement, or enforced without being written down), or Gap (no evidence) signal for each.

Core principles

1. Loop, not linear pipeline — Is there a repeatable unit of work (ticket, issue, task) that cycles through plan → build → review → close, rather than a single linear release process?
2. Committed artifacts chain the audit trail — Does each stage leave a version-controlled file the next stage reads (a plan doc, a spec, review notes), with commits traceable back to the originating ticket/issue?
3. Humans stay accountable for judgment — Are there explicit approval points (branch protection, required review, a defined go/no-go step) before code merges or ships?

Plan (stage 1)

4. Capture as intent — Is there a lightweight pre-spec artifact (a written problem statement, RFC, or issue description) captured before formal requirements, distinct from the eventual implementation plan?

Design (stage 2)

5. Spec reviewed by policy owners before engineering — Is there a design/requirements doc reviewed by a non-engineering stakeholder (security, compliance, product) before implementation starts, or does design happen inside the same pass as coding?

Build (stage 3)

6. Plan committed before code, diff checked against it — Is an implementation plan written and committed (or otherwise persisted) before code changes, in a form the eventual diff can be checked against?
7. Agent-instructions file — Does CLAUDE.md/AGENTS.md (or equivalent) document build/test/ lint commands, architecture, and known recurring mistakes, kept current?
8. Institutional knowledge as reusable, versioned units — Are standards/conventions (security rules, API design, brand/style guides) captured in reusable files agents or engineers load, not just tribal knowledge?
9. Build-time guardrails — Are there enforced hooks/checks that block risky actions deterministically (protected-path edits, auto-format/lint, credential stripping) rather than relying on instructions alone?
10. Parallel isolated work — Is there a mechanism for multiple in-flight changes to proceed without colliding (worktrees, isolated branches/environments, scoped subagents/helpers)?

Test (stage 4)

11. Self-verification against a quantifiable target — Does the workflow give the implementer (human or agent) a concrete pass/fail check to run before handoff, rather than relying on reviewer discovery?
12. Continuous evals/regression suite in CI — Is there an automated regression suite that runs on relevant changes (not just unit tests — a suite that would catch a workflow/config regression), gating merge?

Deploy (stage 5)

13. AI or automated review in the PR loop — Does an automated pass (bot, bundled review tool, CI check) review PRs for bugs/security/compliance with ranked findings, separate from human review?
14. Named-approver gates, logged — Do deploy/release actions require a specific approver (not just "someone approved"), with the decision timestamped/logged?
15. Non-interactive CI/CD with scoped credentials and environment tiers — Does deployment run non-interactively with least-privilege credentials, and are autonomy/permissions different across dev/staging/production?

Maintain (stage 6)

16. Deterministic monitoring triggers diagnosis — Is there a monitoring signal (alert, metric threshold) that automatically kicks off a defined response, rather than purely manual incident discovery?
17. Recurring scheduled scans — Do security/quality scans run on a standing schedule (cron, scheduled workflow), not only reactively per-PR?

Cross-cutting

18. Repo-first source of truth — Is the repo (git) the canonical record, with any external tracker (Jira, etc.) a mirror or reference rather than the primary source?
19. Four governance layers present — Advisory (docs/standards), deterministic (hooks/CI gates), human-approval (review/branch protection), audit-trail (commit history/logs) — are all four distinguishable in the repo, or does everything collapse into one ("just ask for review")?
20. Named leading/lagging metrics — Does the team track and name specific process metrics (time to first artifact, eval pass rate, rework cycles, defect escape rate), or is process health judged informally?

Report format

Write the report inline and to critique/sdlc-audit.md in the repo under analysis, replacing prior contents. First line is the local DateTime the audit ran:

Audit run: MM-DD-YYYY hh:mm AM/PM

Audit run: MM-DD-YYYY hh:mm AM/PM

## SDLC Audit: <repo-name>

### Core principles
1. Loop, not linear pipeline — [Covered|Partial|Gap] — <file:line evidence or "no evidence found">
2. Committed artifacts chain the audit trail — [Covered|Partial|Gap] — <evidence>
3. Humans stay accountable for judgment — [Covered|Partial|Gap] — <evidence>

### Plan
4. Capture as intent — [Covered|Partial|Gap] — <evidence>

### Design
5. Spec reviewed by policy owners before engineering — [Covered|Partial|Gap] — <evidence>

### Build
6. Plan committed before code, diff checked against it — [Covered|Partial|Gap] — <evidence>
7. Agent-instructions file — [Covered|Partial|Gap] — <evidence>
8. Institutional knowledge as reusable, versioned units — [Covered|Partial|Gap] — <evidence>
9. Build-time guardrails — [Covered|Partial|Gap] — <evidence>
10. Parallel isolated work — [Covered|Partial|Gap] — <evidence>

### Test
11. Self-verification against a quantifiable target — [Covered|Partial|Gap] — <evidence>
12. Continuous evals/regression suite in CI — [Covered|Partial|Gap] — <evidence>

### Deploy
13. AI or automated review in the PR loop — [Covered|Partial|Gap] — <evidence>
14. Named-approver gates, logged — [Covered|Partial|Gap] — <evidence>
15. Non-interactive CI/CD, scoped credentials, environment tiers — [Covered|Partial|Gap] — <evidence>

### Maintain
16. Deterministic monitoring triggers diagnosis — [Covered|Partial|Gap] — <evidence>
17. Recurring scheduled scans — [Covered|Partial|Gap] — <evidence>

### Cross-cutting
18. Repo-first source of truth — [Covered|Partial|Gap] — <evidence>
19. Four governance layers present — [Covered|Partial|Gap] — <evidence>
20. Named leading/lagging metrics — [Covered|Partial|Gap] — <evidence>

### Summary
Tally: <n> Covered / <n> Partial / <n> Gap
Strongest stage: <stage> — <one sentence why>
Weakest stage: <stage> — <one sentence why>
Top priority: <the single highest-leverage practice to add next, and why>

Omit no rows — every one of the twenty practices gets a rating, even if it's Gap with "no evidence found". A missing row is a silent skip; a Gap row is an honest finding.