Worked Examples

Golden, end-to-end outputs of the skill pipeline — real artifacts you can read to see what each skill produces and how they chain together. Skills describe how to produce an artifact; these examples show what a good one looks like.

dark-mode-toggle/ — one feature, the whole pipeline

A small but non-trivial feature (a persisted, OS-aware dark mode for a fictional “Notes” web app) carried through every step of the build lifecycle. Each artifact is the kind of output its skill would generate, and each links to the next.

Step	Skill	Artifact
1. PRD	idea-to-prd	dark-mode-toggle/prd.md
2. Design	prd-to-design	dark-mode-toggle/design.md
3. Decisions (architecture)	prd-to-design	dark-mode-toggle/adr/0001-theme-persistence.md
4. Tasks	design-to-tasks	dark-mode-toggle/tasks.md
5. Decisions (implementation)	tasks-to-code	dark-mode-toggle/decisions.md
6. Review	code-review	dark-mode-toggle/review.md
7. Release	release-checklist	dark-mode-toggle/release-checklist.md
8. Retro	plan-retrospective	dark-mode-toggle/retro.md

idea-to-prd → prd-to-design → design-to-tasks → tasks-to-code → code-review → release-checklist → plan-retrospective
   prd.md        design.md         tasks.md        decisions.md    review.md    release-checklist.md      retro.md
                 adr/0001-*.md                                                                            (then archive)

security-review-remediation/ — an audit, entering the pipeline sideways

The complementary path: instead of starting from an idea, work starts from a security-review of a fictional invoicing API (“Ledgerline”). The audit emits its findings as a PRD — each finding is an FR-N with a severity mapped to priority (🔴 → P0, 🟡 → P1, ⚪ → P2) — so it enters the pipeline directly at design-to-tasks, skipping idea-to-prd and prd-to-design entirely. Unlike dark-mode-toggle/, this plan is shown mid-flight: Phase 1 (Critical findings) is complete, Phase 2 is in progress, so you can see the status markers doing real work.

Step	Skill	Artifact
1. Findings PRD	security-review	security-review-remediation/prd.md
2. Tasks	design-to-tasks	security-review-remediation/tasks.md
3. Decisions (implementation)	tasks-to-code	security-review-remediation/decisions.md

security-review → design-to-tasks → tasks-to-code
  prd.md            tasks.md          decisions.md
 (findings)        (remediation)      (in progress)

How to read it

Start with the PRD and follow the links forward. The thread to watch: requirement labels (FR-5, NFR-2, US-1, …) are assigned in the PRD and stay traceable all the way to the retro’s coverage table. One real bug — a flash of the wrong theme — is introduced, caught in the review, explained in decisions.md, and turned into a lesson in the retro.

The labels, status markers ([ ] / [~] / [x] / [!] / [-]), severities, and the plans/ layout these artifacts use are defined once in the shared conventions.

Where these live in a real project

In an actual repo, a plan’s artifacts live in plans/<feature>/ while the work is active, and plan-retrospective moves the folder to plans/archive/<feature>/ at close-out. This example flattens the whole lifecycle into one folder so you can browse every artifact — active and closed — side by side.