mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-13 16:13:03 +08:00
feat: add PRD planning command flow
This commit is contained in:
Affaan Mustafa
committed by
Affaan Mustafa
Affaan Mustafa
parent
940135ea47
commit
f8070dd640
154
docs/PLAN-PRD-PATTERN.md
Normal file
154
docs/PLAN-PRD-PATTERN.md
Normal file
@@ -0,0 +1,154 @@
|
||||
# Plan-PRD Pattern: Markdown-Staged Planning Flow
|
||||
|
||||
A lightweight, SDLC-aligned planning workflow where each phase of the lifecycle produces a committable markdown **staging file** that the next command consumes.
|
||||
|
||||
> Short version: `/plan-prd` writes a PRD, `/plan` writes a plan, the `tdd-workflow` skill implements it, and `/pr` ships it. Each arrow is a file on disk, not a conversation in memory.
|
||||
|
||||
## Feature: Markdown Staging Files
|
||||
|
||||
Every planning artifact is a plain `.md` file under `.claude/`:
|
||||
|
||||
```
|
||||
.claude/
|
||||
prds/ # Product Requirements Documents from /plan-prd
|
||||
plans/ # Implementation plans from /plan
|
||||
reviews/ # Code review artifacts from /code-review
|
||||
```
|
||||
|
||||
These files are:
|
||||
|
||||
- **Plain markdown** — readable by humans, diffable in PRs, grep-able at CLI.
|
||||
- **Committable** — check them in alongside code so the intent travels with the implementation.
|
||||
- **Composable** — each command accepts the previous stage's file as its `$ARGUMENTS`, so the toolchain composes via paths rather than in-context state.
|
||||
- **Resumable** — close the session, open a new one tomorrow, pass the file path back in.
|
||||
|
||||
## Flow
|
||||
|
||||
```
|
||||
┌───────────────────────────┐
|
||||
│ /plan-prd "<idea>" │ Requirements phase
|
||||
│ → .claude/prds/X.prd.md │ Problem · Users · Hypothesis · Scope
|
||||
└─────────────┬─────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────────────┐
|
||||
│ /plan <prd-path> │ Design phase
|
||||
│ → .claude/plans/X.plan.md│ Patterns · Files · Tasks · Validation
|
||||
└─────────────┬─────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────────────┐
|
||||
│ tdd-workflow skill │ Implementation phase
|
||||
│ → code + tests │ Test-first, minimal diff
|
||||
└─────────────┬─────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────────────┐
|
||||
│ /pr │ Delivery phase
|
||||
│ → GitHub PR │ Links back to PRD + plan
|
||||
└───────────────────────────┘
|
||||
```
|
||||
|
||||
Each box is a **gate**. You can:
|
||||
|
||||
- Stop between gates — the artifact persists.
|
||||
- Restart from any gate using the artifact path.
|
||||
- Skip gates for small work — feed `/plan` free-form text and ignore `/plan-prd`.
|
||||
- Run a gate standalone — `/plan "refactor X"` produces a conversational plan with no artifact.
|
||||
|
||||
## Why `/plan-prd` Is Additional to `/plan`
|
||||
|
||||
They answer different questions. Mixing them causes scope creep.
|
||||
|
||||
| Command | Answers | SDLC Phase | Artifact |
|
||||
|---|---|---|---|
|
||||
| `/plan-prd` | *What problem? For whom? How do we know we're done?* | Requirements | `.claude/prds/{name}.prd.md` |
|
||||
| `/plan` | *What files, patterns, and tasks satisfy the requirement?* | Design + Implementation strategy | `.claude/plans/{name}.plan.md` (PRD mode) or inline (text mode) |
|
||||
|
||||
### Why not combine them?
|
||||
|
||||
- **Separation of concerns.** PRDs ask *why*; plans ask *how*. Bundling them creates one oversized command that does both poorly, as the old `/prp-prd` → `/prp-plan` pair demonstrated (8-phase interrogation with implementation-phase tables mixed into requirements).
|
||||
- **Different audiences.** A stakeholder reviewing a PRD does not care about file paths or type-check commands. An engineer reading a plan does not need the market-research phase.
|
||||
- **Different lifespans.** A PRD can remain stable while its plan is rewritten multiple times as implementation assumptions change.
|
||||
- **Optional step.** Many changes (bug fixes, small refactors, single-file additions) don't need a PRD. `/plan` alone is enough. Forcing a PRD on every change is bureaucracy.
|
||||
|
||||
### When to use each
|
||||
|
||||
Use `/plan-prd` when:
|
||||
|
||||
- Scope is unclear or contested.
|
||||
- Multiple stakeholders need to align on the problem before solutioning.
|
||||
- The change is large enough that writing down the hypothesis is cheaper than relitigating scope mid-implementation.
|
||||
|
||||
Use `/plan` directly when:
|
||||
|
||||
- Requirements are already clear (a bug report, a scoped refactor, a known migration).
|
||||
- The work is small enough that a conversational plan + confirmation gate is sufficient.
|
||||
- You already have a PRD — pass it to `/plan` and skip `/plan-prd`.
|
||||
|
||||
## Usage
|
||||
|
||||
### Full flow (feature with unclear scope)
|
||||
|
||||
```bash
|
||||
# 1. Draft the PRD
|
||||
/plan-prd "Per-user rate limits on the public API"
|
||||
|
||||
# → .claude/prds/per-user-rate-limits.prd.md created
|
||||
# Answer the framing questions, provide evidence, define hypothesis and scope.
|
||||
|
||||
# 2. Pick the next pending milestone and produce a plan
|
||||
/plan .claude/prds/per-user-rate-limits.prd.md
|
||||
|
||||
# → .claude/plans/per-user-rate-limits.plan.md created
|
||||
# The plan includes patterns to mirror, files to change, and validation commands.
|
||||
# PRD's Delivery Milestones table updates the selected row to `in-progress`.
|
||||
|
||||
# 3. Implement test-first
|
||||
Use the tdd-workflow skill
|
||||
|
||||
# 4. Open the PR
|
||||
/pr
|
||||
# → PR body auto-references .claude/prds/... and .claude/plans/...
|
||||
```
|
||||
|
||||
### Quick flow (scope already clear)
|
||||
|
||||
```bash
|
||||
/plan "Add retry with exponential backoff to the notifier"
|
||||
# Conversational planning, no artifact.
|
||||
# Confirm, then use the tdd-workflow skill.
|
||||
```
|
||||
|
||||
### Reference an existing PRD from elsewhere
|
||||
|
||||
```bash
|
||||
# PRD was written by someone else, lives in your repo
|
||||
/plan docs/rfcs/0042-rate-limiting.prd.md
|
||||
```
|
||||
|
||||
`/plan` detects any `.prd.md` path and switches to artifact mode, parsing the Delivery Milestones table.
|
||||
|
||||
## Why staging files beat in-context state
|
||||
|
||||
- **Transferable**: drop the PRD path into a fresh session and you're caught up — no replaying a long conversation.
|
||||
- **Auditable**: the PR reviewer sees *what you intended* next to *what you built*.
|
||||
- **Versioned**: the staging file evolves in git history, same as code.
|
||||
- **Machine-parseable**: `/plan` programmatically picks the next pending milestone; `/pr` programmatically links artifacts in the PR body. No prompt engineering required.
|
||||
|
||||
## Related commands
|
||||
|
||||
- `/plan-prd` — requirements (this pattern entry point).
|
||||
- `/plan` — planning (consumes PRDs or free-form text).
|
||||
- `tdd-workflow` skill — test-first implementation.
|
||||
- `/pr` — open a PR that references PRDs and plans.
|
||||
- `/code-review` — reviews local diffs or PRs; auto-detects `.claude/prds/` and `.claude/plans/` as context.
|
||||
|
||||
## Compatibility
|
||||
|
||||
This pattern adds ECC-native staging-file commands alongside the existing `prp-*` command set. The legacy PRP commands remain available for deeper PRP workflows and for users who already have `.claude/PRPs/` artifacts.
|
||||
|
||||
- `/plan-prd` is the lean requirements entry point for `.claude/prds/`.
|
||||
- `/plan` can consume `.prd.md` files and produce `.claude/plans/` artifacts without requiring the legacy PRP directory layout.
|
||||
- `/pr` is the ECC-native PR creation command and can reference `.claude/prds/` and `.claude/plans/`.
|
||||
- `/prp-prd`, `/prp-plan`, `/prp-implement`, `/prp-commit`, and `/prp-pr` remain valid legacy/deep workflow commands.
|
||||
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — 智能体指令
|
||||
|
||||
这是一个**生产就绪的 AI 编码插件**，提供 56 个专业代理、217 项技能、72 条命令以及自动化钩子工作流，用于软件开发。
|
||||
这是一个**生产就绪的 AI 编码插件**，提供 56 个专业代理、217 项技能、74 条命令以及自动化钩子工作流，用于软件开发。
|
||||
|
||||
**版本:** 2.0.0-rc.1
|
||||
|
||||
@@ -148,7 +148,7 @@
|
||||
```
|
||||
agents/ — 56 个专业子代理
|
||||
skills/ — 217 个工作流技能和领域知识
|
||||
commands/ — 72 个斜杠命令
|
||||
commands/ — 74 个斜杠命令
|
||||
hooks/ — 基于触发的自动化
|
||||
rules/ — 始终遵循的指导方针（通用 + 每种语言）
|
||||
scripts/ — 跨平台 Node.js 实用工具
|
||||
|
||||
@@ -224,7 +224,7 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**搞定！** 你现在可以使用 56 个智能体、217 项技能和 72 个命令了。
|
||||
**搞定！** 你现在可以使用 56 个智能体、217 项技能和 74 个命令了。
|
||||
|
||||
***
|
||||
|
||||
@@ -1133,7 +1133,7 @@ opencode
|
||||
| 功能特性 | Claude Code | OpenCode | 状态 |
|
||||
|---------|-------------|----------|--------|
|
||||
| 智能体 | PASS: 56 个 | PASS: 12 个 | **Claude Code 领先** |
|
||||
| 命令 | PASS: 72 个 | PASS: 35 个 | **Claude Code 领先** |
|
||||
| 命令 | PASS: 74 个 | PASS: 35 个 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 217 项 | PASS: 37 项 | **Claude Code 领先** |
|
||||
| 钩子 | PASS: 8 种事件类型 | PASS: 11 种事件 | **OpenCode 更多！** |
|
||||
| 规则 | PASS: 29 条 | PASS: 13 条指令 | **Claude Code 领先** |
|
||||
@@ -1241,7 +1241,7 @@ ECC 是**第一个最大化利用每个主要 AI 编码工具的插件**。以
|
||||
| 功能特性 | Claude Code | Cursor IDE | Codex CLI | OpenCode |
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **智能体** | 56 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
|
||||
| **命令** | 72 | 共享 | 基于指令 | 35 |
|
||||
| **命令** | 74 | 共享 | 基于指令 | 35 |
|
||||
| **技能** | 217 | 共享 | 10 (原生格式) | 37 |
|
||||
| **钩子事件** | 8 种类型 | 15 种类型 | 暂无 | 11 种类型 |
|
||||
| **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | N/A | 插件钩子 |
|
||||
|
||||
Reference in New Issue
Block a user