project-lifecycle
English · 简体中文
Project Life Cycle helps teams turn ad-hoc AI coding sessions into repeatable, verifiable, traceable software development processes.
A Claude Code skill that enforces a traceable, multi-phase software project workflow — driven by 3 slash commands (/init-harness → /ship → /release) and a 10-step per-phase / 6-step per-task discipline. One skill, every project, same contract.
Everything is MD-canonical and git-traceable: specs, plans, user stories, journals, handoffs, PR bodies, CHANGELOG live as markdown in docs/ + repo root. No hidden state.
What changed? → CHANGELOG.md (Keep a Changelog 1.1.0). How to contribute? → CONTRIBUTING.md. Releases? → GitHub Releases (auto-generated from CHANGELOG + PR labels; cut via /release).
TL;DR — the 3-command lifecycle
flowchart LR
A["/init-harness<br/>day 0 · 4 checkpoints<br/><i>stack · folder-map ·<br/>policy+handlers · commit</i>"]
B["Day 1<br/>codebase Q&A<br/><i>no edits</i>"]
C["/ship feature<br/>day 2..N · 3 checkpoints<br/><i>story · spec · PR<br/>repeat per feature</i>"]
D["/release<br/>1 checkpoint<br/><i>SemVer auto-bump<br/>→ GitHub Release</i>"]
CL[("CHANGELOG.md<br/>[Unreleased]<br/>accumulates per PR")]
A --> B --> C --> D
C -. appends .-> CL
CL -. consumed by .-> D
style A fill:#dbeafe,stroke:#1d4ed8,stroke-width:2px,color:#0c4a6e
style C fill:#dbeafe,stroke:#1d4ed8,stroke-width:2px,color:#0c4a6e
style D fill:#dbeafe,stroke:#1d4ed8,stroke-width:2px,color:#0c4a6e
style B fill:#fef3c7,stroke:#d97706,stroke-width:1px,color:#7c2d12
style CL fill:#f3f4f6,stroke:#6b7280,color:#374151
/init-harness — bootstrap a fresh / existing project. Detects stack, generates CLAUDE.md + folder-map + policy keys + .claude/commands/ + .claude/handlers/ scaffolds. Idempotent; merges into existing files. Run once per project./ship <feature> — ship one user-observable feature end-to-end. Chains researcher → story → spec → BE-builder → FE-builder → acceptance verifier → validator → fix loop → PR. Run N times across the milestone./release — cut a SemVer release. Computes bump from CHANGELOG.md [Unreleased], renames the section, bumps both .claude-plugin/ manifests, validates, commits, tags, pushes, verifies GitHub Release. Run when [Unreleased] has accumulated enough user-visible content./builder-profile (opt-in, auxiliary — not part of the core pipeline) — read your own local Claude Code transcripts and write a markdown snapshot of how you actually use an AI coding agent to ~/.claude/builder-profile.md. 100% local (no upload). Gated pipeline: deterministic stats → evidence gate → cold-read → adversarial verify → independent verification. Default descriptive — a mirror (operating modes, signature moves, honest about what couldn't be measured), not a score card; 1-10 scores only behind --scores. Independent of /init-harness → /ship → /release.
Between commands: every PR updates [Unreleased] + carries one category label + uses a Conventional Commits title (see CONTRIBUTING.md). The Validator (cadence step 2, read-only) catches builder lies; the Acceptance Verifier (cadence step 1.5) writes one test per AC; deterministic handlers (.claude/handlers/) inject auth / secrets / pre-flight lint / migration safety before the LLM ever sees them.
The workflow is bounded by two gates. Entry: every fresh request passes the intent-gate front door (references/intent-gate.md) — classify → confirm intent → reframe a fuzzy ask ("this is wrong, fix it") into a precise prompt with a named oracle, before any code. Exit: nothing is "done" until the deterministic close gate passes (references/close-gate.md) — task-done / phase-done checks the wrap-up artifacts actually exist (journal, fresh test evidence, handoff, CHANGELOG, smoke), enforced by a pre-push hook the model can't talk its way around.
Do I type the commands, or does Claude?
Short answer: you don't have to type anything to get the workflow. The project-lifecycle skill auto-loads when Claude detects relevant work, and Claude can run the full cadence inline. The slash commands are a convenience entry point, not a requirement.
