| name | planning |
| description | Generate and optimize PRDs, Implementation Plans, and Progress Tracking documents optimized as AI artifacts for development agents. Use when creating new feature plans, breaking down long planning docs (>800 lines), or setting up progress tracking. Supports: 1) Create PRD from feature request, 2) Create Implementation Plan from PRD with phase breakdown and subagent assignments, 3) Optimize existing plans by breaking into phase-specific files, 4) Create progress tracking with task assignments. Example: "Create a PRD for user authentication feature" or "Break down the sidebar-polish implementation plan into phase files" or "Create progress tracking for data-layer-fixes PRD".
|
Planning Skill
About This Skill
The Planning Skill generates and optimizes Product Requirements Documents (PRDs) and Implementation Plans as AI artifacts - file-based context caches optimized for AI agent consumption rather than human reading.
Purpose
- Generate comprehensive PRDs from feature requests following MP template
- Create phased Implementation Plans with subagent task assignments
- Optimize existing planning docs by breaking into token-efficient files
- Set up progress tracking structures for multi-phase implementations
Key Benefits
- Token Efficiency: Max ~800 lines per file for optimal AI context loading
- Progressive Disclosure: Summary → Detail pattern with linked files
- Subagent Integration: Automatic task assignment to appropriate specialists
- MP Architecture Compliance: Plans follow layered architecture (routers → services → repositories → DB)
- Structured Tracking: One progress file per phase following CLAUDE.md policy
Token Discipline (Mandatory for Orchestrators)
Opus must NOT read source documents that subagents will also read. Provide file paths in delegation prompts instead.
| What to Delegate | Agent | Prompt Size Target |
|---|
| OQ assessment | haiku (general) | 10-15 lines |
| PRD creation | prd-writer (sonnet) | 30-50 lines |
| Implementation plan | implementation-planner (sonnet) | 40-60 lines |
| Progress files | python-backend-engineer (sonnet) | 20-30 lines |
What Opus reads directly: Tracker entries (~5 lines), meta-plan rows (~5 lines), frontmatter for edits (~15 lines). Nothing else.
Anti-patterns with measured cost: See docs/project_plans/CLAUDE.md for the full anti-pattern table with token costs. Key rule: reading a SPIKE as Opus to inform a prd-writer prompt costs ~7K tokens; delegating OQ assessment to haiku costs ~1.2K (6x cheaper).
Agent Consumption Rule
Agents invoked for implementation, review, or execution MUST NOT load docs/project_plans/human-briefs/ files unless the task prompt explicitly names the brief.
- The
audience: [humans] frontmatter field is the machine-readable skip signal.
- Briefs contain orchestrator-level rationale (estimation narrative, wave strategy, open-question inventory). This content is irrelevant to executing subagents and burns context budget without improving output quality.
- Exception: An agent may be explicitly asked to populate an initial brief skeleton or append a note to the Running Log. In both cases, the task prompt must name the brief file explicitly.
- Spec reference:
.claude/specs/artifact-structures/human-brief-spec.md §5.
When to Use This Skill
- Creating PRDs for new features or enhancements
- Generating detailed implementation plans from PRDs
- Breaking down long planning documents (>800 lines) into manageable files
- Setting up progress tracking for multi-phase work
- Optimizing existing plans for better AI agent consumption
- Generating Planning Review Boards to visualize all planning artifacts for a feature
Before You Scope — Check the Deferred Backlog (and IntentTree)
Before authoring a PRD or implementation plan, scan the deferred items backlog
(.claude/rules/deferred-backlog.md → docs/project_plans/deferred-items-backlog.md) for items on
the same surface or higher-priority adjacent items. Pull related DI- rows into the plan when they
fit — landing neighboring deferrals together is the cheapest time to clear them, and the backlog's
"Next Polish Pass" section names the current recommended track. Reference pulled items by DI- ID in
the plan, and flip their Status to in-progress when the plan commits.
Also check IntentTree first (gated, best-effort). When INTENTTREE_SDLC_SYNC=1, query the bound
tree for related/in-flight nodes so the plan reuses or links existing work instead of duplicating it,
per the LOOKUP recipe in .claude/rules/intenttree-integration.md
(itt --json tree graph <id> then filter backlog/in_progress over .nodes[] in jq — node list
requires an off-tree/workspace scope, so the tree-scoped graph is the in-tree lookup). The markdown backlog stays the
canonical "check first" source; the node query is the queryable complement.
Quick Start
Create PRD from Feature Request
User: "Create a PRD for advanced filtering on the prompts page"
Create Implementation Plan from PRD
User: "Create implementation plan for docs/project_plans/PRDs/harden-polish/advanced-filtering-v1.md"
Generate Planning Review Board
python scripts/generate-planning-board.py \
--feature-slug enterprise-tier-comparison-scopes \
--wireframe-dir docs/dev/designs/wireframes/enterprise-unified-sync \
--output planning-review-board.html \
--open
python scripts/generate-planning-board.py \
--plan docs/project_plans/implementation_plans/features/some-feature-v1.md
python scripts/generate-planning-board.py --feature-slug xyz --dry-run
Reference: .claude/skills/planning/references/planning-review-board.md
Optimize Existing Plan
User: "Optimize docs/project_plans/implementation_plans/harden-polish/sidebar-polish-v1.md"
Create Progress Tracking
User: "Create progress tracking for data-layer-fixes PRD"
Track Plan Status Lifecycle
python .claude/skills/artifact-tracking/scripts/manage-plan-status.py \
--file docs/project_plans/PRDs/features/feature-name-v1.md \
--status approved
python .claude/skills/artifact-tracking/scripts/manage-plan-status.py \
--file docs/project_plans/implementation_plans/features/feature-name-v1.md \
--status in-progress
python .claude/skills/artifact-tracking/scripts/manage-plan-status.py \
--file docs/project_plans/implementation_plans/features/feature-name-v1.md \
--status completed
Status values: draft → approved → in-progress → completed
Reference: See .claude/skills/artifact-tracking/plan-status-management.md for full status management guide.
Tier Matrix (Routing Decision Tree)
Before authoring any planning artifact, determine the feature's tier. Tier drives artifact type, execution model, reviewer requirement, and model routing. Use the table below.
| Tier | Size | Pre-commitment exploration | Planning artifact | Execution model | Reviewer | Model routing |
|---|
| 0 | 1–3 pts, single file | skip | none | /dev:quick-feature | optional | sonnet executor |
| 1 | 3–8 pts | optional (use when ambiguity exists, skip when outcome is clear) | Feature Contract (~200–400 lines) | one autonomous sprint per contract | mandatory task-completion-validator | sonnet executor + sonnet contract writer + Opus design block |
| 2 | 8–13 pts | strongly suggested — required when no comparable past-feature anchor exists or risk_level: high | PRD + Implementation Plan | phase-by-phase orchestration | mandatory task-completion-validator per phase; karen at feature end | sonnet executor + sonnet implementation-planner + Opus decisions block |
| 3 | 13+ pts | strongly suggested — required when no comparable past-feature anchor exists or risk_level: high | SPIKE + PRD + Implementation Plan | phase-by-phase orchestration | mandatory karen per phase milestone + end of feature | sonnet executor + sonnet implementation-planner + Opus decisions block |
Large-file override (capacity, not points): Story points size behavior; they don't size agent context. Any refactor that deletes, relocates, splits, or substantially rewrites a single file >~2K lines (>5K = always) is Tier 2 minimum regardless of point estimate. A Tier 1 single-agent sprint cannot hold the large source + its call-sites + edit targets at once and will blow context mid-sprint (observed: a 10,156-line deletion crashed a Tier 1 sprint with all wiring undone). Classify it as Tier 2 up front and decompose file-ownership-first per .claude/specs/workflows/large-file-refactor-decomposition-spec.md. Localized edits inside a large file (a few functions) are exempt.
How to apply:
- Estimate the feature in story points before creating any artifact.
- Select the tier from the table above. Then apply the large-file override: if the work moves/deletes/splits any file >~2K lines, force Tier 2 minimum.
- For Tier 2/3, check whether pre-commitment exploration is warranted (see "Workflow: Pre-Commitment Exploration" below).
- Follow the matching workflow (Tier 0 →
/dev:quick-feature; Tier 1 → "Workflow: Tier 1 Feature Contract"; Tier 2/3 → "Workflow 2: Create Implementation Plan from PRD").
- If scope expands during planning and crosses a tier boundary upward, promote — don't stretch. See promotion rule in the Tier 1 workflow.
Source: .claude/plans/tiered-workflow-overhaul.md §2.1
CCDash Frontmatter Requirements
Use CCDash-aligned frontmatter for all planning artifacts.
- Reference:
.claude/skills/artifact-tracking/schemas/field-reference.md
- Baseline fields for all planning docs:
schema_version, doc_type, title, status, created, updated, feature_slug
- Linkage fields:
prd_ref, plan_ref, related_documents
- Lifecycle fields to update after implementation:
commit_refs, pr_refs, files_affected; on merge to the destination branch: merge_commit, merge_branch
Canonical Paths Table
All planning documents follow a canonical location pattern by doc type, enabling discovery and cross-referencing.
| doc_type | Purpose | Canonical Location | Feeds / Downstream |
|---|
exploration_charter | Pre-commitment exploration boundary contract; contains hypothesis, deal_killer, timebox, legs, verdict | docs/project_plans/exploration/[idea-slug]/[idea-slug]-charter.md | report (feasibility_brief), proposed ADR, prd (on go verdict) |
design_spec | Pre-PRD ideation and design, varying maturity | docs/project_plans/design-specs/[name].md | prd |
prd | Formal product requirements | docs/project_plans/PRDs/[category]/[name]-v1.md | implementation_plan |
implementation_plan | Phased technical breakdown | docs/project_plans/implementation_plans/[category]/[name]-v1.md | phase_plan, progress |
phase_plan | Single phase (if parent plan >800 lines) | docs/project_plans/implementation_plans/[category]/[name]-v1/phase-[N]-[title].md | progress |
progress | Phase task tracking and orchestration | .claude/progress/[feature-slug]/phase-[N]-progress.md | — |
spike | Formal research investigation with charter | docs/project_plans/SPIKEs/[name]-charter.md or docs/project_plans/SPIKEs/[name].md | design_spec, prd, ADR |
report | Investigation, audit, finding, post-mortem | docs/project_plans/reports/[category]/[name].md or .claude/findings/[name].md | design_spec, prd |
meta_plan | Workflow, process, or tooling change (not product) | .claude/plans/[name].md | — |
human_brief | Human-orchestrator lens: estimation rationale, wave strategy, OQ ledger, success behaviors | docs/project_plans/human-briefs/[feature-slug].md | — (audience: humans; agents skip) |
Categories (PRD and implementation_plan subdirs): features, enhancements, refactors, harden-polish, infrastructure
Report categories (subdirs under docs/project_plans/reports/): findings, investigations, audits, post-mortems, refactor-reports
Exploration artifacts live under docs/project_plans/exploration/[idea-slug]/ — not under reports/. The feasibility_brief inside an exploration bundle uses doc_type: report with report_category: feasibility but is stored alongside its charter, not in the reports tree.
Cross-Reference Policy
Prefer envelope fields over ad-hoc fields for linking planning documents. This enables consistent discovery and prevents scattered linkage patterns.
Canonical linkage fields (prefer these):
prd_ref: Path to the PRD this design_spec or report is linked toplan_ref: Path to the implementation plan this phase_plan or progress is linked tospike_ref: Path to the spike this design_spec or PRD referencesrelated_documents: Array of paths to related docs (cross-references, background, context)
Legacy fields to migrate (phase out over time):
related_prds: OLD; use prd_ref or related_documents instead- Scattered ad-hoc fields in existing docs that don't follow envelope schema
Migration strategy: When updating a design_spec or report with related_prds, refactor to use prd_ref (if single primary PRD) or move items into related_documents (if multiple cross-references).
Example:
related_prds:
- docs/project_plans/PRDs/features/xyz-v1.md
prd_ref: docs/project_plans/PRDs/features/xyz-v1.md
related_documents:
- docs/project_plans/PRDs/features/xyz-v1.md
- docs/dev/architecture/adr-123.md
- .claude/context/some-pattern.md
Field Checklist by Doc Type
-
prd
- Required now:
schema_version, doc_type: prd, title, status, created
- Populate early:
feature_slug, priority, risk_level, owner, contributors
- Keep
prd_ref: null; set plan_ref after implementation plan exists
- Optional:
changelog_required: true — set when the feature introduces user-facing changes that must appear in CHANGELOG [Unreleased] before release. Omit (default: unset, treated as false) for purely internal or infrastructure-only changes. When set, Phase 7 Documentation Finalization must include a CHANGELOG entry. See .claude/specs/changelog-spec.md for categorization rules.
-
implementation_plan
- Required now:
schema_version, doc_type: implementation_plan, title, status, created, prd_ref
- Populate early:
scope, effort_estimate, feature_slug, priority, risk_level
- Set
plan_ref: null for root implementation plan
- If plan includes deferred items or research-needed items: populate
deferred_items_spec_refs as design specs are authored in the final phase; populate findings_doc_ref if a findings doc is created lazily during execution
- Optional:
changelog_required: true — inherit from the parent PRD or set independently when the implementation scope confirms user-facing changes. When set, Phase 7 Documentation Finalization must include a CHANGELOG [Unreleased] entry. Default: unset (false). See .claude/specs/changelog-spec.md.
-
phase_plan
- Required now:
schema_version, doc_type: phase_plan, title, status, created, phase, phase_title
- Populate early:
prd_ref, plan_ref, entry_criteria, exit_criteria
- Keep
feature_slug aligned with parent PRD/plan
-
spike
- Required now:
schema_version, doc_type: spike, title, status, created
- Populate early:
feature_slug, research_questions, complexity, estimated_research_time
- Set
prd_ref/plan_ref when spike is linked to planned work
-
human_brief
- Required always:
schema_name: ccdash_document, schema_version: 2, doc_type: human_brief, title, status, created, audience: [humans], feature_slug, category: human-briefs
- Required when linked docs exist:
prd_ref, plan_ref
- Populate early:
owner, priority, confidence, feature_family, feature_version
- Reserve but leave null:
intent_ref, epic_ref (forward-compat for INTENT.md system)
- Do NOT set
blocked or superseded status — use only draft, in-progress, completed
- Full schema:
.claude/specs/artifact-structures/human-brief-spec.md §2
Frontmatter Lifecycle
Planning artifacts follow a structured lifecycle as they move through the SDLC. Frontmatter fields populate progressively at each phase.
Field Population Timeline
| Field | Draft | Approved | In-Progress | Completed |
|---|
title | ✓ | ✓ | ✓ | ✓ |
description | ✓ | ✓ | ✓ | ✓ |
status | draft | approved | in-progress | completed |
created | ✓ | ✓ | ✓ | ✓ |
updated | ✓ | ✓ | ✓ | ✓ |
prd_ref | null | ✓ | ✓ | ✓ |
plan_ref | null | ✓ | ✓ | ✓ |
contributors | [author] | [author] | [author + team] | [author + team] |
milestone | null | ✓ | ✓ | ✓ |
commit_refs | [] | [] | [refs...] | [refs...] |
pr_refs | [] | [] | [refs...] | [refs...] |
files_affected | [] | [] | [files...] | [files...] |
merge_commit | null | null | null | <post-squash sha> |
merge_branch | null | null | null | main (or destination) |
Lifecycle Phases:
- Draft: Initial creation with title, description, author. Status defaults to
draft.
- Approved: PRD/plan review complete. Set status to
approved and populate cross-references (prd_ref / plan_ref).
- In-Progress: Execution begins. Add implementation team to
contributors, set milestone target, track commit_refs as work commits.
- Completed: All tasks done. Finalize
commit_refs, pr_refs, and files_affected list, and — once merged to the destination branch — set merge_commit + merge_branch to the canonical landing SHA. For direct squash-merges with no PR, merge_commit is the only in-repo way to resolve where the feature actually landed (the branch SHA becomes an orphan).
Status Management:
Use manage-plan-status.py to advance status lifecycle:
python .claude/skills/artifact-tracking/scripts/manage-plan-status.py \
--file docs/project_plans/PRDs/features/feature-name-v1.md \
--status approved
Use update-field.py to append to list fields (--append "key=value"; lists: contributors, commit_refs, pr_refs, files_affected) or set scalar fields (--set "key=value", both repeatable):
python .claude/skills/artifact-tracking/scripts/update-field.py \
-f docs/project_plans/implementation_plans/features/feature-name-v1.md \
--append "pr_refs=https://github.com/owner/repo/pull/123"
python .claude/skills/artifact-tracking/scripts/update-field.py \
-f docs/project_plans/implementation_plans/features/feature-name-v1.md \
--set "merge_commit=4e64e630" \
--set "merge_branch=main"
Full field lifecycle details: .claude/skills/artifact-tracking/schemas/field-reference.md
Lifecycle Guidance
Planning artifacts follow a natural progression from ideation through implementation. Use this guide to determine when to create each document type.
Human Briefs are opt-in living documents that accompany PRDs and plans for qualifying features (≥8 pts, ≥2 phases, or notable orchestration complexity — see Workflow 5 heuristic). They live at docs/project_plans/human-briefs/[feature-slug].md alongside their linked PRD and plan, evolve throughout the feature lifecycle, and are archived in place when the feature ships. Unlike plans, briefs are not versioned — no -v1 suffix. See .claude/specs/artifact-structures/human-brief-spec.md §4 for the full heuristic.
Pre-Commitment Exploration → exploration_charter + feasibility_brief
When: You have a speculative idea or loosely-scoped initiative — before committing to a tier or authoring any planning artifact — and one or more of the following is true:
- No comparable past feature exists as an estimation anchor (H5 is unknown)
- The idea has
risk_level: high or involves a capability area the project has never built
- The "should we even do this?" question has not been answered citably
- The requester is unsure whether to proceed or shelve
Where it sits in the lifecycle: Pre-Commitment Exploration is the upstream-most phase — before design_spec, before tier classification, before any PRD or Feature Contract. Its sole purpose is to produce a machine-readable verdict (go | no-go | conditional) that feeds directly into tier classification or archives the idea with rationale.
How the verdict feeds downstream:
go → proceed to tier classification; the feasibility_brief is referenced in the resulting PRD's related_documentsno-go → archive the exploration_charter at docs/project_plans/exploration/[idea-slug]/; idea is closed with documented rationaleconditional → recommended_next_action field in the feasibility brief names the concrete precondition and next command (/plan:explore again, /plan:spike, or defer-until condition)
Command: /plan:explore (see Workflow: Pre-Commitment Exploration below)
Artifacts produced:
exploration_charter at docs/project_plans/exploration/[idea-slug]/[idea-slug]-charter.mdfeasibility_brief (doc_type report, report_category: feasibility) at docs/project_plans/exploration/[idea-slug]/[idea-slug]-feasibility-brief.md- Proposed ADR (optional, only if synthesis surfaces a decision that exists regardless of verdict direction)
Skip when: The idea is Tier 0 or 1 with a clear outcome, a directly comparable past feature exists, and risk_level is low or medium.
Rough Idea → design_spec
When: You have a raw idea, loose thoughts, or unstructured exploration on a potential feature or change.
What to do:
- Create a new file in
docs/project_plans/design-specs/[name].md
- Set
maturity: idea in frontmatter
- Add sections: problem statement (optional), open questions, explored alternatives
- This is your working document for shaping the idea
Example:
---
schema_version: 2
doc_type: design_spec
maturity: idea
title: "Real-time Sync Architecture"
status: draft
created: 2026-04-08
feature_slug: realtime-sync
---
Gaining Shape → maturity: shaping → maturity: ready
When: The design_spec has structure, you've explored trade-offs, and it's crystallizing into a concrete proposal.
What to do:
- Update the design_spec file
- Change
maturity: shaping (has structure, exploring)
- Populate sections: problem_statement, open_questions, explored_alternatives
- Continue iterating until all open questions are resolved
- When ready to formalize, bump to
maturity: ready
Example:
maturity: shaping
maturity: ready
Promote → Create prd
When: The design_spec is at maturity: ready and you're ready to formalize as a product requirement.
What to do:
- Create a new PRD at
docs/project_plans/PRDs/[category]/[name]-v1.md
- Update the design_spec:
- Set
maturity: promoted
- Add
prd_ref: docs/project_plans/PRDs/[category]/[name]-v1.md
- Reference the design_spec in the PRD as context/background
- Move forward with PRD lifecycle and implementation planning
Example:
maturity: promoted
prd_ref: docs/project_plans/PRDs/features/realtime-sync-v1.md
Workflow/Process/Tooling Change → meta_plan
When: You need to document a change to how the team works (process), tools used (tooling), or infrastructure changes (NOT a product feature).
What to do:
- Create a new file in
.claude/plans/[name].md
- Set
doc_type: meta_plan and scope: [process|tooling|workflow|infrastructure|documentation|other]
- Document: what's changing, why, affects_skills, affects_commands, expected outcome
- This is distinct from product PRDs and tracks workflow improvements
Example:
---
schema_version: 2
doc_type: meta_plan
title: "Planning Document Cleanup"
scope: process
status: in-progress
affects_skills: [planning, artifact-tracking, plan-status]
---
Investigation/Audit/Finding → report
When: You discover something worth documenting (bug investigation, performance audit, learning, post-mortem) that informs product or process decisions.
What to do:
- For raw findings during execution, create in
.claude/findings/[name].md with minimal frontmatter (status: draft, source: agent)
- When finding proves load-bearing, promote to
docs/project_plans/reports/[category]/[slug].md with full frontmatter
- Link the report to the PRD or design_spec it informs via
prd_ref or related_documents
- Report categories:
findings, investigations, audits, post-mortems, refactor-reports
Example (raw finding):
---
schema_version: 2
doc_type: report
report_category: finding
title: "SQLAlchemy Comparator Cache Poisoning"
status: draft
source: agent
created: 2026-04-08
feature_slug: enterprise-db-layer
---
Example (promoted finding):
---
schema_version: 2
doc_type: report
report_category: finding
title: "SQLAlchemy Comparator Cache Poisoning"
status: accepted
source: agent
created: 2026-04-08
prd_ref: docs/project_plans/PRDs/features/enterprise-database-v1.md
promoted_to: [docs/project_plans/implementation_plans/features/enterprise-database-v1.md]
outcome: "Implemented manual cache refresh in enterprise repository tests"
---
design_spec Maturity States
Use the maturity field to track ideation progress:
| State | Definition | Next Step |
|---|
idea | Raw ideation, loose thoughts | Explore and structure |
shaping | Has structure, actively exploring | Resolve open questions |
ready | Resolved questions, ready to promote | Create PRD |
promoted | Has prd_ref, formalized to PRD | Use PRD for implementation |
shelved | Not pursuing this idea | Archive if needed |
Core Workflows
Workflow: Pre-Commitment Exploration (/plan:explore)
Applies to: Speculative ideas and loosely-scoped initiatives where the "should we build this?" question has not been answered before any planning artifact is authored.
When to invoke:
- No comparable past feature exists as an estimation anchor (H5 unknown)
- Feature idea has
risk_level: high or introduces a capability area new to the project
- The scope is ambiguous enough that tier classification itself is uncertain
- The requester is unsure whether to proceed, shelve, or defer
When to skip:
- Tier 0 or clear Tier 1 with obvious outcome and low risk
- A directly comparable past feature provides sufficient confidence
- The feature is an enhancement to existing, well-understood functionality
Command hint: /plan:explore [idea-description-or-file] [--timebox=N] [--legs=technical,value,risk,priorart] [--charter=path]
Output bundle (all artifacts land under docs/project_plans/exploration/[idea-slug]/):
docs/project_plans/exploration/[idea-slug]/
├── [idea-slug]-charter.md # exploration_charter (doc_type)
├── spikes/ # SPIKE outputs from /plan:spike legs
├── [idea-slug]-feasibility-brief.md # report (report_category: feasibility)
└── [idea-slug]-proposed-adr.md # ADR status: proposed (only when synthesis forces a decision)
Phase Flow
Phase 0: Triage (Opus, ~3K tokens)
— Does this idea warrant exploration or is a direct tier classification obvious?
— If obvious, skip to tier classification. If speculative, proceed.
↓
Phase 1: Charter (delegated to spike-writer / charter-writer in scoping mode)
— Produce exploration_charter with: hypothesis, deal_killer, timebox_days, investigation_legs
— Template: .claude/skills/planning/templates/exploration-charter-template.md
↓
Phase 2: Parallel legs (delegated; 1–4 SPIKEs in parallel via /plan:spike --leg-of=<charter>)
├── technical → spike-writer / research-technical-spike
├── value → ux-researcher / search-specialist
├── risk → backend-architect / data-layer-expert
└── prior-art → search-specialist / docs-seeker
— Leg catalog and agent routing: .claude/skills/planning/references/exploration-legs-catalog.md
↓
Phase 3: Synthesis (delegated to documentation-writer or spike-writer)
— Produce feasibility_brief (report, report_category: feasibility)
— Produce proposed ADR if synthesis surfaces an architectural decision
— Template: .claude/skills/planning/templates/feasibility-brief-template.md
↓
Phase 4: Verdict (Opus reasoning + mandatory user sign-off for go / no-go)
— go | no-go | conditional
— Handoff: go → /plan:plan-feature (feasibility brief in related_documents)
no-go → archive charter with rationale
conditional → recommended_next_action names the precondition
Token budget target: ~30–60K tokens end-to-end. Each parallel leg ~10K; synthesis ~5K; verdict ~3K.
Output Artifact Contracts
exploration_charter (frontmatter excerpt):
doc_type: exploration_charter
timebox_days: 3
hypothesis: "We believe X is worth building because Y."
deal_killer: "If Z is true, abandon."
investigation_legs:
- id: tech
question: "Is X feasible in the existing architecture?"
assigned_to: spike-writer
verdict: null
verdict_rationale: null
feasibility_brief (reuses report doc_type, no new doc_type introduced):
doc_type: report
report_category: feasibility
verdict: go | no-go | conditional
verdict_confidence: 0.0–1.0
exploration_charter_ref: path
proposed_adr_ref: path | null
recommended_next_action: "/plan:plan-feature --tier=2" | "archive" | "defer-until: [condition]"
Required body sections: Synopsis, Investigation summary table (leg × confidence × conclusion), Cost estimate (H5 anchor), Value statement, Risks & blast radius, Architectural implications, Verdict, Citations.
Verdict Handoff Rules
| Verdict | Next action |
|---|
go | Run /plan:plan-feature; add feasibility_brief path to PRD related_documents |
no-go | Archive charter bundle at docs/project_plans/exploration/[idea-slug]/; no further action |
conditional | recommended_next_action field names the exact next command and precondition; re-enter exploration loop when precondition resolves |
Human sign-off is required for go and no-go verdicts. Opus recommendation alone does not close the verdict.
Anti-Pattern Guards
| Anti-pattern | Guard |
|---|
| Endless investigation | timebox_days in charter is mandatory (default 3, hard max 7); Phase 2 must produce findings at cutoff — silence is not acceptable, partial findings + pivot is |
| Premature PRD | /plan:plan-feature Phase 0 should surface missing charter for speculative ideas and suggest /plan:explore first |
| Exploration without verdict | verdict frontmatter field is mandatory in the feasibility brief; status: concluded cannot be set without it |
| Siloed investigation | Phase 2 legs are spawned in parallel by default; sequential is opt-in via --sequential flag |
| ADR after commitment | ADRs drafted during exploration carry status: proposed; acceptance happens at the verdict phase, not at implementation |
| Missing deal-killer | deal_killer field in charter is mandatory; validator refuses to scaffold a charter without one |
| Verdict-as-prose | verdict and verdict_confidence are structured frontmatter fields, not body sections; tooling must be able to read them |
References:
- Leg catalog and agent assignments:
./references/exploration-legs-catalog.md
- Charter template:
./templates/exploration-charter-template.md
- Feasibility brief template:
./templates/feasibility-brief-template.md
- Meta plan (full design):
.claude/plans/plan-explore-pre-commitment-exploration-v1.md
Workflow: Tier 1 Feature Contract
Applies to: Features estimated at 3–8 story points with a clear, bounded scope and enumerable acceptance criteria. Single-feature scope; does not require multi-phase orchestration.
Artifact: docs/project_plans/feature_contracts/[category]/[feature-slug].md
Template: .claude/skills/planning/templates/feature-contract-template.md
Why not a PRD + Plan?: A 5-pt feature costs ~150–200K tokens with the heavyweight flow. The Feature Contract delivers the same outcome at ~60–80K tokens through a single autonomous sprint rather than N batch-orchestration rounds.
Steps:
-
Opus drafts the contract design block (~15K tokens):
- Fill in
Goal, User/Actor, Job To Be Done, Scope, Acceptance Criteria, Risk Areas, and Architecture Constraints using the template.
- Set
tier: 1 and estimated_points: N in frontmatter.
- Keep the design block to ~50–80 lines — Opus provides the judgment scaffold; sonnet expands the rest.
-
Delegate contract expansion to sonnet contract writer (prd-writer or feature-planner agent):
- Provide the Opus design block (file path) and the feature-contract-template.md (file path).
- The agent fills in
UX/Behavior Requirements, Data Requirements, API/Integration Requirements, and Implementation Notes.
- Target: complete contract of 200–400 lines.
-
Opus sanity review (~3K tokens):
- Verify acceptance criteria are testable and unambiguous.
- Verify scope boundary is clear enough for an autonomous sprint.
- Verify risk areas are identified.
- Approve or send back for revision.
-
Hand off to autonomous sprint:
- Delegate the full contract to
feature-sprint-executor (sonnet, acceptEdits) using Mode C: Autonomous Feature Sprint.
- Provide contract file path; the executor reads it directly.
- The executor implements the full feature: explores, codes, adds tests, validates, and produces a Completion Report.
-
Mandatory reviewer pass:
task-completion-validator reviews: contract acceptance criteria, validation results, and Completion Report.- Reviewer must pass before Opus commits.
- Reviewer output format: see
.claude/skills/dev-execution/validation/completion-criteria.md.
-
Opus commits if review passes.
Promotion rule (scope growth): If during contract drafting (steps 1–2) the estimated points cross 8, stop and promote to Tier 2. Author a PRD that references the draft contract via related_documents and create an Implementation Plan using Workflow 2. Do not retrofit a Tier 1 contract for genuinely complex work. Set prd_ref in the contract frontmatter pointing to the new PRD.
Total cost target: ~60–80K tokens, 3–4 prompt round-trips (contract draft → expansion → sprint → review).
Source: .claude/plans/tiered-workflow-overhaul.md §4.3–§4.4
Workflow 1: Create PRD from Feature Request
Input: Feature description or request from user
Process:
-
Analyze Request
- Extract feature name, scope, goals
- Identify related systems and components
- Determine priority and complexity
-
Structure PRD
- Use template:
./templates/prd-template.md
- Follow MP architecture patterns (see
./references/mp-architecture.md)
- Include frontmatter with proper metadata — author the canonical plan frontmatter (
it_schema: 1) per ./references/plan-frontmatter-schema.md: the templates emit the MUST set + open_questions/decisions (YAML lists) + agent_*/execution_mode/scores; lint with artifact-tracking/scripts/validate-plan-frontmatter.py (advisory). When IntentTree sync is in use, also carry the binding (intenttree_workspace / intenttree_tree) so capture resolves to the bound human workspace/tree (see .claude/rules/intenttree-integration.md)
- Organize into standard PRD sections
-
Add Implementation Context
- Break into phased approach
- Identify architectural layers involved
- Note dependencies and risks
- Define success criteria and acceptance tests
-
Determine Location
- Category:
docs/project_plans/PRDs/[category]/
- Categories:
harden-polish, features, enhancements, refactors
- Naming:
[feature-name]-v1.md (kebab-case)
-
Generate File
- Write PRD to determined location
- Include YAML frontmatter with metadata
- Link to related docs (ADRs, guides, etc.)
- Add to project tracking if needed
Output:
- PRD file at:
docs/project_plans/PRDs/[category]/[feature-name]-v1.md
- Follows template structure
- Ready for implementation planning
Example:
Input: "Add real-time collaboration features to prompt editing"
Output Location: docs/project_plans/PRDs/features/realtime-collaboration-v1.md
Sections:
1. Executive Summary - Real-time collaborative editing
2. Context & Background - Current single-user editing limitations
3. Problem Statement - Users can't collaborate on prompts
4. Goals & Success Metrics - Multiple concurrent editors, conflict resolution
5. Requirements - WebSocket connections, operational transforms, presence indicators
6. Implementation Phases - Phase 1: Backend infrastructure, Phase 2: Frontend integration
... (full PRD structure)
Workflow 2: Create Implementation Plan from PRD
Input: Path to existing PRD or newly created PRD
Process:
-
Analyze PRD
- Read full PRD content
- Extract key requirements
- Identify architectural layers needed
- Determine phase breakdown strategy
-
Plan Phase Structure
- Follow MP layered architecture: routers → services → repositories → DB
- Group related tasks into phases
- Common phases: Database → Repository → Service → API → UI → Testing → Docs → Deployment
- Consider parallel work opportunities
- Identify critical path
- Populate the Phase Summary table in Implementation Strategy (after Critical Path) with every phase, point estimate, target subagents, and model designation. This table is mandatory — it is the canonical orchestration index executors use to plan delegation. Keep it synced with detailed phase breakdowns. Use Claude models by default (
sonnet / haiku); note external models (e.g., gemini-3.1-pro-preview, nano-banana-pro, gpt-5.6-terra) per references/multi-model-guidance.md.
2.5 Opus Decisions Block (Tier 2/3 mandatory) — author before delegating to implementation-planner:
- Opus authors a ~200-line decisions block using
./templates/decisions-block-template.md.
- Decisions block covers: phase boundaries, agent routing per phase, risk hotspots (severity + mitigation), estimation anchors with comparable past features, dependency map (critical path + parallelizable slices), and model routing per phase per agent.
- This is Opus-direct (not delegated) — it is the architectural judgment scaffold that earns Opus its premium on Tier 2/3 features.
- Target ~200 lines; do not expand into full template prose — that is
implementation-planner's job.
- Write the decisions block to
.claude/worknotes/[feature-slug]/decisions-block.md (temporary working file).
Then delegate expansion to implementation-planner (sonnet):
- Provide: decisions block path + PRD path + implementation-plan-template.md path.
- The agent expands the decisions block into the full plan template: detailed phase descriptions, task breakdowns, batch definitions, task tables, success criteria, and model/effort columns.
implementation-planner runs on sonnet (not haiku) — plans drive 200K+ tokens of downstream execution; this is the highest-leverage model routing call in the planning workflow.
Opus sanity review post-expansion (~3K tokens):
- Verify phase boundaries match decisions block.
- Verify agent routing is correctly propagated to task table.
- Verify no critical risks were dropped.
- Approve or send back for targeted revision.
Source: .claude/plans/tiered-workflow-overhaul.md §4.2
- Generate Task Breakdown
- Use template:
./templates/implementation-plan-template.md
- Create tasks for each phase
- Format: Task tables with ID, Name, Description, Acceptance Criteria, Estimate
- Include quality gates for each phase
3.5 Run Estimation Sanity Check (mandatory) — write output to Human Brief, not the plan
- Use reference:
./references/estimation-heuristics.md
- Determine if a Human Brief applies (see §4 creation heuristic in
.claude/specs/artifact-structures/human-brief-spec.md).
- If brief applies: scaffold
docs/project_plans/human-briefs/[feature-slug].md using ./templates/human-brief-template.md, then populate §2 Estimation Sanity Check in the brief with the H1–H6 output.
- If brief does not apply (feature too small): populate the H1–H6 check in a comment or scratchpad for your own reference; do not add the full block to the plan.
- Apply heuristics H1–H6 bottom-up:
- H1: noun-counting (≥2 pts per new CRUD-with-RBAC table)
- H2: dual-implementation multiplier (~1.8× repo subtotal when local+enterprise)
- H3: algorithmic service flag (≥3 pts for any service whose description includes dependency / resolution / graph / conflict / cycle / solver / inference / ranking / scheduling / merge / diff / transform; SPIKE first if test scenarios cannot be enumerated)
- H4: bundle-vs-sum (per-area estimates summed = floor for plan total when ≥3 capability areas)
- H5: anchor reference (cite a comparable completed feature, justify any delta >30%)
- H6: hidden plumbing budget (~15–20% line item for DTOs / DI / OpenAPI / RLS / inventory updates / CHANGELOG)
- If bottom-up total disagrees with top-down intuition, trust bottom-up or write justification.
- Set
**Human Brief** pointer line near the top of the plan (the template provides the field).
-
Assign Subagents
- Use reference:
./references/subagent-assignments.md
- Assign based on task type:
- Database:
data-layer-expert
- Backend API:
python-backend-engineer, backend-architect
- Frontend:
ui-engineer-enhanced, frontend-developer
- UI Components:
ui-designer, ui-engineer
- Testing: appropriate testing agents
- Docs:
documentation-writer, documentation-complex
- Add to each task: "Assigned Subagent(s): agent-1, agent-2"
-
Model Assignment
- Evaluate each task for the appropriate model:
- Default:
sonnet for implementation, haiku for docs/exploration
- Route image generation →
nano-banana-pro
- Route UI wireframing/design →
gemini-3.1-pro-preview
- Route web research →
gemini-3.1-pro-preview
- Route debug escalation →
gpt-5.6-terra
- Assign effort levels per model using the Canonical Effort Vocabulary in
./references/multi-model-guidance.md. Effort is a model-keyed reasoning budget, not a size estimate — use the Estimate column for story points or hours.
- claude (opus/sonnet/haiku):
adaptive (default) or extended only
- codex (gpt-5.6-terra):
none | low | medium | high | xhigh
- gemini (3.1-pro/3.1-flash):
none | low | medium | high
- nano_banana (nano-banana-pro):
standard | quality
- Forbidden: putting story points (e.g.,
"3pts") or hours in the Effort column. Those belong in Estimate.
- Phase-level defaults: Set
wave_plan.phases[].model and wave_plan.phases[].effort as phase-wide defaults. Per-task Model/Effort cells override these defaults. Both are optional; absence means "use the model's own default."
- Group external model tasks as pre-work (batch_0) when possible
- Add to each task: "Model: [model]; Effort: [level]"
- Reference: See
./references/multi-model-guidance.md → Canonical Effort Vocabulary for authoritative values
-
UI Extraction Evaluation (UI-Heavy Phases Only)
- For phases with React/UI component work, evaluate against extraction criteria
- Flag reusable components with
[pkg] marker in task descriptions
- Evaluate: multiple projects reuse (2+), generic API design, stability window (2+ weeks), no app-specific dependencies
- Document extraction candidates for potential
@meaty/ui packaging
- Reference:
./references/ui-extraction-guidance.md for criteria details
- Full spec:
.claude/specs/ui-package-extraction-spec.md
7.5 Deferred Items & Findings Planning
- Scan the PRD for deferred/backlog/research-needed items, open questions with
OQ-* markers, or spike-needed investigations
- List them in a "Deferred Items" triage table in the plan's
## Deferred Items & In-Flight Findings Policy section
- Add a corresponding design-spec authoring task row (DOC-006) for each item — or document "N/A — no deferred items" if none exist
- Initialize
deferred_items_spec_refs: [] and findings_doc_ref: null in plan frontmatter
- Reference:
./references/deferred-items-and-findings.md
-
Documentation Evaluation
- Assess which docs require updates based on feature scope:
- CHANGELOG: Include if user-facing changes (new features, breaking changes, deprecations). When
changelog_required: true is set in frontmatter, a CHANGELOG [Unreleased] entry is mandatory in the Documentation Finalization phase before release. Categorization rules: .claude/specs/changelog-spec.md.
- README: Include if features, CLI commands, screenshots, or version change
- User/dev docs: Include if behavior changes requiring user/developer knowledge
- Context files: Include if changes affect agent behavior or architectural patterns
- Project-level custom skills: Include if changes affect domain of a custom skill (new CLI commands, capability changes, workflow shifts); check
.claude/specs/skills-index.md for domain ownership
- Create doc tasks for the Documentation Finalization phase:
- CHANGELOG →
changelog-generator agent with changelog-generator skill
- README/docs →
documentation-writer agent with managing-readmes skill
- Context files →
documentation-writer agent (progressive disclosure: CLAUDE.md pointers only, detail in key-context)
- Project-level skills →
ai-artifacts-engineer (SPEC.md + SKILL.md) and documentation-writer (workflows)
- Keep docs minimal/usage-focused, not verbose
- Reference:
./references/doc-finalization-guidance.md for detailed heuristics
- Add "Model: haiku; Effort: adaptive" to doc tasks (or "Model: sonnet; Effort: adaptive" for skill SPEC updates — use
extended only if the SPEC authoring is unusually complex)
-
Optimize for Token Efficiency
- If total plan >800 lines: break into phase-specific files
- Pattern:
[feature-name]-v1/phase-[N]-[name].md
- Parent plan links to phase files
- Each phase file <800 lines
- See
./references/optimization-patterns.md
-
Generate Files
- Main plan:
docs/project_plans/implementation_plans/[category]/[feature-name]-v1.md
- Phase files (if needed):
docs/project_plans/implementation_plans/[category]/[feature-name]-v1/phase-[N]-[name].md
- Link phase files from parent plan
-
IntentTree SDLC Sync (gated: INTENTTREE_SDLC_SYNC=1)
Workspace/tree resolution, the INTENTTREE_SDLC_SYNC gate + default, and the human-vs-agent
workspace rule are defined once in .claude/rules/intenttree-integration.md — the single
config-story indirection point. This section is the planning-time capture recipe that consumes
that binding; do not re-derive the config here.
When the env var INTENTTREE_SDLC_SYNC=1 is set, run the following two-step sync after writing
the plan file to disk. This applies equally to PRDs, Implementation Plans, and Feature Contracts.
Binding in plan frontmatter (P1-T2). Author plans carry the binding so it is traceable and
overrides the project default (D2): set intenttree_workspace / intenttree_tree in the plan's
frontmatter (per ./references/plan-frontmatter-schema.md §5.1). When absent, capture resolves to
the project default in the integration rule (this repo: workspace agentic-os, tree
aos-intenttree).
Target the HUMAN/PROJECT workspace (D3). Project plans capture into the project's
human/project workspace (kind != agent; agentic-os, kind=project, for this repo) — not
an agent-kind scratch workspace. Ensure INTENTTREE_WORKSPACE resolves to it before applying.
Step A — dry-run preview (always run first):
itt sync import <plan-file>
Parses the artifact's YAML frontmatter (tasks[], feature_slug, doc_type) and prints what
would be registered and imported — no writes occur. Review the task count and frontmatter keys
before proceeding.
Step B — apply (after reviewing the preview):
itt sync import <plan-file> --apply --tree "${INTENTTREE_TREE:-<repo-intenttree-tree-id>}"
Registers the plan file as a SourceArtifact and projects its tasks[] subtree onto the shared
node in the repo's IntentTree tree. The CLI stamps the resulting intenttree_node (the bound node
ID) and intenttree_tree (the target tree ID) back into the artifact's YAML frontmatter so the
binding is traceable from the markdown file itself.
Invariants (from the AWPR v2 contract):
- Markdown stays canonical — source→node only. The node tree is a derived projection.
Manual writeback (
WritebackPolicy: MANUAL) is the default; the node never overwrites the file.
- Every import is idempotent: re-running with unchanged source is a no-op (no duplicate nodes).
- The step is best-effort / non-fatal when offline — if the IntentTree API is unreachable
(e.g., rocket-fedora node is down), log the error and continue. Do not block plan authoring.
- Unknown frontmatter fields survive verbatim in
binding.raw_source_task.
References:
- Contract:
docs/project_plans/implementation_plans/features/awpr-v2-task-node-contract.md
- CLI source:
client/src/intenttree_client/cli/commands/sync_cmd.py
- Plan task: TASK-6.1 (FR-10, skill-wiring phase of AWPR v2)
Output:
- Implementation Plan at determined location
- Phase breakdown with subagent assignments
- Linked phase files if plan >800 lines
- Quality gates and success criteria per phase
Example:
Input PRD: docs/project_plans/PRDs/features/realtime-collaboration-v1.md
Output:
Main Plan: docs/project_plans/implementation_plans/features/realtime-collaboration-v1.md
Phase Breakdown:
- Phase 1: Database Layer (websocket_sessions, edit_locks tables) - data-layer-expert
- Phase 2: Repository Layer (session management, lock management) - python-backend-engineer
- Phase 3: Service Layer (operational transforms, conflict resolution) - backend-architect
- Phase 4: API Layer (WebSocket endpoints, presence API) - python-backend-engineer
- Phase 5: UI Layer (collaborative editor, presence indicators) - ui-engineer-enhanced, frontend-developer
- Phase 6: Testing (unit, integration, E2E conflict scenarios) - testing agents
- Phase 7: Documentation (API docs, user guides) - documentation-writer
- Phase 8: Deployment (feature flags, monitoring) - DevOps
Phase Files (if plan >800 lines):
- realtime-collaboration-v1/phase-1-database.md
- realtime-collaboration-v1/phase-2-repository.md
- realtime-collaboration-v1/phase-3-5-backend.md (grouped related phases)
- realtime-collaboration-v1/phase-6-8-validation.md (grouped related phases)
Workflow 3: Optimize Existing Plans
Input: Path to existing PRD or Implementation Plan that's >800 lines
Process:
-
Analyze Plan
- Read full plan
- Count total lines
- Identify natural break points (phases, sections)
- Determine optimal split strategy
-
Determine Breakout Strategy
- Primary: Break by phase (most common)
- Secondary: Break by domain (backend vs frontend)
- Tertiary: Break by task type (implementation vs testing)
- Goal: Each file <800 lines, logically cohesive
-
Create Breakout Files
- Pattern:
[plan-name]/phase-[N]-[name].md
- Alternative:
[plan-name]/[domain]-tasks.md
- Each file includes:
- Phase/section overview
- Relevant tasks with subagent assignments
- Quality gates for that section
- Links back to parent plan
-
Update Parent Plan
-
Validate Optimization
- Each file <800 lines ✓
- All content preserved ✓
- Links work correctly ✓
- Logical grouping maintained ✓
- Progressive disclosure achieved ✓
Output:
- Optimized parent plan (summary + links)
- Breakout files for detailed content
- Improved token efficiency (95%+ reduction in single-load context)
Example:
Input: docs/project_plans/implementation_plans/harden-polish/sidebar-polish-v1.md (1200 lines)
Analysis:
- 8 phases, ~150 lines each
- Can group related phases: 1-3 (backend), 4-5 (frontend), 6-8 (validation)
Output:
Parent: sidebar-polish-v1.md (200 lines - summary + links)
Phase Files:
- sidebar-polish-v1/phase-1-3-backend.md (450 lines)
- sidebar-polish-v1/phase-4-5-frontend.md (400 lines)
- sidebar-polish-v1/phase-6-8-validation.md (350 lines)
Token Efficiency:
- Before: Load 1200 lines for any query
- After: Load 200-line summary, then specific phase (450 max) = 67% reduction
Workflow 4: Create Progress Tracking
Input: PRD or Implementation Plan
Process:
Utilize artifact-tracking skill to create progress tracking and context artifacts per the skill instructions.
You should NOT create these files from this skill, as there are specific optimizations and structures required by the artifact-tracking skill.
Workflow 5: Create Human Brief for Feature
Input: PRD path + Implementation Plan path (both required when they exist)
Spec reference: .claude/specs/artifact-structures/human-brief-spec.md
Process:
-
Check creation heuristic (§4 of spec) — create a brief when any of these are true:
- Feature is ≥8 story points estimated
- Implementation plan has ≥2 phases
- Estimation Sanity Check has non-trivial anchor comparison
- ≥2 deferred items with non-trivial rationale
- Feature spans ≥2 capability areas
- Notable orchestration complexity (wave coordination, cross-team dependencies)
Skip when: quick feature (<5 pts, single phase), trivial refactor, single-file fix.
-
Scaffold the brief at docs/project_plans/human-briefs/[feature-slug].md
- Use template:
./templates/human-brief-template.md
- No
-v1 suffix — briefs are living documents, not versioned deliverables
- Set
prd_ref, plan_ref, feature_slug, owner, status: draft
-
Populate on creation:
- §1 Context Pointers: one-line links to PRD, plan, design specs, SPIKEs
- §2 Estimation Sanity Check: migrate H1–H6 output from planning step 3.5
- §4 Open Questions Ledger: harvest
OQ-* markers from PRD and plan
- §8 Expected Success Behaviors: extract human-verifiable outcomes from PRD acceptance criteria
-
Populate as information becomes available:
- §3 Wave & Orchestration Notes — after phase structure is finalized
- §5 Deferred Items Rationale — after triage table in plan is populated
- §6 Risk Narrative — after risk section in plan is written
- §7 What to Watch For — before or during execution
- §9 Running Log — append-only during execution
-
Set brief as in-progress when execution begins; completed when feature ships.
Output: docs/project_plans/human-briefs/[feature-slug].md
Agents must not load this file during execution (see Agent Consumption Rule below and spec §5).
Token Discipline (Planning Workflows)
These rules apply to all planning workflows in this skill. They codify the existing project-wide budget discipline for the planning context specifically.
Reference: .claude/rules/context-budget.md (global rules); .claude/plans/tiered-workflow-overhaul.md §4.9
The Feature Contract (or Decisions Block) Is the Delta
The Feature Contract (Tier 1) and the Opus Decisions Block (Tier 2/3) carry only the new decisions for this feature. All stable architectural context lives in durable docs and must not be restated in contracts or plans:
- Product intent:
intents/intent.md (when available)
- Current system state:
docs/current-state.md (when available)
- Architecture patterns:
docs/dev/architecture/* — link to these, do not copy from them
- Agent operating rules:
CLAUDE.md
Do not restate what is already in durable docs. Provide a path reference instead.
Prompt and Artifact Sizing
| What | Target |
|---|
| Task prompts to subagents | < 500 words |
| Opus decisions block | ~200 lines |
| Tier 1 Feature Contract | 200–400 lines |
| PRD (per doc) | ≤ 800 lines; split into phase files if exceeded |
| Context passed to subagents | File paths, not file contents |
Progressive Disclosure for Planners
When authoring contracts or decisions blocks, load context in this order — stop when you have enough:
- Contract or Decisions Block itself — the immediate planning surface.
- Relevant files — only files directly touched by this feature.
- Deep context docs (
key-context/, architecture docs) — only when blocked by an unresolved design question.
- Historical plans — only to confirm comparable estimates; verify behavior from runtime truth (
openapi.json, symbols-*.json), not from old plans.
Anti-Patterns (with token cost)
| Anti-pattern | Cost | Correct approach |
|---|
| Opus reads a full PRD before delegating to prd-writer | ~7K tokens | Delegate comprehension; provide file paths only |
| Restating CLAUDE.md patterns in the delegation prompt | ~5K tokens | Reference CLAUDE.md by path |
Calling TaskOutput() for plan-writing agents | ~7.5K tokens | Check file on disk with Glob + Read |
| Exploring files Opus will hand to a subagent | ~3–10K tokens | Let the subagent explore its own context |
Reviewer Gates (Summary Pointer)
Reviewer-agent passes are mandatory at tier-appropriate checkpoints. Planning artifacts are not complete until the matching reviewer has signed off.
| Tier | Gate | Reviewer |
|---|
| 1 | End of autonomous sprint | task-completion-validator |
| 2 | End of each phase | task-completion-validator |
| 2 | End of feature | karen |
| 3 | End of each phase | task-completion-validator |
| 3 | Mid-feature milestones + end of feature | karen |
A phase or sprint is not "complete" until the reviewer passes it. Do not commit before the gate clears.
Full gate definitions and reviewer output format: .claude/skills/dev-execution/validation/completion-criteria.md
Source: .claude/plans/tiered-workflow-overhaul.md §4.5
Templates Reference
prd-template.md
Location: ./templates/prd-template.md
Based On: /docs/docs-v2/templates/PRD-TEMPLATE.md
Purpose: Standard PRD structure for MeatyPrompts features
Key Sections:
- Feature Brief & Metadata (name, date, author, related docs)
- Executive Summary (1-2 paragraphs)
- Context & Background (problem space, current state)
- Problem Statement (clear gap or pain point)
- Goals & Success Metrics (measurable outcomes)
- Requirements (functional and non-functional)
- Scope (in-scope vs out-of-scope)
- Dependencies & Assumptions
- Risks & Mitigations
- Target State (post-implementation)
- Acceptance Criteria (definition of done)
- Implementation (phased breakdown with tasks)
When to Use: Creating any new PRD
implementation-plan-template.md
Location: ./templates/implementation-plan-template.md
Based On: /claude-export/templates/pm/implementation-plan-template.md
Purpose: Detailed phased implementation with task breakdown
Key Sections:
- Executive Summary (approach, milestones, success criteria)
- Implementation Strategy (architecture sequence, parallel work, critical path)
- Phase Breakdown (8 standard phases with task tables)
- Risk Mitigation (technical and schedule risks)
- Resource Requirements (team composition, skills, infrastructure)
- Success Metrics (delivery, business, technical)
- Communication Plan (status reporting, escalation)
- Post-Implementation Plan (monitoring, maintenance)
When to Use: Creating implementation plan from PRD
phase-breakdown-template.md
Location: ./templates/phase-breakdown-template.md
Purpose: Template for individual phase files when breaking up long plans
Key Sections:
- Phase overview (duration, dependencies, team)
- Task breakdown table (ID, name, description, acceptance criteria, estimate, assignee)
- Subagent assignments
- Quality gates
- Key files and integration points
- Link back to parent plan
When to Use: Breaking long implementation plans into phase-specific files
feature-contract-template.md
Location: ./templates/feature-contract-template.md
Purpose: Single-file artifact for Tier 1 features (3–8 pts) replacing the PRD + Implementation Plan pair
Key Sections:
- Goal, User/Actor, Job To Be Done, Scope (in/out)
- UX/Behavior Requirements, Data Requirements, API/Integration Requirements
- Architecture Constraints, Acceptance Criteria, Validation Requirements
- Risk Areas, Implementation Notes, Completion Report Required
Frontmatter includes: doc_type: feature_contract, tier: 1, estimated_points, changelog_required
When to Use: Tier 1 features; see "Workflow: Tier 1 Feature Contract" above
decisions-block-template.md
Location: ./templates/decisions-block-template.md
Purpose: Opus-authored scaffold (~200 lines) for Tier 2/3 features; defines phase boundaries, agent routing, risk hotspots, estimation anchors, dependency map, and model routing. Expanded by implementation-planner (sonnet) into the full plan.
Key Sections:
- Phase Boundaries (table: phase, name, scope, success criteria, exit gate)
- Agent Routing (primary + secondary per phase; parallel opportunities)
- Risk Hotspots (severity, rationale, mitigation per risk)
- Estimation Anchors (points per phase + comparable past feature)
- Dependency Map (critical path + mermaid graph)
- Model Routing (model + effort per phase per agent)
- Open Questions for Expansion (OQ-* markers for implementation-planner)
- Plan Skeleton Pointer (template path and output path)
When to Use: Any feature ≥ 8 pts (Tier 2 or 3); Opus authors directly before delegating to implementation-planner
Scripts Reference
All scripts are in ./scripts/ directory and use Node.js (NOT Python).
generate-prd.sh
Purpose: Generate PRD from feature request
Usage:
./scripts/generate-prd.sh "Feature description" "category"
Process:
- Parse feature description
- Determine category and filename
- Load PRD template
- Generate PRD content
- Write to
docs/project_plans/PRDs/[category]/[feature-name]-v1.md
Output: PRD file path
generate-impl-plan.sh
Purpose: Generate implementation plan from PRD
Usage:
./scripts/generate-impl-plan.sh "path/to/prd.md"
Process:
- Read PRD content
- Extract requirements and phases
- Generate task breakdown
- Add subagent assignments
- Determine if plan needs breakout (>800 lines)
- Write main plan and phase files
Output: Implementation plan file path(s)
optimize-plan.sh
Purpose: Break long plan into phase-specific files
Usage:
./scripts/optimize-plan.sh "path/to/plan.md"
Process:
- Read plan and count lines
- Determine optimal breakout strategy
- Create phase-specific files
- Update parent plan with links
- Validate all content preserved
Output: List of created phase files
References
estimation-heuristics.md
Location: ./references/estimation-heuristics.md
Purpose: Bottom-up sizing rules to prevent under-estimation. Codifies six heuristics — noun-counting (H1), dual-implementation multiplier (H2), algorithmic service flag (H3), bundle-vs-sum check (H4), anchor reference comparison (H5), hidden plumbing budget (H6) — and the mandatory "Estimation Sanity Check" template every implementation plan must populate.
Used By: Implementation plan authoring (mandatory sanity check), plan-review skill (post-mortem heuristic tuning).
When to load: Always, when creating or reviewing an implementation plan estimate.
subagent-assignments.md
Location: ./references/subagent-assignments.md
Purpose: Mapping of task types to appropriate subagents
Used By: Implementation planning, progress tracking creation
file-structure.md
Location: ./references/file-structure.md
Purpose: Directory structure conventions for plans and progress
Naming Conventions:
- PRDs:
[feature-name]-v1.md (kebab-case)
- Implementation Plans:
[feature-name]-v1.md
- Phase Files:
phase-[N]-[name].md or phase-[N]-[M]-[name].md (grouped)
Used By: File creation, optimization
optimization-patterns.md
Location: ./references/optimization-patterns.md
Purpose: Patterns for breaking up long files into token-efficient chunks
Content:
Pattern 1: Break by Phase (Most Common)
- Split implementation plan by phase (1-3, 4-5, 6-8)
- Each phase file <800 lines
- Parent links to phase files
- Progressive disclosure: Load summary, then specific phase
Pattern 2: Break by Domain
- Backend phases (Database, Repository, Service, API)
- Frontend phases (UI, Components, State)
- Validation phases (Testing, Docs, Deployment)
Pattern 3: Break by Task Type
- Implementation tasks
- Testing tasks
- Documentation tasks
- Deployment tasks
Pattern 4: Keep Together
- Always keep in parent plan:
- Executive summary
- Phase overview table
- Risk mitigation summary
- Success metrics overview
- Move to phase files:
- Detailed task breakdowns
- Specific acceptance criteria
- Technical implementation notes
Token Efficiency Gains:
- Before: Load entire 1200-line plan
- After: Load 200-line summary + 400-line phase = 50% reduction
- For targeted queries: Load only relevant phase = 67%+ reduction
Used By: Plan optimization workflow
Plan Generator Rules (Mandatory)
Apply these rules whenever generating or reviewing an implementation plan or any phase that contains ACs. These rules are non-negotiable; they catch the class of integration/verification gaps documented in the motivating incident (ccdash-planning-reskin-v2-interaction-performance-addendum).
- R-P1 — No AC may contain the words "across", "everywhere", "throughout", "all X", or "visible" without an explicit
target_surfaces: list. If the AC uses any of these terms without enumerating concrete component paths, the plan generator must expand the AC inline.
- R-P2 — Every new backend field X introduced in a phase introduces an implicit AC "FE handles missing X". If this AC is not already present, the generator writes it automatically. Resilience is a contract state, not a reviewer's courtesy.
- R-P3 — Every phase with ≥2 owner specialties (e.g., FE + BE) and overlapping
files_affected (intersection ≥1 file) must declare an integration_owner field and at least one seam task. A seam task is a task whose sole purpose is to verify the cross-owner propagation contract.
- R-P4 — UI-touching phases (any
*.tsx file in files_affected) must include a "runtime smoke" task in the verification phase. The smoke task must reference every target_surfaces entry from that phase.
AC schema for structured ACs (use this format whenever an AC covers multi-surface propagation or has resilience requirements):
#### AC [ID]: [Short description]
- target_surfaces:
# Use path strings (see §8 Q1 note in references/ac-schema.md).
- components/Planning/PlanningSummaryPanel.tsx
- components/Planning/PlanningGraphPanel.tsx
- propagation_contract: [how the value flows from producer to each surface]
- resilience: [how each surface behaves when the field is absent/null]
- visual_evidence_required: [screenshot spec, e.g. "desktop ≥1440px before/after" or false]
- verified_by: [list of task IDs in the verification phase that sign off this AC]
For the full AC schema reference and examples, see ./references/ac-schema.md.
Best Practices
File Size Management
Guideline: No file should exceed ~800 lines
Rationale:
- Optimal token efficiency for AI context loading
- Enables progressive disclosure pattern
- Reduces cognitive load for agents
- Faster file parsing and analysis
Strategies:
- Break plans by phase when >800 lines
- Group short related phases (1-3, 4-5)
- Keep summaries in parent, details in phase files
- Use links for cross-references
Naming Conventions
PRDs: [feature-name]-v1.md
- Use kebab-case (lowercase with hyphens)
- Include version number (-v1, -v2)
- Descriptive name (e.g.,
advanced-filtering-v1.md)
Implementation Plans: [feature-name]-v1.md
- Match PRD naming
- Same category as PRD
- Version synchronized with PRD
Phase Files: phase-[N]-[name].md
- Sequential numbering (phase-1, phase-2)
- Can group:
phase-1-3-backend.md
- Descriptive name (database, repository, frontend)
Directory Organization
PRDs:
docs/project_plans/PRDs/[category]/- Categories:
harden-polish, features, enhancements, refactors
Implementation Plans:
docs/project_plans/implementation_plans/[category]/- Match PRD category
- Phase breakouts in subdirectory:
[plan-name]/
Token Efficiency Tips
Progressive Disclosure:
- Summary in parent plan (200 lines)
- Link to detailed phase files (400 lines each)
- Agent loads summary first, then specific phase as needed
- 50-67% token reduction
Structured References:
- Link to ADRs instead of duplicating architecture info
- Reference existing docs rather than repeating
- Use relative paths for phase file links
Chunk by Logical Units:
- Keep related tasks together
- Don't split mid-phase
- Group short phases if logical
- Maintain quality gates with phases
YAML Frontmatter
PRDs:
---
title: "Feature Name - PRD"
description: "Brief summary (1-2 sentences)"
audience: [ai-agents, developers]
tags: [relevant, tags, for, search]
created: 2025-11-11
updated: 2025-11-11
category: "product-planning"
status: draft|published
related:
- /docs/architecture/ADRs/relevant-adr.md
- /docs/guides/relevant-guide.md
---
Implementation Plans:
---
title: "Feature Name - Implementation Plan"
description: "Brief summary of implementation approach"
audience: [ai-agents, developers]
tags: [implementation, planning, phases]
created: 2025-11-11
updated: 2025-11-11
category: "product-planning"
status: draft|in-progress|published
related:
- /docs/project_plans/PRDs/category/feature-name-v1.md
---
Design Specifications (schema v2, pre-PRD ideation):
---
schema_version: 2
doc_type: design_spec
title: "Feature Idea Name"
description: "Brief description of what's being designed"
status: draft
maturity: idea
created: 2026-04-08
updated: 2026-04-08
feature_slug: kebab-case-slug
problem_statement: "Clearly articulate the problem being solved (optional for early ideation)"
open_questions:
- "Question 1 blocking clarity?"
- "Question 2 to explore?"
explored_alternatives:
- "Option A considered: pros/cons"
- "Option B considered: pros/cons"
related_documents: []
prd_ref: null
---
Maturity progression: Update maturity field as design_spec evolves: idea → shaping → ready. When promoting to PRD, set maturity: promoted and add prd_ref: docs/project_plans/PRDs/[category]/[name]-v1.md.
Meta Plans (schema v2, process/tooling/workflow changes):
---
schema_version: 2
doc_type: meta_plan
title: "Meta Plan Title (e.g., 'Planning Document Cleanup')"
description: "What process/workflow/tooling is changing and why"
status: draft
scope: process|tooling|workflow|infrastructure|documentation|other
created: 2026-04-08
updated: 2026-04-08
owner: nick
affects_skills: [skill-name-1, skill-name-2]
affects_commands: [/command:name-1, /command:name-2]
outcome: "Expected result or success criteria (optional)"
related_documents: []
plan_ref: null
---
Scope values: Use process for team procedures, tooling for tool changes, workflow for execution patterns, infrastructure for system/deployment changes, documentation for doc updates, other for miscellaneous meta-work.
Examples
Example 1: Create PRD for Advanced Filtering
Input:
User: "Create a PRD for adding advanced filtering to the prompts page. Users need to filter by multiple criteria: model, provider, date range, tags, and favorites."
Process:
- Extract feature name: "Advanced Filtering"
- Determine category: "features"
- Generate PRD using template
- Structure sections:
- Problem: Users can only filter by single criteria
- Goals: Multi-criteria filtering, saved filter sets
- Requirements: UI for filter builder, backend filter query support
- Phases: Phase 1 (Backend), Phase 2 (Frontend), Phase 3 (Saved Filters)
Output:
File: docs/project_plans/PRDs/features/advanced-filtering-v1.md
# Advanced Filtering - PRD
**Feature Name**: Advanced Filtering
**Date**: 2025-11-11
**Author**: Claude (Sonnet 4.5)
**Related**: Filtering guides, search ADRs
## 1. Executive Summary
Enable users to filter prompts by multiple criteria simultaneously (model, provider, date range, tags, favorites) with the ability to save and reuse filter sets.
## 2. Context & Background
Current filtering supports single criteria only. Users frequently need to filter by combinations (e.g., "OpenAI models from last week tagged 'production'").
... (full PRD structure)
Example 2: Create Implementation Plan with Phase Breakout
Input:
User: "Create implementation plan for docs/project_plans/PRDs/features/advanced-filtering-v1.md"
Process:
- Read PRD, extract requirements
- Plan 7 phases following MP architecture
- Generate task breakdown with estimates
- Assign subagents to each task
- Calculate total: 1100 lines → needs breakout
- Create phase files:
- phase-1-3-backend.md (500 lines)
- phase-4-5-frontend.md (400 lines)
- phase-6-7-validation.md (300 lines)
- Update parent plan with links (200 lines)
Output:
Main Plan: docs/project_plans/implementation_plans/features/advanced-filtering-v1.md (200 lines)
# Implementation Plan: Advanced Filtering
## Phase Overview
| Phase | Title | Effort | Files |
|-------|-------|--------|-------|
| 1-3 | Backend Implementation | 18 pts | [Details](./advanced-filtering-v1/phase-1-3-backend.md) |
| 4-5 | Frontend Implementation | 12 pts | [Details](./advanced-filtering-v1/phase-4-5-frontend.md) |
| 6-7 | Validation & Deployment | 8 pts | [Details](./advanced-filtering-v1/phase-6-7-validation.md) |
... (executive summary, strategy)
---
Phase Files Created:
- advanced-filtering-v1/phase-1-3-backend.md (500 lines)
- Phase 1: Database (filter_sets table, indexes)
- Phase 2: Repository (query builder, filter sets repo)
- Phase 3: Service (filter validation, DTO mapping)
- advanced-filtering-v1/phase-4-5-frontend.md (400 lines)
- Phase 4: API (filter endpoints, saved sets API)
- Phase 5: UI (filter builder component, saved sets UI)
- advanced-filtering-v1/phase-6-7-validation.md (300 lines)
- Phase 6: Testing (unit, integration, E2E)
- Phase 7: Deployment (feature flags, monitoring)
Example 3: Optimize Existing Long Plan
Input:
User: "Optimize docs/project_plans/implementation_plans/harden-polish/sidebar-polish-v1.md - it's 1200 lines"
Process:
- Read plan: 8 phases, ~150 lines each
- Determine breakout: Group 1-3 (backend), 4-5 (frontend), 6-8 (validation)
- Create phase files:
- phase-1-3-backend.md (450 lines)
- phase-4-5-frontend.md (400 lines)
- phase-6-8-validation.md (350 lines)
- Update parent plan: Keep summary, add links to phase files (200 lines)
Output:
Updated: docs/project_plans/implementation_plans/harden-polish/sidebar-polish-v1.md (200 lines)
Created Phase Files:
- sidebar-polish-v1/phase-1-3-backend.md (450 lines)
Phase 1: Database - Sidebar state, user preferences
Phase 2: Repository - State management, RLS
Phase 3: Service - Preference sync, DTOs
- sidebar-polish-v1/phase-4-5-frontend.md (400 lines)
Phase 4: API - Endpoints for sidebar state
Phase 5: UI - Sidebar component, animations
- sidebar-polish-v1/phase-6-8-validation.md (350 lines)
Phase 6: Testing - Unit, integration, visual
Phase 7: Documentation - Component docs, API docs
Phase 8: Deployment - Feature flags, rollout
Token Efficiency: 67% reduction for targeted queries
Integration with Project Standards
Architecture Compliance
All plans follow project layered architecture.
Subagent Ecosystem
Plans integrate with 50+ project subagents:
Architecture: lead-architect, backend-architect, data-layer-expert
Development: python-backend-engineer, frontend-developer, ui-engineer-enhanced
UI/UX: ui-designer, ux-researcher
Review: code-reviewer, task-completion-validator
Documentation: documentation-writer, documentation-complex
Testing: testing specialists
Performance: react-performance-optimizer, web-accessibility-checker
Documentation Policy
Follows CLAUDE.md documentation policy:
- PRDs are product-planning docs (allowed)
- Implementation Plans are product-planning docs (allowed)
- NO reports, summaries, etc unless explicitly requested
File Organization
PRDs: /docs/project_plans/PRDs/[category]/[feature-name]-v1.md
Plans: /docs/project_plans/implementation_plans/[category]/[feature-name]-v1.md
Phase Files: [plan-name]/phase-[N]-[name].md
Advanced Usage
Customizing Templates
Edit templates in ./templates/ to match project needs:
