A Claude Code plugin for running software projects through a PDLC lifecycle. It adds skills to bootstrap new projects, add apps or services to existing ones, adopt legacy code, generate API mocks, and write architecture docs. Completion is checked by exit codes, not by the AI's claim.
Claude Code
> /plugin marketplace add kanfu-panda/pdlc-skills> /plugin install pdlc@pdlc-skills
Codex
$ npx skills add kanfu-panda/pdlc-skills -a codex
Cursor
$ npx skills add kanfu-panda/pdlc-skills -a cursor
Gemini CLI
$ npx skills add kanfu-panda/pdlc-skills -a gemini-cli
GitHub Copilot
$ copilot plugin marketplace add kanfu-panda/pdlc-skills$ copilot plugin install pdlc@pdlc-skills
OpenCode
$ npx skills add kanfu-panda/pdlc-skills -a opencode
Windsurf
$ npx skills add kanfu-panda/pdlc-skills -a windsurf
English · 中文
Author: kanfu-panda Repo: github.com/kanfu-panda/pdlc-skills License: MIT
pdlc-skills is built on one rule: an AI saying "done" doesn't count — exit codes do. It's a set of skills — a plugin in Claude Code, and a one-command install in Codex, GitHub Copilot, Cursor, Gemini CLI and any other tool that loads the Agent Skills standard — shipping a staged PDLC (Product Development Life Cycle) workflow — PRD → design → TDD → implement → review → ship → deploy → retro — on top of an auditable, on-disk state machine: every stage persists its artifacts to docs/, updates a per-feature state file, demands red tests before code, self-checks before handing off, and auto-repairs at most once.
Four things fall out of that:
git diff exactly what the AI did.tdd → implement → review to convergence unattended, each step in a fresh process, with fail-stop, stuck-stop, and budget guards.npx skills add kanfu-panda/pdlc-skills and drive the same methodology. See Multi-platform.Without this plugin, an AI assistant working on a feature typically:
PDLC turns those soft conventions into hard contracts:
| Hard contract | What it gives you |
|---|---|
Every artifact lands on disk under docs/ | You can git diff what the AI did |
| Every stage updates a per-feature state machine | /pdlc-status always knows where you are |
| Tests must exist (and fail) before implementation | Real TDD red-light gate, not a suggestion |
| Each stage runs a self-check before handing off | Catch drift at stage boundary, not in review |
| Auto-repair runs at most once | No infinite "fix → check → fix" loops |
Each stage declares its next_step | Multi-stage flows are command-driven, not memorized |
A typical AI workflow kit is prompts plus templates: it asks the model to write tests first and report honestly, then trusts that it did. pdlc-skills assumes the model will sometimes not comply, and checks at three layers:
| Layer | Who decides | What it catches |
|---|---|---|
| Checks in the state machine | pdlc-checks.sh runs the commands in your docs/00_standards/test-commands.yml and maps their exit codes to tests_pass / coverage_pass / lint_clean. Three-state: a command that couldn't run is null — never false, never true | The model reporting "all tests pass" when they don't |
| State transitions | A stage can only close through pdlc-advance.sh: it runs that stage's checks itself and refuses to advance when they're red; it also refuses when the tests written in tdd were changed during implementation (unless a reason is given, which lands in auto_decisions). In Claude Code an opt-in project guard also blocks writing state files directly | Advancing a stage whose checks failed; editing the tests to get green |
| State contract check | pdlc-state-lint.sh runs right after every stage writes its state file (and before any command reads one) | Missing fields, unknown stage names, a stage other than ship / deploy writing _done |
| Behavioural evals | evals/ runs real skills against real models (Claude Code and Codex) in throwaway fixtures, each built so the honest outcome and the lazy one look different | The model ignoring the skill's instructions — e.g. copying the schema example and claiming every check green, or writing code before a red test |
The deterministic parts — the scripts above, the loop driver, the installer — are covered by the plugin's own local test suite. Evals cost model turns, so they run before a release rather than in CI, and they are advisory, not a release gate. Scenarios, and how each one tells honest from lazy: evals/EVALS.md.
| Typical prompt-based workflow | pdlc-skills | |
|---|---|---|
| Who decides "tests pass" | The model's own report | Real exit codes |
| Where progress lives | The chat, or a free-form notes file | A machine-readable state file per feature, contract-checked on every write |
| How far it goes | Usually up to code review | Through ship, deploy, retro, and a quality report a human signs off |
| Unattended runs | Within one session | An external driver: fresh process per step, parallel git worktrees, budget / fail / stuck stops |
| Is the workflow itself tested | Rarely against real models | Behavioural evals on both Claude Code and Codex |
The trade-off is structure: 38 commands and a docs/ layout are more than a single-entry kit asks of you. Layer 1 (/pdlc-feature, /pdlc-fix, /pdlc-status) is all you need to start, and /pdlc-feature --lite skips the task breakdown, PRD review and design for small features — tests-first, exit-code checks and code review still apply.
A typical end-to-end flow looks like this:
$ # In Claude Code:
$ /pdlc-feature add phone-number verification to user login
→ Allocating feature ID F20260502-090000 (user-auth-phone)
→ Stage 1: writing PRD
✓ docs/01_requirements/prd/F20260502-090000-user-auth-phone-prd.md
✓ self-check 8/8 passed
→ Stage 2: technical design
✓ docs/02_design/api/F20260502-090000-user-auth-phone-api.md
✓ docs/02_design/database/F20260502-090000-user-auth-phone-db.md
→ Stage 3: TDD red light
✓ 14 tests written, all failing as expected
→ Stage 4: implementation
✓ 14/14 tests now passing
→ Stage 5: code review + auto-repair
✓ 3 lint issues auto-fixed
✓ docs/07_reviews/code/F20260502-090000-user-auth-phone-review.md
→ Stage 6: handoff
📦 docs/.pdlc-state/F20260502-090000.json updated
👉 Next: /pdlc-ship
Every artifact above is a real file you can git diff. Run /pdlc-status any time to see where each feature stands. (Output above is illustrative — actual Claude Code output is markdown, not ASCII.)
One-liner — no manual clone needed.
# Global (~/.claude/plugins/pdlc/)
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh \
| bash -s -- --global
# Project-scoped (<project>/.claude/plugins/pdlc/)
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh \
| bash -s -- --project /path/to/my-project
That's it. The installer is a thin wrapper around claude plugin marketplace add + claude plugin install: it registers the marketplace source and installs the plugin into your .claude/plugins/pdlc/ directory.
Not on Claude Code? Jump to Multi-platform — it's one command there too.
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh \
| bash -s -- --upgrade --global
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh \
| bash -s -- --uninstall --global
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh \
| bash -s -- --version
If you'd rather call Claude Code's plugin CLI directly:
claude plugin marketplace add kanfu-panda/pdlc-skills
claude plugin install pdlc@pdlc-skills
git clone https://github.com/kanfu-panda/pdlc-skills.git
cd pdlc-skills
# edit references/templates/*.md or skills/pdlc-*/SKILL.md
python3 adapters/sync_skills.py # copy shared fragments / templates / scripts into each skill folder
bash install.sh --global # installs from your local clone
claude plugin list | grep pdlc
# expected: pdlc@pdlc-skills Version: 1.7.17 (or newer) Status: ✔ enabled
In Claude Code (after restarting the session), type / and start typing pdlc- — you should see all 38 sub-commands (/pdlc-feature, /pdlc-prd, /pdlc-tdd, ...) in autocomplete.
Claude Code has the richest integration — 38 slash commands + statusline + in-plugin autonomous loop. But the PDLC methodology, state machine and templates are platform-neutral: the same docs/.pdlc-state/ carries over no matter which tool drives it, so you can switch tools (or share a repo across a team on different tools) without losing PDLC state.
Most AI coding tools now load the Agent Skills open standard. pdlc builds one standard-conformant projection of its skills (36 of them — all but the 2 Claude Code-only ones; every one passes the official skills-ref validator) and installs it wherever your tool looks. Two ways, neither needs a clone:
# ① the generic installer: pick which tools to install into (Codex, Copilot, Cursor, Gemini CLI, OpenCode, … dozens)
npx skills add kanfu-panda/pdlc-skills
# ② this repo's installer: installs the standard projection above (needs python3)
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh \
| bash -s -- --target agents # ~/.agents/skills/ (Copilot, Gemini CLI, OpenCode, Amp, Goose)
# --target agents --project DIR # DIR/.agents/skills/
# --target agents --dest DIR # any tool's own directory, e.g. .cursor/skills, ~/.gemini/config/skills (Antigravity CLI)
# --target codex # ~/.codex/skills/
# add --uninstall to remove; only pdlc-* directories are ever written or removed
The difference: ① installs the skills exactly as they are in the repo (the frontmatter carries Claude Code's argument hint, and the argument line in the body is a $ARGUMENTS placeholder) — on GitHub Copilot CLI 1.0.88 it triggers and reads the arguments correctly; ② installs the standard projection, with the argument line rewritten and a trigger hint added, and passes the official validator. If unsure, use ①. Claude Code users: install the plugin, not ① — otherwise you get a second copy of every skill.
Stars on GitHub
A development methodology for coding agents that makes the agent brainstorm before building, follow plans, run parallel work and finish branches in a disciplined way. You get fewer skipped steps and more consistent results from your coding assistant.
@obraHelps you take a change from a rough idea or bug report through to a tested, reviewed result, with each step handled by a focused skill. Its skills cover pinning down domain terms, designing module interfaces, diagnosing hard bugs, and reviewing changes against your repo's coding standards.
@mattpocockGives your coding agent a planning, testing and review routine to follow on every task. It plans before building, checks changes with tests, has a fresh reviewer look for regressions, and saves repeated wins as reusable skills.
@affaan-mDeveloper tools for working on the React codebase itself. Provides skills for extracting error messages, managing and debugging feature flags across release channels, running Flow type checks, and fixing lint and formatting issues before committing.
@facebookInstall it with the command on its page. It includes pdlc-add-app, pdlc-add-service, pdlc-adopt. Its skills do not fire on their own yet. Free and open source.
Is this plugin yours?
Claim it with GitHubSubmit a pluginPromote it