AI-Native SDLC — Anthropic Playbook

An AI-native software development lifecycle you can actually run — six stages, one committed Markdown artifact per stage, and a human approval gate at every handoff. Packaged as a Claude Code plugin, this repository turns Anthropic's AI-Native SDLC playbook into something a team installs, not just something they read.

A person called that change low-risk, so it skipped the intent and spec stages. Then the agent reached for REVIEW.md — the file that defines what it may touch — and a hook stopped it. That is the whole idea: a declaration buys fewer stages, never fewer boundaries.

Reproduce it in a throwaway repository, no plugin install needed:

export GATE="$PWD/plugins/ai-sdlc/hooks/artifact-gate.sh"
source docs/demo-setup.sh
gate README.md    # exit 0
gate REVIEW.md    # exit 2

Agents generate, investigate, implement, and verify. Humans approve the decisions that need judgment. Git records who asked, what the agent produced, and who approved it.

The name describes the method this implements — Anthropic's AI-Native SDLC playbook.
This is an independent community implementation, not an Anthropic product, and is
neither affiliated with nor endorsed by Anthropic.

What is an AI-native SDLC?

An AI-native SDLC is a software development lifecycle designed around the fact that code generation is no longer the bottleneck. When an agent can implement a well-specified change in minutes, the constraint moves to the steps on either side of Build: deciding what to build, applying policy, verifying the result, reviewing it, authorizing release, and learning from production.

Traditional SDLC models move work between roles — analyst to designer to engineer to QA to ops. An AI-native SDLC replaces those role handoffs with an artifact loop. Each stage emits one version-controlled, human-readable, machine-executable Markdown file, committed beside the application code. The human does not write the artifact; the human accepts it. The repository becomes the audit trail.

This is sometimes called agentic SDLC, AI-driven SDLC, or spec-driven development. The distinguishing property here is not the Markdown — it is that every handoff stops at a gate an agent cannot open by itself.

The six stages

Stage 6 feeds Stage 1. That is the loop.

Two subagents serve it: sdlc-reviewer reviews the plan in Stage 3, runs the REVIEW.md passes in Stage 5, and verifies a finding is real before it is posted; sdlc-diagnostician turns a control-band breach into a draft intent.md in Stage 6.

A change a person declares low-risk takes the fast path: it enters at Build, skipping Stage 1 and Stage 2 and nothing else. The agent checks that declaration against the sensitive-path list in REVIEW.md and refuses it when the change reaches one — REVIEW.md is itself on that list, so the list cannot be emptied on the fast path. The artifact gate enforces the refusal, and Stage 5 re-checks the real diff, because a declared file list is a claim about work not yet done.

Review rounds are capped at three and recorded in .sdlc/<slug>/review-findings.md. After the first round the reviewer sees only the new diff, never reports a finding it already posted, and reports a defect at several call sites once, as a class. At the cap it stops and sends the change back to its plan: rounds that keep finding more mean the approach is wrong, not that the review is working.

Install

Works on Claude Code and Codex. Both read the same plugin directory — the six
stage skills, the hooks, and the artifact templates are shared; only the manifest and the
subagent format differ, and both are shipped.

A marketplace source can be a GitHub repo, a URL, or a local path, so a clone installs
the same way the published repo does.

Claude Code

From GitHub, in an interactive session:

/plugin marketplace add ghiaog123/ai-native-sdlc
/plugin install ai-sdlc@ai-native-sdlc

From GitHub, in the terminal — works everywhere, including surfaces where the /plugin
dialog is unavailable:

claude plugin marketplace add ghiaog123/ai-native-sdlc

claude plugin install ai-sdlc@ai-native-sdlc --scope user

From a local clone, when you are changing the plugin itself:

claude plugin marketplace add ./ai-native-sdlc

To try it for one session only, without installing anything:

claude --plugin-dir ./ai-native-sdlc/plugins/ai-sdlc

ai-sdlc is the plugin; ai-native-sdlc is the marketplace it comes from. Installs are
stored under ~/.claude/plugins/, shared by the CLI and the desktop app, so installing
once covers both. Pull in later edits with claude plugin marketplace update ai-native-sdlc.

Codex

From GitHub:

codex plugin marketplace add ghiaog123/ai-native-sdlc --ref main

codex plugin add ai-sdlc@ai-native-sdlc

The source argument also takes owner/repo@ref, an HTTPS Git URL, or an SSH Git URL, so
codex plugin marketplace add [email protected]:ghiaog123/ai-native-sdlc.git works too. Add
--sparse .claude-plugin --sparse plugins to skip the docs and examples on checkout.

Pull in later changes with:

codex plugin marketplace upgrade ai-native-sdlc

That command only works for a Git marketplace. A marketplace added from a local path has
no revision to upgrade to — re-add it instead.

From a local clone, when you are changing the plugin itself:

codex plugin marketplace add ./ai-native-sdlc

Codex reads plugins/ai-sdlc/.codex-plugin/plugin.json, which points at the same
skills/, the same hook scripts through hooks/hooks.codex.json, and the agents/*.toml
subagent definitions. Nothing needs converting.

One difference matters. Codex requires a one-time trust grant before plugin hooks run,
and only the interactive Codex TUI can give it. Until you grant it there, the plugin's
skills and subagents work but the gates are advisory — the enforcement layer is off. Check
the plugin's hook state in the Codex TUI plugin menu after installing. Do not reach for
--dangerously-bypass-hook-trust to skip this; the trust prompt is the thing that makes a
hook safe to run.

Project memory also differs: Codex reads AGENTS.md, Claude Code reads CLAUDE.md.
ai-sdlc-init detects which the project uses and writes the same content to both when
both apply, from one template, so they cannot drift.

Read the next section before you install — this plugin registers hooks.

What installing this changes on your machine

Read this before installing. This plugin ships hooks, and hooks run automatically.

Once the plugin is enabled, four hooks are registered for every session (immediately on
Claude Code; on Codex after you grant hook trust in its TUI):

Every one of them exits silently and immediately in a repository that has no .sdlc/ directory. That is the opt-in switch, and it is verified behavior, not an intention: installing this plugin does not change how Claude Code behaves in any repository where you have not run /ai-sdlc-init.

In a repository that has opted in, expect the gates to actually stop you. That is the point, and there are three escape hatches:

• .sdlc/OPTOUT — silences every hook for that repository, permanently, no other change needed.
• AI_SDLC_ALLOW_PROD=1 — authorizes one production command after a human has approved it.
• /plugin uninstall ai-sdlc (Claude Code) or codex plugin remove ai-sdlc@ai-native-sdlc (Codex) — removes the hooks entirely.

Each block message names the rule that matched and the escape hatch, so a blocked action is never a mystery.

Quickstart

From the repository you want to run the lifecycle in:

/ai-sdlc-init

This scaffolds .sdlc/, writes a real CLAUDE.md for that project by inspecting its build, test, and lint commands, and copies the REVIEW.md and bands.yaml policy templates.

Then just describe the problem. No workflow keyword is needed; sdlc-plan picks it up:

Customers keep calling support to ask where their claim is.
We should show them the status themselves.

The loop writes .sdlc/<slug>/intent.md and pauses for acceptance. After you accept, it writes spec.md, then plan.md, then implements and verifies the change — stopping at every gate. It never treats its own output as human approval.

Check where any change sits at any time:

/ai-sdlc-status

Stays on after install

Skill auto-triggering is probabilistic. Persistence here does not rely on it — four layers keep the lifecycle asserted, strongest first:

The ON switch is a single directory. /ai-sdlc-init creates .sdlc/, and that one act enables the lifecycle permanently for that repository. Every hook exits silently in repositories without it, so installing this plugin cannot change behavior in unrelated projects. .sdlc/OPTOUT is the OFF switch.

Stage state is derived, never stored — it is computed from which artifacts exist and what git says about them, so there is no state file to go stale.

How it compares

Spec-driven development tools are mature for the front half of the lifecycle. This repository exists because the back half — verification, review policy, release authorization, and production feedback — is where the playbook's real claims live, and it is the part almost nothing implements.

FAQ

What does AI-native SDLC mean in practice?

Every stage produces one Markdown artifact that is committed to git and accepted by a named human before the next stage starts. intent.md → spec.md → plan.md → PR → production → band breach → the next intent.md.

Does this let an AI agent deploy to production?

No. The sdlc-deploy skill is explicitly forbidden from merging or deploying, and Stage 6 proposes fixes through a pull request rather than applying one.

prod-guard.sh adds a second, weaker line: it catches the common shapes of deploy and teardown commands and requires explicit human authorization. Be clear about what that is worth — it is a speed bump, not a security boundary. A caller who spells a deploy differently will get past any regex. IAM permissions, deployment approvals, and branch protection remain the real controls, and this hook is not a reason to relax them.

How is this different from spec-driven development?

Spec-driven development covers writing a spec and planning from it. This covers the full lifecycle including verification evidence, a review policy the agent must obey, release authorization, and monitoring that files the next intent when a service drifts.

What are evals here, and why do they matter?

Evals are regression tests for the agent configuration rather than the code. When CLAUDE.md, a skill, or a hook changes, the eval suite re-runs — because a configuration change can silently degrade agent behavior with no failing unit test to show for it.

Will installing this plugin affect my other repositories?

No. Every hook checks for a .sdlc/ directory first and exits silently without one. This is verified behavior, not an intention.

Does it work with Codex, or only Claude Code?

Both. The plugin ships a Claude Code manifest and a Codex manifest side by side, and the
skills, hook scripts, and templates are shared verbatim. The two differences are handled
for you: subagents ship in .md (Claude Code) and .toml (Codex), and project memory is
written to CLAUDE.md or AGENTS.md as the harness requires. The one thing you must do
yourself on Codex is grant hook trust in its TUI, without which the gates are advisory.

For any other agent, the methodology in docs/PLAYBOOK.md is
tool-neutral and the artifact templates are plain Markdown.

Can I use my existing Jira or ServiceNow workflow?

Yes. Those can remain the system of record as long as commits link both ways. The artifacts are the decision trail, not a replacement tracker.

Repository map

.
├── README.md
├── docs/
│   ├── loop.svg          # The six-stage loop diagram
│   ├── PLAYBOOK.md       # Stage-by-stage operating model and artifact contract
│   ├── GOVERNANCE.md     # Enforceable controls and threat model
│   ├── METRICS.md        # Process health signals and how to compute them
│   └── ADOPTION.md       # Three-phase rollout
├── examples/rate-limit/  # One change walked through all six stages
├── plugins/ai-sdlc/
│   ├── .claude-plugin/   # Plugin manifest
│   ├── .codex-plugin/    # Codex plugin manifest
│   ├── skills/           # Six stage procedures plus ai-sdlc-init and ai-sdlc-status
│   ├── agents/           # sdlc-reviewer, sdlc-diagnostician (.md for Claude, .toml for Codex)
│   ├── hooks/            # Artifact gate, production guard, state, session context, and their checks
│   └── templates/        # intent, spec, plan, review-findings, CLAUDE, REVIEW, bands, settings
└── .claude-plugin/       # Marketplace catalog

Documentation

• Playbook — the thesis, the loop, artifact templates, ownership, and gates.
• Governance — the controls that make policy executable, and the threat model behind them.
• Metrics — leading and lagging indicators, how to compute them, and how each gets gamed.
• Adoption — a rollout from one volunteer to the organization, and the failure modes on the way.

What this is not

• Not permission for an agent to merge, approve, or deploy its own work.
• Not a replacement for product judgment, code ownership, incident command, or regulatory accountability.
• Not a new system of record forced on every team.
• Not a promise that Markdown makes weak requirements good — artifacts help only when reviewers reject ambiguity.
• Not a scorecard for ranking developers by agent usage, output, or speed.
• Not a reason to remove deterministic tests, static analysis, branch protection, sandboxing, or rollback practice.

Start with the artifacts, prove that the gates improve decisions, and automate only the paths the team can explain and audit.

Credits

Method: The AI-Native SDLC playbook, Anthropic Applied AI. This repository is an independent implementation and is not affiliated with or endorsed by Anthropic.

Licensed under the MIT License.