@minhduydev/mdpi 0.3.0

package/dist/template/.pi/prompts/plan.md

@@ -0,0 +1,254 @@
+---
+description: Create detailed implementation plan with TDD steps
+argument-hint: "[--level 0-3] [--dry-run] [--help]"
+---
+
+# Plan
+
+Create a detailed implementation plan with TDD steps. Optional deep-planning between `/create` and `/ship`.
+
+> **Workflow:** `/create` → **`/plan`** (optional) → `/ship`
+>
+> **When to use:** Complex tasks where spec verification steps aren't enough guidance. Skip for simple tasks.
+
+## Parse Arguments
+
+| Argument    | Default | Description                               |
+| ----------- | ------- | ----------------------------------------- |
+| `--level`   | auto    | Force discovery level: 0 (skip), 1 (quick), 2 (standard), 3 (deep) |
+| `--dry-run` | false   | Preview plan without writing to disk       |
+| `--help`    | false   | Show this usage                           |
+
+## Guard Phase
+
+Before planning:
+- Verify `.pi/artifacts/$(cat .pi/artifacts/.active)/spec.md` exists (if not, tell user to run `/create` first)
+- If `plan.md` already exists, ask user: overwrite or skip?
+- If `tasks.json` already exists (from a prior `/plan` run), read it to understand existing task structure — avoid re-decomposing
+
+## Load Skills
+
+| Skill | When | Why |
+|-------|------|-----|
+| `planning-and-task-breakdown` | Always | Goal-backward methodology, dependency graphing, wave assignment |
+| `context-engineering` | Always | Context budget management — plans target ~50% context per execution |
+| `test-driven-development` | Always | Structure tasks as RED-GREEN-REFACTOR steps |
+| `incremental-implementation` | Always | Thin vertical slice discipline — each task is verify-after-each |
+| `subagent-driven-development` | Multi-wave plan | Plan tasks for fresh subagent dispatch per task |
+| `source-driven-development` | Level 1-3 | Ground decisions in official docs when researching dependencies |
+
+## Phase 0: Institutional Research (Mandatory)
+
+### Step 1: Search institutional memory
+
+Use `vcc_recall` to search for bugfixes and existing plans. If relevant observations found, incorporate them.
+
+### Step 2: Mine git history
+
+```bash
+git log --oneline -20
+git log --oneline --follow -- <relevant-file-path>
+git log --oneline --all | head -30
+```
+
+Look for: commit conventions, recent changes (merge conflict risk), similar features, footgun zones.
+
+### Step 3: Spawn learnings-researcher (Level 2-3 work)
+
+```typescript
+subagent({
+  agent: "explore",
+  prompt: "Search the codebase for patterns, conventions, and existing implementations related to: [FEATURE]. Return: existing patterns to follow, files to be aware of, and any gotchas."
+});
+```
+
+## Phase 1: Discovery Assessment
+
+Determine discovery level (same Level 0-3 taxonomy as `/create`):
+
+| Level | Name | Scope | Action |
+|-------|------|-------|--------|
+| **0** | Skip | Pure internal work, existing patterns only | Skip external research |
+| **1** | Quick | Single known library (~30 sec) | `context7` resolve + query |
+| **2** | Standard | Choosing between 2-3 options (~1 min) | Spawn `scout` subagent for research |
+| **3** | Deep | Architectural decision (~2 min) | Full research with parallel `scout` subagents |
+
+Force with `--level N` flag. Default: auto-detect from spec complexity.
+
+## Phase 2: Research (Level 1-3)
+
+Spawn parallel agents:
+
+| Agent     | Purpose                                                              |
+| --------- | -------------------------------------------------------------------- |
+| `explore` | Codebase patterns, affected file structure, test patterns, conflicts |
+| `scout`   | External best practices, common patterns, pitfalls                   |
+
+## Phase 3: Goal-Backward Analysis
+
+Load `planning-and-task-breakdown` skill. Follow its methodology:
+
+**Step 1: Extract Goal from PRD** — outcome-shaped, not task-shaped.
+
+**Step 2: Derive Observable Truths** — 3-7 truths from USER's perspective.
+
+**Step 3: Derive Required Artifacts** — for each truth, what must EXIST.
+
+**Step 4: Identify Key Links** — critical connections where breakage causes cascading failures.
+
+## Phase 4: Decompose with Context Budget
+
+Load `context-engineering` skill. Target ~50% context per execution.
+
+| Task Complexity | Max Tasks | Context/Task | Total |
+|------------------|-----------|--------------|-------|
+| Simple (CRUD)    | 3         | ~10-15%      | ~30-45% |
+| Complex (auth)   | 2         | ~20-30%      | ~40-50% |
+| Very complex     | 1-2       | ~30-40%      | ~30-50% |
+
+## Phase 5: Dependency Graph & Wave Assignment
+
+For each task, record:
+- `needs`: What must exist before this runs
+- `creates`: What this produces
+- `has_checkpoint`: Requires user interaction?
+
+Build wave analysis for parallel execution. Reference `subagent-driven-development` skill for task formats compatible with subagent dispatch.
+
+## Phase 6: Write Plan
+
+Write `.pi/artifacts/$SLUG/plan.md`:
+
+```markdown
+# [Feature] Implementation Plan
+
+**Goal:** [Outcome-shaped goal from PRD]
+**Discovery Level:** [0-3]
+**Context Budget:** [Estimated context usage, target ~50%]
+
+## Must-Haves
+
+### Observable Truths
+1. [Truth 1]
+2. [Truth 2]
+...
+
+### Required Artifacts
+| Artifact | Provides | Path |
+|----------|----------|------|
+...
+
+### Key Links
+| From | To | Via | Risk |
+...
+
+## Dependency Graph
+
+Task A: needs nothing, creates src/models/X.ts
+Task B: needs Task A, creates src/api/X.ts
+
+Wave 1: A
+Wave 2: B
+
+## Tasks
+[Task definitions with TDD steps]
+```
+
+After writing `plan.md`, derive the runtime `tasks.json` from it and write to `.pi/artifacts/$SLUG/tasks.json`:
+
+```json
+{
+  "slug": "<slug>",
+  "title": "<title>",
+  "tasks": [
+    {
+      "id": "task-1",
+      "description": "...",
+      "files": ["src/path.ts"],
+      "depends_on": [],
+      "verification": ["npm run typecheck", "npm test -- path"],
+      "tdd": false,
+      "checkpoint": null
+    }
+  ]
+}
+```
+
+`plan.md` remains the **authoritative** decomposition; `tasks.json` is the runtime mirror consumed by `/ship`. Keep them in sync.
+
+### Task Standards
+
+- **Exact file paths** — never "add to the relevant file"
+- **Complete code** — never "add validation logic here"
+- **Exact commands with expected output**
+- **TDD order** — test first, then implementation (per `test-driven-development` skill)
+- **Each step is 2-5 minutes** — one action per step
+- **UI state coverage** — empty/loading/error/success states when applicable
+- **Thin vertical slices** — per `incremental-implementation` skill
+
+Use `.pi/templates/tasks.md` as the body template for the `## Tasks` section (task IDs, YAML metadata blocks, verification bullets).
+
+## Phase 7: Constitutional Compliance Gate
+
+Scan plan against AGENTS.md hard constraints:
+
+| Violation Pattern                                 | AGENTS.md Rule                              | Severity     |
+| ------------------------------------------------- | ------------------------------------------- | ------------ |
+| `git add .` or `git add -A`                       | Multi-Agent Safety: stage specific files    | **CRITICAL** |
+| `--force` push or `force push`                    | Git Safety: never force push main           | **CRITICAL** |
+| `--no-verify`                                     | Git Safety: never bypass hooks              | **CRITICAL** |
+| `as any` or `@ts-ignore` without justification    | Quality Bar: strong typing                  | **WARNING**  |
+| New package/dependency without approval step      | Guardrails: no new deps without approval    | **WARNING**  |
+| `reset --hard` or `checkout .` or `clean -fd`     | Git Restore: never without explicit request | **CRITICAL** |
+| Secret/credential patterns                        | Security: never expose credentials          | **CRITICAL** |
+
+### Violation Response
+
+| Severity     | Action                                                             |
+| ------------ | ------------------------------------------------------------------ |
+| **CRITICAL** | Stop. Remove violation from plan. Report to user.                  |
+| **WARNING**  | Flag in plan output. Add confirmation checkpoint to affected task. |
+
+## Failure Handling
+
+| Scenario | Action |
+|----------|--------|
+| Plan already exists | Ask user: overwrite or skip? |
+| Missing spec artifact | Report: "No spec found. Run `/create` first." |
+| Subagent research fails | Retry once with adjusted prompt, then proceed with existing knowledge |
+| Verification fails 2x | Stop, report blocker with file:line evidence |
+
+## Stop Conditions
+
+- Spec artifact missing → stop, tell user: run `/create` first
+- Plan already exists → ask user before overwriting
+- Constitutional violation found (CRITICAL) → remove violation from plan, report to user
+- Verification fails 2x on same approach → stop, escalate
+
+## Phase 8: Report
+
+1. **Discovery Level:** [0-3] with rationale
+2. **Must-Haves:** [N] observable truths, [M] required artifacts, [K] key links
+3. **Context Budget:** [Estimated usage]
+4. **Dependency Waves:** [N] waves for parallel execution
+5. **Task count:** [N] tasks, [M] TDD steps
+6. **Files affected:** [List]
+7. **Plan location:** `.pi/artifacts/$SLUG/plan.md`
+8. **Next step:** `/ship`
+
+## Related Commands
+
+| Need           | Command      |
+| -------------- | ------------ |
+| Create spec    | `/create`    |
+| Execute plan   | `/ship`      |
+| Research first | `/research`  |
+
+## Related Skills
+
+- `planning-and-task-breakdown` — goal-backward decomposition, dependency graphing (Phases 3-5)
+- `context-engineering` — context budget management (Phases 0, 4)
+- `test-driven-development` — RED-GREEN-REFACTOR task structuring (Phase 6)
+- `incremental-implementation` — thin vertical slice discipline (Phase 6)
+- `subagent-driven-development` — task format for subagent dispatch (Phase 5)
+- `source-driven-development` — doc-backed research (Phase 2)

package/dist/template/.pi/prompts/research.md

@@ -0,0 +1,136 @@
+---
+description: Research a topic before implementation
+argument-hint: "<topic> [--quick|--thorough] [--dry-run] [--help]"
+---
+
+# Research: $ARGUMENTS
+
+Gather information before implementation. Find answers, document findings, stop when done.
+
+> Research can happen at any phase when you need external information or codebase understanding.
+
+## Parse Arguments
+
+| Argument      | Default  | Description                         |
+| ------------- | -------- | ----------------------------------- |
+| `<topic>`     | required | What to research                    |
+| `--quick`     | false    | ~10 tool calls, single question     |
+| `--thorough`  | false    | ~100+ calls, comprehensive analysis |
+| `--dry-run`   | false    | Report research plan without executing |
+| `--help`      | false    | Show this usage                     |
+
+Default depth: ~30 tool calls for moderate exploration. **Track call count and stop when you hit the depth budget** (`--quick` ≈10, default ≈30, `--thorough` ≈100+) — don't blow past it silently.
+
+## Guard Phase
+
+Before researching:
+- Check `.pi/artifacts/.active` — if active slug exists, write findings to `.pi/artifacts/$SLUG/research.md`
+- If no active slug, report findings inline
+- Assess complexity to choose Direct vs Workflow execution
+
+## Complexity Detection
+
+Before starting, analyze the research topic complexity:
+
+**Simple research** (execute directly):
+- Single factual question
+- One specific API or library
+- Narrow scope with clear boundaries
+
+**Complex research** (invoke workflow):
+- Multi-angle topic requiring cross-checking
+- Broad scope with multiple perspectives
+- Requires verification from multiple sources
+
+### Decision Logic
+
+1. **Parse the topic** from $ARGUMENTS
+2. **Assess complexity:**
+   - Contains "best practices", "compare", "approaches", "strategies" → Complex
+   - Contains "how does", "what is", "explain" → Simple
+   - Topic spans multiple domains or technologies → Complex
+3. **If ambiguous**, ask user: "Is this a quick look-up or deep investigation?"
+4. **Route accordingly:**
+   - Simple → Direct Execution (Phase 1-3)
+   - Complex → Workflow Execution (read `.pi/workflows/deep-research.md`)
+
+## Load Skills
+
+| Skill | When | Why |
+|-------|------|-----|
+| `source-driven-development` | Always | Ground findings in official docs, source code, and cited references |
+| `srcwalk` | Codebase research | Navigate codebase with repo maps, symbol search, callers/callees |
+| `opensrc` | Researching dependencies | Inspect library source for internal behavior |
+| `gemini-large-context` | Large codebase or multi-repo | Analyze beyond typical context limits |
+
+## Direct Execution (Simple Research)
+
+### Phase 1: Search
+
+Follow source priority:
+1. **Codebase patterns** — delegate via `subagent({ agent: "explore" })`. Never escalate to web if codebase has answer.
+2. **Official docs** — `context7` for API references
+3. **Real-world examples** — `codesearch` / `grepsearch`
+4. **Web search** — only if tiers 1-3 don't answer
+
+### Phase 2: Verify
+
+Cross-check findings:
+- Multiple authoritative sources agree → High confidence
+- Single good source, plausible but unverified → Medium confidence
+- Conflicting info, speculation → discard without corroboration
+
+### Phase 3: Synthesize
+
+If within active work, write findings to `.pi/artifacts/$SLUG/research.md`. Otherwise report inline.
+
+## Workflow Execution (Complex Research)
+
+**Announce:** "This is complex research requiring multi-angle analysis. Invoking deep-research workflow."
+
+1. Invoke the workflow:
+   ```
+   run_workflow({ name: "deep-research", args: { question: "<topic from $ARGUMENTS>" } })
+   ```
+2. The runner fans out `scout` agents per angle, then cross-checks with `review` agents, then synthesizes.
+3. Receive the synthesized cited report from the runner.
+
+## Stop Conditions
+
+- All questions answered with medium+ confidence → stop research, proceed
+- Tool budget exhausted for depth level → stop, report findings
+- Network/API repeatedly unavailable → stop, report partial results
+
+## Failure Handling
+
+| Scenario | Action |
+|----------|--------|
+| Subagent returns failure | Retry once with adjusted prompt, then escalate |
+| Network/API error | Cache findings so far, retry with degraded mode |
+| No results found | Report empty result set, suggest broader search terms |
+| Tool budget exhausted | Report findings so far, note what remains unexplored |
+
+## Output
+
+1. **Execution mode:** Direct or Workflow
+2. Depth level and tool call count (if direct)
+3. Questions with answer status and confidence
+4. Key insights (bullet points)
+5. Artifact location: `.pi/artifacts/$SLUG/research.md` (if active work) or inline
+6. Next step suggestion
+
+## Related Commands
+
+| Need           | Command      |
+| -------------- | ------------ |
+| Create spec    | `/create`    |
+| Plan details   | `/plan`      |
+| Ship feature   | `/ship`      |
+| Audit codebase | `/audit`     |
+
+## Related Skills
+
+- `source-driven-development` — doc-backed research methodology (all phases)
+- `srcwalk` — codebase symbol navigation and call tracing
+- `opensrc` — library source inspection for dependency research
+- `gemini-large-context` — large codebase analysis

package/dist/template/.pi/prompts/ship.md

@@ -0,0 +1,219 @@
+---
+description: Ship a plan - implement specs, verify, review, close
+argument-hint: "[--skip-review] [--dry-run] [--help]"
+---
+
+# Ship
+
+Execute spec tasks, verify each passes, run review, mark complete.
+
+> **Workflow:** `/create` → **`/ship`** (or `/create` → `/plan` → `/ship`)
+
+## Parse Arguments
+
+| Argument        | Default | Description                               |
+| --------------- | ------- | ----------------------------------------- |
+| `--skip-review` | false   | Skip Phase 5 review (low-risk changes only) |
+| `--dry-run`     | false   | Validate plan and preview execution without implementing |
+| `--help`        | false   | Show this usage                           |
+
+## Guard Phase
+
+Before shipping:
+- Use `vcc_recall` to search for failed approaches to avoid repeating
+- Verify `.pi/artifacts/$(cat .pi/artifacts/.active)/spec.md` exists (if not, tell user to run `/create` first)
+- If `plan.md` exists, verify it references the current spec
+- Workspace check: create branch if needed, install deps if needed
+
+## Load Skills
+
+| Skill | When | Why |
+|-------|------|-----|
+| `verification-before-completion` | Always | Evidence-before-claims; phantom detection; Worker Distrust Protocol |
+| `shipping-and-launch` | Always | Pre-ship checklist, rollback planning, handoff protocols |
+| `subagent-driven-development` | ≥2 independent tasks | Fresh subagent per task with review gates |
+| `test-driven-development` | Tasks marked `tdd: true` | RED-GREEN-REFACTOR workflow (delegate to subagents) |
+| `git-workflow-and-versioning` | After each task completes | Atomic commits, branch strategy, conventional commits |
+| `code-review-and-quality` | Phase 5 review | 5-axis review: correctness, readability, architecture, security, performance |
+| `doubt-driven-development` | High-risk features | In-flight adversarial review before merge |
+| `context-engineering` | Batch workflow (≥5 independent tasks) | Context budget management for parallel subagent handoffs |
+
+## Phase 1: Route to Execution
+
+### Complexity Detection
+
+**Direct execution** (sequential):
+- Plan has <5 tasks
+- Tasks have dependencies
+- Tasks edit overlapping files
+
+**Workflow execution** (parallel):
+- Plan has ≥5 independent tasks
+- No file conflicts between tasks
+
+### Decision Logic
+
+1. Read task list from `.pi/artifacts/$SLUG/tasks.json` (primary — produced by `/plan`). If `tasks.json` is absent, derive it on the fly from `.pi/artifacts/$SLUG/plan.md` (or the Lite PRD's task outline).
+2. Count independent tasks (no `depends_on`)
+3. Check for file conflicts (any shared files?)
+4. Route:
+   - <5 tasks OR has dependencies OR file conflicts → **Direct execution** (Phase 2)
+   - ≥5 independent AND no conflicts → **Workflow execution** (Phase 3)
+
+## Phase 2: Direct Execution (Sequential)
+
+Execute tasks one at a time, verifying each before proceeding.
+
+### Per-Task Loop
+
+For each task:
+
+1. **Read** the task description, verification steps, affected files
+2. **Read** affected files before editing
+3. **Implement** changes — stay within task's `files` list
+4. **Handle Deviations:** If the implementation reveals scope beyond the task, apply deviation rules:
+   - Rule 1: Trivial fix (<5 lines) in same file → fix inline, note in progress
+   - Rule 2: New small dependency discovered → implement, note
+   - Rule 3: Plan is wrong (task can't be done as specified) → report blocker
+   - Rule 4: Deviance exceeds 20% of task scope → stop, present options
+5. **Checkpoint Protocol:** If task has `checkpoint:*` type:
+
+   | Type | Action |
+   |------|--------|
+   | `checkpoint:human-verify` | Execute automation first, then pause for user verification |
+   | `checkpoint:decision` | Present options, wait for selection |
+   | `checkpoint:human-action` | Request specific action with verification command |
+
+6. **Verify** — run each verification step from the task
+7. **If verification fails**, fix and retry (max 2 attempts per task)
+8. **Commit** — load `git-workflow-and-versioning` skill, follow atomic commit protocol (NEVER `git add .`)
+9. **Mark** `passes: true` in tasks.json
+10. **Append** progress to `.pi/artifacts/$SLUG/progress.md`
+
+### TDD Tasks
+
+When task has `"tdd": true`, load `test-driven-development` skill. Subagents follow RED-GREEN-REFACTOR as defined in that skill. The orchestrating agent verifies the red-green cycle after each subagent returns.
+
+### Stop Conditions
+
+- Verification fails 2x on same task → stop, report blocker
+- Blocked by unfinished dependency → stop, report which one
+- Modifying files outside task scope → stop, ask user
+- Rule 4 deviation → stop, present options
+
+## Phase 3: Workflow Execution (Parallel)
+
+If routed to workflow mode:
+
+1. **Invoke the workflow:**
+   ```
+   run_workflow({ name: "batch-implement", args: { plan: "<plan from plan.md or tasks.json>" } })
+   ```
+2. The runner executes all phases (plan-review → implement → verify → merge) and handles placeholder substitution (`{plan}`, `{phase_N_output}`).
+3. Load `context-engineering` — ensures subagents receive focused context.
+
+**Announce:** "This plan has [N] independent tasks. Invoking batch-implement workflow for parallel execution."
+
+**Fallback:** If the batch workflow fails, fall back to Direct Execution (Phase 2).
+
+## Phase 4: Verification Gate
+
+**Delegate to `/verify` — do not duplicate the gate logic here.** Run the canonical verification protocol defined in `prompts/verify.md` (Phase 1 Completeness → Phase 2 Correctness → Phase 4 Phantom Detection). Concretely:
+
+1. Invoke `/verify all --full` semantics (or run the same steps inline if already mid-session): load `verification-before-completion`, run typecheck + lint + test gates, use **full mode** for shipping (incremental is for iteration only), record stamp to `.pi/artifacts/verify.log` after all gates pass, run phantom completion detection, and do goal-backward verification (observable truths from plan/spec satisfied).
+2. If any gate fails, stop and surface the failure exactly as `/verify` would (don't proceed to Phase 5).
+3. Treat `/verify`'s output as the authoritative result for this phase.
+
+**Why delegate:** `/verify` owns the gate definitions, the verification cache protocol, and phantom detection. Duplicating them here drifts over time. Ship is the consumer; verify is the source of truth for gates.
+
+## Phase 5: Review
+
+> Skip with `--skip-review` for low-risk changes.
+
+### Mode Selection
+
+| Condition | Mode |
+|-----------|------|
+| Routine change, low risk | **Standard Review** |
+| High-risk feature, explicit quality gating request | **Iterative Quality Loop** (`.pi/workflows/quality-loop.md`) |
+
+### Standard Review
+
+Spawn parallel `review` agents using `code-review-and-quality` skill's 5-axis methodology (security/correctness, performance/architecture, type-safety/tests, conventions/patterns, simplicity/completeness). Synthesize findings.
+
+**Budget guard:** Scale reviewer count to diff size — don't blindly spawn 5.
+
+| Changed files | Reviewers | Axes per reviewer |
+|--------------|-----------|------------------|
+| <10 | 2-3 | 2 axes each |
+| 10-30 | 3-4 | 1-2 axes each |
+| >30 | 5 | 1 axis each |
+
+Fewer reviewers on small diffs keeps context cost proportional.
+
+**Auto-fix rule:**
+- Critical issues → fix inline, re-run Phase 4, continue
+- Important issues → fix inline, continue
+- Minor issues → log to `.pi/artifacts/$SLUG/progress.md`
+
+### Iterative Quality Loop
+
+For high-risk features: run the score-gated review loop workflow:
+
+```bash
+SLUG=$(cat .pi/artifacts/.active)
+```
+
+1. Invoke the workflow:
+   ```
+   run_workflow({ name: "quality-loop", args: { slug: "$SLUG" } })
+   ```
+2. The runner initializes `review-state.json` and executes the loop (REVIEW → GATE → STALL CHECK → FILTER → FIX → RE-REVIEW) per the workflow.
+3. Exit when score ≥ 5/5 or escalate per workflow rules (stall / max rounds / architecture finding).
+
+## Phase 6: Close
+
+Ask user before closing. If confirmed:
+- Update `tasks.json` to mark all tasks complete
+- Append completion summary to `.pi/artifacts/$SLUG/progress.md`
+- Clear `.pi/artifacts/.active`
+
+## Failure Handling
+
+| Scenario | Action |
+|----------|--------|
+| Task verification fails 2x | Stop, report blocker with file:line evidence |
+| Subagent returns failure | Read error, retry once with adjusted prompt, then escalate |
+| Review finds critical issue | Fix inline, re-run Phase 4, continue |
+| Batch workflow failure | Fall back to sequential execution |
+| Missing `.active` slug | Report: "No active feature. Run `/create` first." |
+
+## Phase 7: Report
+
+1. **Execution Summary:** tasks completed/total, waves executed, commits made
+2. **Task Results:** per-task status, files modified, commit hashes
+3. **Verification Gate Results:** typecheck, lint, test, build — pass/fail
+4. **Goal-Backward:** artifacts verified (exists/substantive/wired), key links checked
+5. **Review Summary:** critical/important/minor issues, overall assessment
+6. **Next Steps:** Ask user if they want a PR created — always ask, never push without confirmation
+
+## Related Commands
+
+| Need           | Command      |
+| -------------- | ------------ |
+| Create feature | `/create`    |
+| Plan execution | `/plan`      |
+| Research topic | `/research`  |
+| Fix a bug      | `/fix`       |
+| Verify gates   | `/verify`    |
+
+## Related Skills
+
+- `verification-before-completion` — phantom detection, evidence gate, cache protocol (Phases 4-5)
+- `shipping-and-launch` — pre-ship checklist, rollback planning (Phases 4, 6)
+- `test-driven-development` — RED-GREEN-REFACTOR for TDD tasks (Phase 2)
+- `git-workflow-and-versioning` — atomic commit protocol (Phase 2)
+- `code-review-and-quality` — 5-axis review methodology (Phase 5)
+- `subagent-driven-development` — subagent dispatch pattern (Phase 2-3)
+- `doubt-driven-development` — adversarial review for high-risk work (Phase 5)
+- `context-engineering` — context budgets for parallel subagents (Phase 3)