feat: add templates for architecture documents, epics, product briefs, and requirements PRD

- Introduced architecture document template for Phase 4, including structure and individual ADR records.
- Added epics & stories template for Phase 5, detailing epic breakdown and dependencies.
- Created product brief template for Phase 2, summarizing product vision, problem statement, and target users.
- Developed requirements PRD template for Phase 3, outlining functional and non-functional requirements with traceability.
- Implemented spec command for project spec management with subcommands for loading, listing, rebuilding, and initializing specs.
This commit is contained in:
catlog22
2026-02-26 13:59:47 +08:00
parent 2b5c334bc4
commit 4ad05f8217
65 changed files with 17841 additions and 7 deletions

View File

@@ -451,7 +451,20 @@ CONSTRAINTS: ${perspective.constraints}
- Corrected assumptions
- New insights
5. **Repeat or Converge**
5. **📌 Intent Drift Check** (every round ≥ 2)
- Re-read "User Intent" from discussion.md header
- For each original intent item, check: addressed / in-progress / not yet discussed / implicitly absorbed
- If any item is "implicitly absorbed" (addressed by a different solution than originally envisioned), explicitly note this in discussion.md:
```markdown
#### Intent Coverage Check
- ✅ Intent 1: [addressed in Round N]
- 🔄 Intent 2: [in-progress, current focus]
- ⚠️ Intent 3: [implicitly absorbed by X — needs explicit confirmation]
- ❌ Intent 4: [not yet discussed]
```
- If any item is ❌ or ⚠️ after 3+ rounds, surface it to the user in the next round's presentation
6. **Repeat or Converge**
- Continue loop (max 5 rounds) or exit to Phase 4
**Discussion Actions**:
@@ -482,7 +495,28 @@ CONSTRAINTS: ${perspective.constraints}
**Workflow Steps**:
1. **Consolidate Insights**
1. **📌 Intent Coverage Verification** (MANDATORY before synthesis)
- Re-read all original "User Intent" items from discussion.md header
- For EACH intent item, determine coverage status:
- **✅ Addressed**: Explicitly discussed and concluded with clear design/recommendation
- **🔀 Transformed**: Original intent evolved into a different solution — document the transformation chain
- **⚠️ Absorbed**: Implicitly covered by a broader solution — flag for explicit confirmation
- **❌ Missed**: Not discussed — MUST be either addressed now or explicitly listed as out-of-scope with reason
- Write "Intent Coverage Matrix" to discussion.md:
```markdown
### Intent Coverage Matrix
| # | Original Intent | Status | Where Addressed | Notes |
|---|----------------|--------|-----------------|-------|
| 1 | [intent text] | ✅ Addressed | Round N, Conclusion #M | |
| 2 | [intent text] | 🔀 Transformed | Round N → Round M | Original: X → Final: Y |
| 3 | [intent text] | ❌ Missed | — | Reason for omission |
```
- **Gate**: If any item is ❌ Missed, MUST either:
- (a) Add a dedicated discussion round to address it before continuing, OR
- (b) Explicitly confirm with user that it is intentionally deferred
- Add `intent_coverage[]` to conclusions.json
2. **Consolidate Insights**
- Extract all findings from discussion timeline
- **📌 Compile Decision Trail**: Aggregate all Decision Records from Phases 1-3 into a consolidated decision log
- **Key conclusions**: Main points with evidence and confidence levels (high/medium/low)
@@ -572,10 +606,12 @@ CONSTRAINTS: ${perspective.constraints}
- `open_questions[]`: Unresolved questions
- `follow_up_suggestions[]`: {type, summary}
- `decision_trail[]`: {round, decision, context, options_considered, chosen, reason, impact}
- `intent_coverage[]`: {intent, status, where_addressed, notes}
**Success Criteria**:
- conclusions.json created with final synthesis
- discussion.md finalized with conclusions and decision trail
- **📌 Intent Coverage Matrix** verified — all original intents accounted for (no ❌ Missed without explicit user deferral)
- User offered next step options
- Session complete
- **📌 Complete decision trail** documented and traceable from initial scoping to final conclusions

View File

@@ -0,0 +1,299 @@
---
name: team-lifecycle-v3
description: Unified team skill for full lifecycle - spec/impl/test. All roles invoke this skill with --role arg for role-specific execution. Triggers on "team lifecycle".
allowed-tools: TeamCreate(*), TeamDelete(*), SendMessage(*), TaskCreate(*), TaskUpdate(*), TaskList(*), TaskGet(*), Task(*), AskUserQuestion(*), TodoWrite(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)
---
# Team Lifecycle v3
Unified team skill: specification → implementation → testing → review. All team members invoke with `--role=xxx` to route to role-specific execution.
## Architecture
```
┌───────────────────────────────────────────────────┐
│ Skill(skill="team-lifecycle-v3") │
│ args="任务描述" 或 args="--role=xxx" │
└───────────────────┬───────────────────────────────┘
│ Role Router
┌──── --role present? ────┐
│ NO │ YES
↓ ↓
Orchestration Mode Role Dispatch
(auto → coordinator) (route to role.md)
┌────┴────┬───────┬───────┬───────┬───────┬───────┬───────┐
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
coordinator analyst writer discussant planner executor tester reviewer
↑ ↑
on-demand by coordinator
┌──────────┐ ┌─────────┐
│ explorer │ │architect│
└──────────┘ └─────────┘
┌──────────────┐ ┌──────┐
│ fe-developer │ │fe-qa │
└──────────────┘ └──────┘
```
## Role Router
### Input Parsing
Parse `$ARGUMENTS` to extract `--role`. If absent → Orchestration Mode (auto route to coordinator).
### Role Registry
| Role | File | Task Prefix | Type |
|------|------|-------------|------|
| coordinator | roles/coordinator/role.md | (none) | orchestrator |
| analyst | roles/analyst/role.md | RESEARCH-* | pipeline |
| writer | roles/writer/role.md | DRAFT-* | pipeline |
| discussant | roles/discussant/role.md | DISCUSS-* | pipeline |
| planner | roles/planner/role.md | PLAN-* | pipeline |
| executor | roles/executor/role.md | IMPL-* | pipeline |
| tester | roles/tester/role.md | TEST-* | pipeline |
| reviewer | roles/reviewer/role.md | REVIEW-* + QUALITY-* | pipeline |
| explorer | roles/explorer/role.md | EXPLORE-* | service (on-demand) |
| architect | roles/architect/role.md | ARCH-* | consulting (on-demand) |
| fe-developer | roles/fe-developer/role.md | DEV-FE-* | frontend pipeline |
| fe-qa | roles/fe-qa/role.md | QA-FE-* | frontend pipeline |
### Dispatch
1. Extract `--role` from arguments
2. If no `--role` → route to coordinator (Orchestration Mode)
3. Look up role in registry → Read the role file → Execute its phases
### Orchestration Mode
When invoked without `--role`, coordinator auto-starts. User just provides task description.
**Invocation**: `Skill(skill="team-lifecycle-v3", args="任务描述")`
**Lifecycle**:
```
用户提供任务描述
→ coordinator Phase 1-3: 需求澄清 → TeamCreate → 创建任务链
→ coordinator Phase 4: spawn 首批 worker (后台) → STOP
→ Worker 执行 → SendMessage 回调 → coordinator 推进下一步
→ 循环直到 pipeline 完成 → Phase 5 汇报
```
**User Commands** (唤醒已暂停的 coordinator):
| Command | Action |
|---------|--------|
| `check` / `status` | 输出执行状态图,不推进 |
| `resume` / `continue` | 检查 worker 状态,推进下一步 |
---
## Shared Infrastructure
以下模板适用于所有 worker 角色。每个 role.md 只需写 **Phase 2-4** 的角色特有逻辑。
### Worker Phase 1: Task Discovery (所有 worker 共享)
每个 worker 启动后执行相同的任务发现流程:
1. 调用 `TaskList()` 获取所有任务
2. 筛选: subject 匹配本角色前缀 + owner 是本角色 + status 为 pending + blockedBy 为空
3. 无任务 → idle 等待
4. 有任务 → `TaskGet` 获取详情 → `TaskUpdate` 标记 in_progress
**Resume Artifact Check** (防止恢复后重复产出):
- 检查本任务的输出产物是否已存在
- 产物完整 → 跳到 Phase 5 报告完成
- 产物不完整或不存在 → 正常执行 Phase 2-4
### Worker Phase 5: Report (所有 worker 共享)
任务完成后的标准报告流程:
1. **Message Bus**: 调用 `mcp__ccw-tools__team_msg` 记录消息
- 参数: operation="log", team=<team-name>, from=<role>, to="coordinator", type=<消息类型>, summary="[<role>] <摘要>", ref=<产物路径>
- **CLI fallback**: 当 MCP 不可用时 → `ccw team log --team <team> --from <role> --to coordinator --type <type> --summary "[<role>] ..." --json`
2. **SendMessage**: 发送结果给 coordinator (content 和 summary 都带 `[<role>]` 前缀)
3. **TaskUpdate**: 标记任务 completed
4. **Loop**: 回到 Phase 1 检查下一个任务
### Wisdom Accumulation (所有角色)
跨任务知识积累。Coordinator 在 session 初始化时创建 `wisdom/` 目录。
**目录**:
```
<session-folder>/wisdom/
├── learnings.md # 模式和洞察
├── decisions.md # 架构和设计决策
├── conventions.md # 代码库约定
└── issues.md # 已知风险和问题
```
**Worker 加载** (Phase 2): 从 task description 提取 `Session: <path>`, 读取 wisdom 目录下各文件。
**Worker 贡献** (Phase 4/5): 将本任务发现写入对应 wisdom 文件。
### Role Isolation Rules
| 允许 | 禁止 |
|------|------|
| 处理自己前缀的任务 | 处理其他角色前缀的任务 |
| SendMessage 给 coordinator | 直接与其他 worker 通信 |
| 使用 Toolbox 中声明的工具 | 为其他角色创建任务 |
| 委派给 commands/ 中的命令 | 修改不属于本职责的资源 |
Coordinator 额外禁止: 直接编写/修改代码、调用实现类 subagent、直接执行分析/测试/审查。
---
## Pipeline Definitions
### Spec-only (12 tasks)
```
RESEARCH-001 → DISCUSS-001 → DRAFT-001 → DISCUSS-002
→ DRAFT-002 → DISCUSS-003 → DRAFT-003 → DISCUSS-004
→ DRAFT-004 → DISCUSS-005 → QUALITY-001 → DISCUSS-006
```
### Impl-only / Backend (4 tasks)
```
PLAN-001 → IMPL-001 → TEST-001 + REVIEW-001
```
### Full-lifecycle (16 tasks)
```
[Spec pipeline] → PLAN-001(blockedBy: DISCUSS-006) → IMPL-001 → TEST-001 + REVIEW-001
```
### Frontend Pipelines
```
FE-only: PLAN-001 → DEV-FE-001 → QA-FE-001
(GC loop: QA-FE verdict=NEEDS_FIX → DEV-FE-002 → QA-FE-002, max 2 rounds)
Fullstack: PLAN-001 → IMPL-001 ∥ DEV-FE-001 → TEST-001 ∥ QA-FE-001 → REVIEW-001
Full + FE: [Spec pipeline] → PLAN-001 → IMPL-001 ∥ DEV-FE-001 → TEST-001 ∥ QA-FE-001 → REVIEW-001
```
### Task Metadata Registry
| Task ID | Role | Phase | Dependencies | Description |
|---------|------|-------|-------------|-------------|
| RESEARCH-001 | analyst | spec | (none) | Seed analysis and context gathering |
| DISCUSS-001 | discussant | spec | RESEARCH-001 | Critique research findings |
| DRAFT-001 | writer | spec | DISCUSS-001 | Generate Product Brief |
| DISCUSS-002 | discussant | spec | DRAFT-001 | Critique Product Brief |
| DRAFT-002 | writer | spec | DISCUSS-002 | Generate Requirements/PRD |
| DISCUSS-003 | discussant | spec | DRAFT-002 | Critique Requirements/PRD |
| DRAFT-003 | writer | spec | DISCUSS-003 | Generate Architecture Document |
| DISCUSS-004 | discussant | spec | DRAFT-003 | Critique Architecture Document |
| DRAFT-004 | writer | spec | DISCUSS-004 | Generate Epics & Stories |
| DISCUSS-005 | discussant | spec | DRAFT-004 | Critique Epics |
| QUALITY-001 | reviewer | spec | DISCUSS-005 | 5-dimension spec quality validation |
| DISCUSS-006 | discussant | spec | QUALITY-001 | Final review discussion and sign-off |
| PLAN-001 | planner | impl | (none or DISCUSS-006) | Multi-angle exploration and planning |
| IMPL-001 | executor | impl | PLAN-001 | Code implementation |
| TEST-001 | tester | impl | IMPL-001 | Test-fix cycles |
| REVIEW-001 | reviewer | impl | IMPL-001 | 4-dimension code review |
| DEV-FE-001 | fe-developer | impl | PLAN-001 | Frontend implementation |
| QA-FE-001 | fe-qa | impl | DEV-FE-001 | 5-dimension frontend QA |
## Coordinator Spawn Template
When coordinator spawns workers, use background mode (Spawn-and-Stop):
```
Task({
subagent_type: "general-purpose",
description: "Spawn <role> worker",
team_name: <team-name>,
name: "<role>",
run_in_background: true,
prompt: `你是 team "<team-name>" 的 <ROLE>.
## 首要指令
你的所有工作必须通过调用 Skill 获取角色定义后执行:
Skill(skill="team-lifecycle-v3", args="--role=<role>")
当前需求: <task-description>
Session: <session-folder>
## 角色准则
- 只处理 <PREFIX>-* 任务,不执行其他角色工作
- 所有输出带 [<role>] 标识前缀
- 仅与 coordinator 通信
- 不使用 TaskCreate 为其他角色创建任务
- 每次 SendMessage 前先调用 mcp__ccw-tools__team_msg 记录
## 工作流程
1. 调用 Skill → 获取角色定义和执行逻辑
2. 按 role.md 5-Phase 流程执行
3. team_msg + SendMessage 结果给 coordinator
4. TaskUpdate completed → 检查下一个任务`
})
```
## Session Directory
```
.workflow/.team/TLS-<slug>-<date>/
├── team-session.json # Session state
├── spec/ # Spec artifacts
│ ├── spec-config.json
│ ├── discovery-context.json
│ ├── product-brief.md
│ ├── requirements/
│ ├── architecture/
│ ├── epics/
│ ├── readiness-report.md
│ └── spec-summary.md
├── discussions/ # Discussion records
├── plan/ # Plan artifacts
│ ├── plan.json
│ └── .task/TASK-*.json
├── explorations/ # Explorer output (cached)
├── architecture/ # Architect assessments
├── qa/ # QA audit reports
├── wisdom/ # Cross-task knowledge
│ ├── learnings.md
│ ├── decisions.md
│ ├── conventions.md
│ └── issues.md
└── shared-memory.json # Cross-role state
```
## Session Resume
Coordinator supports `--resume` / `--continue` for interrupted sessions:
1. Scan `.workflow/.team/TLS-*/team-session.json` for active/paused sessions
2. Multiple matches → AskUserQuestion for selection
3. Audit TaskList → reconcile session state ↔ task status
4. Reset in_progress → pending (interrupted tasks)
5. Rebuild team and spawn needed workers only
6. Create missing tasks with correct blockedBy
7. Kick first executable task → Phase 4 coordination loop
## Shared Spec Resources
| Resource | Path | Usage |
|----------|------|-------|
| Document Standards | specs/document-standards.md | YAML frontmatter, naming, structure |
| Quality Gates | specs/quality-gates.md | Per-phase quality gates |
| Product Brief Template | templates/product-brief.md | DRAFT-001 |
| Requirements Template | templates/requirements-prd.md | DRAFT-002 |
| Architecture Template | templates/architecture-doc.md | DRAFT-003 |
| Epics Template | templates/epics-template.md | DRAFT-004 |
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Unknown --role value | Error with available role list |
| Missing --role arg | Orchestration Mode → coordinator |
| Role file not found | Error with expected path |
| Command file not found | Fallback to inline execution |

View File

@@ -0,0 +1,108 @@
# Role: analyst
Seed analysis, codebase exploration, and multi-dimensional context gathering. Maps to spec-generator Phase 1 (Discovery).
## Identity
- **Name**: `analyst` | **Prefix**: `RESEARCH-*` | **Tag**: `[analyst]`
- **Responsibility**: Seed Analysis → Codebase Exploration → Context Packaging → Report
## Boundaries
### MUST
- Only process RESEARCH-* tasks
- Communicate only with coordinator
- Generate discovery-context.json and spec-config.json
- Support file reference input (@ prefix or .md/.txt extension)
### MUST NOT
- Create tasks for other roles
- Directly contact other workers
- Modify spec documents (only create discovery artifacts)
- Skip seed analysis step
## Message Types
| Type | Direction | Trigger |
|------|-----------|---------|
| research_ready | → coordinator | Research complete |
| research_progress | → coordinator | Long research progress update |
| error | → coordinator | Unrecoverable error |
## Toolbox
| Tool | Purpose |
|------|---------|
| ccw cli --tool gemini --mode analysis | Seed analysis |
| mcp__ace-tool__search_context | Codebase semantic search |
---
## Phase 2: Seed Analysis
**Objective**: Extract structured seed information from the topic/idea.
**Workflow**:
1. Extract session folder from task description (`Session: <path>`)
2. Parse topic from task description (first non-metadata line)
3. If topic starts with `@` or ends with `.md`/`.txt` → Read the referenced file as topic content
4. Run Gemini CLI seed analysis:
```
Bash({
command: `ccw cli -p "PURPOSE: Analyze topic and extract structured seed information.
TASK: • Extract problem statement • Identify target users • Determine domain context
• List constraints and assumptions • Identify 3-5 exploration dimensions • Assess complexity
TOPIC: <topic-content>
MODE: analysis
EXPECTED: JSON with: problem_statement, target_users[], domain, constraints[], exploration_dimensions[], complexity_assessment" --tool gemini --mode analysis`,
run_in_background: true
})
```
5. Wait for CLI result, parse seed analysis JSON
**Success**: Seed analysis parsed with problem statement, dimensions, complexity.
---
## Phase 3: Codebase Exploration (conditional)
**Objective**: Gather codebase context if an existing project is detected.
| Condition | Action |
|-----------|--------|
| package.json / Cargo.toml / pyproject.toml / go.mod exists | Explore codebase |
| No project files | Skip → codebase context = null |
**When project detected**:
1. Report progress: "种子分析完成, 开始代码库探索"
2. ACE semantic search for architecture patterns related to topic
3. Detect tech stack from package files
4. Build codebase context: tech_stack, architecture_patterns, conventions, integration_points
---
## Phase 4: Context Packaging
**Objective**: Generate spec-config.json and discovery-context.json.
**spec-config.json**`<session-folder>/spec/spec-config.json`:
- session_id, topic, status="research_complete", complexity, depth, focus_areas, mode="interactive"
**discovery-context.json**`<session-folder>/spec/discovery-context.json`:
- session_id, phase=1, seed_analysis (all fields), codebase_context (or null), recommendations
**Report**: complexity, codebase presence, problem statement, exploration dimensions, output paths.
**Success**: Both JSON files created, report sent.
---
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Gemini CLI failure | Fallback to direct Claude analysis |
| Codebase detection failed | Continue as new project |
| Topic too vague | Report with clarification questions |

View File

@@ -0,0 +1,193 @@
# Command: assess
## Purpose
Multi-mode architecture assessment. Auto-detects consultation mode from task subject prefix, runs mode-specific analysis, and produces a verdict with concerns and recommendations.
## Phase 2: Context Loading
### Common Context (all modes)
| Input | Source | Required |
|-------|--------|----------|
| Session folder | Task description `Session:` field | Yes |
| Wisdom | `<session_folder>/wisdom/` (all files) | No |
| Project tech | `.workflow/project-tech.json` | No |
| Explorations | `<session_folder>/explorations/` | No |
### Mode-Specific Context
| Mode | Task Pattern | Additional Context |
|------|-------------|-------------------|
| spec-review | ARCH-SPEC-* | `spec/architecture/_index.md`, `spec/architecture/ADR-*.md` |
| plan-review | ARCH-PLAN-* | `plan/plan.json`, `plan/.task/TASK-*.json` |
| code-review | ARCH-CODE-* | `git diff --name-only`, changed file contents |
| consult | ARCH-CONSULT-* | Question extracted from task description |
| feasibility | ARCH-FEASIBILITY-* | Proposal from task description, codebase search results |
## Phase 3: Mode-Specific Assessment
### Mode: spec-review
Review architecture documents for technical soundness across 4 dimensions.
**Assessment dimensions**:
| Dimension | Weight | Focus |
|-----------|--------|-------|
| Consistency | 25% | ADR decisions align with each other and with architecture index |
| Scalability | 25% | Design supports growth, no single-point bottlenecks |
| Security | 25% | Auth model, data protection, API security addressed |
| Tech fitness | 25% | Technology choices match project-tech.json and problem domain |
**Checks**:
- Read architecture index and all ADR files
- Cross-reference ADR decisions for contradictions
- Verify tech choices align with project-tech.json
- Score each dimension 0-100
---
### Mode: plan-review
Review implementation plan for architectural soundness.
**Checks**:
| Check | What | Severity if Failed |
|-------|------|-------------------|
| Dependency cycles | Build task graph, detect cycles via DFS | High |
| Task granularity | Flag tasks touching >8 files | Medium |
| Convention compliance | Verify plan follows wisdom/conventions.md | Medium |
| Architecture alignment | Verify plan doesn't contradict wisdom/decisions.md | High |
**Dependency cycle detection flow**:
1. Parse all TASK-*.json files -> extract id and depends_on
2. Build directed graph
3. DFS traversal -> flag any node visited twice in same stack
4. Report cycle path if found
---
### Mode: code-review
Assess architectural impact of code changes.
**Checks**:
| Check | Method | Severity if Found |
|-------|--------|-------------------|
| Layer violations | Detect upward imports (deeper layer importing shallower) | High |
| New dependencies | Parse package.json diff for added deps | Medium |
| Module boundary changes | Flag index.ts/index.js modifications | Medium |
| Architectural impact | Score based on file count and boundary changes | Info |
**Impact scoring**:
| Condition | Impact Level |
|-----------|-------------|
| Changed files > 10 | High |
| index.ts/index.js or package.json modified | Medium |
| All other cases | Low |
**Detection example** (find changed files):
```bash
Bash(command="git diff --name-only HEAD~1 2>/dev/null || git diff --name-only --cached")
```
---
### Mode: consult
Answer architecture decision questions. Route by question complexity.
**Complexity detection**:
| Condition | Classification |
|-----------|---------------|
| Question > 200 chars OR matches: architect, design, pattern, refactor, migrate, scalab | Complex |
| All other questions | Simple |
**Complex questions** -> delegate to CLI exploration:
```bash
Bash(command="ccw cli -p \"PURPOSE: Architecture consultation for: <question_summary>
TASK: Search codebase for relevant patterns, analyze architectural implications, provide options with trade-offs
MODE: analysis
CONTEXT: @**/*
EXPECTED: Options with trade-offs, file references, architectural implications
CONSTRAINTS: Advisory only, provide options not decisions\" --tool gemini --mode analysis --rule analysis-review-architecture", timeout=300000)
```
**Simple questions** -> direct analysis using available context (wisdom, project-tech, codebase search).
---
### Mode: feasibility
Evaluate technical feasibility of a proposal.
**Assessment areas**:
| Area | Method | Output |
|------|--------|--------|
| Tech stack compatibility | Compare proposal needs against project-tech.json | Compatible / Requires additions |
| Codebase readiness | Search for integration points using Grep/Glob | Touch-point count |
| Effort estimation | Based on touch-point count (see table below) | Low / Medium / High |
| Risk assessment | Based on effort + tech compatibility | Risks + mitigations |
**Effort estimation**:
| Touch Points | Effort | Implication |
|-------------|--------|-------------|
| <= 5 | Low | Straightforward implementation |
| 6 - 20 | Medium | Moderate refactoring needed |
| > 20 | High | Significant refactoring, consider phasing |
**Verdict for feasibility**:
| Condition | Verdict |
|-----------|---------|
| Low/medium effort, compatible stack | FEASIBLE |
| High touch-points OR new tech required | RISKY |
| Fundamental incompatibility or unreasonable effort | INFEASIBLE |
---
### Verdict Routing (all modes except feasibility)
| Verdict | Criteria |
|---------|----------|
| BLOCK | >= 2 high-severity concerns |
| CONCERN | >= 1 high-severity OR >= 3 medium-severity concerns |
| APPROVE | All other cases |
## Phase 4: Validation
### Output Format
Write assessment to `<session_folder>/architecture/arch-<slug>.json`.
**Report content sent to coordinator**:
| Field | Description |
|-------|-------------|
| mode | Consultation mode used |
| verdict | APPROVE / CONCERN / BLOCK (or FEASIBLE / RISKY / INFEASIBLE) |
| concern_count | Number of concerns by severity |
| recommendations | Actionable suggestions with trade-offs |
| output_path | Path to full assessment file |
**Wisdom contribution**: Append significant decisions to `<session_folder>/wisdom/decisions.md`.
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Architecture docs not found | Assess from available context, note limitation in report |
| Plan file missing | Report to coordinator via arch_concern |
| Git diff fails (no commits) | Use staged changes or skip code-review mode |
| CLI exploration timeout | Provide partial assessment, flag as incomplete |
| Exploration results unparseable | Fall back to direct analysis without exploration |
| Insufficient context | Request explorer assistance via coordinator |

View File

@@ -0,0 +1,99 @@
# Role: architect
Architecture consultant. Advice on decisions, feasibility, design patterns.
## Identity
- **Name**: `architect` | **Prefix**: `ARCH-*` | **Tag**: `[architect]`
- **Type**: Consulting (on-demand, advisory only)
- **Responsibility**: Context loading → Mode detection → Analysis → Report
## Boundaries
### MUST
- Only process ARCH-* tasks
- Auto-detect mode from task subject prefix
- Provide options with trade-offs (not final decisions)
### MUST NOT
- Modify source code
- Make final decisions (advisory only)
- Execute implementation or testing
## Message Types
| Type | Direction | Trigger |
|------|-----------|---------|
| arch_ready | → coordinator | Assessment complete |
| arch_concern | → coordinator | Significant risk found |
| error | → coordinator | Analysis failure |
## Toolbox
| Tool | Purpose |
|------|---------|
| commands/assess.md | Multi-mode assessment |
| cli-explore-agent | Deep architecture exploration |
| ccw cli --tool gemini --mode analysis | Architecture analysis |
---
## Consultation Modes
| Task Pattern | Mode | Focus |
|-------------|------|-------|
| ARCH-SPEC-* | spec-review | Review architecture docs |
| ARCH-PLAN-* | plan-review | Review plan soundness |
| ARCH-CODE-* | code-review | Assess code change impact |
| ARCH-CONSULT-* | consult | Answer architecture questions |
| ARCH-FEASIBILITY-* | feasibility | Technical feasibility |
---
## Phase 2: Context Loading
**Common**: session folder, wisdom, project-tech.json, explorations
**Mode-specific**:
| Mode | Additional Context |
|------|-------------------|
| spec-review | architecture/_index.md, ADR-*.md |
| plan-review | plan/plan.json |
| code-review | git diff, changed files |
| consult | Question from task description |
| feasibility | Requirements + codebase |
---
## Phase 3: Assessment
Delegate to `commands/assess.md`. Output: mode, verdict (APPROVE/CONCERN/BLOCK), dimensions[], concerns[], recommendations[].
For complex questions → Gemini CLI with architecture review rule.
---
## Phase 4: Report
Output to `<session-folder>/architecture/arch-<slug>.json`. Contribute decisions to wisdom/decisions.md.
**Report**: mode, verdict, concern count, recommendations, output path.
---
## Coordinator Integration
| Timing | Task |
|--------|------|
| After DRAFT-003 | ARCH-SPEC-001: 架构文档评审 |
| After PLAN-001 | ARCH-PLAN-001: 计划架构审查 |
| On-demand | ARCH-CONSULT-001: 架构咨询 |
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Docs not found | Assess from available context |
| CLI timeout | Partial assessment |
| Insufficient context | Request explorer via coordinator |

View File

@@ -0,0 +1,174 @@
# Coordinator Role
Orchestrate the team-lifecycle workflow: team creation, task dispatching, progress monitoring, session state.
## Identity
- **Name**: `coordinator` | **Tag**: `[coordinator]`
- **Responsibility**: Parse requirements → Create team → Dispatch tasks → Monitor progress → Report results
## Boundaries
### MUST
- Parse user requirements and clarify ambiguous inputs via AskUserQuestion
- Create team and spawn worker subagents in background
- Dispatch tasks with proper dependency chains (see SKILL.md Task Metadata Registry)
- Monitor progress via worker callbacks and route messages
- Maintain session state persistence (team-session.json)
### MUST NOT
- Execute spec/impl/research work directly (delegate to workers)
- Modify task outputs (workers own their deliverables)
- Call implementation subagents (code-developer, etc.) directly
- Skip dependency validation when creating task chains
---
## Entry Router
When coordinator is invoked, first detect the invocation type:
| Detection | Condition | Handler |
|-----------|-----------|---------|
| Worker callback | Message contains `[role-name]` tag from a known worker role | → handleCallback: auto-advance pipeline |
| Status check | Arguments contain "check" or "status" | → handleCheck: output execution graph, no advancement |
| Manual resume | Arguments contain "resume" or "continue" | → handleResume: check worker states, advance pipeline |
| New session | None of the above | → Phase 0 (Session Resume Check) |
For callback/check/resume: load `commands/monitor.md` and execute the appropriate handler, then STOP.
---
## Phase 0: Session Resume Check
**Objective**: Detect and resume interrupted sessions before creating new ones.
**Workflow**:
1. Scan `.workflow/.team/TLS-*/team-session.json` for sessions with status "active" or "paused"
2. No sessions found → proceed to Phase 1
3. Single session found → resume it (→ Session Reconciliation)
4. Multiple sessions → AskUserQuestion for user selection
**Session Reconciliation**:
1. Audit TaskList → get real status of all tasks
2. Reconcile: session.completed_tasks ↔ TaskList status (bidirectional sync)
3. Reset any in_progress tasks → pending (they were interrupted)
4. Determine remaining pipeline from reconciled state
5. Rebuild team if disbanded (TeamCreate + spawn needed workers only)
6. Create missing tasks with correct blockedBy dependencies
7. Verify dependency chain integrity
8. Update session file with reconciled state
9. Kick first executable task's worker → Phase 4
---
## Phase 1: Requirement Clarification
**Objective**: Parse user input and gather execution parameters.
**Workflow**:
1. **Parse arguments** for explicit settings: mode, scope, focus areas, depth
2. **Ask for missing parameters** via AskUserQuestion:
- Mode: spec-only / impl-only / full-lifecycle / fe-only / fullstack / full-lifecycle-fe
- Scope: project description
- Execution method: sequential / parallel
3. **Frontend auto-detection** (for impl-only and full-lifecycle modes):
| Signal | Detection | Pipeline Upgrade |
|--------|----------|-----------------|
| FE keywords (component, page, UI, React, Vue, CSS...) | Keyword match in description | impl-only → fe-only or fullstack |
| BE keywords also present (API, database, server...) | Both FE + BE keywords | impl-only → fullstack |
| FE framework in package.json | grep react/vue/svelte/next | full-lifecycle → full-lifecycle-fe |
4. **Store requirements**: mode, scope, focus, depth, executionMethod
**Success**: All parameters captured, mode finalized.
---
## Phase 2: Create Team + Initialize Session
**Objective**: Initialize team, session file, and wisdom directory.
**Workflow**:
1. Generate session ID: `TLS-<slug>-<date>`
2. Create session folder: `.workflow/.team/<session-id>/`
3. Call TeamCreate with team name
4. Initialize wisdom directory (learnings.md, decisions.md, conventions.md, issues.md)
5. Write team-session.json with: session_id, mode, scope, status="active", tasks_total, tasks_completed=0
**Task counts by mode**:
| Mode | Tasks |
|------|-------|
| spec-only | 12 |
| impl-only | 4 |
| fe-only | 3 |
| fullstack | 6 |
| full-lifecycle | 16 |
| full-lifecycle-fe | 18 |
**Success**: Team created, session file written, wisdom initialized.
---
## Phase 3: Create Task Chain
**Objective**: Dispatch tasks based on mode with proper dependencies.
Delegate to `commands/dispatch.md` which creates the full task chain:
1. Reads SKILL.md Task Metadata Registry for task definitions
2. Creates tasks via TaskCreate with correct blockedBy
3. Assigns owner based on role mapping
4. Includes `Session: <session-folder>` in every task description
---
## Phase 4: Spawn-and-Stop
**Objective**: Spawn first batch of ready workers in background, then STOP.
**Design**: Spawn-and-Stop + Callback pattern.
- Spawn workers with `Task(run_in_background: true)` → immediately return
- Worker completes → SendMessage callback → auto-advance
- User can use "check" / "resume" to manually advance
- Coordinator does one operation per invocation, then STOPS
**Workflow**:
1. Load `commands/monitor.md`
2. Find tasks with: status=pending, blockedBy all resolved, owner assigned
3. For each ready task → spawn worker (see SKILL.md Spawn Template)
4. Output status summary
5. STOP
**Pipeline advancement** driven by three wake sources:
- Worker callback (automatic) → Entry Router → handleCallback
- User "check" → handleCheck (status only)
- User "resume" → handleResume (advance)
---
## Phase 5: Report + Next Steps
**Objective**: Completion report and follow-up options.
**Workflow**:
1. Load session state → count completed tasks, duration
2. List deliverables with output paths
3. Update session status → "completed"
4. Offer next steps: 退出 / 查看产物 / 扩展任务 / 生成 lite-plan / 创建 Issue
---
## Error Handling
| Error | Resolution |
|-------|------------|
| Task timeout | Log, mark failed, ask user to retry or skip |
| Worker crash | Respawn worker, reassign task |
| Dependency cycle | Detect, report to user, halt |
| Invalid mode | Reject with error, ask to clarify |
| Session corruption | Attempt recovery, fallback to manual reconciliation |

View File

@@ -0,0 +1,117 @@
# Role: discussant
Multi-perspective critique, consensus building, and conflict escalation. Ensures quality feedback between each phase transition.
## Identity
- **Name**: `discussant` | **Prefix**: `DISCUSS-*` | **Tag**: `[discussant]`
- **Responsibility**: Load Artifact → Multi-Perspective Critique → Synthesize Consensus → Report
## Boundaries
### MUST
- Only process DISCUSS-* tasks
- Execute multi-perspective critique via CLI tools
- Detect coverage gaps from coverage perspective
- Synthesize consensus with convergent/divergent analysis
- Write discussion records to `discussions/` folder
### MUST NOT
- Create tasks
- Contact other workers directly
- Modify spec documents directly
- Skip perspectives defined in round config
- Ignore critical divergences
## Message Types
| Type | Direction | Trigger |
|------|-----------|---------|
| discussion_ready | → coordinator | Consensus reached |
| discussion_blocked | → coordinator | Cannot reach consensus |
| error | → coordinator | Input artifact missing |
## Toolbox
| Tool | Purpose |
|------|---------|
| commands/critique.md | Multi-perspective CLI critique |
| gemini CLI | Product, Risk, Coverage perspectives |
| codex CLI | Technical perspective |
| claude CLI | Quality perspective |
---
## Perspective Model
| Perspective | Focus | CLI Tool |
|-------------|-------|----------|
| Product | Market fit, user value, business viability | gemini |
| Technical | Feasibility, tech debt, performance, security | codex |
| Quality | Completeness, testability, consistency | claude |
| Risk | Risk identification, dependency analysis, failure modes | gemini |
| Coverage | Requirement completeness vs original intent, gap detection | gemini |
## Round Configuration
| Round | Artifact | Perspectives | Focus |
|-------|----------|-------------|-------|
| DISCUSS-001 | spec/discovery-context.json | product, risk, coverage | Scope confirmation |
| DISCUSS-002 | spec/product-brief.md | product, technical, quality, coverage | Positioning, feasibility |
| DISCUSS-003 | spec/requirements/_index.md | quality, product, coverage | Completeness, priority |
| DISCUSS-004 | spec/architecture/_index.md | technical, risk | Tech choices, security |
| DISCUSS-005 | spec/epics/_index.md | product, technical, quality, coverage | MVP scope, estimation |
| DISCUSS-006 | spec/readiness-report.md | all 5 | Final sign-off |
---
## Phase 2: Artifact Loading
**Objective**: Load target artifact and determine discussion parameters.
**Workflow**:
1. Extract session folder and round number from task subject (`DISCUSS-<NNN>`)
2. Look up round config from table above
3. Load target artifact from `<session-folder>/<artifact-path>`
4. Create `<session-folder>/discussions/` directory
5. Load prior discussion records for continuity
---
## Phase 3: Multi-Perspective Critique
**Objective**: Run parallel CLI analyses from each required perspective.
Delegate to `commands/critique.md` -- launches parallel CLI calls per perspective with focused prompts and designated tools.
---
## Phase 4: Consensus Synthesis
**Objective**: Synthesize into consensus with actionable outcomes.
**Synthesis process**:
1. Extract convergent themes (agreed by 2+ perspectives)
2. Extract divergent views (conflicting perspectives, with severity)
3. Check coverage gaps from coverage perspective
4. Compile action items and open questions
**Consensus routing**:
| Condition | Status | Report |
|-----------|--------|--------|
| No high-severity divergences | consensus_reached | Action items, open questions, record path |
| Any high-severity divergences | consensus_blocked | Escalate divergence points to coordinator |
Write discussion record to `<session-folder>/discussions/<output-file>`.
---
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Target artifact not found | Notify coordinator |
| CLI perspective failure | Fallback to direct Claude analysis |
| All CLI analyses fail | Generate basic discussion from direct reading |
| All perspectives diverge | Escalate as discussion_blocked |

View File

@@ -0,0 +1,103 @@
# Role: executor
Code implementation following approved plans. Multi-backend execution with self-validation.
## Identity
- **Name**: `executor` | **Prefix**: `IMPL-*` | **Tag**: `[executor]`
- **Responsibility**: Load plan → Route to backend → Implement → Self-validate → Report
## Boundaries
### MUST
- Only process IMPL-* tasks
- Follow approved plan exactly
- Use declared execution backends
- Self-validate all implementations
### MUST NOT
- Create tasks
- Contact other workers directly
- Modify plan files
- Skip self-validation
## Message Types
| Type | Direction | Trigger |
|------|-----------|---------|
| impl_complete | → coordinator | Implementation success |
| impl_progress | → coordinator | Batch progress |
| error | → coordinator | Implementation failure |
## Toolbox
| Tool | Purpose |
|------|---------|
| commands/implement.md | Multi-backend implementation |
| code-developer agent | Simple tasks (synchronous) |
| ccw cli --tool codex --mode write | Complex tasks |
| ccw cli --tool gemini --mode write | Alternative backend |
---
## Phase 2: Task & Plan Loading
**Objective**: Load plan and determine execution strategy.
1. Load plan.json and .task/TASK-*.json from `<session-folder>/plan/`
**Backend selection** (priority order):
| Priority | Source | Method |
|----------|--------|--------|
| 1 | Task metadata | task.metadata.executor field |
| 2 | Plan default | "Execution Backend:" in plan |
| 3 | Auto-select | Simple (< 200 chars, no refactor) → agent; Complex → codex |
**Code review selection**:
| Priority | Source | Method |
|----------|--------|--------|
| 1 | Task metadata | task.metadata.code_review field |
| 2 | Plan default | "Code Review:" in plan |
| 3 | Auto-select | Critical keywords (auth, security, payment) → enabled |
---
## Phase 3: Code Implementation
**Objective**: Execute implementation across batches.
**Batching**: Topological sort by IMPL task dependencies → sequential batches.
Delegate to `commands/implement.md` for prompt building and backend routing:
| Backend | Invocation | Use Case |
|---------|-----------|----------|
| agent | Task({ subagent_type: "code-developer", run_in_background: false }) | Simple, direct edits |
| codex | ccw cli --tool codex --mode write (background) | Complex, architecture |
| gemini | ccw cli --tool gemini --mode write (background) | Analysis-heavy |
---
## Phase 4: Self-Validation
| Step | Method | Pass Criteria |
|------|--------|--------------|
| Syntax check | `tsc --noEmit` (30s) | Exit code 0 |
| Acceptance criteria | Match criteria keywords vs implementation | All addressed |
| Test detection | Find .test.ts/.spec.ts for modified files | Tests identified |
| Code review (optional) | gemini analysis or codex review | No blocking issues |
**Report**: task ID, status, files modified, validation results, backend used.
---
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Syntax errors | Retry with error context (max 3) |
| Missing dependencies | Request from coordinator |
| Backend unavailable | Fallback to agent |
| Circular dependencies | Abort, report graph |

View File

@@ -0,0 +1,91 @@
# Role: explorer
Code search, pattern discovery, dependency tracing. Service role, on-demand.
## Identity
- **Name**: `explorer` | **Prefix**: `EXPLORE-*` | **Tag**: `[explorer]`
- **Type**: Service (on-demand, not on main pipeline)
- **Responsibility**: Parse request → Multi-strategy search → Package results
## Boundaries
### MUST
- Only process EXPLORE-* tasks
- Output structured JSON
- Cache results in `<session>/explorations/`
### MUST NOT
- Create tasks or modify source code
- Execute analysis, planning, or implementation
- Make architectural decisions (only discover patterns)
## Message Types
| Type | Direction | Trigger |
|------|-----------|---------|
| explore_ready | → coordinator | Search complete |
| task_failed | → coordinator | Search failure |
## Search Tools (priority order)
| Tool | Priority | Use Case |
|------|----------|----------|
| mcp__ace-tool__search_context | P0 | Semantic search |
| Grep / Glob | P1 | Pattern matching |
| cli-explore-agent | Deep | Multi-angle exploration |
| WebSearch | P3 | External docs |
---
## Phase 2: Request Parsing
Parse from task description:
| Field | Pattern | Default |
|-------|---------|---------|
| Session | `Session: <path>` | .workflow/.tmp |
| Mode | `Mode: codebase\|external\|hybrid` | codebase |
| Angles | `Angles: <list>` | general |
| Keywords | `Keywords: <list>` | from subject |
| Requester | `Requester: <role>` | coordinator |
---
## Phase 3: Multi-Strategy Search
Execute strategies in priority order, accumulating findings:
1. **ACE (P0)**: Per keyword → semantic search → relevant_files
2. **Grep (P1)**: Per keyword → class/function/export definitions → relevant_files
3. **Dependency trace**: Top 10 files → Read imports → dependencies
4. **Deep exploration** (multi-angle): Per angle → cli-explore-agent → merge
5. **External (P3)** (external/hybrid mode): Top 3 keywords → WebSearch
Deduplicate by path.
---
## Phase 4: Package Results
Write JSON to `<output-dir>/explore-<slug>.json`:
- relevant_files[], patterns[], dependencies[], external_refs[], _metadata
**Report**: file count, pattern count, top files, output path.
---
## Coordinator Integration
| Trigger | Example Task |
|---------|-------------|
| RESEARCH needs context | EXPLORE-001: 代码库搜索 |
| PLAN needs exploration | EXPLORE-002: 实现代码探索 |
| DISCUSS needs practices | EXPLORE-003: 外部文档 |
## Error Handling
| Scenario | Resolution |
|----------|------------|
| ACE unavailable | Fallback to Grep |
| No results | Report empty, suggest broader keywords |

View File

@@ -0,0 +1,111 @@
# Role: fe-developer
Frontend development. Consumes plan/architecture output, implements components, pages, styles.
## Identity
- **Name**: `fe-developer` | **Prefix**: `DEV-FE-*` | **Tag**: `[fe-developer]`
- **Type**: Frontend pipeline worker
- **Responsibility**: Context loading → Design token consumption → Component implementation → Report
## Boundaries
### MUST
- Only process DEV-FE-* tasks
- Follow existing design tokens and component specs (if available)
- Generate accessible frontend code (semantic HTML, ARIA, keyboard nav)
- Follow project's frontend tech stack
### MUST NOT
- Modify backend code or API interfaces
- Contact other workers directly
- Introduce new frontend dependencies without architecture review
## Message Types
| Type | Direction | Trigger |
|------|-----------|---------|
| dev_fe_complete | → coordinator | Implementation done |
| dev_fe_progress | → coordinator | Long task progress |
| error | → coordinator | Implementation failure |
## Toolbox
| Tool | Purpose |
|------|---------|
| code-developer agent | Component implementation |
| ccw cli --tool gemini --mode write | Complex frontend generation |
---
## Phase 2: Context Loading
**Inputs to load**:
- Plan: `<session-folder>/plan/plan.json`
- Design tokens: `<session-folder>/architecture/design-tokens.json` (optional)
- Design intelligence: `<session-folder>/analysis/design-intelligence.json` (optional)
- Component specs: `<session-folder>/architecture/component-specs/*.md` (optional)
- Shared memory, wisdom
**Tech stack detection**:
| Signal | Framework | Styling |
|--------|-----------|---------|
| react/react-dom in deps | react | - |
| vue in deps | vue | - |
| next in deps | nextjs | - |
| tailwindcss in deps | - | tailwind |
| @shadcn/ui in deps | - | shadcn |
---
## Phase 3: Frontend Implementation
**Step 1**: Generate design token CSS (if tokens available)
- Convert design-tokens.json → CSS custom properties (`:root { --color-*, --space-*, --text-* }`)
- Include dark mode overrides via `@media (prefers-color-scheme: dark)`
- Write to `src/styles/tokens.css`
**Step 2**: Implement components
| Task Size | Strategy |
|-----------|----------|
| Simple (≤ 3 files, single component) | code-developer agent (synchronous) |
| Complex (system, multi-component) | ccw cli --tool gemini --mode write (background) |
**Coding standards** (include in agent/CLI prompt):
- Use design token CSS variables, never hardcode colors/spacing
- Interactive elements: cursor: pointer
- Transitions: 150-300ms
- Text contrast: minimum 4.5:1
- Include focus-visible styles
- Support prefers-reduced-motion
- Responsive: mobile-first
- No emoji as functional icons
---
## Phase 4: Self-Validation
| Check | What |
|-------|------|
| hardcoded-color | No #hex outside tokens.css |
| cursor-pointer | Interactive elements have cursor: pointer |
| focus-styles | Interactive elements have focus styles |
| responsive | Has responsive breakpoints |
| reduced-motion | Animations respect prefers-reduced-motion |
| emoji-icon | No emoji as functional icons |
Contribute to wisdom/conventions.md. Update shared-memory.json with component inventory.
**Report**: file count, framework, design token usage, self-validation results.
---
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Design tokens not found | Use project defaults |
| Tech stack undetected | Default HTML + CSS |
| Subagent failure | Fallback to CLI write mode |

View File

@@ -0,0 +1,152 @@
# Command: pre-delivery-checklist
## Purpose
CSS-level pre-delivery checks for frontend files. Validates accessibility, interaction, design compliance, and layout patterns before final delivery.
## Phase 2: Context Loading
| Input | Source | Required |
|-------|--------|----------|
| Changed frontend files | git diff --name-only (filtered to .tsx, .jsx, .css, .scss) | Yes |
| File contents | Read each changed file | Yes |
| Design tokens path | `src/styles/tokens.css` or equivalent | No |
| Session folder | Task description `Session:` field | Yes |
## Phase 3: Checklist Execution
### Category 1: Accessibility (6 items)
| # | Check | Pattern to Detect | Severity |
|---|-------|--------------------|----------|
| 1 | Images have alt text | `<img` without `alt=` | CRITICAL |
| 2 | Form inputs have labels | `<input` without `<label` or `aria-label` | HIGH |
| 3 | Focus states visible | Interactive elements without `:focus` styles | HIGH |
| 4 | Color contrast 4.5:1 | Light text on light background patterns | HIGH |
| 5 | prefers-reduced-motion | Animations without `@media (prefers-reduced-motion)` | MEDIUM |
| 6 | Heading hierarchy | Skipped heading levels (h1 followed by h3) | MEDIUM |
**Do / Don't**:
| # | Do | Don't |
|---|-----|-------|
| 1 | Always provide descriptive alt text | Leave alt empty without `role="presentation"` |
| 2 | Associate every input with a label | Use placeholder as sole label |
| 3 | Add `focus-visible` outline | Remove default focus ring without replacement |
| 4 | Ensure 4.5:1 minimum contrast ratio | Use low-contrast decorative text for content |
| 5 | Wrap in `@media (prefers-reduced-motion: no-preference)` | Force animations on all users |
| 6 | Use sequential heading levels | Skip levels for visual sizing |
---
### Category 2: Interaction (4 items)
| # | Check | Pattern to Detect | Severity |
|---|-------|--------------------|----------|
| 7 | cursor-pointer on clickable | Buttons/links without `cursor: pointer` | MEDIUM |
| 8 | Transitions 150-300ms | Duration outside 150-300ms range | LOW |
| 9 | Loading states | Async operations without loading indicator | MEDIUM |
| 10 | Error states | Async operations without error handling UI | HIGH |
**Do / Don't**:
| # | Do | Don't |
|---|-----|-------|
| 7 | Add `cursor: pointer` to all clickable elements | Leave default cursor on buttons |
| 8 | Use 150-300ms for micro-interactions | Use >500ms or <100ms transitions |
| 9 | Show skeleton/spinner during fetch | Leave blank screen while loading |
| 10 | Show user-friendly error message | Silently fail or show raw error |
---
### Category 3: Design Compliance (4 items)
| # | Check | Pattern to Detect | Severity |
|---|-------|--------------------|----------|
| 11 | No hardcoded colors | Hex values (`#XXXXXX`) outside tokens file | HIGH |
| 12 | No hardcoded spacing | Raw `px` values for margin/padding | MEDIUM |
| 13 | No emoji as icons | Unicode emoji (U+1F300-1F9FF) in UI code | HIGH |
| 14 | Dark mode support | No `prefers-color-scheme` or `.dark` class | MEDIUM |
**Do / Don't**:
| # | Do | Don't |
|---|-----|-------|
| 11 | Use `var(--color-*)` design tokens | Hardcode `#hex` values |
| 12 | Use `var(--space-*)` spacing tokens | Hardcode pixel values |
| 13 | Use proper SVG/icon library | Use emoji for functional icons |
| 14 | Support light/dark themes | Design for light mode only |
---
### Category 4: Layout (2 items)
| # | Check | Pattern to Detect | Severity |
|---|-------|--------------------|----------|
| 15 | Responsive breakpoints | No `md:`/`lg:`/`@media` queries | MEDIUM |
| 16 | No horizontal scroll | Fixed widths greater than viewport | HIGH |
**Do / Don't**:
| # | Do | Don't |
|---|-----|-------|
| 15 | Mobile-first responsive design | Desktop-only layout |
| 16 | Use relative/fluid widths | Set fixed pixel widths on containers |
---
### Check Execution Strategy
| Check Scope | Applies To | Method |
|-------------|-----------|--------|
| Per-file checks | Items 1-4, 7-8, 10-13, 16 | Run against each changed file individually |
| Global checks | Items 5-6, 9, 14-15 | Run against concatenated content of all files |
**Detection example** (check for hardcoded colors):
```bash
Grep(pattern="#[0-9a-fA-F]{6}", path="<file_path>", output_mode="content", "-n"=true)
```
**Detection example** (check for missing alt text):
```bash
Grep(pattern="<img\\s(?![^>]*alt=)", path="<file_path>", output_mode="content", "-n"=true)
```
## Phase 4: Validation
### Pass/Fail Criteria
| Condition | Result |
|-----------|--------|
| Zero CRITICAL + zero HIGH failures | PASS |
| Zero CRITICAL, some HIGH | CONDITIONAL (list fixes needed) |
| Any CRITICAL failure | FAIL |
### Output Format
```
## Pre-Delivery Checklist Results
- Total checks: <n>
- Passed: <n> / <total>
- Failed: <n>
### Failed Items
- [CRITICAL] #1 Images have alt text -- <file_path>
- [HIGH] #11 No hardcoded colors -- <file_path>:<line>
- [MEDIUM] #7 cursor-pointer on clickable -- <file_path>
### Recommendations
(Do/Don't guidance for each failed item)
```
## Error Handling
| Scenario | Resolution |
|----------|------------|
| No frontend files to check | Report empty checklist, all checks N/A |
| File read error | Skip file, note in report |
| Regex match error | Skip check, note in report |
| Design tokens file not found | Skip items 11-12, adjust total |

View File

@@ -0,0 +1,113 @@
# Role: fe-qa
Frontend quality assurance. 5-dimension review + Generator-Critic loop.
## Identity
- **Name**: `fe-qa` | **Prefix**: `QA-FE-*` | **Tag**: `[fe-qa]`
- **Type**: Frontend pipeline worker
- **Responsibility**: Context loading → 5-dimension review → GC feedback → Report
## Boundaries
### MUST
- Only process QA-FE-* tasks
- Execute 5-dimension review
- Support Generator-Critic loop (max 2 rounds)
- Provide actionable fix suggestions (Do/Don't format)
### MUST NOT
- Modify source code directly (review only)
- Contact other workers directly
- Mark pass when score below threshold
## Message Types
| Type | Direction | Trigger |
|------|-----------|---------|
| qa_fe_passed | → coordinator | All dimensions pass |
| qa_fe_result | → coordinator | Review complete (may have issues) |
| fix_required | → coordinator | Critical issues found |
## Toolbox
| Tool | Purpose |
|------|---------|
| commands/pre-delivery-checklist.md | CSS-level delivery checks |
| ccw cli --tool gemini --mode analysis | Frontend code review |
| ccw cli --tool codex --mode review | Git-aware code review |
---
## Review Dimensions
| Dimension | Weight | Focus |
|-----------|--------|-------|
| Code Quality | 25% | TypeScript types, component structure, error handling |
| Accessibility | 25% | Semantic HTML, ARIA, keyboard nav, contrast, focus-visible |
| Design Compliance | 20% | Token usage, no hardcoded colors, no emoji icons |
| UX Best Practices | 15% | Loading/error/empty states, cursor-pointer, responsive |
| Pre-Delivery | 15% | No console.log, dark mode, i18n readiness |
---
## Phase 2: Context Loading
**Inputs**: design tokens, design intelligence, shared memory, previous QA results (for GC round tracking), changed frontend files via git diff.
Determine GC round from previous QA results count. Max 2 rounds.
---
## Phase 3: 5-Dimension Review
For each changed frontend file, check against all 5 dimensions. Score each dimension 0-10, deducting for issues found.
**Scoring deductions**:
| Severity | Deduction |
|----------|-----------|
| High | -2 to -3 |
| Medium | -1 to -1.5 |
| Low | -0.5 |
**Overall score** = weighted sum of dimension scores.
**Verdict routing**:
| Condition | Verdict |
|-----------|---------|
| Score ≥ 8 AND no critical issues | PASS |
| GC round ≥ max AND score ≥ 6 | PASS_WITH_WARNINGS |
| GC round ≥ max AND score < 6 | FAIL |
| Otherwise | NEEDS_FIX |
---
## Phase 4: Report
Write audit to `<session-folder>/qa/audit-fe-<task>-r<round>.json`. Update wisdom and shared memory.
**Report**: round, verdict, overall score, dimension scores, critical issues with Do/Don't format, action required (if NEEDS_FIX).
---
## Generator-Critic Loop
Orchestrated by coordinator:
```
Round 1: DEV-FE-001 → QA-FE-001
if NEEDS_FIX → coordinator creates DEV-FE-002 + QA-FE-002
Round 2: DEV-FE-002 → QA-FE-002
if still NEEDS_FIX → PASS_WITH_WARNINGS or FAIL (max 2)
```
**Convergence**: score ≥ 8 AND critical_count = 0
## Error Handling
| Scenario | Resolution |
|----------|------------|
| No changed files | Report empty, score N/A |
| Design tokens not found | Skip design compliance, adjust weights |
| Max GC rounds exceeded | Force verdict |

View File

@@ -0,0 +1,120 @@
# Role: planner
Multi-angle code exploration and structured implementation planning. Submits plans to coordinator for approval.
## Identity
- **Name**: `planner` | **Prefix**: `PLAN-*` | **Tag**: `[planner]`
- **Responsibility**: Complexity assessment → Code exploration → Plan generation → Approval
## Boundaries
### MUST
- Only process PLAN-* tasks
- Assess complexity before planning
- Execute multi-angle exploration for Medium/High complexity
- Generate plan.json + .task/TASK-*.json
- Load spec context in full-lifecycle mode
- Submit plan for coordinator approval
### MUST NOT
- Create tasks for other roles
- Implement code
- Modify spec documents
- Skip complexity assessment
## Message Types
| Type | Direction | Trigger |
|------|-----------|---------|
| plan_ready | → coordinator | Plan complete |
| plan_revision | → coordinator | Plan revised per feedback |
| error | → coordinator | Exploration or planning failure |
## Toolbox
| Tool | Purpose |
|------|---------|
| commands/explore.md | Multi-angle codebase exploration |
| cli-explore-agent | Per-angle exploration |
| cli-lite-planning-agent | Plan generation |
---
## Phase 1.5: Load Spec Context (Full-Lifecycle)
If `<session-folder>/spec/` exists → load requirements/_index.md, architecture/_index.md, epics/_index.md, spec-config.json. Otherwise → impl-only mode.
---
## Phase 2: Multi-Angle Exploration
**Objective**: Explore codebase to inform planning.
**Complexity routing**:
| Complexity | Criteria | Strategy |
|------------|----------|----------|
| Low | < 200 chars, no refactor/architecture keywords | ACE semantic search only |
| Medium | 200-500 chars or moderate scope | 2-3 angle cli-explore-agent |
| High | > 500 chars, refactor/architecture, multi-module | 3-5 angle cli-explore-agent |
Delegate to `commands/explore.md` for angle selection and parallel execution.
---
## Phase 3: Plan Generation
**Objective**: Generate structured implementation plan.
| Complexity | Strategy |
|------------|----------|
| Low | Direct planning → single TASK-001 with plan.json |
| Medium/High | cli-lite-planning-agent with exploration results |
**Agent call** (Medium/High):
```
Task({
subagent_type: "cli-lite-planning-agent",
run_in_background: false,
description: "Generate implementation plan",
prompt: "Generate plan.
Output: <plan-dir>/plan.json + <plan-dir>/.task/TASK-*.json
Schema: cat ~/.ccw/workflows/cli-templates/schemas/plan-overview-base-schema.json
Task: <task-description>
Explorations: <explorations-manifest>
Complexity: <complexity>
Requirements: 2-7 tasks with id, title, files[].change, convergence.criteria, depends_on"
})
```
**Spec context** (full-lifecycle): Reference REQ-* IDs, follow ADR decisions, reuse Epic/Story decomposition.
---
## Phase 4: Submit for Approval
1. Read plan.json and TASK-*.json
2. Report to coordinator: complexity, task count, task list, approach, plan location
3. Wait for response: approved → complete; revision → update and resubmit
**Session files**:
```
<session-folder>/plan/
├── exploration-<angle>.json
├── explorations-manifest.json
├── plan.json
└── .task/TASK-*.json
```
---
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Exploration agent failure | Plan from description only |
| Planning agent failure | Fallback to direct planning |
| Plan rejected 3+ times | Notify coordinator, suggest alternative |
| Schema not found | Use basic structure |

View File

@@ -0,0 +1,163 @@
# Command: code-review
## Purpose
4-dimension code review analyzing quality, security, architecture, and requirements compliance. Produces a verdict (BLOCK/CONDITIONAL/APPROVE) with categorized findings.
## Phase 2: Context Loading
| Input | Source | Required |
|-------|--------|----------|
| Plan file | `<session_folder>/plan/plan.json` | Yes |
| Git diff | `git diff HEAD~1` or `git diff --cached` | Yes |
| Modified files | From git diff --name-only | Yes |
| Test results | Tester output (if available) | No |
| Wisdom | `<session_folder>/wisdom/` | No |
## Phase 3: 4-Dimension Review
### Dimension Overview
| Dimension | Focus | Weight |
|-----------|-------|--------|
| Quality | Code correctness, type safety, clean code | Equal |
| Security | Vulnerability patterns, secret exposure | Equal |
| Architecture | Module structure, coupling, file size | Equal |
| Requirements | Acceptance criteria coverage, completeness | Equal |
---
### Dimension 1: Quality
Scan each modified file for quality anti-patterns.
| Severity | Pattern | What to Detect |
|----------|---------|----------------|
| Critical | Empty catch blocks | `catch(e) {}` with no handling |
| High | @ts-ignore without justification | Suppression comment < 10 chars explanation |
| High | `any` type in public APIs | `any` outside comments and generic definitions |
| High | console.log in production | `console.(log\|debug\|info)` outside test files |
| Medium | Magic numbers | Numeric literals > 1 digit, not in const/comment |
| Medium | Duplicate code | Identical lines (>30 chars) appearing 3+ times |
**Detection example** (Grep for console statements):
```bash
Grep(pattern="console\\.(log|debug|info)", path="<file_path>", output_mode="content", "-n"=true)
```
---
### Dimension 2: Security
Scan for vulnerability patterns across all modified files.
| Severity | Pattern | What to Detect |
|----------|---------|----------------|
| Critical | Hardcoded secrets | `api_key=`, `password=`, `secret=`, `token=` with string values (20+ chars) |
| Critical | SQL injection | String concatenation in `query()`/`execute()` calls |
| High | eval/exec usage | `eval()`, `new Function()`, `setTimeout(string)` |
| High | XSS vectors | `innerHTML`, `dangerouslySetInnerHTML` |
| Medium | Insecure random | `Math.random()` in security context (token/key/password/session) |
| Low | Missing input validation | Functions with parameters but no validation in first 5 lines |
---
### Dimension 3: Architecture
Assess structural health of modified files.
| Severity | Pattern | What to Detect |
|----------|---------|----------------|
| Critical | Circular dependencies | File A imports B, B imports A |
| High | Excessive parent imports | Import traverses >2 parent directories (`../../../`) |
| Medium | Large files | Files exceeding 500 lines |
| Medium | Tight coupling | >5 imports from same base module |
| Medium | Long functions | Functions exceeding 50 lines |
| Medium | Module boundary changes | Modifications to index.ts/index.js files |
**Detection example** (check for deep parent imports):
```bash
Grep(pattern="from\\s+['\"](\\.\\./){3,}", path="<file_path>", output_mode="content", "-n"=true)
```
---
### Dimension 4: Requirements
Verify implementation against plan acceptance criteria.
| Severity | Check | Method |
|----------|-------|--------|
| High | Unmet acceptance criteria | Extract criteria from plan, check keyword overlap (threshold: 70%) |
| High | Missing error handling | Plan mentions "error handling" but no try/catch in code |
| Medium | Partially met criteria | Keyword overlap 40-69% |
| Medium | Missing tests | Plan mentions "test" but no test files in modified set |
**Verification flow**:
1. Read plan file → extract acceptance criteria section
2. For each criterion → extract keywords (4+ char meaningful words)
3. Search modified files for keyword matches
4. Score: >= 70% match = met, 40-69% = partial, < 40% = unmet
---
### Verdict Routing
| Verdict | Criteria | Action |
|---------|----------|--------|
| BLOCK | Any critical-severity issues found | Must fix before merge |
| CONDITIONAL | High or medium issues, no critical | Should address, can merge with tracking |
| APPROVE | Only low issues or none | Ready to merge |
## Phase 4: Validation
### Report Format
The review report follows this structure:
```
# Code Review Report
**Verdict**: <BLOCK|CONDITIONAL|APPROVE>
## Blocking Issues (if BLOCK)
- **<type>** (<file>:<line>): <message>
## Review Dimensions
### Quality Issues
**CRITICAL** (<count>)
- <message> (<file>:<line>)
### Security Issues
(same format per severity)
### Architecture Issues
(same format per severity)
### Requirements Issues
(same format per severity)
## Recommendations
1. <actionable recommendation>
```
### Summary Counts
| Field | Description |
|-------|-------------|
| Total issues | Sum across all dimensions and severities |
| Critical count | Must be 0 for APPROVE |
| Blocking issues | Listed explicitly in report header |
| Dimensions covered | Must be 4/4 |
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Plan file not found | Skip requirements dimension, note in report |
| Git diff empty | Report no changes to review |
| File read fails | Skip file, note in report |
| No modified files | Report empty review |

View File

@@ -0,0 +1,201 @@
# Command: spec-quality
## Purpose
5-dimension spec quality check with weighted scoring, quality gate determination, and readiness report generation.
## Phase 2: Context Loading
| Input | Source | Required |
|-------|--------|----------|
| Spec documents | `<session_folder>/spec/` (all .md files) | Yes |
| Original requirements | Product brief objectives section | Yes |
| Quality gate config | specs/quality-gates.md | No |
| Session folder | Task description `Session:` field | Yes |
**Spec document phases** (matched by filename/directory):
| Phase | Expected Path |
|-------|--------------|
| product-brief | spec/product-brief.md |
| prd | spec/requirements/*.md |
| architecture | spec/architecture/_index.md + ADR-*.md |
| user-stories | spec/epics/*.md |
| implementation-plan | plan/plan.json |
| test-strategy | spec/test-strategy.md |
## Phase 3: 5-Dimension Scoring
### Dimension Weights
| Dimension | Weight | Focus |
|-----------|--------|-------|
| Completeness | 25% | All required sections present with substance |
| Consistency | 20% | Terminology, format, references, naming |
| Traceability | 25% | Goals -> Reqs -> Components -> Stories chain |
| Depth | 20% | AC testable, ADRs justified, stories estimable |
| Coverage | 10% | Original requirements mapped to spec |
---
### Dimension 1: Completeness (25%)
Check each spec document for required sections.
**Required sections by phase**:
| Phase | Required Sections |
|-------|------------------|
| product-brief | Vision Statement, Problem Statement, Target Audience, Success Metrics, Constraints |
| prd | Goals, Requirements, User Stories, Acceptance Criteria, Non-Functional Requirements |
| architecture | System Overview, Component Design, Data Models, API Specifications, Technology Stack |
| user-stories | Story List, Acceptance Criteria, Priority, Estimation |
| implementation-plan | Task Breakdown, Dependencies, Timeline, Resource Allocation |
| test-strategy | Test Scope, Test Cases, Coverage Goals, Test Environment |
**Scoring formula**:
- Section present: 50% credit
- Section has substantial content (>100 chars beyond header): additional 50% credit
- Per-document score = (present_ratio * 50) + (substantial_ratio * 50)
- Overall = average across all documents
---
### Dimension 2: Consistency (20%)
Check cross-document consistency across four areas.
| Area | What to Check | Severity |
|------|--------------|----------|
| Terminology | Same concept with different casing/spelling across docs | Medium |
| Format | Mixed header styles at same level across docs | Low |
| References | Broken links (`./` or `../` paths that don't resolve) | High |
| Naming | Mixed naming conventions (camelCase vs snake_case vs kebab-case) | Low |
**Scoring**:
- Penalty weights: High = 10, Medium = 5, Low = 2
- Score = max(0, 100 - (total_penalty / 100) * 100)
---
### Dimension 3: Traceability (25%)
Build and validate traceability chains: Goals -> Requirements -> Components -> Stories.
**Chain building flow**:
1. Extract goals from product-brief (pattern: `- Goal: <text>`)
2. Extract requirements from PRD (pattern: `- REQ-NNN: <text>`)
3. Extract components from architecture (pattern: `- Component: <text>`)
4. Extract stories from user-stories (pattern: `- US-NNN: <text>`)
5. Link by keyword overlap (threshold: 30% keyword match)
**Chain completeness**: A chain is complete when a goal links to at least one requirement, one component, and one story.
**Scoring**: (complete chains / total chains) * 100
**Weak link identification**: For each incomplete chain, report which link is missing (no requirements, no components, or no stories).
---
### Dimension 4: Depth (20%)
Assess the analytical depth of spec content across four sub-dimensions.
| Sub-dimension | Source | Testable Criteria |
|---------------|--------|-------------------|
| AC Testability | PRD / User Stories | Contains measurable verbs (display, return, validate) or Given/When/Then or numbers |
| ADR Justification | Architecture | Contains rationale, alternatives, consequences, or trade-offs |
| Story Estimability | User Stories | Has "As a/I want/So that" + AC, or explicit estimate |
| Technical Detail | Architecture + Plan | Contains code blocks, API terms, HTTP methods, DB terms |
**Scoring**: Average of sub-dimension scores (each 0-100%)
---
### Dimension 5: Coverage (10%)
Map original requirements to spec requirements.
**Flow**:
1. Extract original requirements from product-brief objectives section
2. Extract spec requirements from all documents (pattern: `- REQ-NNN:` or `- Requirement:` or `- Feature:`)
3. For each original requirement, check keyword overlap with any spec requirement (threshold: 40%)
4. Score = (covered_count / total_original) * 100
---
### Quality Gate Decision Table
| Gate | Criteria | Message |
|------|----------|---------|
| PASS | Overall score >= 80% AND coverage >= 70% | Ready for implementation |
| FAIL | Overall score < 60% OR coverage < 50% | Major revisions required |
| REVIEW | All other cases | Improvements needed, may proceed with caution |
## Phase 4: Validation
### Readiness Report Format
Write to `<session_folder>/spec/readiness-report.md`:
```
# Specification Readiness Report
**Generated**: <timestamp>
**Overall Score**: <score>%
**Quality Gate**: <PASS|REVIEW|FAIL> - <message>
**Recommended Action**: <action>
## Dimension Scores
| Dimension | Score | Weight | Weighted Score |
|-----------|-------|--------|----------------|
| Completeness | <n>% | 25% | <n>% |
| Consistency | <n>% | 20% | <n>% |
| Traceability | <n>% | 25% | <n>% |
| Depth | <n>% | 20% | <n>% |
| Coverage | <n>% | 10% | <n>% |
## Completeness Analysis
(per-phase breakdown: sections present/expected, missing sections)
## Consistency Analysis
(issues by area: terminology, format, references, naming)
## Traceability Analysis
(complete chains / total, weak links)
## Depth Analysis
(per sub-dimension scores)
## Requirement Coverage
(covered / total, uncovered requirements list)
```
### Spec Summary Format
Write to `<session_folder>/spec/spec-summary.md`:
```
# Specification Summary
**Overall Quality Score**: <score>%
**Quality Gate**: <gate>
## Documents Reviewed
(per document: phase, path, size, section list)
## Key Findings
### Strengths (dimensions scoring >= 80%)
### Areas for Improvement (dimensions scoring < 70%)
### Recommendations
```
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Spec folder empty | FAIL gate, report no documents found |
| Missing phase document | Score 0 for that phase in completeness, note in report |
| No original requirements found | Score coverage at 100% (nothing to cover) |
| Broken references | Flag in consistency, do not fail entire review |

View File

@@ -0,0 +1,104 @@
# Role: reviewer
Dual-mode review: code review (REVIEW-*) and spec quality validation (QUALITY-*). Auto-switches by task prefix.
## Identity
- **Name**: `reviewer` | **Prefix**: `REVIEW-*` + `QUALITY-*` | **Tag**: `[reviewer]`
- **Responsibility**: Branch by Prefix → Review/Score → Report
## Boundaries
### MUST
- Process REVIEW-* and QUALITY-* tasks
- Generate readiness-report.md for QUALITY tasks
- Cover all required dimensions per mode
### MUST NOT
- Create tasks
- Modify source code
- Skip quality dimensions
- Approve without verification
## Message Types
| Type | Direction | Trigger |
|------|-----------|---------|
| review_result | → coordinator | Code review complete |
| quality_result | → coordinator | Spec quality complete |
| fix_required | → coordinator | Critical issues found |
## Toolbox
| Tool | Purpose |
|------|---------|
| commands/code-review.md | 4-dimension code review |
| commands/spec-quality.md | 5-dimension spec quality |
---
## Mode Detection
| Task Prefix | Mode | Dimensions |
|-------------|------|-----------|
| REVIEW-* | Code Review | quality, security, architecture, requirements |
| QUALITY-* | Spec Quality | completeness, consistency, traceability, depth, coverage |
---
## Code Review (REVIEW-*)
**Inputs**: Plan file, git diff, modified files, test results (if available)
**4 dimensions** (delegate to commands/code-review.md):
| Dimension | Critical Issues |
|-----------|----------------|
| Quality | Empty catch, any in public APIs, @ts-ignore, console.log |
| Security | Hardcoded secrets, SQL injection, eval/exec, innerHTML |
| Architecture | Circular deps, parent imports >2 levels, files >500 lines |
| Requirements | Missing core functionality, incomplete acceptance criteria |
**Verdict**:
| Verdict | Criteria |
|---------|----------|
| BLOCK | Critical issues present |
| CONDITIONAL | High/medium only |
| APPROVE | Low or none |
---
## Spec Quality (QUALITY-*)
**Inputs**: All spec docs in session folder, quality gate config
**5 dimensions** (delegate to commands/spec-quality.md):
| Dimension | Weight | Focus |
|-----------|--------|-------|
| Completeness | 25% | All sections present with substance |
| Consistency | 20% | Terminology, format, references |
| Traceability | 25% | Goals → Reqs → Arch → Stories chain |
| Depth | 20% | AC testable, ADRs justified, stories estimable |
| Coverage | 10% | Original requirements mapped |
**Quality gate**:
| Gate | Criteria |
|------|----------|
| PASS | Score ≥ 80% AND coverage ≥ 70% |
| REVIEW | Score 60-79% OR coverage 50-69% |
| FAIL | Score < 60% OR coverage < 50% |
**Artifacts**: readiness-report.md + spec-summary.md
---
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Missing context | Request from coordinator |
| Invalid mode | Abort with error |
| Analysis failure | Retry, then fallback template |

View File

@@ -0,0 +1,152 @@
# Command: validate
## Purpose
Test-fix cycle with strategy engine: detect framework, run tests, classify failures, select fix strategy, iterate until pass rate target is met or max iterations exhausted.
## Constants
| Constant | Value | Description |
|----------|-------|-------------|
| MAX_ITERATIONS | 10 | Maximum test-fix cycle attempts |
| PASS_RATE_TARGET | 95% | Minimum pass rate to succeed |
| AFFECTED_TESTS_FIRST | true | Run affected tests before full suite |
## Phase 2: Context Loading
Load from task description and executor output:
| Input | Source | Required |
|-------|--------|----------|
| Framework | Auto-detected (see below) | Yes |
| Modified files | Executor task output / git diff | Yes |
| Affected tests | Derived from modified files | No |
| Session folder | Task description `Session:` field | Yes |
| Wisdom | `<session_folder>/wisdom/` | No |
**Framework detection** (priority order):
| Priority | Method | Check |
|----------|--------|-------|
| 1 | package.json devDependencies | vitest, jest, mocha, pytest |
| 2 | package.json scripts.test | Command contains framework name |
| 3 | Config file existence | vitest.config.*, jest.config.*, pytest.ini |
**Affected test discovery** from modified files:
- For each modified file `<name>.<ext>`, search:
`<name>.test.ts`, `<name>.spec.ts`, `tests/<name>.test.ts`, `__tests__/<name>.test.ts`
## Phase 3: Test-Fix Cycle
### Test Command Table
| Framework | Affected Tests | Full Suite |
|-----------|---------------|------------|
| vitest | `vitest run <files> --reporter=verbose` | `vitest run --reporter=verbose` |
| jest | `jest <files> --no-coverage --verbose` | `jest --no-coverage --verbose` |
| mocha | `mocha <files> --reporter spec` | `mocha --reporter spec` |
| pytest | `pytest <files> -v --tb=short` | `pytest -v --tb=short` |
### Iteration Flow
```
Iteration 1
├─ Run affected tests (or full suite if none)
├─ Parse results → pass rate
├─ Pass rate >= 95%?
│ ├─ YES + affected-only → run full suite to confirm
│ │ ├─ Full suite passes → SUCCESS
│ │ └─ Full suite fails → continue with full results
│ └─ YES + full suite → SUCCESS
└─ NO → classify failures → select strategy → apply fixes
Iteration 2..10
├─ Re-run tests
├─ Track best pass rate across iterations
├─ Pass rate >= 95% → SUCCESS
├─ No failures to fix → STOP (anomaly)
└─ Failures remain → classify → select strategy → apply fixes
After iteration 10
└─ FAIL: max iterations reached, report best pass rate
```
**Progress update**: When iteration > 5, send progress to coordinator with current pass rate and iteration count.
### Strategy Selection Matrix
| Condition | Strategy | Behavior |
|-----------|----------|----------|
| Iteration <= 3 OR pass rate >= 80% | Conservative | Fix one failure at a time, highest severity first |
| Critical failures exist AND count < 5 | Surgical | Identify common error pattern, fix all matching occurrences |
| Pass rate < 50% OR iteration > 7 | Aggressive | Fix all critical + high failures in batch |
| Default (no other match) | Conservative | Safe fallback |
### Failure Classification Table
| Severity | Error Patterns |
|----------|---------------|
| Critical | SyntaxError, cannot find module, is not defined |
| High | Assertion mismatch (expected/received), toBe/toEqual failures |
| Medium | Timeout, async errors |
| Low | Warnings, deprecation notices |
### Fix Approach by Error Type
| Error Type | Pattern | Fix Approach |
|------------|---------|-------------|
| missing_import | "Cannot find module '<module>'" | Add import statement, resolve relative path from modified files |
| undefined_variable | "<name> is not defined" | Check source for renamed/moved exports, update reference |
| assertion_mismatch | "Expected: X, Received: Y" | Read test file at failure line, update expected value if behavior change is intentional |
| timeout | "Timeout" | Increase timeout or add async/await |
| syntax_error | "SyntaxError" | Read source at error line, fix syntax |
### Tool Call Example
Run tests with framework-appropriate command:
```bash
Bash(command="vitest run src/utils/__tests__/parser.test.ts --reporter=verbose", timeout=120000)
```
Read test file to analyze failure:
```bash
Read(file_path="<test_file_path>")
```
Apply fix via Edit:
```bash
Edit(file_path="<file>", old_string="<old>", new_string="<new>")
```
## Phase 4: Validation
### Success Criteria
| Check | Criteria | Required |
|-------|----------|----------|
| Pass rate | >= 95% | Yes |
| Full suite run | At least one full suite pass | Yes |
| No critical failures | Zero critical-severity failures remaining | Yes |
| Best pass rate tracked | Reported in final result | Yes |
### Result Routing
| Outcome | Message Type | Content |
|---------|-------------|---------|
| Pass rate >= target | test_result | Success, iterations count, full suite confirmed |
| Max iterations, pass rate < target | fix_required | Best pass rate, remaining failures, iteration count |
| No tests found | error | Framework detected but no test files |
| Framework not detected | error | Detection methods exhausted |
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Framework not detected | Report error to coordinator, list detection attempts |
| No test files found | Report to coordinator, suggest manual test path |
| Test command fails (exit code != 0/1) | Check stderr for environment issues, retry once |
| Fix application fails | Skip fix, try next iteration with different strategy |
| Infinite loop (same failures repeat) | Abort after 3 identical result sets |

View File

@@ -0,0 +1,108 @@
# Role: tester
Adaptive test execution with fix cycles and quality gates.
## Identity
- **Name**: `tester` | **Prefix**: `TEST-*` | **Tag**: `[tester]`
- **Responsibility**: Detect Framework → Run Tests → Fix Cycle → Report
## Boundaries
### MUST
- Only process TEST-* tasks
- Detect test framework before running
- Run affected tests before full suite
- Use strategy engine for fix cycles
### MUST NOT
- Create tasks
- Contact other workers directly
- Modify production code beyond test fixes
- Skip framework detection
## Message Types
| Type | Direction | Trigger |
|------|-----------|---------|
| test_result | → coordinator | Tests pass or final result |
| fix_required | → coordinator | Failures after max iterations |
| error | → coordinator | Framework not detected |
## Toolbox
| Tool | Purpose |
|------|---------|
| commands/validate.md | Test-fix cycle with strategy engine |
---
## Phase 2: Framework Detection & Test Discovery
**Framework detection** (priority order):
| Priority | Method | Frameworks |
|----------|--------|-----------|
| 1 | package.json devDependencies | vitest, jest, mocha, pytest |
| 2 | package.json scripts.test | vitest, jest, mocha, pytest |
| 3 | Config files | vitest.config.*, jest.config.*, pytest.ini |
**Affected test discovery** from executor's modified files:
- Search variants: `<name>.test.ts`, `<name>.spec.ts`, `tests/<name>.test.ts`, `__tests__/<name>.test.ts`
---
## Phase 3: Test Execution & Fix Cycle
**Config**: MAX_ITERATIONS=10, PASS_RATE_TARGET=95%, AFFECTED_TESTS_FIRST=true
Delegate to `commands/validate.md`:
1. Run affected tests → parse results
2. Pass rate met → run full suite
3. Failures → select strategy → fix → re-run → repeat
**Strategy selection**:
| Condition | Strategy | Behavior |
|-----------|----------|----------|
| Iteration ≤ 3 or pass ≥ 80% | Conservative | Fix one critical failure at a time |
| Critical failures < 5 | Surgical | Fix specific pattern everywhere |
| Pass < 50% or iteration > 7 | Aggressive | Fix all failures in batch |
**Test commands**:
| Framework | Affected | Full Suite |
|-----------|---------|------------|
| vitest | `vitest run <files>` | `vitest run` |
| jest | `jest <files> --no-coverage` | `jest --no-coverage` |
| pytest | `pytest <files> -v` | `pytest -v` |
---
## Phase 4: Result Analysis
**Failure classification**:
| Severity | Patterns |
|----------|----------|
| Critical | SyntaxError, cannot find module, undefined |
| High | Assertion failures, toBe/toEqual |
| Medium | Timeout, async errors |
| Low | Warnings, deprecations |
**Report routing**:
| Condition | Type |
|-----------|------|
| Pass rate ≥ target | test_result (success) |
| Pass rate < target after max iterations | fix_required |
---
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Framework not detected | Prompt user |
| No tests found | Report to coordinator |
| Infinite fix loop | Abort after MAX_ITERATIONS |

View File

@@ -0,0 +1,96 @@
# Role: writer
Product Brief, Requirements/PRD, Architecture, and Epics & Stories document generation. Maps to spec-generator Phases 2-5.
## Identity
- **Name**: `writer` | **Prefix**: `DRAFT-*` | **Tag**: `[writer]`
- **Responsibility**: Load Context → Generate Document → Incorporate Feedback → Report
## Boundaries
### MUST
- Only process DRAFT-* tasks
- Read templates before generating (from `../../templates/`)
- Follow document-standards.md (from `../../specs/`)
- Integrate discussion feedback when available
- Generate proper YAML frontmatter
### MUST NOT
- Create tasks for other roles
- Skip template loading
- Modify discussion records
## Message Types
| Type | Direction | Trigger |
|------|-----------|---------|
| draft_ready | → coordinator | Document writing complete |
| draft_revision | → coordinator | Document revised per feedback |
| error | → coordinator | Template missing, insufficient context |
## Toolbox
| Tool | Purpose |
|------|---------|
| commands/generate-doc.md | Multi-CLI document generation |
| gemini, codex, claude CLI | Multi-perspective content generation |
---
## Phase 2: Context & Discussion Loading
**Objective**: Load all required inputs for document generation.
**Document type routing**:
| Task Subject Contains | Doc Type | Template | Discussion Input |
|----------------------|----------|----------|-----------------|
| Product Brief | product-brief | templates/product-brief.md | discuss-001-scope.md |
| Requirements / PRD | requirements | templates/requirements-prd.md | discuss-002-brief.md |
| Architecture | architecture | templates/architecture-doc.md | discuss-003-requirements.md |
| Epics | epics | templates/epics-template.md | discuss-004-architecture.md |
**Progressive dependency loading**:
| Doc Type | Requires |
|----------|----------|
| product-brief | discovery-context.json |
| requirements | + product-brief.md |
| architecture | + requirements/_index.md |
| epics | + architecture/_index.md |
**Success**: Template loaded, discussion feedback loaded (if exists), prior docs loaded.
---
## Phase 3: Document Generation
**Objective**: Generate document using template and multi-CLI analysis.
Delegate to `commands/generate-doc.md` with: doc type, session folder, spec config, discussion feedback, prior docs.
---
## Phase 4: Self-Validation
**Objective**: Verify document meets standards.
| Check | What to Verify |
|-------|---------------|
| has_frontmatter | Starts with YAML frontmatter |
| sections_complete | All template sections present |
| cross_references | session_id included |
| discussion_integrated | Reflects feedback (if exists) |
**Report**: doc type, validation status, summary, output path.
---
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Prior doc not found | Notify coordinator, request prerequisite |
| CLI failure | Retry with fallback tool |
| Discussion contradicts prior docs | Note conflict, flag for next discussion |

View File

@@ -0,0 +1,192 @@
# Document Standards
Defines format conventions, YAML frontmatter schema, naming rules, and content structure for all spec-generator outputs.
## When to Use
| Phase | Usage | Section |
|-------|-------|---------|
| All Phases | Frontmatter format | YAML Frontmatter Schema |
| All Phases | File naming | Naming Conventions |
| Phase 2-5 | Document structure | Content Structure |
| Phase 6 | Validation reference | All sections |
---
## YAML Frontmatter Schema
Every generated document MUST begin with YAML frontmatter:
```yaml
---
session_id: SPEC-{slug}-{YYYY-MM-DD}
phase: {1-6}
document_type: {product-brief|requirements|architecture|epics|readiness-report|spec-summary}
status: draft|review|complete
generated_at: {ISO8601 timestamp}
stepsCompleted: []
version: 1
dependencies:
- {list of input documents used}
---
```
### Field Definitions
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `session_id` | string | Yes | Session identifier matching spec-config.json |
| `phase` | number | Yes | Phase number that generated this document (1-6) |
| `document_type` | string | Yes | One of: product-brief, requirements, architecture, epics, readiness-report, spec-summary |
| `status` | enum | Yes | draft (initial), review (user reviewed), complete (finalized) |
| `generated_at` | string | Yes | ISO8601 timestamp of generation |
| `stepsCompleted` | array | Yes | List of step IDs completed during generation |
| `version` | number | Yes | Document version, incremented on re-generation |
| `dependencies` | array | No | List of input files this document depends on |
### Status Transitions
```
draft -> review -> complete
| ^
+-------------------+ (direct promotion in auto mode)
```
- **draft**: Initial generation, not yet user-reviewed
- **review**: User has reviewed and provided feedback
- **complete**: Finalized, ready for downstream consumption
In auto mode (`-y`), documents are promoted directly from `draft` to `complete`.
---
## Naming Conventions
### Session ID Format
```
SPEC-{slug}-{YYYY-MM-DD}
```
- **slug**: Lowercase, alphanumeric + Chinese characters, hyphens as separators, max 40 chars
- **date**: UTC+8 date in YYYY-MM-DD format
Examples:
- `SPEC-task-management-system-2026-02-11`
- `SPEC-user-auth-oauth-2026-02-11`
### Output Files
| File | Phase | Description |
|------|-------|-------------|
| `spec-config.json` | 1 | Session configuration and state |
| `discovery-context.json` | 1 | Codebase exploration results (optional) |
| `product-brief.md` | 2 | Product brief document |
| `requirements.md` | 3 | PRD document |
| `architecture.md` | 4 | Architecture decisions document |
| `epics.md` | 5 | Epic/Story breakdown document |
| `readiness-report.md` | 6 | Quality validation report |
| `spec-summary.md` | 6 | One-page executive summary |
### Output Directory
```
.workflow/.spec/{session-id}/
```
---
## Content Structure
### Heading Hierarchy
- `#` (H1): Document title only (one per document)
- `##` (H2): Major sections
- `###` (H3): Subsections
- `####` (H4): Detail items (use sparingly)
Maximum depth: 4 levels. Prefer flat structures.
### Section Ordering
Every document follows this general pattern:
1. **YAML Frontmatter** (mandatory)
2. **Title** (H1)
3. **Executive Summary** (2-3 sentences)
4. **Core Content Sections** (H2, document-specific)
5. **Open Questions / Risks** (if applicable)
6. **References / Traceability** (links to upstream/downstream docs)
### Formatting Rules
| Element | Format | Example |
|---------|--------|---------|
| Requirements | `REQ-{NNN}` prefix | REQ-001: User login |
| Acceptance criteria | Checkbox list | `- [ ] User can log in with email` |
| Architecture decisions | `ADR-{NNN}` prefix | ADR-001: Use PostgreSQL |
| Epics | `EPIC-{NNN}` prefix | EPIC-001: Authentication |
| Stories | `STORY-{EPIC}-{NNN}` prefix | STORY-001-001: Login form |
| Priority tags | MoSCoW labels | `[Must]`, `[Should]`, `[Could]`, `[Won't]` |
| Mermaid diagrams | Fenced code blocks | ````mermaid ... ``` `` |
| Code examples | Language-tagged blocks | ````typescript ... ``` `` |
### Cross-Reference Format
Use relative references between documents:
```markdown
See [Product Brief](product-brief.md#section-name) for details.
Derived from [REQ-001](requirements.md#req-001).
```
### Language
- Document body: Follow user's input language (Chinese or English)
- Technical identifiers: Always English (REQ-001, ADR-001, EPIC-001)
- YAML frontmatter keys: Always English
---
## spec-config.json Schema
```json
{
"session_id": "string (required)",
"seed_input": "string (required) - original user input",
"input_type": "text|file (required)",
"timestamp": "ISO8601 (required)",
"mode": "interactive|auto (required)",
"complexity": "simple|moderate|complex (required)",
"depth": "light|standard|comprehensive (required)",
"focus_areas": ["string array"],
"seed_analysis": {
"problem_statement": "string",
"target_users": ["string array"],
"domain": "string",
"constraints": ["string array"],
"dimensions": ["string array - 3-5 exploration dimensions"]
},
"has_codebase": "boolean",
"phasesCompleted": [
{
"phase": "number (1-6)",
"name": "string (phase name)",
"output_file": "string (primary output file)",
"completed_at": "ISO8601"
}
]
}
```
---
## Validation Checklist
- [ ] Every document starts with valid YAML frontmatter
- [ ] `session_id` matches across all documents in a session
- [ ] `status` field reflects current document state
- [ ] All cross-references resolve to valid targets
- [ ] Heading hierarchy is correct (no skipped levels)
- [ ] Technical identifiers use correct prefixes
- [ ] Output files are in the correct directory

View File

@@ -0,0 +1,207 @@
# Quality Gates
Per-phase quality gate criteria and scoring dimensions for spec-generator outputs.
## When to Use
| Phase | Usage | Section |
|-------|-------|---------|
| Phase 2-5 | Post-generation self-check | Per-Phase Gates |
| Phase 6 | Cross-document validation | Cross-Document Validation |
| Phase 6 | Final scoring | Scoring Dimensions |
---
## Quality Thresholds
| Gate | Score | Action |
|------|-------|--------|
| **Pass** | >= 80% | Continue to next phase |
| **Review** | 60-79% | Log warnings, continue with caveats |
| **Fail** | < 60% | Must address issues before continuing |
In auto mode (`-y`), Review-level issues are logged but do not block progress.
---
## Scoring Dimensions
### 1. Completeness (25%)
All required sections present with substantive content.
| Score | Criteria |
|-------|----------|
| 100% | All template sections filled with detailed content |
| 75% | All sections present, some lack detail |
| 50% | Major sections present but minor sections missing |
| 25% | Multiple major sections missing or empty |
| 0% | Document is a skeleton only |
### 2. Consistency (25%)
Terminology, formatting, and references are uniform across documents.
| Score | Criteria |
|-------|----------|
| 100% | All terms consistent, all references valid, formatting uniform |
| 75% | Minor terminology variations, all references valid |
| 50% | Some inconsistent terms, 1-2 broken references |
| 25% | Frequent inconsistencies, multiple broken references |
| 0% | Documents contradict each other |
### 3. Traceability (25%)
Requirements, architecture decisions, and stories trace back to goals.
| Score | Criteria |
|-------|----------|
| 100% | Every story traces to a requirement, every requirement traces to a goal |
| 75% | Most items traceable, few orphans |
| 50% | Partial traceability, some disconnected items |
| 25% | Weak traceability, many orphan items |
| 0% | No traceability between documents |
### 4. Depth (25%)
Content provides sufficient detail for execution teams.
| Score | Criteria |
|-------|----------|
| 100% | Acceptance criteria specific and testable, architecture decisions justified, stories estimable |
| 75% | Most items detailed enough, few vague areas |
| 50% | Mix of detailed and vague content |
| 25% | Mostly high-level, lacking actionable detail |
| 0% | Too abstract for execution |
---
## Per-Phase Quality Gates
### Phase 1: Discovery
| Check | Criteria | Severity |
|-------|----------|----------|
| Session ID valid | Matches `SPEC-{slug}-{date}` format | Error |
| Problem statement exists | Non-empty, >= 20 characters | Error |
| Target users identified | >= 1 user group | Error |
| Dimensions generated | 3-5 exploration dimensions | Warning |
| Constraints listed | >= 0 (can be empty with justification) | Info |
### Phase 2: Product Brief
| Check | Criteria | Severity |
|-------|----------|----------|
| Vision statement | Clear, 1-3 sentences | Error |
| Problem statement | Specific and measurable | Error |
| Target users | >= 1 persona with needs described | Error |
| Goals defined | >= 2 measurable goals | Error |
| Success metrics | >= 2 quantifiable metrics | Warning |
| Scope boundaries | In-scope and out-of-scope listed | Warning |
| Multi-perspective | >= 2 CLI perspectives synthesized | Info |
### Phase 3: Requirements (PRD)
| Check | Criteria | Severity |
|-------|----------|----------|
| Functional requirements | >= 3 with REQ-NNN IDs | Error |
| Acceptance criteria | Every requirement has >= 1 criterion | Error |
| MoSCoW priority | Every requirement tagged | Error |
| Non-functional requirements | >= 1 (performance, security, etc.) | Warning |
| User stories | >= 1 per Must-have requirement | Warning |
| Traceability | Requirements trace to product brief goals | Warning |
### Phase 4: Architecture
| Check | Criteria | Severity |
|-------|----------|----------|
| Component diagram | Present (Mermaid or ASCII) | Error |
| Tech stack specified | Languages, frameworks, key libraries | Error |
| ADR present | >= 1 Architecture Decision Record | Error |
| ADR has alternatives | Each ADR lists >= 2 options considered | Warning |
| Integration points | External systems/APIs identified | Warning |
| Data model | Key entities and relationships described | Warning |
| Codebase mapping | Mapped to existing code (if has_codebase) | Info |
### Phase 5: Epics & Stories
| Check | Criteria | Severity |
|-------|----------|----------|
| Epics defined | 3-7 epics with EPIC-NNN IDs | Error |
| MVP subset | >= 1 epic tagged as MVP | Error |
| Stories per epic | 2-5 stories per epic | Error |
| Story format | "As a...I want...So that..." pattern | Warning |
| Dependency map | Cross-epic dependencies documented | Warning |
| Estimation hints | Relative sizing (S/M/L/XL) per story | Info |
| Traceability | Stories trace to requirements | Warning |
### Phase 6: Readiness Check
| Check | Criteria | Severity |
|-------|----------|----------|
| All documents exist | product-brief, requirements, architecture, epics | Error |
| Frontmatter valid | All YAML frontmatter parseable and correct | Error |
| Cross-references valid | All document links resolve | Error |
| Overall score >= 60% | Weighted average across 4 dimensions | Error |
| No unresolved Errors | All Error-severity issues addressed | Error |
| Summary generated | spec-summary.md created | Warning |
---
## Cross-Document Validation
Checks performed during Phase 6 across all documents:
### Completeness Matrix
```
Product Brief goals -> Requirements (each goal has >= 1 requirement)
Requirements -> Architecture (each Must requirement has design coverage)
Requirements -> Epics (each Must requirement appears in >= 1 story)
Architecture ADRs -> Epics (tech choices reflected in implementation stories)
```
### Consistency Checks
| Check | Documents | Rule |
|-------|-----------|------|
| Terminology | All | Same term used consistently (no synonyms for same concept) |
| User personas | Brief + PRD + Epics | Same user names/roles throughout |
| Scope | Brief + PRD | PRD scope does not exceed brief scope |
| Tech stack | Architecture + Epics | Stories reference correct technologies |
### Traceability Matrix Format
```markdown
| Goal | Requirements | Architecture | Epics |
|------|-------------|--------------|-------|
| G-001: ... | REQ-001, REQ-002 | ADR-001 | EPIC-001 |
| G-002: ... | REQ-003 | ADR-002 | EPIC-002, EPIC-003 |
```
---
## Issue Classification
### Error (Must Fix)
- Missing required document or section
- Broken cross-references
- Contradictory information between documents
- Empty acceptance criteria on Must-have requirements
- No MVP subset defined in epics
### Warning (Should Fix)
- Vague acceptance criteria
- Missing non-functional requirements
- No success metrics defined
- Incomplete traceability
- Missing architecture review notes
### Info (Nice to Have)
- Could add more detailed personas
- Consider additional ADR alternatives
- Story estimation hints missing
- Mermaid diagrams could be more detailed

View File

@@ -0,0 +1,156 @@
{
"team_name": "team-lifecycle",
"team_display_name": "Team Lifecycle",
"description": "Unified team skill covering spec-to-dev-to-test full lifecycle",
"version": "2.0.0",
"architecture": "folder-based",
"role_structure": "roles/{name}/role.md + roles/{name}/commands/*.md",
"roles": {
"coordinator": {
"task_prefix": null,
"responsibility": "Pipeline orchestration, requirement clarification, task chain creation, message dispatch",
"message_types": ["plan_approved", "plan_revision", "task_unblocked", "fix_required", "error", "shutdown"]
},
"analyst": {
"task_prefix": "RESEARCH",
"responsibility": "Seed analysis, codebase exploration, multi-dimensional context gathering",
"message_types": ["research_ready", "research_progress", "error"]
},
"writer": {
"task_prefix": "DRAFT",
"responsibility": "Product Brief / PRD / Architecture / Epics document generation",
"message_types": ["draft_ready", "draft_revision", "impl_progress", "error"]
},
"discussant": {
"task_prefix": "DISCUSS",
"responsibility": "Multi-perspective critique, consensus building, conflict escalation",
"message_types": ["discussion_ready", "discussion_blocked", "impl_progress", "error"]
},
"planner": {
"task_prefix": "PLAN",
"responsibility": "Multi-angle code exploration, structured implementation planning",
"message_types": ["plan_ready", "plan_revision", "impl_progress", "error"]
},
"executor": {
"task_prefix": "IMPL",
"responsibility": "Code implementation following approved plans",
"message_types": ["impl_complete", "impl_progress", "error"]
},
"tester": {
"task_prefix": "TEST",
"responsibility": "Adaptive test-fix cycles, progressive testing, quality gates",
"message_types": ["test_result", "impl_progress", "fix_required", "error"]
},
"reviewer": {
"task_prefix": "REVIEW",
"additional_prefixes": ["QUALITY"],
"responsibility": "Code review (REVIEW-*) + Spec quality validation (QUALITY-*)",
"message_types": ["review_result", "quality_result", "fix_required", "error"]
},
"explorer": {
"task_prefix": "EXPLORE",
"responsibility": "Code search, pattern discovery, dependency tracing. Service role — on-demand by coordinator",
"role_type": "service",
"message_types": ["explore_ready", "explore_progress", "task_failed"]
},
"architect": {
"task_prefix": "ARCH",
"responsibility": "Architecture assessment, tech feasibility, design pattern review. Consulting role — on-demand by coordinator",
"role_type": "consulting",
"consultation_modes": ["spec-review", "plan-review", "code-review", "consult", "feasibility"],
"message_types": ["arch_ready", "arch_concern", "arch_progress", "error"]
},
"fe-developer": {
"task_prefix": "DEV-FE",
"responsibility": "Frontend component/page implementation, design token consumption, responsive UI",
"role_type": "frontend-pipeline",
"message_types": ["dev_fe_complete", "dev_fe_progress", "error"]
},
"fe-qa": {
"task_prefix": "QA-FE",
"responsibility": "5-dimension frontend review (quality, a11y, design compliance, UX, pre-delivery), GC loop",
"role_type": "frontend-pipeline",
"message_types": ["qa_fe_passed", "qa_fe_result", "fix_required", "error"]
}
},
"pipelines": {
"spec-only": {
"description": "Specification pipeline: research → discuss → draft → quality",
"task_chain": [
"RESEARCH-001",
"DISCUSS-001", "DRAFT-001", "DISCUSS-002",
"DRAFT-002", "DISCUSS-003", "DRAFT-003", "DISCUSS-004",
"DRAFT-004", "DISCUSS-005", "QUALITY-001", "DISCUSS-006"
]
},
"impl-only": {
"description": "Implementation pipeline: plan → implement → test + review",
"task_chain": ["PLAN-001", "IMPL-001", "TEST-001", "REVIEW-001"]
},
"full-lifecycle": {
"description": "Full lifecycle: spec pipeline → implementation pipeline",
"task_chain": "spec-only + impl-only (PLAN-001 blockedBy DISCUSS-006)"
},
"fe-only": {
"description": "Frontend-only pipeline: plan → frontend dev → frontend QA",
"task_chain": ["PLAN-001", "DEV-FE-001", "QA-FE-001"],
"gc_loop": { "max_rounds": 2, "convergence": "score >= 8 && critical === 0" }
},
"fullstack": {
"description": "Fullstack pipeline: plan → backend + frontend parallel → test + QA",
"task_chain": ["PLAN-001", "IMPL-001||DEV-FE-001", "TEST-001||QA-FE-001", "REVIEW-001"],
"sync_points": ["REVIEW-001"]
},
"full-lifecycle-fe": {
"description": "Full lifecycle with frontend: spec → plan → backend + frontend → test + QA",
"task_chain": "spec-only + fullstack (PLAN-001 blockedBy DISCUSS-006)"
}
},
"frontend_detection": {
"keywords": ["component", "page", "UI", "前端", "frontend", "CSS", "HTML", "React", "Vue", "Tailwind", "组件", "页面", "样式", "layout", "responsive", "Svelte", "Next.js", "Nuxt", "shadcn", "设计系统", "design system"],
"file_patterns": ["*.tsx", "*.jsx", "*.vue", "*.svelte", "*.css", "*.scss", "*.html"],
"routing_rules": {
"frontend_only": "All tasks match frontend keywords, no backend/API mentions",
"fullstack": "Mix of frontend and backend tasks",
"backend_only": "No frontend keywords detected (default impl-only)"
}
},
"ui_ux_pro_max": {
"skill_name": "ui-ux-pro-max",
"install_command": "/plugin install ui-ux-pro-max@ui-ux-pro-max-skill",
"invocation": "Skill(skill=\"ui-ux-pro-max\", args=\"...\")",
"domains": ["product", "style", "typography", "color", "landing", "chart", "ux", "web"],
"stacks": ["html-tailwind", "react", "nextjs", "vue", "svelte", "shadcn", "swiftui", "react-native", "flutter"],
"fallback": "llm-general-knowledge",
"design_intelligence_chain": ["analyst → design-intelligence.json", "architect → design-tokens.json", "fe-developer → tokens.css", "fe-qa → anti-pattern audit"]
},
"shared_memory": {
"file": "shared-memory.json",
"schema": {
"design_intelligence": "From analyst via ui-ux-pro-max",
"design_token_registry": "From architect, consumed by fe-developer/fe-qa",
"component_inventory": "From fe-developer, list of implemented components",
"style_decisions": "Accumulated design decisions",
"qa_history": "From fe-qa, audit trail",
"industry_context": "Industry + strictness config"
}
},
"collaboration_patterns": ["CP-1", "CP-2", "CP-4", "CP-5", "CP-6", "CP-10"],
"session_dirs": {
"base": ".workflow/.team/TLS-{slug}-{YYYY-MM-DD}/",
"spec": "spec/",
"discussions": "discussions/",
"plan": "plan/",
"explorations": "explorations/",
"architecture": "architecture/",
"wisdom": "wisdom/",
"messages": ".workflow/.team-msg/{team-name}/"
}
}

View File

@@ -0,0 +1,254 @@
# Architecture Document Template (Directory Structure)
Template for generating architecture decision documents as a directory of individual ADR files in Phase 4.
## Usage Context
| Phase | Usage |
|-------|-------|
| Phase 4 (Architecture) | Generate `architecture/` directory from requirements analysis |
| Output Location | `{workDir}/architecture/` |
## Output Structure
```
{workDir}/architecture/
├── _index.md # Overview, components, tech stack, data model, security
├── ADR-001-{slug}.md # Individual Architecture Decision Record
├── ADR-002-{slug}.md
└── ...
```
---
## Template: _index.md
```markdown
---
session_id: {session_id}
phase: 4
document_type: architecture-index
status: draft
generated_at: {timestamp}
version: 1
dependencies:
- ../spec-config.json
- ../product-brief.md
- ../requirements/_index.md
---
# Architecture: {product_name}
{executive_summary - high-level architecture approach and key decisions}
## System Overview
### Architecture Style
{description of chosen architecture style: microservices, monolith, serverless, etc.}
### System Context Diagram
```mermaid
C4Context
title System Context Diagram
Person(user, "User", "Primary user")
System(system, "{product_name}", "Core system")
System_Ext(ext1, "{external_system}", "{description}")
Rel(user, system, "Uses")
Rel(system, ext1, "Integrates with")
```
## Component Architecture
### Component Diagram
```mermaid
graph TD
subgraph "{product_name}"
A[Component A] --> B[Component B]
B --> C[Component C]
A --> D[Component D]
end
B --> E[External Service]
```
### Component Descriptions
| Component | Responsibility | Technology | Dependencies |
|-----------|---------------|------------|--------------|
| {component_name} | {what it does} | {tech stack} | {depends on} |
## Technology Stack
### Core Technologies
| Layer | Technology | Version | Rationale |
|-------|-----------|---------|-----------|
| Frontend | {technology} | {version} | {why chosen} |
| Backend | {technology} | {version} | {why chosen} |
| Database | {technology} | {version} | {why chosen} |
| Infrastructure | {technology} | {version} | {why chosen} |
### Key Libraries & Frameworks
| Library | Purpose | License |
|---------|---------|---------|
| {library_name} | {purpose} | {license} |
## Architecture Decision Records
| ADR | Title | Status | Key Choice |
|-----|-------|--------|------------|
| [ADR-001](ADR-001-{slug}.md) | {title} | Accepted | {one-line summary} |
| [ADR-002](ADR-002-{slug}.md) | {title} | Accepted | {one-line summary} |
| [ADR-003](ADR-003-{slug}.md) | {title} | Proposed | {one-line summary} |
## Data Architecture
### Data Model
```mermaid
erDiagram
ENTITY_A ||--o{ ENTITY_B : "has many"
ENTITY_A {
string id PK
string name
datetime created_at
}
ENTITY_B {
string id PK
string entity_a_id FK
string value
}
```
### Data Storage Strategy
| Data Type | Storage | Retention | Backup |
|-----------|---------|-----------|--------|
| {type} | {storage solution} | {retention policy} | {backup strategy} |
## API Design
### API Overview
| Endpoint | Method | Purpose | Auth |
|----------|--------|---------|------|
| {/api/resource} | {GET/POST/etc} | {purpose} | {auth type} |
## Security Architecture
### Security Controls
| Control | Implementation | Requirement |
|---------|---------------|-------------|
| Authentication | {approach} | [NFR-S-{NNN}](../requirements/NFR-S-{NNN}-{slug}.md) |
| Authorization | {approach} | [NFR-S-{NNN}](../requirements/NFR-S-{NNN}-{slug}.md) |
| Data Protection | {approach} | [NFR-S-{NNN}](../requirements/NFR-S-{NNN}-{slug}.md) |
## Infrastructure & Deployment
### Deployment Architecture
{description of deployment model: containers, serverless, VMs, etc.}
### Environment Strategy
| Environment | Purpose | Configuration |
|-------------|---------|---------------|
| Development | Local development | {config} |
| Staging | Pre-production testing | {config} |
| Production | Live system | {config} |
## Codebase Integration
{if has_codebase is true:}
### Existing Code Mapping
| New Component | Existing Module | Integration Type | Notes |
|--------------|----------------|------------------|-------|
| {component} | {existing module path} | Extend/Replace/New | {notes} |
### Migration Notes
{any migration considerations for existing code}
## Quality Attributes
| Attribute | Target | Measurement | ADR Reference |
|-----------|--------|-------------|---------------|
| Performance | {target} | {how measured} | [ADR-{NNN}](ADR-{NNN}-{slug}.md) |
| Scalability | {target} | {how measured} | [ADR-{NNN}](ADR-{NNN}-{slug}.md) |
| Reliability | {target} | {how measured} | [ADR-{NNN}](ADR-{NNN}-{slug}.md) |
## Risks & Mitigations
| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| {risk} | High/Medium/Low | High/Medium/Low | {mitigation approach} |
## Open Questions
- [ ] {architectural question 1}
- [ ] {architectural question 2}
## References
- Derived from: [Requirements](../requirements/_index.md), [Product Brief](../product-brief.md)
- Next: [Epics & Stories](../epics/_index.md)
```
---
## Template: ADR-NNN-{slug}.md (Individual Architecture Decision Record)
```markdown
---
id: ADR-{NNN}
status: Accepted
traces_to: [{REQ-NNN}, {NFR-X-NNN}]
date: {timestamp}
---
# ADR-{NNN}: {decision_title}
## Context
{what is the situation that motivates this decision}
## Decision
{what is the chosen approach}
## Alternatives Considered
| Option | Pros | Cons |
|--------|------|------|
| {option_1 - chosen} | {pros} | {cons} |
| {option_2} | {pros} | {cons} |
| {option_3} | {pros} | {cons} |
## Consequences
- **Positive**: {positive outcomes}
- **Negative**: {tradeoffs accepted}
- **Risks**: {risks to monitor}
## Traces
- **Requirements**: [REQ-{NNN}](../requirements/REQ-{NNN}-{slug}.md), [NFR-X-{NNN}](../requirements/NFR-X-{NNN}-{slug}.md)
- **Implemented by**: [EPIC-{NNN}](../epics/EPIC-{NNN}-{slug}.md) (added in Phase 5)
```
---
## Variable Descriptions
| Variable | Source | Description |
|----------|--------|-------------|
| `{session_id}` | spec-config.json | Session identifier |
| `{timestamp}` | Runtime | ISO8601 generation timestamp |
| `{product_name}` | product-brief.md | Product/feature name |
| `{NNN}` | Auto-increment | ADR/requirement number |
| `{slug}` | Auto-generated | Kebab-case from decision title |
| `{has_codebase}` | spec-config.json | Whether existing codebase exists |

View File

@@ -0,0 +1,196 @@
# Epics & Stories Template (Directory Structure)
Template for generating epic/story breakdown as a directory of individual Epic files in Phase 5.
## Usage Context
| Phase | Usage |
|-------|-------|
| Phase 5 (Epics & Stories) | Generate `epics/` directory from requirements decomposition |
| Output Location | `{workDir}/epics/` |
## Output Structure
```
{workDir}/epics/
├── _index.md # Overview table + dependency map + MVP scope + execution order
├── EPIC-001-{slug}.md # Individual Epic with its Stories
├── EPIC-002-{slug}.md
└── ...
```
---
## Template: _index.md
```markdown
---
session_id: {session_id}
phase: 5
document_type: epics-index
status: draft
generated_at: {timestamp}
version: 1
dependencies:
- ../spec-config.json
- ../product-brief.md
- ../requirements/_index.md
- ../architecture/_index.md
---
# Epics & Stories: {product_name}
{executive_summary - overview of epic structure and MVP scope}
## Epic Overview
| Epic ID | Title | Priority | MVP | Stories | Est. Size |
|---------|-------|----------|-----|---------|-----------|
| [EPIC-001](EPIC-001-{slug}.md) | {title} | Must | Yes | {n} | {S/M/L/XL} |
| [EPIC-002](EPIC-002-{slug}.md) | {title} | Must | Yes | {n} | {S/M/L/XL} |
| [EPIC-003](EPIC-003-{slug}.md) | {title} | Should | No | {n} | {S/M/L/XL} |
## Dependency Map
```mermaid
graph LR
EPIC-001 --> EPIC-002
EPIC-001 --> EPIC-003
EPIC-002 --> EPIC-004
EPIC-003 --> EPIC-005
```
### Dependency Notes
{explanation of why these dependencies exist and suggested execution order}
### Recommended Execution Order
1. [EPIC-{NNN}](EPIC-{NNN}-{slug}.md): {reason - foundational}
2. [EPIC-{NNN}](EPIC-{NNN}-{slug}.md): {reason - depends on #1}
3. ...
## MVP Scope
### MVP Epics
{list of epics included in MVP with justification, linking to each}
### MVP Definition of Done
- [ ] {MVP completion criterion 1}
- [ ] {MVP completion criterion 2}
- [ ] {MVP completion criterion 3}
## Traceability Matrix
| Requirement | Epic | Stories | Architecture |
|-------------|------|---------|--------------|
| [REQ-001](../requirements/REQ-001-{slug}.md) | [EPIC-001](EPIC-001-{slug}.md) | STORY-001-001, STORY-001-002 | [ADR-001](../architecture/ADR-001-{slug}.md) |
| [REQ-002](../requirements/REQ-002-{slug}.md) | [EPIC-001](EPIC-001-{slug}.md) | STORY-001-003 | Component B |
| [REQ-003](../requirements/REQ-003-{slug}.md) | [EPIC-002](EPIC-002-{slug}.md) | STORY-002-001 | [ADR-002](../architecture/ADR-002-{slug}.md) |
## Estimation Summary
| Size | Meaning | Count |
|------|---------|-------|
| S | Small - well-understood, minimal risk | {n} |
| M | Medium - some complexity, moderate risk | {n} |
| L | Large - significant complexity, should consider splitting | {n} |
| XL | Extra Large - high complexity, must split before implementation | {n} |
## Risks & Considerations
| Risk | Affected Epics | Mitigation |
|------|---------------|------------|
| {risk description} | [EPIC-{NNN}](EPIC-{NNN}-{slug}.md) | {mitigation} |
## Open Questions
- [ ] {question about scope or implementation 1}
- [ ] {question about scope or implementation 2}
## References
- Derived from: [Requirements](../requirements/_index.md), [Architecture](../architecture/_index.md)
- Handoff to: execution workflows (lite-plan, plan, req-plan)
```
---
## Template: EPIC-NNN-{slug}.md (Individual Epic)
```markdown
---
id: EPIC-{NNN}
priority: {Must|Should|Could}
mvp: {true|false}
size: {S|M|L|XL}
requirements: [REQ-{NNN}]
architecture: [ADR-{NNN}]
dependencies: [EPIC-{NNN}]
status: draft
---
# EPIC-{NNN}: {epic_title}
**Priority**: {Must|Should|Could}
**MVP**: {Yes|No}
**Estimated Size**: {S|M|L|XL}
## Description
{detailed epic description}
## Requirements
- [REQ-{NNN}](../requirements/REQ-{NNN}-{slug}.md): {title}
- [REQ-{NNN}](../requirements/REQ-{NNN}-{slug}.md): {title}
## Architecture
- [ADR-{NNN}](../architecture/ADR-{NNN}-{slug}.md): {title}
- Component: {component_name}
## Dependencies
- [EPIC-{NNN}](EPIC-{NNN}-{slug}.md) (blocking): {reason}
- [EPIC-{NNN}](EPIC-{NNN}-{slug}.md) (soft): {reason}
## Stories
### STORY-{EPIC}-001: {story_title}
**User Story**: As a {persona}, I want to {action} so that {benefit}.
**Acceptance Criteria**:
- [ ] {criterion 1}
- [ ] {criterion 2}
- [ ] {criterion 3}
**Size**: {S|M|L|XL}
**Traces to**: [REQ-{NNN}](../requirements/REQ-{NNN}-{slug}.md)
---
### STORY-{EPIC}-002: {story_title}
**User Story**: As a {persona}, I want to {action} so that {benefit}.
**Acceptance Criteria**:
- [ ] {criterion 1}
- [ ] {criterion 2}
**Size**: {S|M|L|XL}
**Traces to**: [REQ-{NNN}](../requirements/REQ-{NNN}-{slug}.md)
```
---
## Variable Descriptions
| Variable | Source | Description |
|----------|--------|-------------|
| `{session_id}` | spec-config.json | Session identifier |
| `{timestamp}` | Runtime | ISO8601 generation timestamp |
| `{product_name}` | product-brief.md | Product/feature name |
| `{EPIC}` | Auto-increment | Epic number (3 digits) |
| `{NNN}` | Auto-increment | Story/requirement number |
| `{slug}` | Auto-generated | Kebab-case from epic/story title |
| `{S\|M\|L\|XL}` | CLI analysis | Relative size estimate |

View File

@@ -0,0 +1,133 @@
# Product Brief Template
Template for generating product brief documents in Phase 2.
## Usage Context
| Phase | Usage |
|-------|-------|
| Phase 2 (Product Brief) | Generate product-brief.md from multi-CLI analysis |
| Output Location | `{workDir}/product-brief.md` |
---
## Template
```markdown
---
session_id: {session_id}
phase: 2
document_type: product-brief
status: draft
generated_at: {timestamp}
stepsCompleted: []
version: 1
dependencies:
- spec-config.json
---
# Product Brief: {product_name}
{executive_summary - 2-3 sentences capturing the essence of the product/feature}
## Vision
{vision_statement - clear, aspirational 1-3 sentence statement of what success looks like}
## Problem Statement
### Current Situation
{description of the current state and pain points}
### Impact
{quantified impact of the problem - who is affected, how much, how often}
## Target Users
{for each user persona:}
### {Persona Name}
- **Role**: {user's role/context}
- **Needs**: {primary needs related to this product}
- **Pain Points**: {current frustrations}
- **Success Criteria**: {what success looks like for this user}
## Goals & Success Metrics
| Goal ID | Goal | Success Metric | Target |
|---------|------|----------------|--------|
| G-001 | {goal description} | {measurable metric} | {specific target} |
| G-002 | {goal description} | {measurable metric} | {specific target} |
## Scope
### In Scope
- {feature/capability 1}
- {feature/capability 2}
- {feature/capability 3}
### Out of Scope
- {explicitly excluded item 1}
- {explicitly excluded item 2}
### Assumptions
- {key assumption 1}
- {key assumption 2}
## Competitive Landscape
| Aspect | Current State | Proposed Solution | Advantage |
|--------|--------------|-------------------|-----------|
| {aspect} | {how it's done now} | {our approach} | {differentiator} |
## Constraints & Dependencies
### Technical Constraints
- {constraint 1}
- {constraint 2}
### Business Constraints
- {constraint 1}
### Dependencies
- {external dependency 1}
- {external dependency 2}
## Multi-Perspective Synthesis
### Product Perspective
{summary of product/market analysis findings}
### Technical Perspective
{summary of technical feasibility and constraints}
### User Perspective
{summary of user journey and UX considerations}
### Convergent Themes
{themes where all perspectives agree}
### Conflicting Views
{areas where perspectives differ, with notes on resolution approach}
## Open Questions
- [ ] {unresolved question 1}
- [ ] {unresolved question 2}
## References
- Derived from: [spec-config.json](spec-config.json)
- Next: [Requirements PRD](requirements.md)
```
## Variable Descriptions
| Variable | Source | Description |
|----------|--------|-------------|
| `{session_id}` | spec-config.json | Session identifier |
| `{timestamp}` | Runtime | ISO8601 generation timestamp |
| `{product_name}` | Seed analysis | Product/feature name |
| `{executive_summary}` | CLI synthesis | 2-3 sentence summary |
| `{vision_statement}` | CLI product perspective | Aspirational vision |
| All `{...}` fields | CLI analysis outputs | Filled from multi-perspective analysis |

View File

@@ -0,0 +1,224 @@
# Requirements PRD Template (Directory Structure)
Template for generating Product Requirements Document as a directory of individual requirement files in Phase 3.
## Usage Context
| Phase | Usage |
|-------|-------|
| Phase 3 (Requirements) | Generate `requirements/` directory from product brief expansion |
| Output Location | `{workDir}/requirements/` |
## Output Structure
```
{workDir}/requirements/
├── _index.md # Summary + MoSCoW table + traceability matrix + links
├── REQ-001-{slug}.md # Individual functional requirement
├── REQ-002-{slug}.md
├── NFR-P-001-{slug}.md # Non-functional: Performance
├── NFR-S-001-{slug}.md # Non-functional: Security
├── NFR-SC-001-{slug}.md # Non-functional: Scalability
├── NFR-U-001-{slug}.md # Non-functional: Usability
└── ...
```
---
## Template: _index.md
```markdown
---
session_id: {session_id}
phase: 3
document_type: requirements-index
status: draft
generated_at: {timestamp}
version: 1
dependencies:
- ../spec-config.json
- ../product-brief.md
---
# Requirements: {product_name}
{executive_summary - brief overview of what this PRD covers and key decisions}
## Requirement Summary
| Priority | Count | Coverage |
|----------|-------|----------|
| Must Have | {n} | {description of must-have scope} |
| Should Have | {n} | {description of should-have scope} |
| Could Have | {n} | {description of could-have scope} |
| Won't Have | {n} | {description of explicitly excluded} |
## Functional Requirements
| ID | Title | Priority | Traces To |
|----|-------|----------|-----------|
| [REQ-001](REQ-001-{slug}.md) | {title} | Must | [G-001](../product-brief.md#goals--success-metrics) |
| [REQ-002](REQ-002-{slug}.md) | {title} | Must | [G-001](../product-brief.md#goals--success-metrics) |
| [REQ-003](REQ-003-{slug}.md) | {title} | Should | [G-002](../product-brief.md#goals--success-metrics) |
## Non-Functional Requirements
### Performance
| ID | Title | Target |
|----|-------|--------|
| [NFR-P-001](NFR-P-001-{slug}.md) | {title} | {target value} |
### Security
| ID | Title | Standard |
|----|-------|----------|
| [NFR-S-001](NFR-S-001-{slug}.md) | {title} | {standard/framework} |
### Scalability
| ID | Title | Target |
|----|-------|--------|
| [NFR-SC-001](NFR-SC-001-{slug}.md) | {title} | {target value} |
### Usability
| ID | Title | Target |
|----|-------|--------|
| [NFR-U-001](NFR-U-001-{slug}.md) | {title} | {target value} |
## Data Requirements
### Data Entities
| Entity | Description | Key Attributes |
|--------|-------------|----------------|
| {entity_name} | {description} | {attr1, attr2, attr3} |
### Data Flows
{description of key data flows, optionally with Mermaid diagram}
## Integration Requirements
| System | Direction | Protocol | Data Format | Notes |
|--------|-----------|----------|-------------|-------|
| {system_name} | Inbound/Outbound/Both | {REST/gRPC/etc} | {JSON/XML/etc} | {notes} |
## Constraints & Assumptions
### Constraints
- {technical or business constraint 1}
- {technical or business constraint 2}
### Assumptions
- {assumption 1 - must be validated}
- {assumption 2 - must be validated}
## Priority Rationale
{explanation of MoSCoW prioritization decisions, especially for Should/Could boundaries}
## Traceability Matrix
| Goal | Requirements |
|------|-------------|
| G-001 | [REQ-001](REQ-001-{slug}.md), [REQ-002](REQ-002-{slug}.md), [NFR-P-001](NFR-P-001-{slug}.md) |
| G-002 | [REQ-003](REQ-003-{slug}.md), [NFR-S-001](NFR-S-001-{slug}.md) |
## Open Questions
- [ ] {unresolved question 1}
- [ ] {unresolved question 2}
## References
- Derived from: [Product Brief](../product-brief.md)
- Next: [Architecture](../architecture/_index.md)
```
---
## Template: REQ-NNN-{slug}.md (Individual Functional Requirement)
```markdown
---
id: REQ-{NNN}
type: functional
priority: {Must|Should|Could|Won't}
traces_to: [G-{NNN}]
status: draft
---
# REQ-{NNN}: {requirement_title}
**Priority**: {Must|Should|Could|Won't}
## Description
{detailed requirement description}
## User Story
As a {persona}, I want to {action} so that {benefit}.
## Acceptance Criteria
- [ ] {specific, testable criterion 1}
- [ ] {specific, testable criterion 2}
- [ ] {specific, testable criterion 3}
## Traces
- **Goal**: [G-{NNN}](../product-brief.md#goals--success-metrics)
- **Architecture**: [ADR-{NNN}](../architecture/ADR-{NNN}-{slug}.md) (if applicable)
- **Implemented by**: [EPIC-{NNN}](../epics/EPIC-{NNN}-{slug}.md) (added in Phase 5)
```
---
## Template: NFR-{type}-NNN-{slug}.md (Individual Non-Functional Requirement)
```markdown
---
id: NFR-{type}-{NNN}
type: non-functional
category: {Performance|Security|Scalability|Usability}
priority: {Must|Should|Could}
status: draft
---
# NFR-{type}-{NNN}: {requirement_title}
**Category**: {Performance|Security|Scalability|Usability}
**Priority**: {Must|Should|Could}
## Requirement
{detailed requirement description}
## Metric & Target
| Metric | Target | Measurement Method |
|--------|--------|--------------------|
| {metric} | {target value} | {how measured} |
## Traces
- **Goal**: [G-{NNN}](../product-brief.md#goals--success-metrics)
- **Architecture**: [ADR-{NNN}](../architecture/ADR-{NNN}-{slug}.md) (if applicable)
```
---
## Variable Descriptions
| Variable | Source | Description |
|----------|--------|-------------|
| `{session_id}` | spec-config.json | Session identifier |
| `{timestamp}` | Runtime | ISO8601 generation timestamp |
| `{product_name}` | product-brief.md | Product/feature name |
| `{NNN}` | Auto-increment | Requirement number (zero-padded 3 digits) |
| `{slug}` | Auto-generated | Kebab-case from requirement title |
| `{type}` | Category | P (Performance), S (Security), SC (Scalability), U (Usability) |
| `{Must\|Should\|Could\|Won't}` | User input / auto | MoSCoW priority tag |

View File

@@ -0,0 +1,177 @@
---
name: workflow-lite-plan
description: Lightweight planning and execution skill - route to lite-plan or lite-execute with prompt enhancement. Triggers on "workflow:lite-plan", "workflow:lite-execute".
allowed-tools: Skill, Task, AskUserQuestion, TodoWrite, Read, Write, Edit, Bash, Glob, Grep
---
# Workflow Lite-Plan
Unified lightweight planning and execution skill. Routes to lite-plan (planning pipeline) or lite-execute (execution engine) based on trigger, with prompt enhancement for both modes.
## Architecture Overview
```
┌─────────────────────────────────────────────────────┐
│ SKILL.md (Router + Prompt Enhancement) │
│ → Detect mode → Enhance prompt → Dispatch to phase │
└──────────────────────┬──────────────────────────────┘
┌───────────┼───────────┐
↓ ↓
┌───────────┐ ┌───────────┐
│ lite-plan │ │lite-execute│
│ Phase 1 │ │ Phase 2 │
│ Plan+Exec │─direct──→│ Standalone │
└───────────┘ └───────────┘
```
## Mode Detection & Routing
```javascript
const args = $ARGUMENTS
const mode = detectMode()
function detectMode() {
if (skillName === 'workflow:lite-execute') return 'execute'
return 'plan' // default: workflow:lite-plan
}
```
**Routing Table**:
| Trigger | Mode | Phase Document | Description |
|---------|------|----------------|-------------|
| `workflow:lite-plan` | plan | [phases/01-lite-plan.md](phases/01-lite-plan.md) | Full planning pipeline (explore → plan → confirm → execute) |
| `workflow:lite-execute` | execute | [phases/02-lite-execute.md](phases/02-lite-execute.md) | Standalone execution (in-memory / prompt / file) |
## Interactive Preference Collection
Before dispatching, collect workflow preferences via AskUserQuestion:
```javascript
// ★ 统一 auto mode 检测:-y/--yes 从 $ARGUMENTS 或 ccw 传播
const autoYes = /\b(-y|--yes)\b/.test($ARGUMENTS)
if (autoYes) {
// 自动模式:跳过所有询问,使用默认值
workflowPreferences = { autoYes: true, forceExplore: false }
} else if (mode === 'plan') {
const prefResponse = AskUserQuestion({
questions: [
{
question: "是否跳过所有确认步骤(自动模式)?",
header: "Auto Mode",
multiSelect: false,
options: [
{ label: "Interactive (Recommended)", description: "交互模式,包含确认步骤" },
{ label: "Auto", description: "跳过所有确认,自动执行" }
]
},
{
question: "是否强制执行代码探索阶段?",
header: "Exploration",
multiSelect: false,
options: [
{ label: "Auto-detect (Recommended)", description: "智能判断是否需要探索" },
{ label: "Force explore", description: "强制执行代码探索" }
]
}
]
})
workflowPreferences = {
autoYes: prefResponse.autoMode === 'Auto',
forceExplore: prefResponse.exploration === 'Force explore'
}
} else if (mode !== 'plan') {
// Execute mode (standalone, not in-memory)
const prefResponse = AskUserQuestion({
questions: [
{
question: "是否跳过所有确认步骤(自动模式)?",
header: "Auto Mode",
multiSelect: false,
options: [
{ label: "Interactive (Recommended)", description: "交互模式,包含确认步骤" },
{ label: "Auto", description: "跳过所有确认,自动执行" }
]
}
]
})
workflowPreferences = {
autoYes: prefResponse.autoMode === 'Auto',
forceExplore: false
}
}
```
**workflowPreferences** is passed to phase execution as context variable, referenced as `workflowPreferences.autoYes` and `workflowPreferences.forceExplore` within phases.
## Prompt Enhancement
After collecting preferences, enhance context and dispatch:
```javascript
// Step 0: Parse --from-analysis handoff (from analyze-with-file)
const fromAnalysisMatch = args.match(/--from-analysis\s+(\S+)/)
if (fromAnalysisMatch) {
const handoffPath = fromAnalysisMatch[1]
workflowPreferences.analysisHandoff = JSON.parse(Read(handoffPath))
workflowPreferences.forceExplore = false
// Strip flag from args, keep task description
args = args.replace(/--from-analysis\s+\S+\s*/, '').trim()
}
// Step 1: Check for project context files
const hasProjectTech = fileExists('.workflow/project-tech.json')
const hasProjectGuidelines = fileExists('.workflow/project-guidelines.json')
// Step 2: Log available context
if (hasProjectTech) {
console.log('Project tech context available: .workflow/project-tech.json')
}
if (hasProjectGuidelines) {
console.log('Project guidelines available: .workflow/project-guidelines.json')
}
// Step 3: Dispatch to phase (workflowPreferences available as context)
if (mode === 'plan') {
// Read phases/01-lite-plan.md and execute
} else {
// Read phases/02-lite-execute.md and execute
}
```
## Execution Flow
### Plan Mode
```
1. Collect preferences via AskUserQuestion (autoYes, forceExplore)
2. Enhance prompt with project context availability
3. Read phases/01-lite-plan.md
4. Execute lite-plan pipeline (Phase 1-5 within the phase doc)
5. lite-plan Phase 5 directly reads and executes Phase 2 (lite-execute) with executionContext
```
### Execute Mode
```
1. Collect preferences via AskUserQuestion (autoYes)
2. Enhance prompt with project context availability
3. Read phases/02-lite-execute.md
4. Execute lite-execute pipeline (input detection → execution → review)
```
## Usage
Plan mode and execute mode are triggered by skill name routing (see Mode Detection). Workflow preferences (auto mode, force explore) are collected interactively via AskUserQuestion before dispatching to phases.
**Plan mode**: Task description provided as arguments → interactive preference collection → planning pipeline
**Execute mode**: Task description, file path, or in-memory context → interactive preference collection → execution pipeline
## Phase Reference Documents
| Phase | Document | Purpose |
|-------|----------|---------|
| 1 | [phases/01-lite-plan.md](phases/01-lite-plan.md) | Complete planning pipeline: exploration, clarification, planning, confirmation, handoff |
| 2 | [phases/02-lite-execute.md](phases/02-lite-execute.md) | Complete execution engine: input modes, task grouping, batch execution, code review |

View File

@@ -0,0 +1,770 @@
# Phase 1: Lite-Plan
Complete planning pipeline: task analysis, multi-angle exploration, clarification, adaptive planning, confirmation, and execution handoff.
---
## Overview
Intelligent lightweight planning command with dynamic workflow adaptation based on task complexity. Focuses on planning phases (exploration, clarification, planning, confirmation) and delegates execution to Phase 2 (lite-execute).
**Core capabilities:**
- Intelligent task analysis with automatic exploration detection
- Dynamic code exploration (cli-explore-agent) when codebase understanding needed
- Interactive clarification after exploration to gather missing information
- Adaptive planning: Low complexity → Direct Claude; Medium/High → cli-lite-planning-agent
- Two-step confirmation: plan display → multi-dimensional input collection
- Execution handoff with complete context to lite-execute
## Input
```
<task-description> Task description or path to .md file (required)
```
Workflow preferences (`autoYes`, `forceExplore`) are collected by SKILL.md via AskUserQuestion and passed as `workflowPreferences` context variable.
## Output Artifacts
| Artifact | Description |
|----------|-------------|
| `exploration-{angle}.json` | Per-angle exploration results (1-4 files based on complexity) |
| `explorations-manifest.json` | Index of all exploration files |
| `planning-context.md` | Evidence paths + synthesized understanding |
| `plan.json` | Plan overview with task_ids[] (plan-overview-base-schema.json) |
| `.task/TASK-*.json` | Independent task files (one per task) |
**Output Directory**: `.workflow/.lite-plan/{task-slug}-{YYYY-MM-DD}/`
**Agent Usage**:
- Low complexity → Direct Claude planning (no agent)
- Medium/High complexity → `cli-lite-planning-agent` generates `plan.json`
**Schema Reference**: `~/.ccw/workflows/cli-templates/schemas/plan-overview-base-schema.json`
## Auto Mode Defaults
When `workflowPreferences.autoYes === true`:
- **Clarification Questions**: Skipped (no clarification phase)
- **Plan Confirmation**: Auto-selected "Allow"
- **Execution Method**: Auto-selected "Auto"
- **Code Review**: Auto-selected "Skip"
## Execution Process
```
Phase 1: Task Analysis & Exploration
├─ Parse input (description or .md file)
├─ intelligent complexity assessment (Low/Medium/High)
├─ Exploration decision (auto-detect or workflowPreferences.forceExplore)
├─ Context protection: If file reading ≥50k chars → force cli-explore-agent
└─ Decision:
├─ needsExploration=true → Launch parallel cli-explore-agents (1-4 based on complexity)
└─ needsExploration=false → Skip to Phase 2/3
Phase 2: Clarification (optional, multi-round)
├─ Aggregate clarification_needs from all exploration angles
├─ Deduplicate similar questions
└─ Decision:
├─ Has clarifications → AskUserQuestion (max 4 questions per round, multiple rounds allowed)
└─ No clarifications → Skip to Phase 3
Phase 3: Planning (NO CODE EXECUTION - planning only)
└─ Decision (based on Phase 1 complexity):
├─ Low → Load schema: cat ~/.ccw/workflows/cli-templates/schemas/plan-overview-base-schema.json → Direct Claude planning (following schema) → plan.json
└─ Medium/High → cli-lite-planning-agent → plan.json (agent internally executes quality check)
Phase 4: Confirmation & Selection
├─ Display plan summary (tasks, complexity, estimated time)
└─ AskUserQuestion:
├─ Confirm: Allow / Modify / Cancel
├─ Execution: Agent / Codex / Auto
└─ Review: Gemini / Agent / Skip
Phase 5: Execute
├─ Build executionContext (plan + explorations + clarifications + selections)
└─ Direct handoff: Read phases/02-lite-execute.md → Execute with executionContext (Mode 1)
```
## Implementation
### Phase 1: Intelligent Multi-Angle Exploration
**Session Setup** (MANDATORY - follow exactly):
```javascript
// Helper: Get UTC+8 (China Standard Time) ISO string
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
const taskSlug = task_description.toLowerCase().replace(/[^a-z0-9]+/g, '-').substring(0, 40)
const dateStr = getUtc8ISOString().substring(0, 10) // Format: 2025-11-29
const sessionId = `${taskSlug}-${dateStr}` // e.g., "implement-jwt-refresh-2025-11-29"
const sessionFolder = `.workflow/.lite-plan/${sessionId}`
bash(`mkdir -p ${sessionFolder} && test -d ${sessionFolder} && echo "SUCCESS: ${sessionFolder}" || echo "FAILED: ${sessionFolder}"`)
```
**Exploration Decision Logic**:
```javascript
// Analysis handoff: reconstruct exploration from upstream analysis artifacts
if (workflowPreferences.analysisHandoff) {
const handoff = workflowPreferences.analysisHandoff
Write(`${sessionFolder}/exploration-from-analysis.json`, JSON.stringify({
relevant_files: handoff.exploration_digest.relevant_files || [],
patterns: handoff.exploration_digest.patterns || [],
key_findings: handoff.exploration_digest.key_findings || [],
clarification_needs: [], // analysis already did multi-round discussion
_metadata: { exploration_angle: "from-analysis", source_session: handoff.source_session, reconstructed: true }
}, null, 2))
Write(`${sessionFolder}/explorations-manifest.json`, JSON.stringify({
session_id: sessionId, task_description: task_description, timestamp: getUtc8ISOString(),
complexity: complexity, exploration_count: 1, from_analysis: handoff.source_session,
explorations: [{ angle: "from-analysis", file: "exploration-from-analysis.json",
path: `${sessionFolder}/exploration-from-analysis.json`, index: 1 }]
}, null, 2))
needsExploration = false
// clarification_needs=[] → Phase 2 naturally skipped → proceed to Phase 3
}
needsExploration = needsExploration ?? (
workflowPreferences.forceExplore ||
task.mentions_specific_files ||
task.requires_codebase_context ||
task.needs_architecture_understanding ||
task.modifies_existing_code
)
if (!needsExploration) {
// Skip to Phase 2 (Clarification) or Phase 3 (Planning)
proceed_to_next_phase()
}
```
**⚠️ Context Protection**: File reading ≥50k chars → force `needsExploration=true` (delegate to cli-explore-agent)
**Complexity Assessment** (Intelligent Analysis):
```javascript
// analyzes task complexity based on:
// - Scope: How many systems/modules are affected?
// - Depth: Surface change vs architectural impact?
// - Risk: Potential for breaking existing functionality?
// - Dependencies: How interconnected is the change?
const complexity = analyzeTaskComplexity(task_description)
// Returns: 'Low' | 'Medium' | 'High'
// Low: ONLY truly trivial — single file, single function, zero cross-module impact, no new patterns
// Examples: fix typo, rename variable, add log line, adjust constant value
// Medium: Multiple files OR any integration point OR new pattern introduction OR moderate risk
// Examples: add endpoint, implement feature, refactor module, fix bug spanning files
// High: Cross-module, architectural, or systemic change
// Examples: new subsystem, migration, security overhaul, API redesign
// ⚠️ Default bias: When uncertain between Low and Medium, choose Medium
// Angle assignment based on task type (orchestrator decides, not agent)
const ANGLE_PRESETS = {
architecture: ['architecture', 'dependencies', 'modularity', 'integration-points'],
security: ['security', 'auth-patterns', 'dataflow', 'validation'],
performance: ['performance', 'bottlenecks', 'caching', 'data-access'],
bugfix: ['error-handling', 'dataflow', 'state-management', 'edge-cases'],
feature: ['patterns', 'integration-points', 'testing', 'dependencies']
}
function selectAngles(taskDescription, count) {
const text = taskDescription.toLowerCase()
let preset = 'feature' // default
if (/refactor|architect|restructure|modular/.test(text)) preset = 'architecture'
else if (/security|auth|permission|access/.test(text)) preset = 'security'
else if (/performance|slow|optimi|cache/.test(text)) preset = 'performance'
else if (/fix|bug|error|issue|broken/.test(text)) preset = 'bugfix'
return ANGLE_PRESETS[preset].slice(0, count)
}
const selectedAngles = selectAngles(task_description, complexity === 'High' ? 4 : (complexity === 'Medium' ? 3 : 1))
// Planning strategy determination
// Agent trigger: anything beyond trivial single-file change
// - analysisHandoff → always agent (analysis validated non-trivial task)
// - multi-angle exploration → agent (complexity warranted multiple angles)
// - Medium/High complexity → agent
// Direct Claude planning ONLY for truly trivial Low + no analysis + single angle
const planningStrategy = (
complexity === 'Low' && !workflowPreferences.analysisHandoff && selectedAngles.length <= 1
) ? 'Direct Claude Planning'
: 'cli-lite-planning-agent'
console.log(`
## Exploration Plan
Task Complexity: ${complexity}
Selected Angles: ${selectedAngles.join(', ')}
Planning Strategy: ${planningStrategy}
Launching ${selectedAngles.length} parallel explorations...
`)
```
**Launch Parallel Explorations** - Orchestrator assigns angle to each agent:
**⚠️ CRITICAL - NO BACKGROUND EXECUTION**:
- **MUST NOT use `run_in_background: true`** - exploration results are REQUIRED before planning
```javascript
// Launch agents with pre-assigned angles
const explorationTasks = selectedAngles.map((angle, index) =>
Task(
subagent_type="cli-explore-agent",
run_in_background=false, // ⚠️ MANDATORY: Must wait for results
description=`Explore: ${angle}`,
prompt=`
## Task Objective
Execute **${angle}** exploration for task planning context. Analyze codebase from this specific angle to discover relevant structure, patterns, and constraints.
## Output Location
**Session Folder**: ${sessionFolder}
**Output File**: ${sessionFolder}/exploration-${angle}.json
## Assigned Context
- **Exploration Angle**: ${angle}
- **Task Description**: ${task_description}
- **Exploration Index**: ${index + 1} of ${selectedAngles.length}
## Agent Initialization
cli-explore-agent autonomously handles: project structure discovery, schema loading, project context loading (project-tech.json, project-guidelines.json), and keyword search. These steps execute automatically.
## Exploration Strategy (${angle} focus)
**Step 1: Structural Scan** (Bash)
- get_modules_by_depth.sh → identify modules related to ${angle}
- find/rg → locate files relevant to ${angle} aspect
- Analyze imports/dependencies from ${angle} perspective
**Step 2: Semantic Analysis** (Gemini CLI)
- How does existing code handle ${angle} concerns?
- What patterns are used for ${angle}?
- Where would new code integrate from ${angle} viewpoint?
**Step 3: Write Output**
- Consolidate ${angle} findings into JSON
- Identify ${angle}-specific clarification needs
## Expected Output
**Schema Reference**: explore-json-schema.json (auto-loaded by agent during initialization)
**Required Fields** (all ${angle} focused):
- Follow explore-json-schema.json exactly (auto-loaded by agent)
- All fields scoped to ${angle} perspective
- Ensure rationale is specific and >10 chars (not generic)
- Include file:line locations in integration_points
- _metadata.exploration_angle: "${angle}"
## Success Criteria
- [ ] get_modules_by_depth.sh executed
- [ ] At least 3 relevant files identified with specific rationale + role
- [ ] Every file has rationale >10 chars (not generic like "Related to ${angle}")
- [ ] Every file has role classification (modify_target/dependency/etc.)
- [ ] Patterns are actionable (code examples, not generic advice)
- [ ] Integration points include file:line locations
- [ ] Constraints are project-specific to ${angle}
- [ ] JSON output follows schema exactly
- [ ] clarification_needs includes options + recommended
## Execution
**Write**: \`${sessionFolder}/exploration-${angle}.json\`
**Return**: 2-3 sentence summary of ${angle} findings
`
)
)
// Execute all exploration tasks in parallel
```
**Auto-discover Generated Exploration Files**:
```javascript
// After explorations complete, auto-discover all exploration-*.json files
const explorationFiles = bash(`find ${sessionFolder} -name "exploration-*.json" -type f`)
.split('\n')
.filter(f => f.trim())
// Read metadata to build manifest
const explorationManifest = {
session_id: sessionId,
task_description: task_description,
timestamp: getUtc8ISOString(),
complexity: complexity,
exploration_count: explorationCount,
explorations: explorationFiles.map(file => {
const data = JSON.parse(Read(file))
const filename = path.basename(file)
return {
angle: data._metadata.exploration_angle,
file: filename,
path: file,
index: data._metadata.exploration_index
}
})
}
Write(`${sessionFolder}/explorations-manifest.json`, JSON.stringify(explorationManifest, null, 2))
console.log(`
## Exploration Complete
Generated exploration files in ${sessionFolder}:
${explorationManifest.explorations.map(e => `- exploration-${e.angle}.json (angle: ${e.angle})`).join('\n')}
Manifest: explorations-manifest.json
Angles explored: ${explorationManifest.explorations.map(e => e.angle).join(', ')}
`)
```
**Output**:
- `${sessionFolder}/exploration-{angle1}.json`
- `${sessionFolder}/exploration-{angle2}.json`
- ... (1-4 files based on complexity)
- `${sessionFolder}/explorations-manifest.json`
---
### Phase 2: Clarification (Optional, Multi-Round)
**Skip if**: No exploration or `clarification_needs` is empty across all explorations
**⚠️ CRITICAL**: AskUserQuestion tool limits max 4 questions per call. **MUST execute multiple rounds** to exhaust all clarification needs - do NOT stop at round 1.
**Aggregate clarification needs from all exploration angles**:
```javascript
// Load manifest and all exploration files
const manifest = JSON.parse(Read(`${sessionFolder}/explorations-manifest.json`))
const explorations = manifest.explorations.map(exp => ({
angle: exp.angle,
data: JSON.parse(Read(exp.path))
}))
// Aggregate clarification needs from all explorations
const allClarifications = []
explorations.forEach(exp => {
if (exp.data.clarification_needs?.length > 0) {
exp.data.clarification_needs.forEach(need => {
allClarifications.push({
...need,
source_angle: exp.angle
})
})
}
})
// Intelligent deduplication: analyze allClarifications by intent
// - Identify questions with similar intent across different angles
// - Merge similar questions: combine options, consolidate context
// - Produce dedupedClarifications with unique intents only
const dedupedClarifications = intelligentMerge(allClarifications)
const autoYes = workflowPreferences.autoYes
if (autoYes) {
// Auto mode: Skip clarification phase
console.log(`[Auto] Skipping ${dedupedClarifications.length} clarification questions`)
console.log(`Proceeding to planning with exploration results...`)
// Continue to Phase 3
} else if (dedupedClarifications.length > 0) {
// Interactive mode: Multi-round clarification
const BATCH_SIZE = 4
const totalRounds = Math.ceil(dedupedClarifications.length / BATCH_SIZE)
for (let i = 0; i < dedupedClarifications.length; i += BATCH_SIZE) {
const batch = dedupedClarifications.slice(i, i + BATCH_SIZE)
const currentRound = Math.floor(i / BATCH_SIZE) + 1
console.log(`### Clarification Round ${currentRound}/${totalRounds}`)
AskUserQuestion({
questions: batch.map(need => ({
question: `[${need.source_angle}] ${need.question}\n\nContext: ${need.context}`,
header: need.source_angle.substring(0, 12),
multiSelect: false,
options: need.options.map((opt, index) => ({
label: need.recommended === index ? `${opt}` : opt,
description: need.recommended === index ? `Recommended` : `Use ${opt}`
}))
}))
})
// Store batch responses in clarificationContext before next round
}
}
```
**Output**: `clarificationContext` (in-memory)
---
### Phase 3: Planning
**Planning Strategy Selection** (based on Phase 1 complexity):
**IMPORTANT**: Phase 3 is **planning only** - NO code execution. All execution happens in Phase 5 via lite-execute.
**Executor Assignment** (Claude 智能分配plan 生成后执行):
```javascript
// 分配规则(优先级从高到低):
// 1. 用户明确指定:"用 gemini 分析..." → gemini, "codex 实现..." → codex
// 2. 默认 → agent
const executorAssignments = {} // { taskId: { executor: 'gemini'|'codex'|'agent', reason: string } }
// Load tasks from .task/ directory for executor assignment
const taskFiles = Glob(`${sessionFolder}/.task/TASK-*.json`)
taskFiles.forEach(taskPath => {
const task = JSON.parse(Read(taskPath))
// Claude 根据上述规则语义分析,为每个 task 分配 executor
executorAssignments[task.id] = { executor: '...', reason: '...' }
})
```
**Low Complexity** - Direct planning by Claude:
```javascript
// Step 1: Read schema
const schema = Bash(`cat ~/.ccw/workflows/cli-templates/schemas/plan-overview-base-schema.json`)
// Step 2: ⚠️ MANDATORY - Read and review ALL exploration files
const manifest = JSON.parse(Read(`${sessionFolder}/explorations-manifest.json`))
manifest.explorations.forEach(exp => {
const explorationData = Read(exp.path)
console.log(`\n### Exploration: ${exp.angle}\n${explorationData}`)
})
// Step 3: Generate task objects (Claude directly, no agent)
// ⚠️ Tasks MUST incorporate insights from exploration files read in Step 2
// Task fields use NEW names: convergence.criteria (not acceptance), files[].change (not modification_points), test (not verification)
const tasks = [
{
id: "TASK-001",
title: "...",
description: "...",
depends_on: [],
convergence: { criteria: ["..."] },
files: [{ path: "...", change: "..." }],
implementation: ["..."],
test: "..."
},
// ... more tasks
]
// Step 4: Write task files to .task/ directory
const taskDir = `${sessionFolder}/.task`
Bash(`mkdir -p "${taskDir}"`)
tasks.forEach(task => {
Write(`${taskDir}/${task.id}.json`, JSON.stringify(task, null, 2))
})
// Step 5: Generate plan overview (NO embedded tasks[])
const plan = {
summary: "...",
approach: "...",
task_ids: tasks.map(t => t.id),
task_count: tasks.length,
complexity: "Low",
estimated_time: "...",
recommended_execution: "Agent",
_metadata: {
timestamp: getUtc8ISOString(),
source: "direct-planning",
planning_mode: "direct",
plan_type: "feature"
}
}
// Step 6: Write plan overview to session folder
Write(`${sessionFolder}/plan.json`, JSON.stringify(plan, null, 2))
// Step 7: MUST continue to Phase 4 (Confirmation) - DO NOT execute code here
```
**Medium/High Complexity** - Invoke cli-lite-planning-agent:
```javascript
Task(
subagent_type="cli-lite-planning-agent",
run_in_background=false,
description="Generate detailed implementation plan",
prompt=`
Generate implementation plan and write plan.json.
## Output Location
**Session Folder**: ${sessionFolder}
**Output Files**:
- ${sessionFolder}/planning-context.md (evidence + understanding)
- ${sessionFolder}/plan.json (plan overview -- NO embedded tasks[])
- ${sessionFolder}/.task/TASK-*.json (independent task files, one per task)
## Output Schema Reference
Execute: cat ~/.ccw/workflows/cli-templates/schemas/plan-overview-base-schema.json (get schema reference before generating plan)
## Project Context (MANDATORY - Read Both Files)
1. Read: .workflow/project-tech.json (technology stack, architecture, key components)
2. Read: .workflow/project-guidelines.json (user-defined constraints and conventions)
**CRITICAL**: All generated tasks MUST comply with constraints in project-guidelines.json
## Task Description
${task_description}
## Multi-Angle Exploration Context
${manifest.explorations.map(exp => `### Exploration: ${exp.angle} (${exp.file})
Path: ${exp.path}
Read this file for detailed ${exp.angle} analysis.`).join('\n\n')}
Total explorations: ${manifest.exploration_count}
Angles covered: ${manifest.explorations.map(e => e.angle).join(', ')}
Manifest: ${sessionFolder}/explorations-manifest.json
## User Clarifications
${JSON.stringify(clarificationContext) || "None"}
## Complexity Level
${complexity}
## Requirements
Generate plan.json and .task/*.json following the schema obtained above. Key constraints:
- _metadata.exploration_angles: ${JSON.stringify(manifest.explorations.map(e => e.angle))}
**Output Format**: Two-layer structure:
- plan.json: Overview with task_ids[] referencing .task/ files (NO tasks[] array)
- .task/TASK-*.json: Independent task files following task-schema.json
Follow plan-overview-base-schema.json (loaded via cat command above) for plan.json structure.
Follow task-schema.json for .task/TASK-*.json structure.
Note: Use files[].change (not modification_points), convergence.criteria (not acceptance).
## Task Grouping Rules
1. **Group by feature**: All changes for one feature = one task (even if 3-5 files)
2. **Group by context**: Tasks with similar context or related functional changes can be grouped together
3. **Minimize agent count**: Simple, unrelated tasks can also be grouped to reduce agent execution overhead
4. **Avoid file-per-task**: Do NOT create separate tasks for each file
5. **Substantial tasks**: Each task should represent 15-60 minutes of work
6. **True dependencies only**: Only use depends_on when Task B cannot start without Task A's output
7. **Prefer parallel**: Most tasks should be independent (no depends_on)
## Execution
1. Read schema file (cat command above)
2. Execute CLI planning using Gemini (Qwen fallback)
3. Read ALL exploration files for comprehensive context
4. Synthesize findings and generate tasks + plan overview
5. **Write**: \`${sessionFolder}/planning-context.md\` (evidence paths + understanding)
6. **Create**: \`${sessionFolder}/.task/\` directory (mkdir -p)
7. **Write**: \`${sessionFolder}/.task/TASK-001.json\`, \`TASK-002.json\`, etc. (one per task)
8. **Write**: \`${sessionFolder}/plan.json\` (overview with task_ids[], NO tasks[])
9. Return brief completion summary
`
)
```
**Output**: `${sessionFolder}/plan.json`
---
### Phase 4: Task Confirmation & Execution Selection
**Step 4.1: Display Plan**
```javascript
const plan = JSON.parse(Read(`${sessionFolder}/plan.json`))
// Load tasks from .task/ directory
const tasks = (plan.task_ids || []).map(id => {
const taskPath = `${sessionFolder}/.task/${id}.json`
return JSON.parse(Read(taskPath))
})
const taskList = tasks
console.log(`
## Implementation Plan
**Summary**: ${plan.summary}
**Approach**: ${plan.approach}
**Tasks** (${taskList.length}):
${taskList.map((t, i) => `${i+1}. ${t.title} (${t.scope || t.files?.[0]?.path || ''})`).join('\n')}
**Complexity**: ${plan.complexity}
**Estimated Time**: ${plan.estimated_time}
**Recommended**: ${plan.recommended_execution}
`)
```
**Step 4.2: Collect Confirmation**
```javascript
const autoYes = workflowPreferences.autoYes
let userSelection
if (autoYes) {
// Auto mode: Use defaults
console.log(`[Auto] Auto-confirming plan:`)
console.log(` - Confirmation: Allow`)
console.log(` - Execution: Auto`)
console.log(` - Review: Skip`)
userSelection = {
confirmation: "Allow",
execution_method: "Auto",
code_review_tool: "Skip"
}
} else {
// Interactive mode: Ask user
// Note: Execution "Other" option allows specifying CLI tools from ~/.claude/cli-tools.json
userSelection = AskUserQuestion({
questions: [
{
question: `Confirm plan? (${taskList.length} tasks, ${plan.complexity})`,
header: "Confirm",
multiSelect: false,
options: [
{ label: "Allow", description: "Proceed as-is" },
{ label: "Modify", description: "Adjust before execution" },
{ label: "Cancel", description: "Abort workflow" }
]
},
{
question: "Execution method:",
header: "Execution",
multiSelect: false,
options: [
{ label: "Agent", description: "@code-developer agent" },
{ label: "Codex", description: "codex CLI tool" },
{ label: "Auto", description: `Auto: ${plan.complexity === 'Low' ? 'Agent' : 'Codex'}` }
]
},
{
question: "Code review after execution?",
header: "Review",
multiSelect: false,
options: [
{ label: "Gemini Review", description: "Gemini CLI review" },
{ label: "Codex Review", description: "Git-aware review (prompt OR --uncommitted)" },
{ label: "Agent Review", description: "@code-reviewer agent" },
{ label: "Skip", description: "No review" }
]
}
]
})
}
```
---
### Phase 5: Handoff to Execution
**CRITICAL**: lite-plan NEVER executes code directly. ALL execution MUST go through lite-execute.
**Step 5.1: Build executionContext**
```javascript
// Load manifest and all exploration files
const manifest = JSON.parse(Read(`${sessionFolder}/explorations-manifest.json`))
const explorations = {}
manifest.explorations.forEach(exp => {
if (file_exists(exp.path)) {
explorations[exp.angle] = JSON.parse(Read(exp.path))
}
})
const plan = JSON.parse(Read(`${sessionFolder}/plan.json`))
executionContext = {
planObject: plan, // plan overview (no tasks[])
taskFiles: (plan.task_ids || []).map(id => ({
id,
path: `${sessionFolder}/.task/${id}.json`
})),
explorationsContext: explorations,
explorationAngles: manifest.explorations.map(e => e.angle),
explorationManifest: manifest,
clarificationContext: clarificationContext || null,
executionMethod: userSelection.execution_method, // 全局默认,可被 executorAssignments 覆盖
codeReviewTool: userSelection.code_review_tool,
originalUserInput: task_description,
// 任务级 executor 分配(优先于全局 executionMethod
executorAssignments: executorAssignments, // { taskId: { executor, reason } }
session: {
id: sessionId,
folder: sessionFolder,
artifacts: {
explorations: manifest.explorations.map(exp => ({
angle: exp.angle,
path: exp.path
})),
explorations_manifest: `${sessionFolder}/explorations-manifest.json`,
plan: `${sessionFolder}/plan.json`,
task_dir: `${sessionFolder}/.task`
}
}
}
```
**Step 5.2: Handoff**
```javascript
// Direct phase handoff: Read and execute Phase 2 (lite-execute) with in-memory context
// No Skill routing needed - executionContext is already set in Step 5.1
Read("phases/02-lite-execute.md")
// Execute Phase 2 with executionContext (Mode 1: In-Memory Plan)
```
## Session Folder Structure
```
.workflow/.lite-plan/{task-slug}-{YYYY-MM-DD}/
├── exploration-{angle1}.json # Exploration angle 1
├── exploration-{angle2}.json # Exploration angle 2
├── exploration-{angle3}.json # Exploration angle 3 (if applicable)
├── exploration-{angle4}.json # Exploration angle 4 (if applicable)
├── explorations-manifest.json # Exploration index
├── planning-context.md # Evidence paths + understanding
├── plan.json # Plan overview (task_ids[])
└── .task/ # Task files directory
├── TASK-001.json
├── TASK-002.json
└── ...
```
**Example**:
```
.workflow/.lite-plan/implement-jwt-refresh-2025-11-25-14-30-25/
├── exploration-architecture.json
├── exploration-auth-patterns.json
├── exploration-security.json
├── explorations-manifest.json
├── planning-context.md
├── plan.json
└── .task/
├── TASK-001.json
├── TASK-002.json
└── TASK-003.json
```
## Error Handling
| Error | Resolution |
|-------|------------|
| Exploration agent failure | Skip exploration, continue with task description only |
| Planning agent failure | Fallback to direct planning by Claude |
| Clarification timeout | Use exploration findings as-is |
| Confirmation timeout | Save context, display resume instructions |
| Modify loop > 3 times | Suggest breaking task or using /workflow:plan |
## Next Phase
After Phase 5 handoff, execution continues in [Phase 2: Lite-Execute](02-lite-execute.md).

View File

@@ -0,0 +1,776 @@
# Phase 2: Lite-Execute
Complete execution engine: multi-mode input, task grouping, batch execution, code review, and development index update.
---
## Overview
Flexible task execution command supporting three input modes: in-memory plan (from lite-plan), direct prompt description, or file content. Handles execution orchestration, progress tracking, and optional code review.
**Core capabilities:**
- Multi-mode input (in-memory plan, prompt description, or file path)
- Execution orchestration (Agent or Codex) with full context
- Live progress tracking via TodoWrite at execution call level
- Optional code review with selected tool (Gemini, Agent, or custom)
- Context continuity across multiple executions
- Intelligent format detection (Enhanced Task JSON vs plain text)
## Usage
### Input
```
<input> Task description string, or path to file (required)
```
Mode 1 (In-Memory) is triggered by lite-plan direct handoff when `executionContext` is available.
Workflow preferences (`autoYes`) are passed from SKILL.md via `workflowPreferences` context variable.
## Input Modes
### Mode 1: In-Memory Plan
**Trigger**: Called by lite-plan direct handoff after Phase 4 approval (executionContext available)
**Input Source**: `executionContext` global variable set by lite-plan
**Content**: Complete execution context (see Data Structures section)
**Behavior**:
- Skip execution method selection (already set by lite-plan)
- Directly proceed to execution with full context
- All planning artifacts available (exploration, clarifications, plan)
### Mode 2: Prompt Description
**Trigger**: User calls with task description string
**Input**: Simple task description (e.g., "Add unit tests for auth module")
**Behavior**:
- Store prompt as `originalUserInput`
- Create simple execution plan from prompt
- AskUserQuestion: Select execution method (Agent/Codex/Auto)
- AskUserQuestion: Select code review tool (Skip/Gemini/Agent/Other)
- Proceed to execution with `originalUserInput` included
**User Interaction**:
```javascript
const autoYes = workflowPreferences.autoYes
let userSelection
if (autoYes) {
// Auto mode: Use defaults
console.log(`[Auto] Auto-confirming execution:`)
console.log(` - Execution method: Auto`)
console.log(` - Code review: Skip`)
userSelection = {
execution_method: "Auto",
code_review_tool: "Skip"
}
} else {
// Interactive mode: Ask user
userSelection = AskUserQuestion({
questions: [
{
question: "Select execution method:",
header: "Execution",
multiSelect: false,
options: [
{ label: "Agent", description: "@code-developer agent" },
{ label: "Codex", description: "codex CLI tool" },
{ label: "Auto", description: "Auto-select based on complexity" }
]
},
{
question: "Enable code review after execution?",
header: "Code Review",
multiSelect: false,
options: [
{ label: "Skip", description: "No review" },
{ label: "Gemini Review", description: "Gemini CLI tool" },
{ label: "Codex Review", description: "Git-aware review (prompt OR --uncommitted)" },
{ label: "Agent Review", description: "Current agent review" }
]
}
]
})
}
```
### Mode 3: File Content
**Trigger**: User calls with file path
**Input**: Path to file containing task description or plan.json
**Step 1: Read and Detect Format**
```javascript
fileContent = Read(filePath)
// Attempt JSON parsing
try {
jsonData = JSON.parse(fileContent)
// Check if plan.json from lite-plan session (two-layer format: task_ids[])
if (jsonData.summary && jsonData.approach && jsonData.task_ids) {
planObject = jsonData
originalUserInput = jsonData.summary
isPlanJson = true
// Load tasks from .task/*.json files
const planDir = filePath.replace(/[/\\][^/\\]+$/, '') // parent directory
planObject._loadedTasks = loadTaskFiles(planDir, jsonData.task_ids)
} else {
// Valid JSON but not plan.json - treat as plain text
originalUserInput = fileContent
isPlanJson = false
}
} catch {
// Not valid JSON - treat as plain text prompt
originalUserInput = fileContent
isPlanJson = false
}
```
**Step 2: Create Execution Plan**
If `isPlanJson === true`:
- Use `planObject` directly
- User selects execution method and code review
If `isPlanJson === false`:
- Treat file content as prompt (same behavior as Mode 2)
- Create simple execution plan from content
**Step 3: User Interaction**
- AskUserQuestion: Select execution method (Agent/Codex/Auto)
- AskUserQuestion: Select code review tool
- Proceed to execution with full context
## Helper Functions
```javascript
// Load task files from .task/ directory (two-layer format)
function loadTaskFiles(planDir, taskIds) {
return taskIds.map(id => {
const taskPath = `${planDir}/.task/${id}.json`
return JSON.parse(Read(taskPath))
})
}
// Get tasks array from loaded .task/*.json files
function getTasks(planObject) {
return planObject._loadedTasks || []
}
```
## Execution Process
```
Input Parsing:
└─ Decision (mode detection):
├─ executionContext exists → Mode 1: Load executionContext → Skip user selection
├─ Ends with .md/.json/.txt → Mode 3: Read file → Detect format
│ ├─ Valid plan.json → Use planObject → User selects method + review
│ └─ Not plan.json → Treat as prompt → User selects method + review
└─ Other → Mode 2: Prompt description → User selects method + review
Execution:
├─ Step 1: Initialize result tracking (previousExecutionResults = [])
├─ Step 2: Task grouping & batch creation
│ ├─ Extract explicit depends_on (no file/keyword inference)
│ ├─ Group: independent tasks → per-executor parallel batches (one CLI per batch)
│ ├─ Group: dependent tasks → sequential phases (respect dependencies)
│ └─ Create TodoWrite list for batches
├─ Step 3: Launch execution
│ ├─ Phase 1: Independent tasks (⚡ per-executor batches, multi-CLI concurrent)
│ └─ Phase 2+: Dependent tasks by dependency order
├─ Step 4: Track progress (TodoWrite updates per batch)
└─ Step 5: Code review (if codeReviewTool ≠ "Skip")
Output:
└─ Execution complete with results in previousExecutionResults[]
```
## Detailed Execution Steps
### Step 1: Initialize Execution Tracking
**Operations**:
- Initialize result tracking for multi-execution scenarios
- Set up `previousExecutionResults` array for context continuity
- **In-Memory Mode**: Echo execution strategy from lite-plan for transparency
```javascript
// Initialize result tracking
previousExecutionResults = []
// In-Memory Mode: Echo execution strategy (transparency before execution)
if (executionContext) {
console.log(`
📋 Execution Strategy (from lite-plan):
Method: ${executionContext.executionMethod}
Review: ${executionContext.codeReviewTool}
Tasks: ${getTasks(executionContext.planObject).length}
Complexity: ${executionContext.planObject.complexity}
${executionContext.executorAssignments ? ` Assignments: ${JSON.stringify(executionContext.executorAssignments)}` : ''}
`)
}
```
### Step 2: Task Grouping & Batch Creation
**Dependency Analysis & Grouping Algorithm**:
```javascript
// Use explicit depends_on from plan.json (no inference from file/keywords)
function extractDependencies(tasks) {
const taskIdToIndex = {}
tasks.forEach((t, i) => { taskIdToIndex[t.id] = i })
return tasks.map((task, i) => {
// Only use explicit depends_on from plan.json
const deps = (task.depends_on || [])
.map(depId => taskIdToIndex[depId])
.filter(idx => idx !== undefined && idx < i)
return { ...task, taskIndex: i, dependencies: deps }
})
}
// Executor Resolution (used by task grouping below)
// 获取任务的 executor优先使用 executorAssignmentsfallback 到全局 executionMethod
function getTaskExecutor(task) {
const assignments = executionContext?.executorAssignments || {}
if (assignments[task.id]) {
return assignments[task.id].executor // 'gemini' | 'codex' | 'agent'
}
// Fallback: 全局 executionMethod 映射
const method = executionContext?.executionMethod || 'Auto'
if (method === 'Agent') return 'agent'
if (method === 'Codex') return 'codex'
// Auto: 根据复杂度
return planObject.complexity === 'Low' ? 'agent' : 'codex'
}
// 按 executor 分组任务(核心分组组件)
function groupTasksByExecutor(tasks) {
const groups = { gemini: [], codex: [], agent: [] }
tasks.forEach(task => {
const executor = getTaskExecutor(task)
groups[executor].push(task)
})
return groups
}
// Group into batches: per-executor parallel batches (one CLI per batch)
function createExecutionCalls(tasks, executionMethod) {
const tasksWithDeps = extractDependencies(tasks)
const processed = new Set()
const calls = []
// Phase 1: Independent tasks → per-executor batches (multi-CLI concurrent)
const independentTasks = tasksWithDeps.filter(t => t.dependencies.length === 0)
if (independentTasks.length > 0) {
const executorGroups = groupTasksByExecutor(independentTasks)
let parallelIndex = 1
for (const [executor, tasks] of Object.entries(executorGroups)) {
if (tasks.length === 0) continue
tasks.forEach(t => processed.add(t.taskIndex))
calls.push({
method: executionMethod,
executor: executor, // 明确指定 executor
executionType: "parallel",
groupId: `P${parallelIndex++}`,
taskSummary: tasks.map(t => t.title).join(' | '),
tasks: tasks
})
}
}
// Phase 2: Dependent tasks → sequential/parallel batches (respect dependencies)
let sequentialIndex = 1
let remaining = tasksWithDeps.filter(t => !processed.has(t.taskIndex))
while (remaining.length > 0) {
// Find tasks whose dependencies are all satisfied
const ready = remaining.filter(t =>
t.dependencies.every(d => processed.has(d))
)
if (ready.length === 0) {
console.warn('Circular dependency detected, forcing remaining tasks')
ready.push(...remaining)
}
if (ready.length > 1) {
// Multiple ready tasks → per-executor batches (parallel within this phase)
const executorGroups = groupTasksByExecutor(ready)
for (const [executor, tasks] of Object.entries(executorGroups)) {
if (tasks.length === 0) continue
tasks.forEach(t => processed.add(t.taskIndex))
calls.push({
method: executionMethod,
executor: executor,
executionType: "parallel",
groupId: `P${calls.length + 1}`,
taskSummary: tasks.map(t => t.title).join(' | '),
tasks: tasks
})
}
} else {
// Single ready task → sequential batch
ready.forEach(t => processed.add(t.taskIndex))
calls.push({
method: executionMethod,
executor: getTaskExecutor(ready[0]),
executionType: "sequential",
groupId: `S${sequentialIndex++}`,
taskSummary: ready[0].title,
tasks: ready
})
}
remaining = remaining.filter(t => !processed.has(t.taskIndex))
}
return calls
}
executionCalls = createExecutionCalls(getTasks(planObject), executionMethod).map(c => ({ ...c, id: `[${c.groupId}]` }))
TodoWrite({
todos: executionCalls.map(c => ({
content: `${c.executionType === "parallel" ? "⚡" : "→"} ${c.id} (${c.tasks.length} tasks)`,
status: "pending",
activeForm: `Executing ${c.id}`
}))
})
```
### Step 3: Launch Execution
**Executor Resolution**: `getTaskExecutor()` and `groupTasksByExecutor()` defined in Step 2 (Task Grouping).
**Batch Execution Routing** (根据 batch.executor 字段路由):
```javascript
// executeBatch 根据 batch 自身的 executor 字段决定调用哪个 CLI
function executeBatch(batch) {
const executor = batch.executor || getTaskExecutor(batch.tasks[0])
const sessionId = executionContext?.session?.id || 'standalone'
const fixedId = `${sessionId}-${batch.groupId}`
if (executor === 'agent') {
// Agent execution (synchronous)
return Task({
subagent_type: "code-developer",
run_in_background: false,
description: batch.taskSummary,
prompt: buildExecutionPrompt(batch)
})
} else if (executor === 'codex') {
// Codex CLI (background)
return Bash(`ccw cli -p "${buildExecutionPrompt(batch)}" --tool codex --mode write --id ${fixedId}`, { run_in_background: true })
} else if (executor === 'gemini') {
// Gemini CLI (background)
return Bash(`ccw cli -p "${buildExecutionPrompt(batch)}" --tool gemini --mode write --id ${fixedId}`, { run_in_background: true })
}
}
```
**并行执行原则**:
- 每个 batch 对应一个独立的 CLI 实例或 Agent 调用
- 并行 = 多个 Bash(run_in_background=true) 或多个 Task() 同时发出
- 绝不将多个独立任务合并到同一个 CLI prompt 中
- Agent 任务不可后台执行run_in_background=false但多个 Agent 任务可通过单条消息中的多个 Task() 调用并发
**Execution Flow**: Parallel batches concurrently → Sequential batches in order
```javascript
const parallel = executionCalls.filter(c => c.executionType === "parallel")
const sequential = executionCalls.filter(c => c.executionType === "sequential")
// Phase 1: Launch all parallel batches (single message with multiple tool calls)
if (parallel.length > 0) {
TodoWrite({ todos: executionCalls.map(c => ({ status: c.executionType === "parallel" ? "in_progress" : "pending" })) })
parallelResults = await Promise.all(parallel.map(c => executeBatch(c)))
previousExecutionResults.push(...parallelResults)
TodoWrite({ todos: executionCalls.map(c => ({ status: parallel.includes(c) ? "completed" : "pending" })) })
}
// Phase 2: Execute sequential batches one by one
for (const call of sequential) {
TodoWrite({ todos: executionCalls.map(c => ({ status: c === call ? "in_progress" : "..." })) })
result = await executeBatch(call)
previousExecutionResults.push(result)
TodoWrite({ todos: executionCalls.map(c => ({ status: "completed" or "pending" })) })
}
```
### Unified Task Prompt Builder
**Task Formatting Principle**: Each task is a self-contained checklist. The executor only needs to know what THIS task requires. Same template for Agent and CLI.
```javascript
function buildExecutionPrompt(batch) {
// Task template (6 parts: Files → Why → How → Reference → Risks → Done)
const formatTask = (t) => `
## ${t.title}
**Scope**: \`${t.scope}\` | **Action**: ${t.action}
### Files
${(t.files || []).map(f => `- **${f.path}** → \`${f.target || ''}\`: ${f.change || (f.changes || []).join(', ') || ''}`).join('\n')}
${t.rationale ? `
### Why this approach (Medium/High)
${t.rationale.chosen_approach}
${t.rationale.decision_factors?.length > 0 ? `\nKey factors: ${t.rationale.decision_factors.join(', ')}` : ''}
${t.rationale.tradeoffs ? `\nTradeoffs: ${t.rationale.tradeoffs}` : ''}
` : ''}
### How to do it
${t.description}
${t.implementation.map(step => `- ${step}`).join('\n')}
${t.code_skeleton ? `
### Code skeleton (High)
${t.code_skeleton.interfaces?.length > 0 ? `**Interfaces**: ${t.code_skeleton.interfaces.map(i => `\`${i.name}\` - ${i.purpose}`).join(', ')}` : ''}
${t.code_skeleton.key_functions?.length > 0 ? `\n**Functions**: ${t.code_skeleton.key_functions.map(f => `\`${f.signature}\` - ${f.purpose}`).join(', ')}` : ''}
${t.code_skeleton.classes?.length > 0 ? `\n**Classes**: ${t.code_skeleton.classes.map(c => `\`${c.name}\` - ${c.purpose}`).join(', ')}` : ''}
` : ''}
### Reference
- Pattern: ${t.reference?.pattern || 'N/A'}
- Files: ${t.reference?.files?.join(', ') || 'N/A'}
${t.reference?.examples ? `- Notes: ${t.reference.examples}` : ''}
${t.risks?.length > 0 ? `
### Risk mitigations (High)
${t.risks.map(r => `- ${r.description} → **${r.mitigation}**`).join('\n')}
` : ''}
### Done when
${(t.convergence?.criteria || []).map(c => `- [ ] ${c}`).join('\n')}
${(t.test?.success_metrics || []).length > 0 ? `\n**Success metrics**: ${t.test.success_metrics.join(', ')}` : ''}`
// Build prompt
const sections = []
if (originalUserInput) sections.push(`## Goal\n${originalUserInput}`)
sections.push(`## Tasks\n${batch.tasks.map(formatTask).join('\n\n---\n')}`)
// Context (reference only)
const context = []
if (previousExecutionResults.length > 0) {
context.push(`### Previous Work\n${previousExecutionResults.map(r => `- ${r.tasksSummary}: ${r.status}`).join('\n')}`)
}
if (clarificationContext) {
context.push(`### Clarifications\n${Object.entries(clarificationContext).map(([q, a]) => `- ${q}: ${a}`).join('\n')}`)
}
if (executionContext?.planObject?.data_flow?.diagram) {
context.push(`### Data Flow\n${executionContext.planObject.data_flow.diagram}`)
}
if (executionContext?.session?.artifacts?.plan) {
context.push(`### Artifacts\nPlan: ${executionContext.session.artifacts.plan}`)
}
// Project guidelines (user-defined constraints from /workflow:session:solidify)
context.push(`### Project Guidelines\n@.workflow/project-guidelines.json`)
if (context.length > 0) sections.push(`## Context\n${context.join('\n\n')}`)
sections.push(`Complete each task according to its "Done when" checklist.`)
return sections.join('\n\n')
}
```
**Option A: Agent Execution**
When to use:
- `getTaskExecutor(task) === "agent"`
-`executionMethod = "Agent"` (全局 fallback)
-`executionMethod = "Auto" AND complexity = "Low"` (全局 fallback)
```javascript
Task(
subagent_type="code-developer",
run_in_background=false,
description=batch.taskSummary,
prompt=buildExecutionPrompt(batch)
)
```
**Result Collection**: After completion, collect result following `executionResult` structure (see Data Structures section)
**Option B: CLI Execution (Codex)**
When to use:
- `getTaskExecutor(task) === "codex"`
-`executionMethod = "Codex"` (全局 fallback)
-`executionMethod = "Auto" AND complexity = "Medium/High"` (全局 fallback)
```bash
ccw cli -p "${buildExecutionPrompt(batch)}" --tool codex --mode write
```
**Execution with fixed IDs** (predictable ID pattern):
```javascript
// Launch CLI in background, wait for task hook callback
// Generate fixed execution ID: ${sessionId}-${groupId}
const sessionId = executionContext?.session?.id || 'standalone'
const fixedExecutionId = `${sessionId}-${batch.groupId}` // e.g., "implement-auth-2025-12-13-P1"
// Check if resuming from previous failed execution
const previousCliId = batch.resumeFromCliId || null
// Build command with fixed ID (and optional resume for continuation)
const cli_command = previousCliId
? `ccw cli -p "${buildExecutionPrompt(batch)}" --tool codex --mode write --id ${fixedExecutionId} --resume ${previousCliId}`
: `ccw cli -p "${buildExecutionPrompt(batch)}" --tool codex --mode write --id ${fixedExecutionId}`
// Execute in background, stop output and wait for task hook callback
Bash(
command=cli_command,
run_in_background=true
)
// STOP HERE - CLI executes in background, task hook will notify on completion
```
**Resume on Failure** (with fixed ID):
```javascript
// If execution failed or timed out, offer resume option
if (bash_result.status === 'failed' || bash_result.status === 'timeout') {
console.log(`
⚠️ Execution incomplete. Resume available:
Fixed ID: ${fixedExecutionId}
Lookup: ccw cli detail ${fixedExecutionId}
Resume: ccw cli -p "Continue tasks" --resume ${fixedExecutionId} --tool codex --mode write --id ${fixedExecutionId}-retry
`)
// Store for potential retry in same session
batch.resumeFromCliId = fixedExecutionId
}
```
**Result Collection**: After completion, analyze output and collect result following `executionResult` structure (include `cliExecutionId` for resume capability)
**Option C: CLI Execution (Gemini)**
When to use: `getTaskExecutor(task) === "gemini"` (分析类任务)
```bash
# 使用统一的 buildExecutionPrompt切换 tool 和 mode
ccw cli -p "${buildExecutionPrompt(batch)}" --tool gemini --mode analysis --id ${sessionId}-${batch.groupId}
```
### Step 4: Progress Tracking
Progress tracked at batch level (not individual task level). Icons: ⚡ (parallel, concurrent), → (sequential, one-by-one)
### Step 5: Code Review (Optional)
**Skip Condition**: Only run if `codeReviewTool ≠ "Skip"`
**Review Focus**: Verify implementation against plan convergence criteria and test requirements
- Read plan.json + .task/*.json for task convergence criteria and test checklist
- Check each convergence criterion is fulfilled
- Verify success metrics from test field (Medium/High complexity)
- Run unit/integration tests specified in test field
- Validate code quality and identify issues
- Ensure alignment with planned approach and risk mitigations
**Operations**:
- Agent Review: Current agent performs direct review
- Gemini Review: Execute gemini CLI with review prompt
- Codex Review: Two options - (A) with prompt for complex reviews, (B) `--uncommitted` flag only for quick reviews
- Custom tool: Execute specified CLI tool (qwen, etc.)
**Unified Review Template** (All tools use same standard):
**Review Criteria**:
- **Convergence Criteria**: Verify each criterion from task convergence.criteria
- **Test Checklist** (Medium/High): Check unit, integration, success_metrics from task test
- **Code Quality**: Analyze quality, identify issues, suggest improvements
- **Plan Alignment**: Validate implementation matches planned approach and risk mitigations
**Shared Prompt Template** (used by all CLI tools):
```
PURPOSE: Code review for implemented changes against plan convergence criteria and test requirements
TASK: • Verify plan convergence criteria fulfillment • Check test requirements (unit, integration, success_metrics) • Analyze code quality • Identify issues • Suggest improvements • Validate plan adherence and risk mitigations
MODE: analysis
CONTEXT: @**/* @{plan.json} @{.task/*.json} [@{exploration.json}] | Memory: Review lite-execute changes against plan requirements including test checklist
EXPECTED: Quality assessment with:
- Convergence criteria verification (all tasks from .task/*.json)
- Test checklist validation (Medium/High: unit, integration, success_metrics)
- Issue identification
- Recommendations
Explicitly check each convergence criterion and test item from .task/*.json files.
CONSTRAINTS: Focus on plan convergence criteria, test requirements, and plan adherence | analysis=READ-ONLY
```
**Tool-Specific Execution** (Apply shared prompt template above):
```bash
# Method 1: Agent Review (current agent)
# - Read plan.json: ${executionContext.session.artifacts.plan}
# - Apply unified review criteria (see Shared Prompt Template)
# - Report findings directly
# Method 2: Gemini Review (recommended)
ccw cli -p "[Shared Prompt Template with artifacts]" --tool gemini --mode analysis
# CONTEXT includes: @**/* @${plan.json} [@${exploration.json}]
# Method 3: Qwen Review (alternative)
ccw cli -p "[Shared Prompt Template with artifacts]" --tool qwen --mode analysis
# Same prompt as Gemini, different execution engine
# Method 4: Codex Review (git-aware) - Two mutually exclusive options:
# Option A: With custom prompt (reviews uncommitted by default)
ccw cli -p "[Shared Prompt Template with artifacts]" --tool codex --mode review
# Use for complex reviews with specific focus areas
# Option B: Target flag only (no prompt allowed)
ccw cli --tool codex --mode review --uncommitted
# Quick review of uncommitted changes without custom instructions
# ⚠️ IMPORTANT: -p prompt and target flags (--uncommitted/--base/--commit) are MUTUALLY EXCLUSIVE
```
**Multi-Round Review with Fixed IDs**:
```javascript
// Generate fixed review ID
const reviewId = `${sessionId}-review`
// First review pass with fixed ID
const reviewResult = Bash(`ccw cli -p "[Review prompt]" --tool gemini --mode analysis --id ${reviewId}`)
// If issues found, continue review dialog with fixed ID chain
if (hasUnresolvedIssues(reviewResult)) {
// Resume with follow-up questions
Bash(`ccw cli -p "Clarify the security concerns you mentioned" --resume ${reviewId} --tool gemini --mode analysis --id ${reviewId}-followup`)
}
```
**Implementation Note**: Replace `[Shared Prompt Template with artifacts]` placeholder with actual template content, substituting:
- `@{plan.json}``@${executionContext.session.artifacts.plan}`
- `[@{exploration.json}]` → exploration files from artifacts (if exists)
### Step 6: Auto-Sync Project State
**Trigger**: After all executions complete (regardless of code review)
**Operation**: Execute `/workflow:session:sync -y "{summary}"` to update both `project-guidelines.json` and `project-tech.json` in one shot.
Summary 取值优先级:`originalUserInput``planObject.summary` → git log 自动推断。
## Best Practices
**Input Modes**: In-memory (lite-plan), prompt (standalone), file (JSON/text)
**Task Grouping**: Based on explicit depends_on only; independent tasks split by executor, each batch runs as separate CLI instance
**Execution**: Independent task batches launch concurrently via single Claude message with multiple tool calls (one tool call per batch)
## Error Handling
| Error | Cause | Resolution |
|-------|-------|------------|
| Missing executionContext | In-memory mode without context | Error: "No execution context found. Only available when called by lite-plan." |
| File not found | File path doesn't exist | Error: "File not found: {path}. Check file path." |
| Empty file | File exists but no content | Error: "File is empty: {path}. Provide task description." |
| Invalid Enhanced Task JSON | JSON missing required fields | Warning: "Missing required fields. Treating as plain text." |
| Malformed JSON | JSON parsing fails | Treat as plain text (expected for non-JSON files) |
| Execution failure | Agent/Codex crashes | Display error, use fixed ID `${sessionId}-${groupId}` for resume: `ccw cli -p "Continue" --resume <fixed-id> --id <fixed-id>-retry` |
| Execution timeout | CLI exceeded timeout | Use fixed ID for resume with extended timeout |
| Codex unavailable | Codex not installed | Show installation instructions, offer Agent execution |
| Fixed ID not found | Custom ID lookup failed | Check `ccw cli history`, verify date directories |
## Data Structures
### executionContext (Input - Mode 1)
Passed from lite-plan via global variable:
```javascript
{
planObject: {
summary: string,
approach: string,
task_ids: string[], // Task IDs referencing .task/*.json files
task_count: number, // Number of tasks
_loadedTasks: [...], // Populated at runtime from .task/*.json files
estimated_time: string,
recommended_execution: string,
complexity: string
},
// Task file paths (populated for two-layer format)
taskFiles: [{id: string, path: string}] | null,
explorationsContext: {...} | null, // Multi-angle explorations
explorationAngles: string[], // List of exploration angles
explorationManifest: {...} | null, // Exploration manifest
clarificationContext: {...} | null,
executionMethod: "Agent" | "Codex" | "Auto", // 全局默认
codeReviewTool: "Skip" | "Gemini Review" | "Agent Review" | string,
originalUserInput: string,
// 任务级 executor 分配(优先于 executionMethod
executorAssignments: {
[taskId]: { executor: "gemini" | "codex" | "agent", reason: string }
},
// Session artifacts location (saved by lite-plan)
session: {
id: string, // Session identifier: {taskSlug}-{shortTimestamp}
folder: string, // Session folder path: .workflow/.lite-plan/{session-id}
artifacts: {
explorations: [{angle, path}], // exploration-{angle}.json paths
explorations_manifest: string, // explorations-manifest.json path
plan: string // plan.json path (always present)
}
}
}
```
**Artifact Usage**:
- Artifact files contain detailed planning context
- Pass artifact paths to CLI tools and agents for enhanced context
- See execution options below for usage examples
### executionResult (Output)
Collected after each execution call completes:
```javascript
{
executionId: string, // e.g., "[Agent-1]", "[Codex-1]"
status: "completed" | "partial" | "failed",
tasksSummary: string, // Brief description of tasks handled
completionSummary: string, // What was completed
keyOutputs: string, // Files created/modified, key changes
notes: string, // Important context for next execution
fixedCliId: string | null // Fixed CLI execution ID (e.g., "implement-auth-2025-12-13-P1")
}
```
Appended to `previousExecutionResults` array for context continuity in multi-execution scenarios.
## Post-Completion Expansion
**Auto-sync**: 执行 `/workflow:session:sync -y "{summary}"` 更新 project-guidelines + project-techStep 6 已触发,此处不重复)。
完成后询问用户是否扩展为issue(test/enhance/refactor/doc),选中项调用 `/issue:new "{summary} - {dimension}"`
**Fixed ID Pattern**: `${sessionId}-${groupId}` enables predictable lookup without auto-generated timestamps.
**Resume Usage**: If `status` is "partial" or "failed", use `fixedCliId` to resume:
```bash
# Lookup previous execution
ccw cli detail ${fixedCliId}
# Resume with new fixed ID for retry
ccw cli -p "Continue from where we left off" --resume ${fixedCliId} --tool codex --mode write --id ${fixedCliId}-retry
```

View File

@@ -714,13 +714,55 @@ executionContext = {
}
```
**Step 5.2: Handoff**
**Step 5.2: Serialize & Agent Handoff**
> **Why agent handoff**: Phase 1 history consumes significant context. Direct `Read("phases/02-lite-execute.md")` in the same context risks compact compressing Phase 2 instructions mid-execution. Spawning a fresh agent gives Phase 2 a clean context window.
```javascript
// Direct phase handoff: Read and execute Phase 2 (lite-execute) with in-memory context
// No Skill routing needed - executionContext is already set in Step 5.1
Read("phases/02-lite-execute.md")
// Execute Phase 2 with executionContext (Mode 1: In-Memory Plan)
// Pre-populate _loadedTasks so serialized context is self-contained
executionContext.planObject._loadedTasks = (executionContext.planObject.task_ids || []).map(id =>
JSON.parse(Read(`${sessionFolder}/.task/${id}.json`))
)
// Save executionContext to file for agent handoff
Write(`${sessionFolder}/execution-context.json`, JSON.stringify(executionContext, null, 2))
// Resolve absolute path to Phase 2 instructions
const phaseFile = Bash(`cd "${Bash('pwd').trim()}/.claude/skills/workflow-lite-plan/phases" && pwd`).trim()
+ '/02-lite-execute.md'
// Agent handoff: fresh context prevents compact from losing Phase 2 instructions
Task(
subagent_type="universal-executor",
run_in_background=false,
description=`Execute: ${taskSlug}`,
prompt=`
Execute implementation plan following lite-execute protocol.
## Phase Instructions (MUST read first)
Read and follow: ${phaseFile}
## Execution Context (Mode 1: In-Memory Plan)
Read and parse as JSON: ${sessionFolder}/execution-context.json
This is the executionContext variable referenced throughout Phase 2.
The planObject._loadedTasks array is pre-populated — getTasks(planObject) works directly.
## Key References
- Session ID: ${sessionId}
- Session folder: ${sessionFolder}
- Plan: ${sessionFolder}/plan.json
- Task files: ${sessionFolder}/.task/TASK-*.json
- Original task: ${task_description}
## Execution Steps
1. Read phase instructions file (full protocol)
2. Read execution-context.json → parse as executionContext
3. Follow Phase 2 Mode 1 (In-Memory Plan) — executionContext exists, skip user selection
4. Execute all tasks (Step 1-4 in Phase 2)
5. Run code review if codeReviewTool ≠ "Skip" (Step 5)
6. Run auto-sync (Step 6)
`
)
```
## Session Folder Structure

View File

@@ -0,0 +1,574 @@
---
name: team-lifecycle-v2
description: Unified team skill for full lifecycle - spec/impl/test. All roles invoke this skill with --role arg for role-specific execution. Triggers on "team lifecycle".
allowed-tools: TeamCreate(*), TeamDelete(*), SendMessage(*), TaskCreate(*), TaskUpdate(*), TaskList(*), TaskGet(*), Task(*), AskUserQuestion(*), TodoWrite(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)
---
# Team Lifecycle
Unified team skill covering specification, implementation, testing, and review. All team members invoke this skill with `--role=xxx` to route to role-specific execution.
## Architecture Overview
```
┌───────────────────────────────────────────────────┐
│ Skill(skill="team-lifecycle-v2") │
│ args="任务描述" 或 args="--role=xxx" │
└───────────────────┬───────────────────────────────┘
│ Role Router
┌──── --role present? ────┐
│ NO │ YES
↓ ↓
Orchestration Mode Role Dispatch
(auto → coordinator) (route to role.md)
┌────┴────┬───────┬───────┬───────┬───────┬───────┬───────┐
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
┌──────────┐┌───────┐┌──────┐┌──────────┐┌───────┐┌────────┐┌──────┐┌────────┐
│coordinator││analyst││writer││discussant││planner││executor││tester││reviewer│
│ roles/ ││roles/ ││roles/││ roles/ ││roles/ ││ roles/ ││roles/││ roles/ │
└──────────┘└───────┘└──────┘└──────────┘└───────┘└────────┘└──────┘└────────┘
↑ ↑
on-demand by coordinator
┌──────────┐ ┌─────────┐
│ explorer │ │architect│
│ (service)│ │(consult)│
└──────────┘ └─────────┘
```
## Command Architecture
Each role is organized as a folder with a `role.md` orchestrator and optional `commands/` for delegation:
```
roles/
├── coordinator/
│ ├── role.md # Orchestrator (Phase 1/5 inline, Phase 2-4 delegate)
│ └── commands/
│ ├── dispatch.md # Task chain creation (3 modes)
│ └── monitor.md # Coordination loop + message routing
├── analyst/
│ ├── role.md
│ └── commands/
├── writer/
│ ├── role.md
│ └── commands/
│ └── generate-doc.md # Multi-CLI document generation (4 doc types)
├── discussant/
│ ├── role.md
│ └── commands/
│ └── critique.md # Multi-perspective CLI critique
├── planner/
│ ├── role.md
│ └── commands/
│ └── explore.md # Multi-angle codebase exploration
├── executor/
│ ├── role.md
│ └── commands/
│ └── implement.md # Multi-backend code implementation
├── tester/
│ ├── role.md
│ └── commands/
│ └── validate.md # Test-fix cycle
├── reviewer/
│ ├── role.md
│ └── commands/
│ ├── code-review.md # 4-dimension code review
│ └── spec-quality.md # 5-dimension spec quality check
├── explorer/ # Service role (on-demand)
│ └── role.md # Multi-strategy code search & pattern discovery
└── architect/ # Consulting role (on-demand)
├── role.md # Multi-mode architecture assessment
└── commands/
└── assess.md # Mode-specific assessment strategies
├── fe-developer/ # Frontend pipeline role
│ └── role.md # Frontend component/page implementation
└── fe-qa/ # Frontend pipeline role
├── role.md
└── commands/
└── pre-delivery-checklist.md
└── role.md # 5-dimension frontend QA + GC loop
```
**Design principle**: role.md keeps Phase 1 (Task Discovery) and Phase 5 (Report) inline. Phases 2-4 either stay inline (simple logic) or delegate to `commands/*.md` via `Read("commands/xxx.md")` when they involve subagent delegation, CLI fan-out, or complex strategies.
**Command files** are self-contained: each includes Strategy, Execution Steps, and Error Handling. Any subagent can `Read()` a command file and execute it independently.
## Role Router
### Input Parsing
Parse `$ARGUMENTS` to extract `--role`:
```javascript
const args = "$ARGUMENTS"
const roleMatch = args.match(/--role[=\s]+(\w+)/)
const teamName = args.match(/--team[=\s]+([\w-]+)/)?.[1] || "lifecycle"
if (!roleMatch) {
// No --role: Orchestration Mode → auto route to coordinator
// See "Orchestration Mode" section below
}
const role = roleMatch ? roleMatch[1] : "coordinator"
```
### Role Dispatch
```javascript
const VALID_ROLES = {
"coordinator": { file: "roles/coordinator/role.md", prefix: null },
"analyst": { file: "roles/analyst/role.md", prefix: "RESEARCH" },
"writer": { file: "roles/writer/role.md", prefix: "DRAFT" },
"discussant": { file: "roles/discussant/role.md", prefix: "DISCUSS" },
"planner": { file: "roles/planner/role.md", prefix: "PLAN" },
"executor": { file: "roles/executor/role.md", prefix: "IMPL" },
"tester": { file: "roles/tester/role.md", prefix: "TEST" },
"reviewer": { file: "roles/reviewer/role.md", prefix: ["REVIEW", "QUALITY"] },
"explorer": { file: "roles/explorer/role.md", prefix: "EXPLORE", type: "service" },
"architect": { file: "roles/architect/role.md", prefix: "ARCH", type: "consulting" },
"fe-developer":{ file: "roles/fe-developer/role.md",prefix: "DEV-FE", type: "frontend-pipeline" },
"fe-qa": { file: "roles/fe-qa/role.md", prefix: "QA-FE", type: "frontend-pipeline" }
}
if (!VALID_ROLES[role]) {
throw new Error(`Unknown role: ${role}. Available: ${Object.keys(VALID_ROLES).join(', ')}`)
}
// Read and execute role-specific logic
Read(VALID_ROLES[role].file)
// → Execute the 5-phase process defined in that file
```
### Orchestration Mode无参数触发
当不带 `--role` 调用时,自动进入 coordinator 编排模式。用户只需传任务描述即可触发完整流程。
**触发方式**:
```javascript
// 用户调用(无 --role— 自动路由到 coordinator
Skill(skill="team-lifecycle-v2", args="任务描述")
// 等价于
Skill(skill="team-lifecycle-v2", args="--role=coordinator 任务描述")
```
**流程**:
```javascript
if (!roleMatch) {
// Orchestration Mode: 自动路由到 coordinator
// coordinator role.md 将执行:
// Phase 1: 需求澄清
// Phase 2: TeamCreate + spawn 所有 worker agents
// 每个 agent prompt 中包含 Skill(args="--role=xxx") 回调
// Phase 3: 创建任务链
// Phase 4: 监控协调循环
// Phase 5: 结果汇报
const role = "coordinator"
Read(VALID_ROLES[role].file)
}
```
**完整调用链**:
```
用户: Skill(args="任务描述")
├─ SKILL.md: 无 --role → Orchestration Mode → 读取 coordinator role.md
├─ coordinator Phase 2: TeamCreate + spawn workers
│ 每个 worker prompt 中包含 Skill(args="--role=xxx") 回调
├─ coordinator Phase 3: dispatch 任务链
├─ worker 收到任务 → Skill(args="--role=xxx") → SKILL.md Role Router → role.md
│ 每个 worker 自动获取:
│ ├─ 角色定义 (role.md: identity, boundaries, message types)
│ ├─ 可用命令 (commands/*.md)
│ └─ 执行逻辑 (5-phase process)
└─ coordinator Phase 4-5: 监控 → 结果汇报
```
### Available Roles
| Role | Task Prefix | Responsibility | Role File |
|------|-------------|----------------|-----------|
| `coordinator` | N/A | Pipeline orchestration, requirement clarification, task dispatch | [roles/coordinator/role.md](roles/coordinator/role.md) |
| `analyst` | RESEARCH-* | Seed analysis, codebase exploration, context gathering | [roles/analyst/role.md](roles/analyst/role.md) |
| `writer` | DRAFT-* | Product Brief / PRD / Architecture / Epics generation | [roles/writer/role.md](roles/writer/role.md) |
| `discussant` | DISCUSS-* | Multi-perspective critique, consensus building | [roles/discussant/role.md](roles/discussant/role.md) |
| `planner` | PLAN-* | Multi-angle exploration, structured planning | [roles/planner/role.md](roles/planner/role.md) |
| `executor` | IMPL-* | Code implementation following plans | [roles/executor/role.md](roles/executor/role.md) |
| `tester` | TEST-* | Adaptive test-fix cycles, quality gates | [roles/tester/role.md](roles/tester/role.md) |
| `reviewer` | `REVIEW-*` + `QUALITY-*` | Code review + Spec quality validation (auto-switch by prefix) | [roles/reviewer/role.md](roles/reviewer/role.md) |
| `explorer` | EXPLORE-* | Code search, pattern discovery, dependency tracing (service role, on-demand) | [roles/explorer/role.md](roles/explorer/role.md) |
| `architect` | ARCH-* | Architecture assessment, tech feasibility, design review (consulting role, on-demand) | [roles/architect/role.md](roles/architect/role.md) |
| `fe-developer` | DEV-FE-* | Frontend component/page implementation, design token consumption (frontend pipeline) | [roles/fe-developer/role.md](roles/fe-developer/role.md) |
| `fe-qa` | QA-FE-* | 5-dimension frontend QA, accessibility, design compliance, GC loop (frontend pipeline) | [roles/fe-qa/role.md](roles/fe-qa/role.md) |
## Shared Infrastructure
### Role Isolation Rules
**核心原则**: 每个角色仅能执行自己职责范围内的工作。
#### Output Tagging强制
所有角色的输出必须带 `[role_name]` 标识前缀:
```javascript
// SendMessage — content 和 summary 都必须带标识
SendMessage({
content: `## [${role}] ...`,
summary: `[${role}] ...`
})
// team_msg — summary 必须带标识
mcp__ccw-tools__team_msg({
summary: `[${role}] ...`
})
```
#### Coordinator 隔离
| 允许 | 禁止 |
|------|------|
| 需求澄清 (AskUserQuestion) | ❌ 直接编写/修改代码 |
| 创建任务链 (TaskCreate) | ❌ 调用实现类 subagent (code-developer 等) |
| 分发任务给 worker | ❌ 直接执行分析/测试/审查 |
| 监控进度 (消息总线) | ❌ 绕过 worker 自行完成任务 |
| 汇报结果给用户 | ❌ 修改源代码或产物文件 |
#### Worker 隔离
| 允许 | 禁止 |
|------|------|
| 处理自己前缀的任务 | ❌ 处理其他角色前缀的任务 |
| SendMessage 给 coordinator | ❌ 直接与其他 worker 通信 |
| 使用 Toolbox 中声明的工具 | ❌ 为其他角色创建任务 (TaskCreate) |
| 委派给 commands/ 中的命令 | ❌ 修改不属于本职责的资源 |
### Message Bus (All Roles)
Every SendMessage **before**, must call `mcp__ccw-tools__team_msg` to log:
```javascript
mcp__ccw-tools__team_msg({
operation: "log",
team: teamName,
from: role,
to: "coordinator",
type: "<type>",
summary: `[${role}] <summary>`,
ref: "<file_path>"
})
```
**Message types by role**:
| Role | Types |
|------|-------|
| coordinator | `plan_approved`, `plan_revision`, `task_unblocked`, `fix_required`, `error`, `shutdown` |
| analyst | `research_ready`, `research_progress`, `error` |
| writer | `draft_ready`, `draft_revision`, `impl_progress`, `error` |
| discussant | `discussion_ready`, `discussion_blocked`, `impl_progress`, `error` |
| planner | `plan_ready`, `plan_revision`, `impl_progress`, `error` |
| executor | `impl_complete`, `impl_progress`, `error` |
| tester | `test_result`, `impl_progress`, `fix_required`, `error` |
| reviewer | `review_result`, `quality_result`, `fix_required`, `error` |
| explorer | `explore_ready`, `explore_progress`, `task_failed` |
| architect | `arch_ready`, `arch_concern`, `arch_progress`, `error` |
| fe-developer | `dev_fe_complete`, `dev_fe_progress`, `error` |
| fe-qa | `qa_fe_passed`, `qa_fe_result`, `fix_required`, `error` |
### CLI Fallback
When `mcp__ccw-tools__team_msg` MCP is unavailable:
```javascript
Bash(`ccw team log --team "${teamName}" --from "${role}" --to "coordinator" --type "<type>" --summary "[${role}] <summary>" --json`)
Bash(`ccw team list --team "${teamName}" --last 10 --json`)
Bash(`ccw team status --team "${teamName}" --json`)
```
### Wisdom Accumulation (All Roles)
跨任务知识积累机制。Coordinator 在 session 初始化时创建 `wisdom/` 目录,所有 worker 在执行过程中读取和贡献 wisdom。
**目录结构**:
```
{sessionFolder}/wisdom/
├── learnings.md # 发现的模式和洞察
├── decisions.md # 架构和设计决策
├── conventions.md # 代码库约定
└── issues.md # 已知风险和问题
```
**Phase 2 加载(所有 worker**:
```javascript
// Load wisdom context at start of Phase 2
const sessionFolder = task.description.match(/Session:\s*([^\n]+)/)?.[1]?.trim()
let wisdom = {}
if (sessionFolder) {
try { wisdom.learnings = Read(`${sessionFolder}/wisdom/learnings.md`) } catch {}
try { wisdom.decisions = Read(`${sessionFolder}/wisdom/decisions.md`) } catch {}
try { wisdom.conventions = Read(`${sessionFolder}/wisdom/conventions.md`) } catch {}
try { wisdom.issues = Read(`${sessionFolder}/wisdom/issues.md`) } catch {}
}
```
**Phase 4/5 贡献(任务完成时)**:
```javascript
// Contribute wisdom after task completion
if (sessionFolder) {
const timestamp = new Date().toISOString().substring(0, 10)
// Role-specific contributions:
// analyst → learnings (exploration dimensions, codebase patterns)
// writer → conventions (document structure, naming patterns)
// planner → decisions (task decomposition rationale)
// executor → learnings (implementation patterns), issues (bugs encountered)
// tester → issues (test failures, edge cases), learnings (test patterns)
// reviewer → conventions (code quality patterns), issues (review findings)
// explorer → conventions (codebase patterns), learnings (dependency insights)
// architect → decisions (architecture choices), issues (architectural risks)
try {
const targetFile = `${sessionFolder}/wisdom/${wisdomTarget}.md`
const existing = Read(targetFile)
const entry = `- [${timestamp}] [${role}] ${wisdomEntry}`
Write(targetFile, existing + '\n' + entry)
} catch {} // wisdom not initialized
}
```
**Coordinator 注入**: Coordinator 在 spawn worker 时通过 task description 传递 `Session: {sessionFolder}`worker 据此定位 wisdom 目录。已有 wisdom 内容为后续 worker 提供上下文,实现跨任务知识传递。
### Task Lifecycle (All Worker Roles)
```javascript
// Standard task lifecycle every worker role follows
// Phase 1: Discovery
const tasks = TaskList()
const prefixes = Array.isArray(VALID_ROLES[role].prefix) ? VALID_ROLES[role].prefix : [VALID_ROLES[role].prefix]
const myTasks = tasks.filter(t =>
prefixes.some(p => t.subject.startsWith(`${p}-`)) &&
t.owner === role &&
t.status === 'pending' &&
t.blockedBy.length === 0
)
if (myTasks.length === 0) return // idle
const task = TaskGet({ taskId: myTasks[0].id })
TaskUpdate({ taskId: task.id, status: 'in_progress' })
// Phase 1.5: Resume Artifact Check (防止重复产出)
// 当 session 从暂停恢复时coordinator 已将 in_progress 任务重置为 pending。
// Worker 在开始工作前,必须检查该任务的输出产物是否已存在。
// 如果产物已存在且内容完整:
// → 直接跳到 Phase 5 报告完成(避免覆盖上次成果)
// 如果产物存在但不完整(如文件为空或缺少关键 section
// → 正常执行 Phase 2-4基于已有产物继续而非从头开始
// 如果产物不存在:
// → 正常执行 Phase 2-4
//
// 每个 role 检查自己的输出路径:
// analyst → sessionFolder/spec/discovery-context.json
// writer → sessionFolder/spec/{product-brief.md | requirements/ | architecture/ | epics/}
// discussant → sessionFolder/discussions/discuss-NNN-*.md
// planner → sessionFolder/plan/plan.json
// executor → git diff (已提交的代码变更)
// tester → test pass rate
// reviewer → sessionFolder/spec/readiness-report.md (quality) 或 review findings (code)
// Phase 2-4: Role-specific (see roles/{role}/role.md)
// Phase 5: Report + Loop — 所有输出必须带 [role] 标识
mcp__ccw-tools__team_msg({ operation: "log", team: teamName, from: role, to: "coordinator", type: "...", summary: `[${role}] ...` })
SendMessage({ type: "message", recipient: "coordinator", content: `## [${role}] ...`, summary: `[${role}] ...` })
TaskUpdate({ taskId: task.id, status: 'completed' })
// Check for next task → back to Phase 1
```
## Three-Mode Pipeline
```
Spec-only:
RESEARCH-001 → DISCUSS-001 → DRAFT-001 → DISCUSS-002
→ DRAFT-002 → DISCUSS-003 → DRAFT-003 → DISCUSS-004
→ DRAFT-004 → DISCUSS-005 → QUALITY-001 → DISCUSS-006
Impl-only (backend):
PLAN-001 → IMPL-001 → TEST-001 + REVIEW-001
Full-lifecycle (backend):
[Spec pipeline] → PLAN-001(blockedBy: DISCUSS-006) → IMPL-001 → TEST-001 + REVIEW-001
```
### Frontend Pipelines
Coordinator 根据任务关键词自动检测前端任务并路由到前端子流水线:
```
FE-only (纯前端):
PLAN-001 → DEV-FE-001 → QA-FE-001
(GC loop: if QA-FE verdict=NEEDS_FIX → DEV-FE-002 → QA-FE-002, max 2 rounds)
Fullstack (前后端并行):
PLAN-001 → IMPL-001 ∥ DEV-FE-001 → TEST-001 ∥ QA-FE-001 → REVIEW-001
Full-lifecycle + FE:
[Spec pipeline] → PLAN-001(blockedBy: DISCUSS-006)
→ IMPL-001 ∥ DEV-FE-001 → TEST-001 ∥ QA-FE-001 → REVIEW-001
```
### Frontend Detection
Coordinator 在 Phase 1 根据任务关键词 + 项目文件自动检测前端任务并选择流水线模式fe-only / fullstack / impl-only。检测逻辑见 [roles/coordinator/role.md](roles/coordinator/role.md)。
### Generator-Critic Loop (fe-developer ↔ fe-qa)
```
┌──────────────┐ DEV-FE artifact ┌──────────┐
│ fe-developer │ ──────────────────→ │ fe-qa │
│ (Generator) │ │ (Critic) │
│ │ ←────────────────── │ │
└──────────────┘ QA-FE feedback └──────────┘
(max 2 rounds)
Convergence: fe-qa.score >= 8 && fe-qa.critical_count === 0
```
## Unified Session Directory
All session artifacts are stored under a single session folder:
```
.workflow/.team/TLS-{slug}-{YYYY-MM-DD}/
├── team-session.json # Session state (status, progress, completed_tasks)
├── spec/ # Spec artifacts (analyst, writer, reviewer output)
│ ├── spec-config.json
│ ├── discovery-context.json
│ ├── product-brief.md
│ ├── requirements/ # _index.md + REQ-*.md + NFR-*.md
│ ├── architecture/ # _index.md + ADR-*.md
│ ├── epics/ # _index.md + EPIC-*.md
│ ├── readiness-report.md
│ └── spec-summary.md
├── discussions/ # Discussion records (discussant output)
│ └── discuss-001..006.md
├── plan/ # Plan artifacts (planner output)
│ ├── exploration-{angle}.json
│ ├── explorations-manifest.json
│ ├── plan.json
│ └── .task/
│ └── TASK-*.json
├── explorations/ # Explorer output (cached for cross-role reuse)
│ └── explore-*.json
├── architecture/ # Architect output (assessment reports)
│ └── arch-*.json
└── wisdom/ # Cross-task accumulated knowledge
├── learnings.md # Patterns and insights discovered
├── decisions.md # Architectural decisions made
├── conventions.md # Codebase conventions found
└── issues.md # Known issues and risks
├── qa/ # QA output (fe-qa audit reports)
│ └── audit-fe-*.json
└── build/ # Frontend build output (fe-developer)
├── token-files/
└── component-files/
```
Messages remain at `.workflow/.team-msg/{team-name}/` (unchanged).
## Session Resume
Coordinator supports `--resume` / `--continue` flags to resume interrupted sessions:
1. Scans `.workflow/.team/TLS-*/team-session.json` for `status: "active"` or `"paused"`
2. Multiple matches → `AskUserQuestion` for user selection
3. **Audit TaskList** — 获取当前所有任务的真实状态
4. **Reconcile** — 双向同步 session.completed_tasks ↔ TaskList 状态:
- session 已完成但 TaskList 未标记 → 修正 TaskList 为 completed
- TaskList 已完成但 session 未记录 → 补录到 session
- in_progress 状态(暂停中断)→ 重置为 pending
5. Determines remaining pipeline from reconciled state
6. Rebuilds team (`TeamCreate` + worker spawns for needed roles only)
7. Creates missing tasks with correct `blockedBy` dependency chain (uses `TASK_METADATA` lookup)
8. Verifies dependency chain integrity for existing tasks
9. Updates session file with reconciled state + current_phase
10. **Kick** — 向首个可执行任务的 worker 发送 `task_unblocked` 消息,打破 resume 死锁
11. Jumps to Phase 4 coordination loop
## Coordinator Spawn Template
When coordinator creates teammates, use this pattern:
```javascript
TeamCreate({ team_name: teamName })
// For each worker role:
Task({
subagent_type: "general-purpose",
description: `Spawn ${roleName} worker`, // ← 必填参数
team_name: teamName,
name: "<role_name>",
prompt: `你是 team "${teamName}" 的 <ROLE_NAME_UPPER>.
## ⚠️ 首要指令MUST
你的所有工作必须通过调用 Skill 获取角色定义后执行,禁止自行发挥:
Skill(skill="team-lifecycle-v2", args="--role=<role_name>")
此调用会加载你的角色定义role.md、可用命令commands/*.md和完整执行逻辑。
当前需求: ${taskDescription}
约束: ${constraints}
Session: ${sessionFolder}
## 角色准则(强制)
- 你只能处理 <PREFIX>-* 前缀的任务,不得执行其他角色的工作
- 所有输出SendMessage、team_msg必须带 [<role_name>] 标识前缀
- 仅与 coordinator 通信,不得直接联系其他 worker
- 不得使用 TaskCreate 为其他角色创建任务
## 消息总线(必须)
每次 SendMessage 前,先调用 mcp__ccw-tools__team_msg 记录。
## 工作流程(严格按顺序)
1. 调用 Skill(skill="team-lifecycle-v2", args="--role=<role_name>") 获取角色定义和执行逻辑
2. 按 role.md 中的 5-Phase 流程执行TaskList → 找到 <PREFIX>-* 任务 → 执行 → 汇报)
3. team_msg log + SendMessage 结果给 coordinator带 [<role_name>] 标识)
4. TaskUpdate completed → 检查下一个任务 → 回到步骤 1`
})
```
See [roles/coordinator/role.md](roles/coordinator/role.md) for the full spawn implementation with per-role prompts.
## Shared Spec Resources
Writer 和 Reviewer 角色在 spec 模式下使用本 skill 内置的标准和模板(从 spec-generator 复制,独立维护):
| Resource | Path | Usage |
|----------|------|-------|
| Document Standards | `specs/document-standards.md` | YAML frontmatter、命名规范、内容结构 |
| Quality Gates | `specs/quality-gates.md` | Per-phase 质量门禁、评分标尺 |
| Product Brief Template | `templates/product-brief.md` | DRAFT-001 文档生成 |
| Requirements Template | `templates/requirements-prd.md` | DRAFT-002 文档生成 |
| Architecture Template | `templates/architecture-doc.md` | DRAFT-003 文档生成 |
| Epics Template | `templates/epics-template.md` | DRAFT-004 文档生成 |
> Writer 在执行每个 DRAFT-* 任务前 **必须先 Read** 对应的 template 文件和 document-standards.md。
> 从 `roles/` 子目录引用时路径为 `../../specs/` 和 `../../templates/`。
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Unknown --role value | Error with available role list |
| Missing --role arg | Orchestration Mode → auto route to coordinator |
| Role file not found | Error with expected path (roles/{name}/role.md) |
| Command file not found | Fall back to inline execution in role.md |
| Task prefix conflict | Log warning, proceed |

View File

@@ -0,0 +1,271 @@
# Role: analyst
Seed analysis, codebase exploration, and multi-dimensional context gathering. Maps to spec-generator Phase 1 (Discovery).
## Role Identity
- **Name**: `analyst`
- **Task Prefix**: `RESEARCH-*`
- **Output Tag**: `[analyst]`
- **Responsibility**: Seed Analysis → Codebase Exploration → Context Packaging → Report
- **Communication**: SendMessage to coordinator only
## Role Boundaries
### MUST
- Only process RESEARCH-* tasks
- Communicate only with coordinator
- Use Toolbox tools (ACE search, Gemini CLI)
- Generate discovery-context.json and spec-config.json
- Support file reference input (@ prefix or .md/.txt extension)
### MUST NOT
- Create tasks for other roles
- Directly contact other workers
- Modify spec documents (only create discovery-context.json and spec-config.json)
- Skip seed analysis step
- Proceed without codebase detection
## Message Types
| Type | Direction | Trigger | Description |
|------|-----------|---------|-------------|
| `research_ready` | analyst → coordinator | Research complete | With discovery-context.json path and dimension summary |
| `research_progress` | analyst → coordinator | Long research progress | Intermediate progress update |
| `error` | analyst → coordinator | Unrecoverable error | Codebase access failure, CLI timeout, etc. |
## Message Bus
Before every `SendMessage`, MUST call `mcp__ccw-tools__team_msg` to log:
```javascript
// Research complete
mcp__ccw-tools__team_msg({
operation: "log",
team: teamName,
from: "analyst",
to: "coordinator",
type: "research_ready",
summary: "[analyst] Research done: 5 exploration dimensions",
ref: `${sessionFolder}/spec/discovery-context.json`
})
// Error report
mcp__ccw-tools__team_msg({
operation: "log",
team: teamName,
from: "analyst",
to: "coordinator",
type: "error",
summary: "[analyst] Codebase access failed"
})
```
### CLI Fallback
When `mcp__ccw-tools__team_msg` MCP is unavailable:
```bash
ccw team log --team "${teamName}" --from "analyst" --to "coordinator" --type "research_ready" --summary "[analyst] Research done" --ref "${sessionFolder}/discovery-context.json" --json
```
## Toolbox
### Available Commands
- None (simple enough for inline execution)
### Subagent Capabilities
- None
### CLI Capabilities
- `ccw cli --tool gemini --mode analysis` for seed analysis
## Execution (5-Phase)
### Phase 1: Task Discovery
```javascript
const tasks = TaskList()
const myTasks = tasks.filter(t =>
t.subject.startsWith('RESEARCH-') &&
t.owner === 'analyst' &&
t.status === 'pending' &&
t.blockedBy.length === 0
)
if (myTasks.length === 0) return // idle
const task = TaskGet({ taskId: myTasks[0].id })
TaskUpdate({ taskId: task.id, status: 'in_progress' })
```
### Phase 2: Seed Analysis
```javascript
// Extract session folder from task description
const sessionMatch = task.description.match(/Session:\s*(.+)/)
const sessionFolder = sessionMatch ? sessionMatch[1].trim() : '.workflow/.team/default'
// Parse topic from task description
const topicLines = task.description.split('\n').filter(l => !l.startsWith('Session:') && !l.startsWith('输出:') && l.trim())
const rawTopic = topicLines[0] || task.subject.replace('RESEARCH-001: ', '')
// 支持文件引用输入(与 spec-generator Phase 1 一致)
const topic = (rawTopic.startsWith('@') || rawTopic.endsWith('.md') || rawTopic.endsWith('.txt'))
? Read(rawTopic.replace(/^@/, ''))
: rawTopic
// Use Gemini CLI for seed analysis
Bash({
command: `ccw cli -p "PURPOSE: Analyze the following topic/idea and extract structured seed information for specification generation.
TASK:
• Extract problem statement (what problem does this solve)
• Identify target users and their pain points
• Determine domain and industry context
• List constraints and assumptions
• Identify 3-5 exploration dimensions for deeper research
• Assess complexity (simple/moderate/complex)
TOPIC: ${topic}
MODE: analysis
CONTEXT: @**/*
EXPECTED: JSON output with fields: problem_statement, target_users[], domain, constraints[], exploration_dimensions[], complexity_assessment
CONSTRAINTS: Output as valid JSON" --tool gemini --mode analysis --rule analysis-analyze-technical-document`,
run_in_background: true
})
// Wait for CLI result, then parse seedAnalysis from output
```
### Phase 3: Codebase Exploration (conditional)
```javascript
// Check if there's an existing codebase to explore
const hasProject = Bash(`test -f package.json || test -f Cargo.toml || test -f pyproject.toml || test -f go.mod; echo $?`)
if (hasProject === '0') {
mcp__ccw-tools__team_msg({
operation: "log",
team: teamName,
from: "analyst",
to: "coordinator",
type: "research_progress",
summary: "[analyst] 种子分析完成, 开始代码库探索"
})
// Explore codebase using ACE search
const archSearch = mcp__ace-tool__search_context({
project_root_path: projectRoot,
query: `Architecture patterns, main modules, entry points for: ${topic}`
})
// Detect tech stack from package files
// Explore existing patterns and integration points
var codebaseContext = {
tech_stack,
architecture_patterns,
existing_conventions,
integration_points,
constraints_from_codebase: []
}
} else {
var codebaseContext = null
}
```
### Phase 4: Context Packaging
```javascript
// Generate spec-config.json
const specConfig = {
session_id: `SPEC-${topicSlug}-${dateStr}`,
topic: topic,
status: "research_complete",
complexity: seedAnalysis.complexity_assessment || "moderate",
depth: task.description.match(/讨论深度:\s*(.+)/)?.[1] || "standard",
focus_areas: seedAnalysis.exploration_dimensions || [],
mode: "interactive", // team 模式始终交互
phases_completed: ["discovery"],
created_at: new Date().toISOString(),
session_folder: sessionFolder,
discussion_depth: task.description.match(/讨论深度:\s*(.+)/)?.[1] || "standard"
}
Write(`${sessionFolder}/spec/spec-config.json`, JSON.stringify(specConfig, null, 2))
// Generate discovery-context.json
const discoveryContext = {
session_id: specConfig.session_id,
phase: 1,
document_type: "discovery-context",
status: "complete",
generated_at: new Date().toISOString(),
seed_analysis: {
problem_statement: seedAnalysis.problem_statement,
target_users: seedAnalysis.target_users,
domain: seedAnalysis.domain,
constraints: seedAnalysis.constraints,
exploration_dimensions: seedAnalysis.exploration_dimensions,
complexity: seedAnalysis.complexity_assessment
},
codebase_context: codebaseContext,
recommendations: { focus_areas: [], risks: [], open_questions: [] }
}
Write(`${sessionFolder}/spec/discovery-context.json`, JSON.stringify(discoveryContext, null, 2))
```
### Phase 5: Report to Coordinator
```javascript
const dimensionCount = discoveryContext.seed_analysis.exploration_dimensions?.length || 0
const hasCodebase = codebaseContext !== null
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "analyst", to: "coordinator",
type: "research_ready",
summary: `[analyst] 研究完成: ${dimensionCount}个探索维度, ${hasCodebase ? '有' : '无'}代码库上下文, 复杂度=${specConfig.complexity}`,
ref: `${sessionFolder}/discovery-context.json`
})
SendMessage({
type: "message",
recipient: "coordinator",
content: `[analyst] ## 研究分析结果
**Task**: ${task.subject}
**复杂度**: ${specConfig.complexity}
**代码库**: ${hasCodebase ? '已检测到现有项目' : '全新项目'}
### 问题陈述
${discoveryContext.seed_analysis.problem_statement}
### 目标用户
${(discoveryContext.seed_analysis.target_users || []).map(u => '- ' + u).join('\n')}
### 探索维度
${(discoveryContext.seed_analysis.exploration_dimensions || []).map((d, i) => (i+1) + '. ' + d).join('\n')}
### 输出位置
- Config: ${sessionFolder}/spec/spec-config.json
- Context: ${sessionFolder}/spec/discovery-context.json
研究已就绪,可进入讨论轮次 DISCUSS-001。`,
summary: `[analyst] 研究就绪: ${dimensionCount}维度, ${specConfig.complexity}`
})
TaskUpdate({ taskId: task.id, status: 'completed' })
// Check for next RESEARCH task → back to Phase 1
```
## Error Handling
| Scenario | Resolution |
|----------|------------|
| No RESEARCH-* tasks available | Idle, wait for coordinator assignment |
| Gemini CLI analysis failure | Fallback to direct Claude analysis without CLI |
| Codebase detection failed | Continue as new project (no codebase context) |
| Session folder cannot be created | Notify coordinator, request alternative path |
| Topic too vague for analysis | Report to coordinator with clarification questions |
| Unexpected error | Log error via team_msg, report to coordinator |

View File

@@ -0,0 +1,271 @@
# Assess Command
## Purpose
Multi-mode architecture assessment with mode-specific analysis strategies. Delegated from architect role.md Phase 3.
## Input Context
```javascript
// Provided by role.md Phase 2
const { consultMode, sessionFolder, wisdom, explorations, projectTech, task } = context
```
## Mode Strategies
### spec-review (ARCH-SPEC-*)
审查架构文档的技术合理性。
```javascript
const dimensions = [
{ name: 'consistency', weight: 0.25 },
{ name: 'scalability', weight: 0.25 },
{ name: 'security', weight: 0.25 },
{ name: 'tech-fitness', weight: 0.25 }
]
// Load architecture documents
const archIndex = Read(`${sessionFolder}/spec/architecture/_index.md`)
const adrFiles = Glob({ pattern: `${sessionFolder}/spec/architecture/ADR-*.md` })
const adrs = adrFiles.map(f => ({ path: f, content: Read(f) }))
// Check ADR consistency
const adrDecisions = adrs.map(adr => {
const status = adr.content.match(/status:\s*(\w+)/i)?.[1]
const context = adr.content.match(/## Context\n([\s\S]*?)##/)?.[1]?.trim()
const decision = adr.content.match(/## Decision\n([\s\S]*?)##/)?.[1]?.trim()
return { path: adr.path, status, context, decision }
})
// Cross-reference: ADR decisions vs architecture index
// Flag contradictions between ADRs
// Check if tech choices align with project-tech.json
for (const dim of dimensions) {
const score = evaluateDimension(dim.name, archIndex, adrs, projectTech)
assessment.dimensions.push({ name: dim.name, score, weight: dim.weight })
}
```
### plan-review (ARCH-PLAN-*)
审查实现计划的架构合理性。
```javascript
const plan = JSON.parse(Read(`${sessionFolder}/plan/plan.json`))
const taskFiles = Glob({ pattern: `${sessionFolder}/plan/.task/TASK-*.json` })
const tasks = taskFiles.map(f => JSON.parse(Read(f)))
// 1. Dependency cycle detection
function detectCycles(tasks) {
const graph = {}
tasks.forEach(t => { graph[t.id] = t.depends_on || [] })
const visited = new Set(), inStack = new Set()
function dfs(node) {
if (inStack.has(node)) return true // cycle
if (visited.has(node)) return false
visited.add(node); inStack.add(node)
for (const dep of (graph[node] || [])) {
if (dfs(dep)) return true
}
inStack.delete(node)
return false
}
return Object.keys(graph).filter(n => dfs(n))
}
const cycles = detectCycles(tasks)
if (cycles.length > 0) {
assessment.concerns.push({
severity: 'high',
concern: `Circular dependency detected: ${cycles.join(' → ')}`,
suggestion: 'Break cycle by extracting shared interface or reordering tasks'
})
}
// 2. Task granularity check
tasks.forEach(t => {
const fileCount = (t.files || []).length
if (fileCount > 8) {
assessment.concerns.push({
severity: 'medium',
task: t.id,
concern: `Task touches ${fileCount} files — may be too coarse`,
suggestion: 'Split into smaller tasks with clearer boundaries'
})
}
})
// 3. Convention compliance (from wisdom)
if (wisdom.conventions) {
// Check if plan follows discovered conventions
}
// 4. Architecture alignment (from wisdom.decisions)
if (wisdom.decisions) {
// Verify plan doesn't contradict previous architectural decisions
}
```
### code-review (ARCH-CODE-*)
评估代码变更的架构影响。
```javascript
const changedFiles = Bash(`git diff --name-only HEAD~1 2>/dev/null || git diff --name-only --cached`)
.split('\n').filter(Boolean)
// 1. Layer violation detection
function detectLayerViolation(file, content) {
// Check import depth — deeper layers should not import from shallower
const imports = (content.match(/from\s+['"]([^'"]+)['"]/g) || [])
.map(i => i.match(/['"]([^'"]+)['"]/)?.[1]).filter(Boolean)
return imports.filter(imp => isUpwardImport(file, imp))
}
// 2. New dependency analysis
const pkgChanges = changedFiles.filter(f => f.includes('package.json'))
if (pkgChanges.length > 0) {
for (const pkg of pkgChanges) {
const diff = Bash(`git diff HEAD~1 -- ${pkg} 2>/dev/null || git diff --cached -- ${pkg}`)
const newDeps = (diff.match(/\+\s+"([^"]+)":\s+"[^"]+"/g) || [])
.map(d => d.match(/"([^"]+)"/)?.[1]).filter(Boolean)
if (newDeps.length > 0) {
assessment.recommendations.push({
area: 'dependencies',
suggestion: `New dependencies added: ${newDeps.join(', ')}. Verify license compatibility and bundle size impact.`
})
}
}
}
// 3. Module boundary changes
const indexChanges = changedFiles.filter(f => f.endsWith('index.ts') || f.endsWith('index.js'))
if (indexChanges.length > 0) {
assessment.concerns.push({
severity: 'medium',
concern: `Module boundary files modified: ${indexChanges.join(', ')}`,
suggestion: 'Verify public API changes are intentional and backward compatible'
})
}
// 4. Architectural impact scoring
assessment.architectural_impact = changedFiles.length > 10 ? 'high'
: indexChanges.length > 0 || pkgChanges.length > 0 ? 'medium' : 'low'
```
### consult (ARCH-CONSULT-*)
回答架构决策咨询。
```javascript
const question = task.description
.replace(/Session:.*\n?/g, '')
.replace(/Requester:.*\n?/g, '')
.trim()
const isComplex = question.length > 200 ||
/architect|design|pattern|refactor|migrate|scalab/i.test(question)
if (isComplex) {
// Use cli-explore-agent for deep exploration
Task({
subagent_type: "cli-explore-agent",
run_in_background: false,
description: `Architecture consultation: ${question.substring(0, 80)}`,
prompt: `## Architecture Consultation
Question: ${question}
## Steps
1. Run: ccw tool exec get_modules_by_depth '{}'
2. Search for relevant architectural patterns in codebase
3. Read .workflow/project-tech.json (if exists)
4. Analyze architectural implications
## Output
Write to: ${sessionFolder}/architecture/consult-exploration.json
Schema: { relevant_files[], patterns[], architectural_implications[], options[] }`
})
// Parse exploration results into assessment
try {
const exploration = JSON.parse(Read(`${sessionFolder}/architecture/consult-exploration.json`))
assessment.recommendations = (exploration.options || []).map(opt => ({
area: 'architecture',
suggestion: `${opt.name}: ${opt.description}`,
trade_offs: opt.trade_offs || []
}))
} catch {}
} else {
// Simple consultation — direct analysis
assessment.recommendations.push({
area: 'architecture',
suggestion: `Direct answer based on codebase context and wisdom`
})
}
```
### feasibility (ARCH-FEASIBILITY-*)
技术可行性评估。
```javascript
const proposal = task.description
.replace(/Session:.*\n?/g, '')
.replace(/Requester:.*\n?/g, '')
.trim()
// 1. Tech stack compatibility
const techStack = projectTech?.tech_stack || {}
// Check if proposal requires technologies not in current stack
// 2. Codebase readiness
// Use ACE search to find relevant integration points
const searchResults = mcp__ace-tool__search_context({
project_root_path: '.',
query: proposal
})
// 3. Effort estimation
const touchPoints = (searchResults?.relevant_files || []).length
const effort = touchPoints > 20 ? 'high' : touchPoints > 5 ? 'medium' : 'low'
// 4. Risk assessment
assessment.verdict = 'FEASIBLE' // FEASIBLE | RISKY | INFEASIBLE
assessment.effort_estimate = effort
assessment.prerequisites = []
assessment.risks = []
if (touchPoints > 20) {
assessment.verdict = 'RISKY'
assessment.risks.push({
risk: 'High touch-point count suggests significant refactoring',
mitigation: 'Phase the implementation, start with core module'
})
}
```
## Verdict Logic
```javascript
function determineVerdict(assessment) {
const highConcerns = (assessment.concerns || []).filter(c => c.severity === 'high')
const mediumConcerns = (assessment.concerns || []).filter(c => c.severity === 'medium')
if (highConcerns.length >= 2) return 'BLOCK'
if (highConcerns.length >= 1 || mediumConcerns.length >= 3) return 'CONCERN'
return 'APPROVE'
}
assessment.overall_verdict = determineVerdict(assessment)
```
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Architecture docs not found | Assess from available context, note limitation in report |
| Plan file missing | Report to coordinator via arch_concern |
| Git diff fails (no commits) | Use staged changes or skip code-review mode |
| CLI exploration timeout | Provide partial assessment, flag as incomplete |
| Exploration results unparseable | Fall back to direct analysis without exploration |

View File

@@ -0,0 +1,368 @@
# Role: architect
架构顾问。提供架构决策咨询、技术可行性评估、设计模式建议。咨询角色,在 spec 和 impl 流程关键节点提供专业判断。
## Role Identity
- **Name**: `architect`
- **Task Prefix**: `ARCH-*`
- **Responsibility**: Context loading → Mode detection → Architecture analysis → Package assessment → Report
- **Communication**: SendMessage to coordinator only
- **Output Tag**: `[architect]`
- **Role Type**: Consulting咨询角色不阻塞主链路输出被引用
## Role Boundaries
### MUST
- 仅处理 `ARCH-*` 前缀的任务
- 所有输出SendMessage、team_msg、日志必须带 `[architect]` 标识
- 仅通过 SendMessage 与 coordinator 通信
- 输出结构化评估报告供调用方消费
- 根据任务前缀自动切换咨询模式
### MUST NOT
- ❌ 直接修改源代码文件
- ❌ 执行需求分析、代码实现、测试等其他角色职责
- ❌ 直接与其他 worker 角色通信
- ❌ 为其他角色创建任务
- ❌ 做最终决策(仅提供建议,决策权在 coordinator/用户)
- ❌ 在输出中省略 `[architect]` 标识
## Message Types
| Type | Direction | Trigger | Description |
|------|-----------|---------|-------------|
| `arch_ready` | architect → coordinator | Consultation complete | 架构评估/建议已就绪 |
| `arch_concern` | architect → coordinator | Significant risk found | 发现重大架构风险 |
| `arch_progress` | architect → coordinator | Long analysis progress | 复杂分析进度更新 |
| `error` | architect → coordinator | Analysis failure | 分析失败或上下文不足 |
## Message Bus
每次 SendMessage **前**,必须调用 `mcp__ccw-tools__team_msg` 记录消息:
```javascript
// Consultation complete
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "architect", to: "coordinator",
type: "arch_ready",
summary: "[architect] ARCH complete: 3 recommendations, 1 concern",
ref: outputPath
})
// Risk alert
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "architect", to: "coordinator",
type: "arch_concern",
summary: "[architect] RISK: circular dependency in module graph"
})
```
### CLI 回退
`mcp__ccw-tools__team_msg` MCP 不可用时,使用 `ccw team` CLI 作为等效回退:
```javascript
Bash(`ccw team log --team "${teamName}" --from "architect" --to "coordinator" --type "arch_ready" --summary "[architect] ARCH complete" --ref "${outputPath}" --json`)
```
**参数映射**: `team_msg(params)``ccw team log --team <team> --from architect --to coordinator --type <type> --summary "<text>" [--ref <path>] [--json]`
## Toolbox
### Available Commands
- `commands/assess.md` — Multi-mode architecture assessment (Phase 3)
### Subagent Capabilities
| Agent Type | Used By | Purpose |
|------------|---------|---------|
| `cli-explore-agent` | commands/assess.md | 深度架构探索(模块依赖、分层结构) |
### CLI Capabilities
| CLI Tool | Mode | Used By | Purpose |
|----------|------|---------|---------|
| `ccw cli --tool gemini --mode analysis` | analysis | commands/assess.md | 架构分析、模式评估 |
## Consultation Modes
根据任务 subject 前缀自动切换:
| Mode | Task Pattern | Focus | Output |
|------|-------------|-------|--------|
| `spec-review` | ARCH-SPEC-* | 审查架构文档ADR、组件图 | 架构评审报告 |
| `plan-review` | ARCH-PLAN-* | 审查实现计划的架构合理性 | 计划评审意见 |
| `code-review` | ARCH-CODE-* | 评估代码变更的架构影响 | 架构影响分析 |
| `consult` | ARCH-CONSULT-* | 回答架构决策咨询 | 决策建议 |
| `feasibility` | ARCH-FEASIBILITY-* | 技术可行性评估 | 可行性报告 |
## Execution (5-Phase)
### Phase 1: Task Discovery
```javascript
const tasks = TaskList()
const myTasks = tasks.filter(t =>
t.subject.startsWith('ARCH-') &&
t.owner === 'architect' &&
t.status === 'pending' &&
t.blockedBy.length === 0
)
if (myTasks.length === 0) return // idle
const task = TaskGet({ taskId: myTasks[0].id })
TaskUpdate({ taskId: task.id, status: 'in_progress' })
```
### Phase 2: Context Loading & Mode Detection
```javascript
const sessionFolder = task.description.match(/Session:\s*([^\n]+)/)?.[1]?.trim()
// Auto-detect consultation mode from task subject
const MODE_MAP = {
'ARCH-SPEC': 'spec-review',
'ARCH-PLAN': 'plan-review',
'ARCH-CODE': 'code-review',
'ARCH-CONSULT': 'consult',
'ARCH-FEASIBILITY': 'feasibility'
}
const modePrefix = Object.keys(MODE_MAP).find(p => task.subject.startsWith(p))
const consultMode = modePrefix ? MODE_MAP[modePrefix] : 'consult'
// Load wisdom (accumulated knowledge from previous tasks)
let wisdom = {}
if (sessionFolder) {
try { wisdom.learnings = Read(`${sessionFolder}/wisdom/learnings.md`) } catch {}
try { wisdom.decisions = Read(`${sessionFolder}/wisdom/decisions.md`) } catch {}
try { wisdom.conventions = Read(`${sessionFolder}/wisdom/conventions.md`) } catch {}
}
// Load project tech context
let projectTech = {}
try { projectTech = JSON.parse(Read('.workflow/project-tech.json')) } catch {}
// Load exploration results if available
let explorations = []
if (sessionFolder) {
try {
const exploreFiles = Glob({ pattern: `${sessionFolder}/explorations/*.json` })
explorations = exploreFiles.map(f => {
try { return JSON.parse(Read(f)) } catch { return null }
}).filter(Boolean)
} catch {}
}
```
### Phase 3: Architecture Assessment
Delegate to command file for mode-specific analysis:
```javascript
try {
const assessCommand = Read("commands/assess.md")
// Execute mode-specific strategy defined in command file
// Input: consultMode, sessionFolder, wisdom, explorations, projectTech
// Output: assessment object
} catch {
// Fallback: inline execution (see below)
}
```
**Command**: [commands/assess.md](commands/assess.md)
**Inline Fallback** (when command file unavailable):
```javascript
const assessment = {
mode: consultMode,
overall_verdict: 'APPROVE', // APPROVE | CONCERN | BLOCK
dimensions: [],
concerns: [],
recommendations: [],
_metadata: { timestamp: new Date().toISOString(), wisdom_loaded: Object.keys(wisdom).length > 0 }
}
// Mode-specific analysis
if (consultMode === 'spec-review') {
// Load architecture documents, check ADR consistency, scalability, security
const archIndex = Read(`${sessionFolder}/spec/architecture/_index.md`)
const adrFiles = Glob({ pattern: `${sessionFolder}/spec/architecture/ADR-*.md` })
// Score dimensions: consistency, scalability, security, tech-fitness
}
if (consultMode === 'plan-review') {
// Load plan.json, check task granularity, dependency cycles, convention compliance
const plan = JSON.parse(Read(`${sessionFolder}/plan/plan.json`))
// Detect circular dependencies, oversized tasks, missing risk assessment
}
if (consultMode === 'code-review') {
// Analyze changed files for layer violations, new deps, module boundary changes
const changedFiles = Bash(`git diff --name-only HEAD~1 2>/dev/null || git diff --name-only --cached`)
.split('\n').filter(Boolean)
// Check import depth, package.json changes, index.ts modifications
}
if (consultMode === 'consult') {
// Free-form consultation — use CLI for complex questions
const question = task.description.replace(/Session:.*\n?/g, '').replace(/Requester:.*\n?/g, '').trim()
const isComplex = question.length > 200 || /architect|design|pattern|refactor|migrate/i.test(question)
if (isComplex) {
Bash({
command: `ccw cli -p "PURPOSE: Architecture consultation — ${question}
TASK: • Analyze architectural implications • Identify options with trade-offs • Recommend approach
MODE: analysis
CONTEXT: @**/*
EXPECTED: Structured analysis with options, trade-offs, recommendation
CONSTRAINTS: Architecture-level only" --tool gemini --mode analysis --rule analysis-review-architecture`,
run_in_background: true
})
// Wait for result, parse into assessment
}
}
if (consultMode === 'feasibility') {
// Assess technical feasibility against current codebase
// Output: verdict (FEASIBLE|RISKY|INFEASIBLE), risks, effort estimate, prerequisites
}
```
### Phase 4: Package & Wisdom Contribution
```javascript
// Write assessment to session
const outputPath = sessionFolder
? `${sessionFolder}/architecture/arch-${task.subject.replace(/[^a-zA-Z0-9-]/g, '-').toLowerCase()}.json`
: '.workflow/.tmp/arch-assessment.json'
Bash(`mkdir -p "$(dirname '${outputPath}')"`)
Write(outputPath, JSON.stringify(assessment, null, 2))
// Contribute to wisdom: record architectural decisions
if (sessionFolder && assessment.recommendations?.length > 0) {
try {
const decisionsPath = `${sessionFolder}/wisdom/decisions.md`
const existing = Read(decisionsPath)
const newDecisions = assessment.recommendations
.map(r => `- [${new Date().toISOString().substring(0, 10)}] ${r.area || r.dimension}: ${r.suggestion}`)
.join('\n')
Write(decisionsPath, existing + '\n' + newDecisions)
} catch {} // wisdom not initialized
}
```
### Phase 5: Report to Coordinator
```javascript
const verdict = assessment.overall_verdict || assessment.verdict || 'N/A'
const concernCount = (assessment.concerns || []).length
const highConcerns = (assessment.concerns || []).filter(c => c.severity === 'high').length
const recCount = (assessment.recommendations || []).length
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "architect", to: "coordinator",
type: highConcerns > 0 ? "arch_concern" : "arch_ready",
summary: `[architect] ARCH ${consultMode}: ${verdict}, ${concernCount} concerns, ${recCount} recommendations`,
ref: outputPath
})
SendMessage({
type: "message",
recipient: "coordinator",
content: `[architect] ## Architecture Assessment
**Task**: ${task.subject}
**Mode**: ${consultMode}
**Verdict**: ${verdict}
### Summary
- **Concerns**: ${concernCount} (${highConcerns} high)
- **Recommendations**: ${recCount}
${assessment.architectural_impact ? `- **Impact**: ${assessment.architectural_impact}` : ''}
${assessment.dimensions?.length > 0 ? `### Dimension Scores
${assessment.dimensions.map(d => `- **${d.name}**: ${d.score}%`).join('\n')}` : ''}
${concernCount > 0 ? `### Concerns
${assessment.concerns.map(c => `- [${(c.severity || 'medium').toUpperCase()}] ${c.task || c.file || ''}: ${c.concern}`).join('\n')}` : ''}
### Recommendations
${(assessment.recommendations || []).map(r => `- ${r.area || r.dimension || ''}: ${r.suggestion}`).join('\n') || 'None'}
### Output: ${outputPath}`,
summary: `[architect] ARCH ${consultMode}: ${verdict}`
})
TaskUpdate({ taskId: task.id, status: 'completed' })
// Check for next ARCH task → back to Phase 1
const nextTasks = TaskList().filter(t =>
t.subject.startsWith('ARCH-') &&
t.owner === 'architect' &&
t.status === 'pending' &&
t.blockedBy.length === 0
)
if (nextTasks.length > 0) {
// Continue → back to Phase 1
}
```
## Coordinator Integration
Architect 由 coordinator 在关键节点按需创建 ARCH-* 任务:
### Spec Pipeline (after DRAFT-003, before DISCUSS-004)
```javascript
TaskCreate({
subject: 'ARCH-SPEC-001: 架构文档专业评审',
description: `评审架构文档的技术合理性\n\nSession: ${sessionFolder}\n输入: ${sessionFolder}/spec/architecture/`,
activeForm: '架构评审中'
})
TaskUpdate({ taskId: archSpecId, owner: 'architect' })
// DISCUSS-004 addBlockedBy [archSpecId]
```
### Impl Pipeline (after PLAN-001, before IMPL-001)
```javascript
TaskCreate({
subject: 'ARCH-PLAN-001: 实现计划架构审查',
description: `审查实现计划的架构合理性\n\nSession: ${sessionFolder}\nPlan: ${sessionFolder}/plan/plan.json`,
activeForm: '计划审查中'
})
TaskUpdate({ taskId: archPlanId, owner: 'architect' })
// IMPL-001 addBlockedBy [archPlanId]
```
### On-Demand (any point via coordinator)
```javascript
TaskCreate({
subject: 'ARCH-CONSULT-001: 架构决策咨询',
description: `${question}\n\nSession: ${sessionFolder}\nRequester: ${role}`,
activeForm: '架构咨询中'
})
TaskUpdate({ taskId: archConsultId, owner: 'architect' })
```
## Error Handling
| Scenario | Resolution |
|----------|------------|
| No ARCH-* tasks available | Idle, wait for coordinator assignment |
| Architecture documents not found | Assess from available context, note limitation |
| Plan file not found | Report to coordinator, request location |
| CLI analysis timeout | Provide partial assessment, note incomplete |
| Insufficient context | Request explorer to gather more context via coordinator |
| Conflicting requirements | Flag as concern, provide options |
| Command file not found | Fall back to inline execution |
| Unexpected error | Log error via team_msg, report to coordinator |

View File

@@ -0,0 +1,523 @@
# Dispatch Command - Task Chain Creation
**Purpose**: Create task chains based on execution mode, aligned with SKILL.md Three-Mode Pipeline
**Invoked by**: Coordinator role.md Phase 3
**Output Tag**: `[coordinator]`
---
## Task Chain Strategies
### Role-Task Mapping (Source of Truth: SKILL.md VALID_ROLES)
| Task Prefix | Role | VALID_ROLES Key |
|-------------|------|-----------------|
| RESEARCH-* | analyst | `analyst` |
| DISCUSS-* | discussant | `discussant` |
| DRAFT-* | writer | `writer` |
| QUALITY-* | reviewer | `reviewer` |
| PLAN-* | planner | `planner` |
| IMPL-* | executor | `executor` |
| TEST-* | tester | `tester` |
| REVIEW-* | reviewer | `reviewer` |
| DEV-FE-* | fe-developer | `fe-developer` |
| QA-FE-* | fe-qa | `fe-qa` |
---
### Strategy 1: Spec-Only Mode (12 tasks)
Pipeline: `RESEARCH → DISCUSS → DRAFT → DISCUSS → DRAFT → DISCUSS → DRAFT → DISCUSS → DRAFT → DISCUSS → QUALITY → DISCUSS`
```javascript
if (requirements.mode === "spec-only") {
Output("[coordinator] Creating spec-only task chain (12 tasks)")
// Task 1: Seed Analysis
TaskCreate({
subject: "RESEARCH-001",
owner: "analyst",
description: `Seed analysis: codebase exploration and context gathering\nSession: ${sessionFolder}\nScope: ${requirements.scope}\nFocus: ${requirements.focus.join(", ")}\nDepth: ${requirements.depth}`,
blockedBy: [],
status: "pending"
})
// Task 2: Critique Research
TaskCreate({
subject: "DISCUSS-001",
owner: "discussant",
description: `Critique research findings from RESEARCH-001, identify gaps and clarify scope\nSession: ${sessionFolder}`,
blockedBy: ["RESEARCH-001"],
status: "pending"
})
// Task 3: Product Brief
TaskCreate({
subject: "DRAFT-001",
owner: "writer",
description: `Generate Product Brief based on RESEARCH-001 findings and DISCUSS-001 feedback\nSession: ${sessionFolder}`,
blockedBy: ["DISCUSS-001"],
status: "pending"
})
// Task 4: Critique Product Brief
TaskCreate({
subject: "DISCUSS-002",
owner: "discussant",
description: `Critique Product Brief (DRAFT-001), evaluate completeness and clarity\nSession: ${sessionFolder}`,
blockedBy: ["DRAFT-001"],
status: "pending"
})
// Task 5: Requirements/PRD
TaskCreate({
subject: "DRAFT-002",
owner: "writer",
description: `Generate Requirements/PRD incorporating DISCUSS-002 feedback\nSession: ${sessionFolder}`,
blockedBy: ["DISCUSS-002"],
status: "pending"
})
// Task 6: Critique Requirements
TaskCreate({
subject: "DISCUSS-003",
owner: "discussant",
description: `Critique Requirements/PRD (DRAFT-002), validate coverage and feasibility\nSession: ${sessionFolder}`,
blockedBy: ["DRAFT-002"],
status: "pending"
})
// Task 7: Architecture Document
TaskCreate({
subject: "DRAFT-003",
owner: "writer",
description: `Generate Architecture Document incorporating DISCUSS-003 feedback\nSession: ${sessionFolder}`,
blockedBy: ["DISCUSS-003"],
status: "pending"
})
// Task 8: Critique Architecture
TaskCreate({
subject: "DISCUSS-004",
owner: "discussant",
description: `Critique Architecture Document (DRAFT-003), evaluate design decisions\nSession: ${sessionFolder}`,
blockedBy: ["DRAFT-003"],
status: "pending"
})
// Task 9: Epics
TaskCreate({
subject: "DRAFT-004",
owner: "writer",
description: `Generate Epics document incorporating DISCUSS-004 feedback\nSession: ${sessionFolder}`,
blockedBy: ["DISCUSS-004"],
status: "pending"
})
// Task 10: Critique Epics
TaskCreate({
subject: "DISCUSS-005",
owner: "discussant",
description: `Critique Epics (DRAFT-004), validate task decomposition and priorities\nSession: ${sessionFolder}`,
blockedBy: ["DRAFT-004"],
status: "pending"
})
// Task 11: Spec Quality Check
TaskCreate({
subject: "QUALITY-001",
owner: "reviewer",
description: `5-dimension spec quality validation across all spec artifacts\nSession: ${sessionFolder}`,
blockedBy: ["DISCUSS-005"],
status: "pending"
})
// Task 12: Final Review Discussion
TaskCreate({
subject: "DISCUSS-006",
owner: "discussant",
description: `Final review discussion: address QUALITY-001 findings, sign-off\nSession: ${sessionFolder}`,
blockedBy: ["QUALITY-001"],
status: "pending"
})
Output("[coordinator] Spec-only task chain created (12 tasks)")
Output("[coordinator] Starting with: RESEARCH-001 (analyst)")
}
```
---
### Strategy 2: Impl-Only Mode (4 tasks)
Pipeline: `PLAN → IMPL → TEST + REVIEW`
```javascript
if (requirements.mode === "impl-only") {
Output("[coordinator] Creating impl-only task chain (4 tasks)")
// Verify spec exists
const specExists = AskUserQuestion({
question: "Implementation mode requires existing specifications. Do you have a spec file?",
choices: ["yes", "no"]
})
if (specExists === "no") {
Output("[coordinator] ERROR: impl-only mode requires existing specifications")
Output("[coordinator] Please run spec-only mode first or use full-lifecycle mode")
throw new Error("Missing specifications for impl-only mode")
}
const specFile = AskUserQuestion({
question: "Provide path to specification file:",
type: "text"
})
const specContent = Read(specFile)
if (!specContent) {
throw new Error(`Specification file not found: ${specFile}`)
}
Output(`[coordinator] Using specification: ${specFile}`)
// Task 1: Planning
TaskCreate({
subject: "PLAN-001",
owner: "planner",
description: `Multi-angle codebase exploration and structured planning\nSession: ${sessionFolder}\nSpec: ${specFile}\nScope: ${requirements.scope}`,
blockedBy: [],
status: "pending"
})
// Task 2: Implementation
TaskCreate({
subject: "IMPL-001",
owner: "executor",
description: `Code implementation following PLAN-001\nSession: ${sessionFolder}\nSpec: ${specFile}`,
blockedBy: ["PLAN-001"],
status: "pending"
})
// Task 3: Testing (parallel with REVIEW-001)
TaskCreate({
subject: "TEST-001",
owner: "tester",
description: `Adaptive test-fix cycles and quality gates\nSession: ${sessionFolder}`,
blockedBy: ["IMPL-001"],
status: "pending"
})
// Task 4: Code Review (parallel with TEST-001)
TaskCreate({
subject: "REVIEW-001",
owner: "reviewer",
description: `4-dimension code review of IMPL-001 output\nSession: ${sessionFolder}`,
blockedBy: ["IMPL-001"],
status: "pending"
})
Output("[coordinator] Impl-only task chain created (4 tasks)")
Output("[coordinator] Starting with: PLAN-001 (planner)")
}
```
---
### Strategy 3: Full-Lifecycle Mode (16 tasks)
Pipeline: `[Spec pipeline 12] → PLAN(blockedBy: DISCUSS-006) → IMPL → TEST + REVIEW`
```javascript
if (requirements.mode === "full-lifecycle") {
Output("[coordinator] Creating full-lifecycle task chain (16 tasks)")
// ========================================
// SPEC PHASE (12 tasks) — same as spec-only
// ========================================
TaskCreate({ subject: "RESEARCH-001", owner: "analyst", description: `Seed analysis: codebase exploration and context gathering\nSession: ${sessionFolder}\nScope: ${requirements.scope}\nFocus: ${requirements.focus.join(", ")}\nDepth: ${requirements.depth}`, blockedBy: [], status: "pending" })
TaskCreate({ subject: "DISCUSS-001", owner: "discussant", description: `Critique research findings from RESEARCH-001\nSession: ${sessionFolder}`, blockedBy: ["RESEARCH-001"], status: "pending" })
TaskCreate({ subject: "DRAFT-001", owner: "writer", description: `Generate Product Brief\nSession: ${sessionFolder}`, blockedBy: ["DISCUSS-001"], status: "pending" })
TaskCreate({ subject: "DISCUSS-002", owner: "discussant", description: `Critique Product Brief (DRAFT-001)\nSession: ${sessionFolder}`, blockedBy: ["DRAFT-001"], status: "pending" })
TaskCreate({ subject: "DRAFT-002", owner: "writer", description: `Generate Requirements/PRD\nSession: ${sessionFolder}`, blockedBy: ["DISCUSS-002"], status: "pending" })
TaskCreate({ subject: "DISCUSS-003", owner: "discussant", description: `Critique Requirements/PRD (DRAFT-002)\nSession: ${sessionFolder}`, blockedBy: ["DRAFT-002"], status: "pending" })
TaskCreate({ subject: "DRAFT-003", owner: "writer", description: `Generate Architecture Document\nSession: ${sessionFolder}`, blockedBy: ["DISCUSS-003"], status: "pending" })
TaskCreate({ subject: "DISCUSS-004", owner: "discussant", description: `Critique Architecture Document (DRAFT-003)\nSession: ${sessionFolder}`, blockedBy: ["DRAFT-003"], status: "pending" })
TaskCreate({ subject: "DRAFT-004", owner: "writer", description: `Generate Epics\nSession: ${sessionFolder}`, blockedBy: ["DISCUSS-004"], status: "pending" })
TaskCreate({ subject: "DISCUSS-005", owner: "discussant", description: `Critique Epics (DRAFT-004)\nSession: ${sessionFolder}`, blockedBy: ["DRAFT-004"], status: "pending" })
TaskCreate({ subject: "QUALITY-001", owner: "reviewer", description: `5-dimension spec quality validation\nSession: ${sessionFolder}`, blockedBy: ["DISCUSS-005"], status: "pending" })
TaskCreate({ subject: "DISCUSS-006", owner: "discussant", description: `Final review discussion and sign-off\nSession: ${sessionFolder}`, blockedBy: ["QUALITY-001"], status: "pending" })
// ========================================
// IMPL PHASE (4 tasks) — blocked by spec completion
// ========================================
TaskCreate({
subject: "PLAN-001",
owner: "planner",
description: `Multi-angle codebase exploration and structured planning\nSession: ${sessionFolder}\nScope: ${requirements.scope}`,
blockedBy: ["DISCUSS-006"], // Blocked until spec phase completes
status: "pending"
})
TaskCreate({
subject: "IMPL-001",
owner: "executor",
description: `Code implementation following PLAN-001\nSession: ${sessionFolder}`,
blockedBy: ["PLAN-001"],
status: "pending"
})
TaskCreate({
subject: "TEST-001",
owner: "tester",
description: `Adaptive test-fix cycles and quality gates\nSession: ${sessionFolder}`,
blockedBy: ["IMPL-001"],
status: "pending"
})
TaskCreate({
subject: "REVIEW-001",
owner: "reviewer",
description: `4-dimension code review of IMPL-001 output\nSession: ${sessionFolder}`,
blockedBy: ["IMPL-001"],
status: "pending"
})
Output("[coordinator] Full-lifecycle task chain created (16 tasks)")
Output("[coordinator] Starting with: RESEARCH-001 (analyst)")
}
```
---
### Strategy 4: FE-Only Mode (3 tasks)
Pipeline: `PLAN → DEV-FE → QA-FE` (with GC loop: max 2 rounds)
```javascript
if (requirements.mode === "fe-only") {
Output("[coordinator] Creating fe-only task chain (3 tasks)")
TaskCreate({
subject: "PLAN-001",
owner: "planner",
description: `Multi-angle codebase exploration and structured planning (frontend focus)\nSession: ${sessionFolder}\nScope: ${requirements.scope}`,
blockedBy: [],
status: "pending"
})
TaskCreate({
subject: "DEV-FE-001",
owner: "fe-developer",
description: `Frontend component/page implementation following PLAN-001\nSession: ${sessionFolder}`,
blockedBy: ["PLAN-001"],
status: "pending"
})
TaskCreate({
subject: "QA-FE-001",
owner: "fe-qa",
description: `5-dimension frontend QA for DEV-FE-001 output\nSession: ${sessionFolder}`,
blockedBy: ["DEV-FE-001"],
status: "pending"
})
// Note: GC loop (DEV-FE-002 → QA-FE-002) created dynamically by coordinator
// when QA-FE-001 verdict = NEEDS_FIX (max 2 rounds)
Output("[coordinator] FE-only task chain created (3 tasks)")
Output("[coordinator] Starting with: PLAN-001 (planner)")
}
```
---
### Strategy 5: Fullstack Mode (6 tasks)
Pipeline: `PLAN → IMPL ∥ DEV-FE → TEST ∥ QA-FE → REVIEW`
```javascript
if (requirements.mode === "fullstack") {
Output("[coordinator] Creating fullstack task chain (6 tasks)")
TaskCreate({
subject: "PLAN-001",
owner: "planner",
description: `Multi-angle codebase exploration and structured planning (fullstack)\nSession: ${sessionFolder}\nScope: ${requirements.scope}`,
blockedBy: [],
status: "pending"
})
// Backend + Frontend in parallel
TaskCreate({
subject: "IMPL-001",
owner: "executor",
description: `Backend implementation following PLAN-001\nSession: ${sessionFolder}`,
blockedBy: ["PLAN-001"],
status: "pending"
})
TaskCreate({
subject: "DEV-FE-001",
owner: "fe-developer",
description: `Frontend implementation following PLAN-001\nSession: ${sessionFolder}`,
blockedBy: ["PLAN-001"],
status: "pending"
})
// Testing + QA in parallel
TaskCreate({
subject: "TEST-001",
owner: "tester",
description: `Backend test-fix cycles\nSession: ${sessionFolder}`,
blockedBy: ["IMPL-001"],
status: "pending"
})
TaskCreate({
subject: "QA-FE-001",
owner: "fe-qa",
description: `Frontend QA for DEV-FE-001\nSession: ${sessionFolder}`,
blockedBy: ["DEV-FE-001"],
status: "pending"
})
// Final review after all testing
TaskCreate({
subject: "REVIEW-001",
owner: "reviewer",
description: `Full code review (backend + frontend)\nSession: ${sessionFolder}`,
blockedBy: ["TEST-001", "QA-FE-001"],
status: "pending"
})
Output("[coordinator] Fullstack task chain created (6 tasks)")
Output("[coordinator] Starting with: PLAN-001 (planner)")
}
```
---
### Strategy 6: Full-Lifecycle-FE Mode (18 tasks)
Pipeline: `[Spec 12] → PLAN(blockedBy: DISCUSS-006) → IMPL ∥ DEV-FE → TEST ∥ QA-FE → REVIEW`
```javascript
if (requirements.mode === "full-lifecycle-fe") {
Output("[coordinator] Creating full-lifecycle-fe task chain (18 tasks)")
// SPEC PHASE (12 tasks) — same as spec-only
TaskCreate({ subject: "RESEARCH-001", owner: "analyst", description: `Seed analysis\nSession: ${sessionFolder}\nScope: ${requirements.scope}`, blockedBy: [], status: "pending" })
TaskCreate({ subject: "DISCUSS-001", owner: "discussant", description: `Critique research findings\nSession: ${sessionFolder}`, blockedBy: ["RESEARCH-001"], status: "pending" })
TaskCreate({ subject: "DRAFT-001", owner: "writer", description: `Generate Product Brief\nSession: ${sessionFolder}`, blockedBy: ["DISCUSS-001"], status: "pending" })
TaskCreate({ subject: "DISCUSS-002", owner: "discussant", description: `Critique Product Brief\nSession: ${sessionFolder}`, blockedBy: ["DRAFT-001"], status: "pending" })
TaskCreate({ subject: "DRAFT-002", owner: "writer", description: `Generate Requirements/PRD\nSession: ${sessionFolder}`, blockedBy: ["DISCUSS-002"], status: "pending" })
TaskCreate({ subject: "DISCUSS-003", owner: "discussant", description: `Critique Requirements\nSession: ${sessionFolder}`, blockedBy: ["DRAFT-002"], status: "pending" })
TaskCreate({ subject: "DRAFT-003", owner: "writer", description: `Generate Architecture Document\nSession: ${sessionFolder}`, blockedBy: ["DISCUSS-003"], status: "pending" })
TaskCreate({ subject: "DISCUSS-004", owner: "discussant", description: `Critique Architecture\nSession: ${sessionFolder}`, blockedBy: ["DRAFT-003"], status: "pending" })
TaskCreate({ subject: "DRAFT-004", owner: "writer", description: `Generate Epics\nSession: ${sessionFolder}`, blockedBy: ["DISCUSS-004"], status: "pending" })
TaskCreate({ subject: "DISCUSS-005", owner: "discussant", description: `Critique Epics\nSession: ${sessionFolder}`, blockedBy: ["DRAFT-004"], status: "pending" })
TaskCreate({ subject: "QUALITY-001", owner: "reviewer", description: `Spec quality validation\nSession: ${sessionFolder}`, blockedBy: ["DISCUSS-005"], status: "pending" })
TaskCreate({ subject: "DISCUSS-006", owner: "discussant", description: `Final review and sign-off\nSession: ${sessionFolder}`, blockedBy: ["QUALITY-001"], status: "pending" })
// IMPL PHASE (6 tasks) — fullstack, blocked by spec
TaskCreate({ subject: "PLAN-001", owner: "planner", description: `Fullstack planning\nSession: ${sessionFolder}`, blockedBy: ["DISCUSS-006"], status: "pending" })
TaskCreate({ subject: "IMPL-001", owner: "executor", description: `Backend implementation\nSession: ${sessionFolder}`, blockedBy: ["PLAN-001"], status: "pending" })
TaskCreate({ subject: "DEV-FE-001", owner: "fe-developer", description: `Frontend implementation\nSession: ${sessionFolder}`, blockedBy: ["PLAN-001"], status: "pending" })
TaskCreate({ subject: "TEST-001", owner: "tester", description: `Backend test-fix cycles\nSession: ${sessionFolder}`, blockedBy: ["IMPL-001"], status: "pending" })
TaskCreate({ subject: "QA-FE-001", owner: "fe-qa", description: `Frontend QA\nSession: ${sessionFolder}`, blockedBy: ["DEV-FE-001"], status: "pending" })
TaskCreate({ subject: "REVIEW-001", owner: "reviewer", description: `Full code review\nSession: ${sessionFolder}`, blockedBy: ["TEST-001", "QA-FE-001"], status: "pending" })
Output("[coordinator] Full-lifecycle-fe task chain created (18 tasks)")
Output("[coordinator] Starting with: RESEARCH-001 (analyst)")
}
```
---
## Task Metadata Reference
```javascript
// Unified metadata for all pipelines (used by Session Resume)
const TASK_METADATA = {
// Spec pipeline (12 tasks)
"RESEARCH-001": { role: "analyst", deps: [], description: "Seed analysis: codebase exploration and context gathering" },
"DISCUSS-001": { role: "discussant", deps: ["RESEARCH-001"], description: "Critique research findings, identify gaps" },
"DRAFT-001": { role: "writer", deps: ["DISCUSS-001"], description: "Generate Product Brief" },
"DISCUSS-002": { role: "discussant", deps: ["DRAFT-001"], description: "Critique Product Brief" },
"DRAFT-002": { role: "writer", deps: ["DISCUSS-002"], description: "Generate Requirements/PRD" },
"DISCUSS-003": { role: "discussant", deps: ["DRAFT-002"], description: "Critique Requirements/PRD" },
"DRAFT-003": { role: "writer", deps: ["DISCUSS-003"], description: "Generate Architecture Document" },
"DISCUSS-004": { role: "discussant", deps: ["DRAFT-003"], description: "Critique Architecture Document" },
"DRAFT-004": { role: "writer", deps: ["DISCUSS-004"], description: "Generate Epics" },
"DISCUSS-005": { role: "discussant", deps: ["DRAFT-004"], description: "Critique Epics" },
"QUALITY-001": { role: "reviewer", deps: ["DISCUSS-005"], description: "5-dimension spec quality validation" },
"DISCUSS-006": { role: "discussant", deps: ["QUALITY-001"], description: "Final review discussion and sign-off" },
// Impl pipeline (4 tasks) — deps shown for impl-only mode
// In full-lifecycle, PLAN-001 deps = ["DISCUSS-006"]
"PLAN-001": { role: "planner", deps: [], description: "Multi-angle codebase exploration and structured planning" },
"IMPL-001": { role: "executor", deps: ["PLAN-001"], description: "Code implementation following plan" },
"TEST-001": { role: "tester", deps: ["IMPL-001"], description: "Adaptive test-fix cycles and quality gates" },
"REVIEW-001": { role: "reviewer", deps: ["IMPL-001"], description: "4-dimension code review" },
// Frontend pipeline tasks
"DEV-FE-001": { role: "fe-developer", deps: ["PLAN-001"], description: "Frontend component/page implementation" },
"QA-FE-001": { role: "fe-qa", deps: ["DEV-FE-001"], description: "5-dimension frontend QA" },
// GC loop tasks (created dynamically)
"DEV-FE-002": { role: "fe-developer", deps: ["QA-FE-001"], description: "Frontend fixes (GC round 2)" },
"QA-FE-002": { role: "fe-qa", deps: ["DEV-FE-002"], description: "Frontend QA re-check (GC round 2)" }
}
// Pipeline chain constants
const SPEC_CHAIN = [
"RESEARCH-001", "DISCUSS-001", "DRAFT-001", "DISCUSS-002",
"DRAFT-002", "DISCUSS-003", "DRAFT-003", "DISCUSS-004",
"DRAFT-004", "DISCUSS-005", "QUALITY-001", "DISCUSS-006"
]
const IMPL_CHAIN = ["PLAN-001", "IMPL-001", "TEST-001", "REVIEW-001"]
const FE_CHAIN = ["DEV-FE-001", "QA-FE-001"]
const FULLSTACK_CHAIN = ["PLAN-001", "IMPL-001", "DEV-FE-001", "TEST-001", "QA-FE-001", "REVIEW-001"]
```
---
## Execution Method Handling
### Sequential Execution
```javascript
if (requirements.executionMethod === "sequential") {
Output("[coordinator] Sequential execution: tasks will run one at a time")
// Only one task active at a time
// Next task activated only after predecessor completes
}
```
### Parallel Execution
```javascript
if (requirements.executionMethod === "parallel") {
Output("[coordinator] Parallel execution: independent tasks will run concurrently")
// Tasks with all deps met can run in parallel
// e.g., TEST-001 and REVIEW-001 both depend on IMPL-001 → run together
// e.g., IMPL-001 and DEV-FE-001 both depend on PLAN-001 → run together
}
```
---
## Output Format
All outputs from this command use the `[coordinator]` tag:
```
[coordinator] Creating spec-only task chain (12 tasks)
[coordinator] Starting with: RESEARCH-001 (analyst)
```

View File

@@ -0,0 +1,368 @@
# Monitor Command - Coordination Loop
**Purpose**: Monitor task progress, route messages, and handle checkpoints
**Invoked by**: Coordinator role.md Phase 4
**Output Tag**: `[coordinator]`
---
## Coordination Loop
> **设计原则**: 模型执行没有时间概念,禁止任何形式的轮询等待。
> 使用同步 `Task(run_in_background: false)` 调用作为等待机制。
> Worker 返回 = 阶段完成信号(天然回调),无需 sleep 轮询。
```javascript
Output("[coordinator] Entering coordination loop (Stop-Wait mode)...")
// Get all tasks and filter for pending work
const allTasks = TaskList()
const pendingTasks = allTasks.filter(t => t.status !== 'completed')
for (const task of pendingTasks) {
// Check if all dependencies are met
const allDepsMet = (task.blockedBy || []).every(depSubject => {
const dep = allTasks.find(t => t.subject === depSubject)
return dep && dep.status === 'completed'
})
if (!allDepsMet) {
Output(`[coordinator] Task ${task.subject} blocked by dependencies, skipping`)
continue
}
// Determine role from task subject prefix → TASK_METADATA lookup
const taskMeta = TASK_METADATA[task.subject]
const role = taskMeta ? taskMeta.role : task.owner
Output(`[coordinator] Starting task: ${task.subject} (role: ${role})`)
// Mark as in_progress
TaskUpdate({ taskId: task.id, status: 'in_progress' })
// ============================================================
// Spawn worker using SKILL.md Coordinator Spawn Template
// Key: worker MUST call Skill() to load role definition
// ============================================================
Task({
subagent_type: "general-purpose",
description: `Spawn ${role} worker for ${task.subject}`,
team_name: teamName,
name: role,
prompt: `你是 team "${teamName}" 的 ${role.toUpperCase()}.
## ⚠️ 首要指令MUST
你的所有工作必须通过调用 Skill 获取角色定义后执行,禁止自行发挥:
Skill(skill="team-lifecycle-v2", args="--role=${role}")
此调用会加载你的角色定义role.md、可用命令commands/*.md和完整执行逻辑。
当前任务: ${task.subject} - ${task.description}
Session: ${sessionFolder}
## 角色准则(强制)
- 你只能处理 ${taskMeta ? task.subject.split('-')[0] : ''}-* 前缀的任务,不得执行其他角色的工作
- 所有输出SendMessage、team_msg必须带 [${role}] 标识前缀
- 仅与 coordinator 通信,不得直接联系其他 worker
- 不得使用 TaskCreate 为其他角色创建任务
## 消息总线(必须)
每次 SendMessage 前,先调用 mcp__ccw-tools__team_msg 记录。
## 工作流程(严格按顺序)
1. 调用 Skill(skill="team-lifecycle-v2", args="--role=${role}") 获取角色定义和执行逻辑
2. 按 role.md 中的 5-Phase 流程执行TaskList → 找到任务 → 执行 → 汇报)
3. team_msg log + SendMessage 结果给 coordinator带 [${role}] 标识)
4. TaskUpdate completed → 检查下一个任务 → 回到步骤 1`,
run_in_background: false
})
// Worker returned — check status
const completedTask = TaskGet({ taskId: task.id })
Output(`[coordinator] Task ${task.subject} status: ${completedTask.status}`)
if (completedTask.status === "completed") {
handleTaskComplete({ subject: task.subject, output: completedTask })
}
// Update session progress
const session = Read(sessionFile)
const allTasksNow = TaskList()
session.tasks_completed = allTasksNow.filter(t => t.status === "completed").length
Write(sessionFile, session)
// Check if all tasks complete
const remaining = allTasksNow.filter(t => t.status !== "completed")
if (remaining.length === 0) {
Output("[coordinator] All tasks completed!")
break
}
}
Output("[coordinator] Coordination loop complete")
```
---
## Message Handlers
### handleTaskComplete
```javascript
function handleTaskComplete(message) {
const subject = message.subject
Output(`[coordinator] Task completed: ${subject}`)
// Check for dependent tasks
const allTasks = TaskList()
const dependentTasks = allTasks.filter(t =>
(t.blockedBy || []).includes(subject) && t.status === 'pending'
)
Output(`[coordinator] Checking ${dependentTasks.length} dependent tasks`)
for (const depTask of dependentTasks) {
// Check if all dependencies are met
const allDepsMet = (depTask.blockedBy || []).every(depSubject => {
const dep = allTasks.find(t => t.subject === depSubject)
return dep && dep.status === 'completed'
})
if (allDepsMet) {
Output(`[coordinator] Unblocking task: ${depTask.subject} (${depTask.owner})`)
}
}
// Special checkpoint: Spec phase complete before implementation
if (subject === "DISCUSS-006" && (requirements.mode === "full-lifecycle" || requirements.mode === "full-lifecycle-fe")) {
Output("[coordinator] Spec phase complete. Checkpoint before implementation.")
handleSpecCompleteCheckpoint()
}
}
```
---
### handleTaskBlocked
```javascript
function handleTaskBlocked(message) {
const subject = message.subject
const reason = message.reason
Output(`[coordinator] Task blocked: ${subject}`)
Output(`[coordinator] Reason: ${reason}`)
// Check if block reason is dependency-related
if (reason.includes("dependency")) {
Output("[coordinator] Dependency block detected. Waiting for predecessor tasks.")
return
}
// Check if block reason is ambiguity-related
if (reason.includes("ambiguous") || reason.includes("unclear")) {
Output("[coordinator] Ambiguity detected. Routing to analyst for research.")
handleAmbiguityBlock(subject, reason)
return
}
// Unknown block reason - escalate to user
Output("[coordinator] Unknown block reason. Escalating to user.")
const userDecision = AskUserQuestion({
question: `Task ${subject} is blocked: ${reason}. How to proceed?`,
choices: [
"retry - Retry the task",
"skip - Skip this task",
"abort - Abort entire workflow",
"manual - Provide manual input"
]
})
switch (userDecision) {
case "retry":
// Task will be retried in next coordination loop iteration
break
case "skip":
const task = TaskList().find(t => t.subject === subject)
if (task) TaskUpdate({ taskId: task.id, status: "completed" })
Output(`[coordinator] Task ${subject} skipped by user`)
break
case "abort":
Output("[coordinator] Workflow aborted by user")
loopActive = false
break
case "manual":
const manualInput = AskUserQuestion({
question: `Provide manual input for task ${subject}:`,
type: "text"
})
const taskToComplete = TaskList().find(t => t.subject === subject)
if (taskToComplete) TaskUpdate({ taskId: taskToComplete.id, status: "completed" })
Output(`[coordinator] Task ${subject} completed with manual input`)
break
}
}
// Route ambiguity to analyst (explorer as fallback)
function handleAmbiguityBlock(subject, reason) {
Output(`[coordinator] Creating research task for ambiguity in ${subject}`)
// Spawn analyst on-demand to research the ambiguity
Task({
subagent_type: "general-purpose",
description: `Spawn analyst for ambiguity research`,
team_name: teamName,
name: "analyst",
prompt: `你是 team "${teamName}" 的 ANALYST.
## ⚠️ 首要指令MUST
Skill(skill="team-lifecycle-v2", args="--role=analyst")
## 紧急研究任务
被阻塞任务: ${subject}
阻塞原因: ${reason}
Session: ${sessionFolder}
请调查并通过 SendMessage 汇报研究结果给 coordinator。`,
run_in_background: false
})
Output(`[coordinator] Ambiguity research complete for ${subject}`)
}
```
---
### handleDiscussionNeeded
```javascript
function handleDiscussionNeeded(message) {
const subject = message.subject
const question = message.question
const context = message.context
Output(`[coordinator] Discussion needed for task: ${subject}`)
Output(`[coordinator] Question: ${question}`)
// Route to user
const userResponse = AskUserQuestion({
question: `Task ${subject} needs clarification:\n\n${question}\n\nContext: ${context}`,
type: "text"
})
Output(`[coordinator] User response received for ${subject}`)
}
```
---
## Checkpoint Handlers
### handleSpecCompleteCheckpoint
```javascript
function handleSpecCompleteCheckpoint() {
Output("[coordinator] ========================================")
Output("[coordinator] SPEC PHASE COMPLETE - CHECKPOINT")
Output("[coordinator] ========================================")
// Ask user to review
const userDecision = AskUserQuestion({
question: "Spec phase complete (DISCUSS-006 done). Review specifications before proceeding to implementation?",
choices: [
"proceed - Proceed to implementation (PLAN-001)",
"review - Review spec artifacts in session folder",
"revise - Request spec revision",
"stop - Stop here (spec-only)"
]
})
switch (userDecision) {
case "proceed":
Output("[coordinator] Proceeding to implementation phase (PLAN-001)")
break
case "review":
Output("[coordinator] Spec artifacts are in: " + sessionFolder + "/spec/")
Output("[coordinator] Please review and then re-invoke to continue.")
handleSpecCompleteCheckpoint()
break
case "revise":
const revisionScope = AskUserQuestion({
question: "Which spec artifacts need revision? (e.g., DRAFT-002 requirements, DRAFT-003 architecture)",
type: "text"
})
Output(`[coordinator] Revision requested: ${revisionScope}`)
handleSpecCompleteCheckpoint()
break
case "stop":
Output("[coordinator] Stopping at spec phase (user request)")
loopActive = false
break
}
}
```
---
## Message Routing Tables
### Spec Phase Messages
| Message Type | Sender Role | Trigger | Coordinator Action |
|--------------|-------------|---------|-------------------|
| `research_ready` | analyst | RESEARCH-* done | Update session, unblock DISCUSS-001 |
| `discussion_ready` | discussant | DISCUSS-* done | Unblock next DRAFT-* or QUALITY-* |
| `draft_ready` | writer | DRAFT-* done | Unblock next DISCUSS-* |
| `quality_result` | reviewer | QUALITY-* done | Unblock DISCUSS-006 |
| `error` | any worker | Task failed | Log error, escalate to user |
### Impl Phase Messages
| Message Type | Sender Role | Trigger | Coordinator Action |
|--------------|-------------|---------|-------------------|
| `plan_ready` | planner | PLAN-001 done | Unblock IMPL-001 (+ DEV-FE-001 for fullstack) |
| `impl_complete` | executor | IMPL-001 done | Unblock TEST-001 + REVIEW-001 |
| `test_result` | tester | TEST-001 done | Log results |
| `review_result` | reviewer | REVIEW-001 done | Log results |
| `dev_fe_complete` | fe-developer | DEV-FE-* done | Unblock QA-FE-* |
| `qa_fe_result` | fe-qa | QA-FE-* done | Check verdict, maybe create GC round |
| `error` | any worker | Task failed | Log error, escalate to user |
---
## Progress Tracking
```javascript
function logProgress() {
const session = Read(sessionFile)
const completedCount = session.tasks_completed
const totalCount = session.tasks_total
const percentage = Math.round((completedCount / totalCount) * 100)
Output(`[coordinator] Progress: ${completedCount}/${totalCount} tasks (${percentage}%)`)
Output(`[coordinator] Current phase: ${session.current_phase}`)
}
```
---
## Output Format
All outputs from this command use the `[coordinator]` tag:
```
[coordinator] Entering coordination loop (Stop-Wait mode)...
[coordinator] Starting task: RESEARCH-001 (role: analyst)
[coordinator] Task RESEARCH-001 status: completed
[coordinator] Checking 1 dependent tasks
[coordinator] Unblocking task: DISCUSS-001 (discussant)
[coordinator] Progress: 1/12 tasks (8%)
```

View File

@@ -0,0 +1,695 @@
# Coordinator Role
## Role Identity
**Role**: Coordinator
**Output Tag**: `[coordinator]`
**Responsibility**: Orchestrate the team-lifecycle workflow by managing team creation, task dispatching, progress monitoring, and session state persistence.
## Role Boundaries
### MUST
- Parse user requirements and clarify ambiguous inputs
- Create team and spawn worker subagents
- Dispatch tasks with proper dependency chains
- Monitor task progress and route messages
- Handle session resume and reconciliation
- Maintain session state persistence
- Provide progress reports and next-step options
### MUST NOT
- Execute spec/impl/research work directly (delegate to workers)
- Modify task outputs (workers own their deliverables)
- Skip dependency validation
- Proceed without user confirmation at checkpoints
## Message Types
| Message Type | Sender | Trigger | Coordinator Action |
|--------------|--------|---------|-------------------|
| `task_complete` | Worker | Task finished | Update session, check dependencies, kick next task |
| `task_blocked` | Worker | Dependency missing | Log block reason, wait for predecessor |
| `discussion_needed` | Worker | Ambiguity found | Route to user via AskUserQuestion |
| `research_ready` | analyst | Research done | Checkpoint with user before impl |
## Toolbox
### Available Commands
- `commands/dispatch.md` - Task chain creation strategies (spec-only, impl-only, full-lifecycle)
- `commands/monitor.md` - Coordination loop with message routing and checkpoint handling
### Subagent Capabilities
- `TeamCreate` - Initialize team with session metadata
- `TeamSpawn` - Spawn worker subagents (analyst, writer, discussant, planner, executor, tester, reviewer, etc.)
- `TaskCreate` - Create tasks with dependencies
- `TaskUpdate` - Update task status/metadata
- `TaskGet` - Retrieve task details
- `AskUserQuestion` - Interactive user prompts
### CLI Capabilities
- Session file I/O (`Read`, `Write`)
- Directory scanning (`Glob`)
- Background execution for long-running tasks
---
## Execution Flow
### Phase 0: Session Resume Check
**Purpose**: Detect and resume interrupted sessions
```javascript
// Scan for session files
const sessionFiles = Glob("D:/Claude_dms3/.workflow/.sessions/team-lifecycle-*.json")
if (sessionFiles.length === 0) {
// No existing session, proceed to Phase 1
goto Phase1
}
if (sessionFiles.length === 1) {
// Single session found
const session = Read(sessionFiles[0])
if (session.status === "active" || session.status === "paused") {
Output("[coordinator] Resuming session: " + session.session_id)
goto SessionReconciliation
}
}
if (sessionFiles.length > 1) {
// Multiple sessions - ask user
const choices = sessionFiles.map(f => {
const s = Read(f)
return `${s.session_id} (${s.status}) - ${s.mode} - ${s.tasks_completed}/${s.tasks_total}`
})
const answer = AskUserQuestion({
question: "Multiple sessions found. Which to resume?",
choices: ["Create new session", ...choices]
})
if (answer === "Create new session") {
goto Phase1
} else {
const selectedSession = Read(sessionFiles[answer.index - 1])
goto SessionReconciliation
}
}
// Session Reconciliation Process
SessionReconciliation: {
Output("[coordinator] Reconciling session state...")
// Pipeline constants (aligned with SKILL.md Three-Mode Pipeline)
const SPEC_CHAIN = [
"RESEARCH-001", "DISCUSS-001", "DRAFT-001", "DISCUSS-002",
"DRAFT-002", "DISCUSS-003", "DRAFT-003", "DISCUSS-004",
"DRAFT-004", "DISCUSS-005", "QUALITY-001", "DISCUSS-006"
]
const IMPL_CHAIN = ["PLAN-001", "IMPL-001", "TEST-001", "REVIEW-001"]
const FE_CHAIN = ["DEV-FE-001", "QA-FE-001"]
const FULLSTACK_CHAIN = ["PLAN-001", "IMPL-001", "DEV-FE-001", "TEST-001", "QA-FE-001", "REVIEW-001"]
// Task metadata — role must match VALID_ROLES in SKILL.md
const TASK_METADATA = {
// Spec pipeline (12 tasks)
"RESEARCH-001": { role: "analyst", phase: "spec", deps: [], description: "Seed analysis: codebase exploration and context gathering" },
"DISCUSS-001": { role: "discussant", phase: "spec", deps: ["RESEARCH-001"], description: "Critique research findings" },
"DRAFT-001": { role: "writer", phase: "spec", deps: ["DISCUSS-001"], description: "Generate Product Brief" },
"DISCUSS-002": { role: "discussant", phase: "spec", deps: ["DRAFT-001"], description: "Critique Product Brief" },
"DRAFT-002": { role: "writer", phase: "spec", deps: ["DISCUSS-002"], description: "Generate Requirements/PRD" },
"DISCUSS-003": { role: "discussant", phase: "spec", deps: ["DRAFT-002"], description: "Critique Requirements/PRD" },
"DRAFT-003": { role: "writer", phase: "spec", deps: ["DISCUSS-003"], description: "Generate Architecture Document" },
"DISCUSS-004": { role: "discussant", phase: "spec", deps: ["DRAFT-003"], description: "Critique Architecture Document" },
"DRAFT-004": { role: "writer", phase: "spec", deps: ["DISCUSS-004"], description: "Generate Epics" },
"DISCUSS-005": { role: "discussant", phase: "spec", deps: ["DRAFT-004"], description: "Critique Epics" },
"QUALITY-001": { role: "reviewer", phase: "spec", deps: ["DISCUSS-005"], description: "5-dimension spec quality validation" },
"DISCUSS-006": { role: "discussant", phase: "spec", deps: ["QUALITY-001"], description: "Final review discussion and sign-off" },
// Impl pipeline (deps shown for impl-only; full-lifecycle adds PLAN-001 → ["DISCUSS-006"])
"PLAN-001": { role: "planner", phase: "impl", deps: [], description: "Multi-angle codebase exploration and structured planning" },
"IMPL-001": { role: "executor", phase: "impl", deps: ["PLAN-001"], description: "Code implementation following plan" },
"TEST-001": { role: "tester", phase: "impl", deps: ["IMPL-001"], description: "Adaptive test-fix cycles and quality gates" },
"REVIEW-001": { role: "reviewer", phase: "impl", deps: ["IMPL-001"], description: "4-dimension code review" },
// Frontend pipeline tasks
"DEV-FE-001": { role: "fe-developer", phase: "impl", deps: ["PLAN-001"], description: "Frontend component/page implementation" },
"QA-FE-001": { role: "fe-qa", phase: "impl", deps: ["DEV-FE-001"], description: "5-dimension frontend QA" }
}
// Helper: Get predecessor task
function getPredecessor(taskId, chain) {
const index = chain.indexOf(taskId)
return index > 0 ? chain[index - 1] : null
}
// Step 1: Audit current state
const session = Read(sessionFile)
const teamState = TeamGet(session.team_id)
const allTasks = teamState.tasks
Output("[coordinator] Session audit:")
Output(` Mode: ${session.mode}`)
Output(` Tasks completed: ${session.tasks_completed}/${session.tasks_total}`)
Output(` Status: ${session.status}`)
// Step 2: Reconcile task states
const completedTasks = allTasks.filter(t => t.status === "completed")
const activeTasks = allTasks.filter(t => t.status === "active")
const blockedTasks = allTasks.filter(t => t.status === "blocked")
const pendingTasks = allTasks.filter(t => t.status === "pending")
Output("[coordinator] Task breakdown:")
Output(` Completed: ${completedTasks.length}`)
Output(` Active: ${activeTasks.length}`)
Output(` Blocked: ${blockedTasks.length}`)
Output(` Pending: ${pendingTasks.length}`)
// Step 3: Determine remaining work
const expectedChain =
session.mode === "spec-only" ? SPEC_CHAIN :
session.mode === "impl-only" ? IMPL_CHAIN :
session.mode === "fe-only" ? ["PLAN-001", ...FE_CHAIN] :
session.mode === "fullstack" ? FULLSTACK_CHAIN :
session.mode === "full-lifecycle-fe" ? [...SPEC_CHAIN, ...FULLSTACK_CHAIN] :
[...SPEC_CHAIN, ...IMPL_CHAIN] // full-lifecycle default
const remainingTaskIds = expectedChain.filter(id =>
!completedTasks.some(t => t.subject === id)
)
Output(`[coordinator] Remaining tasks: ${remainingTaskIds.join(", ")}`)
// Step 4: Rebuild team if needed
if (!teamState || teamState.status === "disbanded") {
Output("[coordinator] Team disbanded, recreating...")
TeamCreate({
team_id: session.team_id,
session_id: session.session_id,
mode: session.mode
})
}
// Step 5: Create missing tasks
for (const taskId of remainingTaskIds) {
const existingTask = allTasks.find(t => t.subject === taskId)
if (!existingTask) {
const metadata = TASK_METADATA[taskId]
TaskCreate({
subject: taskId,
owner: metadata.role,
description: `${metadata.description}\nSession: ${sessionFolder}`,
blockedBy: metadata.deps,
status: "pending"
})
Output(`[coordinator] Created missing task: ${taskId} (${metadata.role})`)
}
}
// Step 6: Verify dependencies
for (const taskId of remainingTaskIds) {
const task = allTasks.find(t => t.subject === taskId)
if (!task) continue
const metadata = TASK_METADATA[taskId]
const allDepsMet = metadata.deps.every(depId =>
completedTasks.some(t => t.subject === depId)
)
if (allDepsMet && task.status !== "completed") {
Output(`[coordinator] Unblocked task: ${taskId} (${metadata.role})`)
}
}
// Step 7: Update session state
session.status = "active"
session.resumed_at = new Date().toISOString()
session.tasks_completed = completedTasks.length
Write(sessionFile, session)
// Step 8: Report reconciliation
Output("[coordinator] Session reconciliation complete")
Output(`[coordinator] Ready to resume from: ${remainingTaskIds[0] || "all tasks complete"}`)
// Step 9: Kick next task
if (remainingTaskIds.length > 0) {
const nextTaskId = remainingTaskIds[0]
const nextTask = TaskGet(nextTaskId)
const metadata = TASK_METADATA[nextTaskId]
if (metadata.deps.every(depId => completedTasks.some(t => t.subject === depId))) {
TaskUpdate(nextTaskId, { status: "active" })
Output(`[coordinator] Kicking task: ${nextTaskId}`)
goto Phase4_CoordinationLoop
} else {
Output(`[coordinator] Next task ${nextTaskId} blocked on: ${metadata.deps.join(", ")}`)
goto Phase4_CoordinationLoop
}
} else {
Output("[coordinator] All tasks complete!")
goto Phase5_Report
}
}
```
---
### Phase 1: Requirement Clarification
**Purpose**: Parse user input and clarify execution parameters
```javascript
Output("[coordinator] Phase 1: Requirement Clarification")
// Parse $ARGUMENTS
const userInput = $ARGUMENTS
// Extract mode if specified
let mode = null
if (userInput.includes("spec-only")) mode = "spec-only"
if (userInput.includes("impl-only")) mode = "impl-only"
if (userInput.includes("full-lifecycle")) mode = "full-lifecycle"
// Extract scope if specified
let scope = null
if (userInput.includes("scope:")) {
scope = userInput.match(/scope:\s*([^\n]+)/)[1]
}
// Extract focus areas
let focus = []
if (userInput.includes("focus:")) {
focus = userInput.match(/focus:\s*([^\n]+)/)[1].split(",").map(s => s.trim())
}
// Extract depth preference
let depth = "standard"
if (userInput.includes("depth:shallow")) depth = "shallow"
if (userInput.includes("depth:deep")) depth = "deep"
// Ask for missing parameters
if (!mode) {
mode = AskUserQuestion({
question: "Select execution mode:",
choices: [
"spec-only - Generate specifications only",
"impl-only - Implementation only (requires existing spec)",
"full-lifecycle - Complete spec + implementation",
"fe-only - Frontend-only pipeline (plan → dev → QA)",
"fullstack - Backend + frontend parallel pipeline",
"full-lifecycle-fe - Full lifecycle with frontend (spec → fullstack)"
]
})
}
if (!scope) {
scope = AskUserQuestion({
question: "Describe the project scope:",
type: "text"
})
}
if (focus.length === 0) {
const focusAnswer = AskUserQuestion({
question: "Any specific focus areas? (optional)",
type: "text",
optional: true
})
if (focusAnswer) {
focus = focusAnswer.split(",").map(s => s.trim())
}
}
// Determine execution method
const executionMethod = AskUserQuestion({
question: "Execution method:",
choices: [
"sequential - One task at a time (safer, slower)",
"parallel - Multiple tasks in parallel (faster, more complex)"
]
})
// Store clarified requirements
const requirements = {
mode,
scope,
focus,
depth,
executionMethod,
originalInput: userInput
}
// --- Frontend Detection ---
// Auto-detect frontend tasks and adjust pipeline mode
const FE_KEYWORDS = /component|page|UI|前端|frontend|CSS|HTML|React|Vue|Tailwind|组件|页面|样式|layout|responsive|Svelte|Next\.js|Nuxt|shadcn|设计系统|design.system/i
const BE_KEYWORDS = /API|database|server|后端|backend|middleware|auth|REST|GraphQL|migration|schema|model|controller|service/i
function detectImplMode(taskDescription) {
const hasFE = FE_KEYWORDS.test(taskDescription)
const hasBE = BE_KEYWORDS.test(taskDescription)
// Also check project files for frontend frameworks
const hasFEFiles = Bash(`test -f package.json && (grep -q react package.json || grep -q vue package.json || grep -q svelte package.json || grep -q next package.json); echo $?`) === '0'
if (hasFE && hasBE) return 'fullstack'
if (hasFE || hasFEFiles) return 'fe-only'
return 'impl-only' // default backend
}
// Apply frontend detection for implementation modes
if (mode === 'impl-only' || mode === 'full-lifecycle') {
const detectedMode = detectImplMode(scope + ' ' + userInput)
if (detectedMode !== 'impl-only') {
// Frontend detected — upgrade pipeline mode
if (mode === 'impl-only') {
mode = detectedMode // fe-only or fullstack
} else if (mode === 'full-lifecycle') {
mode = 'full-lifecycle-fe' // spec + fullstack
}
requirements.mode = mode
Output(`[coordinator] Frontend detected → pipeline upgraded to: ${mode}`)
}
}
Output("[coordinator] Requirements clarified:")
Output(` Mode: ${mode}`)
Output(` Scope: ${scope}`)
Output(` Focus: ${focus.join(", ") || "none"}`)
Output(` Depth: ${depth}`)
Output(` Execution: ${executionMethod}`)
goto Phase2
```
---
### Phase 2: Create Team + Initialize Session
**Purpose**: Initialize team and session state
```javascript
Output("[coordinator] Phase 2: Team Creation")
// Generate session ID
const sessionId = `team-lifecycle-${Date.now()}`
const teamId = sessionId
// Create team
TeamCreate({
team_id: teamId,
session_id: sessionId,
mode: requirements.mode,
scope: requirements.scope,
focus: requirements.focus,
depth: requirements.depth,
executionMethod: requirements.executionMethod
})
Output(`[coordinator] Team created: ${teamId}`)
// Initialize wisdom directory
const wisdomDir = `${sessionFolder}/wisdom`
Bash(`mkdir -p "${wisdomDir}"`)
Write(`${wisdomDir}/learnings.md`, `# Learnings\n\n<!-- Auto-accumulated by team roles -->\n`)
Write(`${wisdomDir}/decisions.md`, `# Decisions\n\n<!-- Architectural and design decisions -->\n`)
Write(`${wisdomDir}/conventions.md`, `# Conventions\n\n<!-- Codebase conventions discovered -->\n<!-- explorer-patterns -->\n`)
Write(`${wisdomDir}/issues.md`, `# Known Issues\n\n<!-- Risks and issues found during execution -->\n`)
// Initialize session file
const sessionFile = `D:/Claude_dms3/.workflow/.sessions/${sessionId}.json`
const sessionData = {
session_id: sessionId,
team_id: teamId,
mode: requirements.mode,
scope: requirements.scope,
focus: requirements.focus,
depth: requirements.depth,
executionMethod: requirements.executionMethod,
status: "active",
created_at: new Date().toISOString(),
tasks_total: requirements.mode === "spec-only" ? 12 :
requirements.mode === "impl-only" ? 4 :
requirements.mode === "fe-only" ? 3 :
requirements.mode === "fullstack" ? 6 :
requirements.mode === "full-lifecycle-fe" ? 18 : 16,
tasks_completed: 0,
current_phase: requirements.mode === "impl-only" ? "impl" : "spec"
}
Write(sessionFile, sessionData)
Output(`[coordinator] Session file created: ${sessionFile}`)
// ⚠️ Workers are NOT pre-spawned here.
// Workers are spawned per-stage in Phase 4 via Stop-Wait Task(run_in_background: false).
// See SKILL.md Coordinator Spawn Template for worker prompt templates.
//
// Worker roles by mode (spawned on-demand, must match VALID_ROLES in SKILL.md):
// spec-only: analyst, discussant, writer, reviewer
// impl-only: planner, executor, tester, reviewer
// fe-only: planner, fe-developer, fe-qa
// fullstack: planner, executor, fe-developer, tester, fe-qa, reviewer
// full-lifecycle: analyst, discussant, writer, reviewer, planner, executor, tester
// full-lifecycle-fe: all of the above + fe-developer, fe-qa
// On-demand (ambiguity): analyst or explorer
goto Phase3
```
---
### Phase 3: Create Task Chain
**Purpose**: Dispatch tasks based on execution mode
```javascript
Output("[coordinator] Phase 3: Task Dispatching")
// Delegate to command file
const dispatchStrategy = Read("commands/dispatch.md")
// Execute strategy defined in command file
// (dispatch.md contains the complete task chain creation logic)
goto Phase4
```
---
### Phase 4: Coordination Loop
**Purpose**: Monitor task progress and route messages
> **设计原则Stop-Wait**: 模型执行没有时间概念,禁止任何形式的轮询等待。
> - ❌ 禁止: `while` 循环 + `sleep` + 检查状态
> - ✅ 采用: 同步 `Task(run_in_background: false)` 调用Worker 返回 = 阶段完成信号
>
> 按 Phase 3 创建的任务链顺序,逐阶段 spawn worker 同步执行。
> Worker prompt 使用 SKILL.md Coordinator Spawn Template。
```javascript
Output("[coordinator] Phase 4: Coordination Loop")
// Delegate to command file
const monitorStrategy = Read("commands/monitor.md")
// Execute strategy defined in command file
// (monitor.md contains the complete message routing and checkpoint logic)
goto Phase5
```
---
### Phase 5: Report + Persistent Loop
**Purpose**: Provide completion report and offer next steps
```javascript
Output("[coordinator] Phase 5: Completion Report")
// Load session state
const session = Read(sessionFile)
const teamState = TeamGet(session.team_id)
// Generate report
Output("[coordinator] ========================================")
Output("[coordinator] TEAM LIFECYCLE EXECUTION COMPLETE")
Output("[coordinator] ========================================")
Output(`[coordinator] Session ID: ${session.session_id}`)
Output(`[coordinator] Mode: ${session.mode}`)
Output(`[coordinator] Tasks Completed: ${session.tasks_completed}/${session.tasks_total}`)
Output(`[coordinator] Duration: ${calculateDuration(session.created_at, new Date())}`)
// List deliverables
const completedTasks = teamState.tasks.filter(t => t.status === "completed")
Output("[coordinator] Deliverables:")
for (const task of completedTasks) {
Output(`${task.subject}: ${task.description}`)
if (task.output_file) {
Output(` Output: ${task.output_file}`)
}
}
// Update session status
session.status = "completed"
session.completed_at = new Date().toISOString()
Write(sessionFile, session)
// Offer next steps
const nextAction = AskUserQuestion({
question: "What would you like to do next?",
choices: [
"exit - End session",
"review - Review specific deliverables",
"extend - Add more tasks to this session",
"handoff-lite-plan - Create lite-plan from spec",
"handoff-full-plan - Create full-plan from spec",
"handoff-req-plan - Create req-plan from requirements",
"handoff-create-issues - Generate GitHub issues"
]
})
switch (nextAction) {
case "exit":
Output("[coordinator] Session ended. Goodbye!")
break
case "review":
const taskToReview = AskUserQuestion({
question: "Which task output to review?",
choices: completedTasks.map(t => t.subject)
})
const reviewTask = completedTasks.find(t => t.subject === taskToReview)
if (reviewTask.output_file) {
const content = Read(reviewTask.output_file)
Output(`[coordinator] Task: ${reviewTask.subject}`)
Output(content)
}
goto Phase5 // Loop back for more actions
case "extend":
const extensionScope = AskUserQuestion({
question: "Describe additional work:",
type: "text"
})
Output("[coordinator] Creating extension tasks...")
// Create custom tasks based on extension scope
// (Implementation depends on extension requirements)
goto Phase4 // Return to coordination loop
case "handoff-lite-plan":
Output("[coordinator] Generating lite-plan from specifications...")
// Read spec completion output (DISCUSS-006 = final sign-off)
const specOutput = Read(getTaskOutput("DISCUSS-006"))
// Create lite-plan format
const litePlan = generateLitePlan(specOutput)
const litePlanFile = `D:/Claude_dms3/.workflow/.sessions/${session.session_id}-lite-plan.md`
Write(litePlanFile, litePlan)
Output(`[coordinator] Lite-plan created: ${litePlanFile}`)
goto Phase5
case "handoff-full-plan":
Output("[coordinator] Generating full-plan from specifications...")
const fullSpecOutput = Read(getTaskOutput("DISCUSS-006"))
const fullPlan = generateFullPlan(fullSpecOutput)
const fullPlanFile = `D:/Claude_dms3/.workflow/.sessions/${session.session_id}-full-plan.md`
Write(fullPlanFile, fullPlan)
Output(`[coordinator] Full-plan created: ${fullPlanFile}`)
goto Phase5
case "handoff-req-plan":
Output("[coordinator] Generating req-plan from requirements...")
const reqAnalysis = Read(getTaskOutput("RESEARCH-001"))
const reqPlan = generateReqPlan(reqAnalysis)
const reqPlanFile = `D:/Claude_dms3/.workflow/.sessions/${session.session_id}-req-plan.md`
Write(reqPlanFile, reqPlan)
Output(`[coordinator] Req-plan created: ${reqPlanFile}`)
goto Phase5
case "handoff-create-issues":
Output("[coordinator] Generating GitHub issues...")
const issuesSpec = Read(getTaskOutput("DISCUSS-006"))
const issues = generateGitHubIssues(issuesSpec)
const issuesFile = `D:/Claude_dms3/.workflow/.sessions/${session.session_id}-issues.json`
Write(issuesFile, issues)
Output(`[coordinator] Issues created: ${issuesFile}`)
Output("[coordinator] Use GitHub CLI to import: gh issue create --title ... --body ...")
goto Phase5
}
// Helper functions
function calculateDuration(start, end) {
const diff = new Date(end) - new Date(start)
const minutes = Math.floor(diff / 60000)
const seconds = Math.floor((diff % 60000) / 1000)
return `${minutes}m ${seconds}s`
}
function getTaskOutput(taskId) {
const task = TaskGet(taskId)
return task.output_file
}
function generateLitePlan(specOutput) {
// Parse spec output and create lite-plan format
return `# Lite Plan\n\n${specOutput}\n\n## Implementation Steps\n- Step 1\n- Step 2\n...`
}
function generateFullPlan(specOutput) {
// Parse spec output and create full-plan format with detailed breakdown
return `# Full Plan\n\n${specOutput}\n\n## Detailed Implementation\n### Phase 1\n### Phase 2\n...`
}
function generateReqPlan(reqAnalysis) {
// Parse requirements and create req-plan format
return `# Requirements Plan\n\n${reqAnalysis}\n\n## Acceptance Criteria\n- Criterion 1\n- Criterion 2\n...`
}
function generateGitHubIssues(specOutput) {
// Parse spec and generate GitHub issue JSON
return {
issues: [
{ title: "Issue 1", body: "Description", labels: ["feature"] },
{ title: "Issue 2", body: "Description", labels: ["bug"] }
]
}
}
```
---
## Session File Structure
```json
{
"session_id": "team-lifecycle-1234567890",
"team_id": "team-lifecycle-1234567890",
"mode": "full-lifecycle",
"scope": "Build authentication system",
"focus": ["security", "scalability"],
"depth": "standard",
"executionMethod": "sequential",
"status": "active",
"created_at": "2026-02-18T10:00:00Z",
"completed_at": null,
"resumed_at": null,
"tasks_total": 16,
"tasks_completed": 5,
"current_phase": "spec"
}
```
---
## Error Handling
| Error Type | Coordinator Action |
|------------|-------------------|
| Task timeout | Log timeout, mark task as failed, ask user to retry or skip |
| Worker crash | Respawn worker, reassign task |
| Dependency cycle | Detect cycle, report to user, halt execution |
| Invalid mode | Reject with error message, ask user to clarify |
| Session corruption | Attempt recovery, fallback to manual reconciliation |

View File

@@ -0,0 +1,396 @@
# Command: Multi-Perspective Critique
Phase 3 of discussant execution - launch parallel CLI analyses for each required perspective.
## Overview
This command executes multi-perspective critique by routing to specialized CLI tools based on perspective type. Each perspective produces structured critique with strengths, weaknesses, suggestions, and ratings.
## Perspective Definitions
### 1. Product Perspective (gemini)
**Focus**: Market fit, user value, business viability, competitive differentiation
**CLI Tool**: gemini
**Output Structure**:
```json
{
"perspective": "product",
"strengths": ["string"],
"weaknesses": ["string"],
"suggestions": ["string"],
"rating": 1-5
}
```
**Prompt Template**:
```
Analyze from Product Manager perspective:
- Market fit and user value proposition
- Business viability and ROI potential
- Competitive differentiation
- User experience and adoption barriers
Artifact: {artifactContent}
Output JSON with: strengths[], weaknesses[], suggestions[], rating (1-5)
```
### 2. Technical Perspective (codex)
**Focus**: Feasibility, tech debt, performance, security, maintainability
**CLI Tool**: codex
**Output Structure**:
```json
{
"perspective": "technical",
"strengths": ["string"],
"weaknesses": ["string"],
"suggestions": ["string"],
"rating": 1-5
}
```
**Prompt Template**:
```
Analyze from Tech Lead perspective:
- Technical feasibility and implementation complexity
- Architecture decisions and tech debt implications
- Performance and scalability considerations
- Security vulnerabilities and risks
- Code maintainability and extensibility
Artifact: {artifactContent}
Output JSON with: strengths[], weaknesses[], suggestions[], rating (1-5)
```
### 3. Quality Perspective (claude)
**Focus**: Completeness, testability, consistency, standards compliance
**CLI Tool**: claude
**Output Structure**:
```json
{
"perspective": "quality",
"strengths": ["string"],
"weaknesses": ["string"],
"suggestions": ["string"],
"rating": 1-5
}
```
**Prompt Template**:
```
Analyze from QA Lead perspective:
- Specification completeness and clarity
- Testability and test coverage potential
- Consistency across requirements/design
- Standards compliance (coding, documentation, accessibility)
- Ambiguity detection and edge case coverage
Artifact: {artifactContent}
Output JSON with: strengths[], weaknesses[], suggestions[], rating (1-5)
```
### 4. Risk Perspective (gemini)
**Focus**: Risk identification, dependency analysis, assumption validation, failure modes
**CLI Tool**: gemini
**Output Structure**:
```json
{
"perspective": "risk",
"strengths": ["string"],
"weaknesses": ["string"],
"suggestions": ["string"],
"rating": 1-5,
"risk_level": "low|medium|high|critical"
}
```
**Prompt Template**:
```
Analyze from Risk Analyst perspective:
- Risk identification (technical, business, operational)
- Dependency analysis and external risks
- Assumption validation and hidden dependencies
- Failure modes and mitigation strategies
- Timeline and resource risks
Artifact: {artifactContent}
Output JSON with: strengths[], weaknesses[], suggestions[], rating (1-5), risk_level
```
### 5. Coverage Perspective (gemini)
**Focus**: Requirement completeness vs original intent, scope drift, gap detection
**CLI Tool**: gemini
**Output Structure**:
```json
{
"perspective": "coverage",
"strengths": ["string"],
"weaknesses": ["string"],
"suggestions": ["string"],
"rating": 1-5,
"covered_requirements": ["REQ-ID"],
"partial_requirements": ["REQ-ID"],
"missing_requirements": ["REQ-ID"],
"scope_creep": ["description"]
}
```
**Prompt Template**:
```
Analyze from Requirements Analyst perspective:
- Compare current artifact against original requirements in discovery-context.json
- Identify covered requirements (fully addressed)
- Identify partial requirements (partially addressed)
- Identify missing requirements (not addressed)
- Detect scope creep (new items not in original requirements)
Original Requirements: {discoveryContext}
Current Artifact: {artifactContent}
Output JSON with:
- strengths[], weaknesses[], suggestions[], rating (1-5)
- covered_requirements[] (REQ-IDs fully addressed)
- partial_requirements[] (REQ-IDs partially addressed)
- missing_requirements[] (REQ-IDs not addressed) ← CRITICAL if non-empty
- scope_creep[] (new items not in original requirements)
```
## Execution Pattern
### Parallel CLI Execution
```javascript
// Load artifact content
const artifactPath = `${sessionFolder}/${config.artifact}`
const artifactContent = config.type === 'json'
? JSON.parse(Read(artifactPath))
: Read(artifactPath)
// Load discovery context for coverage perspective
let discoveryContext = null
try {
discoveryContext = JSON.parse(Read(`${sessionFolder}/spec/discovery-context.json`))
} catch { /* may not exist in early rounds */ }
// Launch parallel CLI analyses
const perspectiveResults = []
for (const perspective of config.perspectives) {
let cliTool, prompt
switch(perspective) {
case 'product':
cliTool = 'gemini'
prompt = `Analyze from Product Manager perspective:
- Market fit and user value proposition
- Business viability and ROI potential
- Competitive differentiation
- User experience and adoption barriers
Artifact:
${JSON.stringify(artifactContent, null, 2)}
Output JSON with: strengths[], weaknesses[], suggestions[], rating (1-5)`
break
case 'technical':
cliTool = 'codex'
prompt = `Analyze from Tech Lead perspective:
- Technical feasibility and implementation complexity
- Architecture decisions and tech debt implications
- Performance and scalability considerations
- Security vulnerabilities and risks
- Code maintainability and extensibility
Artifact:
${JSON.stringify(artifactContent, null, 2)}
Output JSON with: strengths[], weaknesses[], suggestions[], rating (1-5)`
break
case 'quality':
cliTool = 'claude'
prompt = `Analyze from QA Lead perspective:
- Specification completeness and clarity
- Testability and test coverage potential
- Consistency across requirements/design
- Standards compliance (coding, documentation, accessibility)
- Ambiguity detection and edge case coverage
Artifact:
${JSON.stringify(artifactContent, null, 2)}
Output JSON with: strengths[], weaknesses[], suggestions[], rating (1-5)`
break
case 'risk':
cliTool = 'gemini'
prompt = `Analyze from Risk Analyst perspective:
- Risk identification (technical, business, operational)
- Dependency analysis and external risks
- Assumption validation and hidden dependencies
- Failure modes and mitigation strategies
- Timeline and resource risks
Artifact:
${JSON.stringify(artifactContent, null, 2)}
Output JSON with: strengths[], weaknesses[], suggestions[], rating (1-5), risk_level`
break
case 'coverage':
cliTool = 'gemini'
prompt = `Analyze from Requirements Analyst perspective:
- Compare current artifact against original requirements in discovery-context.json
- Identify covered requirements (fully addressed)
- Identify partial requirements (partially addressed)
- Identify missing requirements (not addressed)
- Detect scope creep (new items not in original requirements)
Original Requirements:
${discoveryContext ? JSON.stringify(discoveryContext, null, 2) : 'Not available'}
Current Artifact:
${JSON.stringify(artifactContent, null, 2)}
Output JSON with:
- strengths[], weaknesses[], suggestions[], rating (1-5)
- covered_requirements[] (REQ-IDs fully addressed)
- partial_requirements[] (REQ-IDs partially addressed)
- missing_requirements[] (REQ-IDs not addressed) ← CRITICAL if non-empty
- scope_creep[] (new items not in original requirements)`
break
}
// Execute CLI analysis (run_in_background: true per CLAUDE.md)
Bash({
command: `ccw cli -p "${prompt.replace(/"/g, '\\"')}" --tool ${cliTool} --mode analysis`,
run_in_background: true,
description: `[discussant] ${perspective} perspective analysis`
})
}
// Wait for all CLI results via hook callbacks
// Results will be collected in perspectiveResults array
```
## Critical Divergence Detection
### Coverage Gap Detection
```javascript
const coverageResult = perspectiveResults.find(p => p.perspective === 'coverage')
if (coverageResult?.missing_requirements?.length > 0) {
// Flag as critical divergence
synthesis.divergent_views.push({
topic: 'requirement_coverage_gap',
description: `${coverageResult.missing_requirements.length} requirements from discovery-context not covered: ${coverageResult.missing_requirements.join(', ')}`,
severity: 'high',
source: 'coverage'
})
}
```
### Risk Level Detection
```javascript
const riskResult = perspectiveResults.find(p => p.perspective === 'risk')
if (riskResult?.risk_level === 'high' || riskResult?.risk_level === 'critical') {
synthesis.risk_flags.push({
level: riskResult.risk_level,
description: riskResult.weaknesses.join('; ')
})
}
```
## Fallback Strategy
### CLI Failure Fallback
```javascript
// If CLI analysis fails for a perspective, fallback to direct Claude analysis
try {
// CLI execution
Bash({ command: `ccw cli -p "..." --tool ${cliTool} --mode analysis`, run_in_background: true })
} catch (error) {
// Fallback: Direct Claude analysis
const fallbackResult = {
perspective: perspective,
strengths: ["Direct analysis: ..."],
weaknesses: ["Direct analysis: ..."],
suggestions: ["Direct analysis: ..."],
rating: 3,
_fallback: true
}
perspectiveResults.push(fallbackResult)
}
```
### All CLI Failures
```javascript
if (perspectiveResults.every(r => r._fallback)) {
// Generate basic discussion from direct reading
const basicDiscussion = {
convergent_themes: ["Basic analysis from direct reading"],
divergent_views: [],
action_items: ["Review artifact manually"],
open_questions: [],
decisions: [],
risk_flags: [],
overall_sentiment: 'neutral',
consensus_reached: true,
_basic_mode: true
}
}
```
## Output Format
Each perspective produces:
```json
{
"perspective": "product|technical|quality|risk|coverage",
"strengths": ["string"],
"weaknesses": ["string"],
"suggestions": ["string"],
"rating": 1-5,
// Risk perspective only
"risk_level": "low|medium|high|critical",
// Coverage perspective only
"covered_requirements": ["REQ-ID"],
"partial_requirements": ["REQ-ID"],
"missing_requirements": ["REQ-ID"],
"scope_creep": ["description"]
}
```
## Integration with Phase 4
Phase 4 (Consensus Synthesis) consumes `perspectiveResults` array to:
1. Extract convergent themes (2+ perspectives agree)
2. Extract divergent views (perspectives conflict)
3. Detect coverage gaps (missing_requirements non-empty)
4. Assess risk flags (high/critical risk_level)
5. Determine consensus_reached (true if no critical divergences)

View File

@@ -0,0 +1,265 @@
# Role: discussant
Multi-perspective critique, consensus building, and conflict escalation. The key differentiator of the spec team workflow — ensuring quality feedback between each phase transition.
## Role Identity
- **Name**: `discussant`
- **Task Prefix**: `DISCUSS-*`
- **Output Tag**: `[discussant]`
- **Responsibility**: Load Artifact → Multi-Perspective Critique → Synthesize Consensus → Report
- **Communication**: SendMessage to coordinator only
## Role Boundaries
### MUST
- Only process DISCUSS-* tasks
- Communicate only with coordinator
- Write discussion records to `discussions/` folder
- Tag all SendMessage and team_msg calls with `[discussant]`
- Load roundConfig with all 6 rounds
- Execute multi-perspective critique via CLI tools
- Detect coverage gaps from coverage perspective
- Synthesize consensus with convergent/divergent analysis
- Report consensus_reached vs discussion_blocked paths
### MUST NOT
- Create tasks
- Contact other workers directly
- Modify spec documents directly
- Skip perspectives defined in roundConfig
- Proceed without artifact loading
- Ignore critical divergences
## Message Types
| Type | Direction | Trigger | Description |
|------|-----------|---------|-------------|
| `discussion_ready` | discussant → coordinator | Discussion complete, consensus reached | With discussion record path and decision summary |
| `discussion_blocked` | discussant → coordinator | Cannot reach consensus | With divergence points and options, needs coordinator |
| `impl_progress` | discussant → coordinator | Long discussion progress | Multi-perspective analysis progress |
| `error` | discussant → coordinator | Discussion cannot proceed | Input artifact missing, etc. |
## Message Bus
Before every `SendMessage`, MUST call `mcp__ccw-tools__team_msg` to log:
```javascript
// Discussion complete
mcp__ccw-tools__team_msg({ operation: "log", team: teamName, from: "discussant", to: "coordinator", type: "discussion_ready", summary: "[discussant] Scope discussion consensus reached: 3 decisions", ref: `${sessionFolder}/discussions/discuss-001-scope.md` })
// Discussion blocked
mcp__ccw-tools__team_msg({ operation: "log", team: teamName, from: "discussant", to: "coordinator", type: "discussion_blocked", summary: "[discussant] Cannot reach consensus on tech stack", data: { reason: "...", options: [...] } })
// Error report
mcp__ccw-tools__team_msg({ operation: "log", team: teamName, from: "discussant", to: "coordinator", type: "error", summary: "[discussant] Input artifact missing" })
```
### CLI Fallback
When `mcp__ccw-tools__team_msg` MCP is unavailable:
```javascript
Bash(`ccw team log --team "${teamName}" --from "discussant" --to "coordinator" --type "discussion_ready" --summary "[discussant] Discussion complete" --ref "${sessionFolder}/discussions/discuss-001-scope.md" --json`)
```
## Discussion Dimension Model
Each discussion round analyzes from 5 perspectives:
| Perspective | Focus | Representative | CLI Tool |
|-------------|-------|----------------|----------|
| **Product** | Market fit, user value, business viability, competitive differentiation | Product Manager | gemini |
| **Technical** | Feasibility, tech debt, performance, security, maintainability | Tech Lead | codex |
| **Quality** | Completeness, testability, consistency, standards compliance | QA Lead | claude |
| **Risk** | Risk identification, dependency analysis, assumption validation, failure modes | Risk Analyst | gemini |
| **Coverage** | Requirement completeness vs original intent, scope drift, gap detection | Requirements Analyst | gemini |
## Discussion Round Configuration
| Round | Artifact | Key Perspectives | Focus |
|-------|----------|-----------------|-------|
| DISCUSS-001 | discovery-context | product + risk + **coverage** | Scope confirmation, direction, initial coverage check |
| DISCUSS-002 | product-brief | product + technical + quality + **coverage** | Positioning, feasibility, requirement coverage |
| DISCUSS-003 | requirements | quality + product + **coverage** | Completeness, priority, gap detection |
| DISCUSS-004 | architecture | technical + risk | Tech choices, security |
| DISCUSS-005 | epics | product + technical + quality + **coverage** | MVP scope, estimation, requirement tracing |
| DISCUSS-006 | readiness-report | all 5 perspectives | Final sign-off |
## Toolbox
### Available Commands
- `commands/critique.md` - Multi-perspective CLI critique (Phase 3)
### Subagent Capabilities
None (discussant uses CLI tools directly)
### CLI Capabilities
- **gemini**: Product perspective, Risk perspective, Coverage perspective
- **codex**: Technical perspective
- **claude**: Quality perspective
## Execution (5-Phase)
### Phase 1: Task Discovery
```javascript
const tasks = TaskList()
const myTasks = tasks.filter(t =>
t.subject.startsWith('DISCUSS-') &&
t.owner === 'discussant' &&
t.status === 'pending' &&
t.blockedBy.length === 0
)
if (myTasks.length === 0) return // idle
const task = TaskGet({ taskId: myTasks[0].id })
TaskUpdate({ taskId: task.id, status: 'in_progress' })
```
### Phase 2: Artifact Loading
```javascript
const sessionMatch = task.description.match(/Session:\s*(.+)/)
const sessionFolder = sessionMatch ? sessionMatch[1].trim() : ''
const roundMatch = task.subject.match(/DISCUSS-(\d+)/)
const roundNumber = roundMatch ? parseInt(roundMatch[1]) : 0
const roundConfig = {
1: { artifact: 'spec/discovery-context.json', type: 'json', outputFile: 'discuss-001-scope.md', perspectives: ['product', 'risk', 'coverage'], label: '范围讨论' },
2: { artifact: 'spec/product-brief.md', type: 'md', outputFile: 'discuss-002-brief.md', perspectives: ['product', 'technical', 'quality', 'coverage'], label: 'Brief评审' },
3: { artifact: 'spec/requirements/_index.md', type: 'md', outputFile: 'discuss-003-requirements.md', perspectives: ['quality', 'product', 'coverage'], label: '需求讨论' },
4: { artifact: 'spec/architecture/_index.md', type: 'md', outputFile: 'discuss-004-architecture.md', perspectives: ['technical', 'risk'], label: '架构讨论' },
5: { artifact: 'spec/epics/_index.md', type: 'md', outputFile: 'discuss-005-epics.md', perspectives: ['product', 'technical', 'quality', 'coverage'], label: 'Epics讨论' },
6: { artifact: 'spec/readiness-report.md', type: 'md', outputFile: 'discuss-006-final.md', perspectives: ['product', 'technical', 'quality', 'risk', 'coverage'], label: '最终签收' }
}
const config = roundConfig[roundNumber]
// Load target artifact and prior discussion records for continuity
Bash(`mkdir -p ${sessionFolder}/discussions`)
```
### Phase 3: Multi-Perspective Critique
**Delegate to**: `Read("commands/critique.md")`
Launch parallel CLI analyses for each required perspective. See `commands/critique.md` for full implementation.
### Phase 4: Consensus Synthesis
```javascript
const synthesis = {
convergent_themes: [],
divergent_views: [],
action_items: [],
open_questions: [],
decisions: [],
risk_flags: [],
overall_sentiment: '', // positive/neutral/concerns/critical
consensus_reached: true // false if major unresolvable conflicts
}
// Extract convergent themes (items mentioned positively by 2+ perspectives)
// Extract divergent views (items where perspectives conflict)
// Check coverage gaps from coverage perspective (if present)
const coverageResult = perspectiveResults.find(p => p.perspective === 'coverage')
if (coverageResult?.missing_requirements?.length > 0) {
synthesis.coverage_gaps = coverageResult.missing_requirements
synthesis.divergent_views.push({
topic: 'requirement_coverage_gap',
description: `${coverageResult.missing_requirements.length} requirements from discovery-context not covered: ${coverageResult.missing_requirements.join(', ')}`,
severity: 'high',
source: 'coverage'
})
}
// Check for unresolvable conflicts
const criticalDivergences = synthesis.divergent_views.filter(d => d.severity === 'high')
if (criticalDivergences.length > 0) synthesis.consensus_reached = false
// Determine overall sentiment from average rating
// Generate discussion record markdown with all perspectives, convergence, divergence, action items
Write(`${sessionFolder}/discussions/${config.outputFile}`, discussionRecord)
```
### Phase 5: Report to Coordinator
```javascript
if (synthesis.consensus_reached) {
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "discussant", to: "coordinator",
type: "discussion_ready",
summary: `[discussant] ${config.label}讨论完成: ${synthesis.action_items.length}个行动项, ${synthesis.open_questions.length}个开放问题, 总体${synthesis.overall_sentiment}`,
ref: `${sessionFolder}/discussions/${config.outputFile}`
})
SendMessage({
type: "message",
recipient: "coordinator",
content: `[discussant] ## 讨论结果: ${config.label}
**Task**: ${task.subject}
**共识**: 已达成
**总体评价**: ${synthesis.overall_sentiment}
### 行动项 (${synthesis.action_items.length})
${synthesis.action_items.map((item, i) => (i+1) + '. ' + item).join('\n') || '无'}
### 开放问题 (${synthesis.open_questions.length})
${synthesis.open_questions.map((q, i) => (i+1) + '. ' + q).join('\n') || '无'}
### 讨论记录
${sessionFolder}/discussions/${config.outputFile}
共识已达成,可推进至下一阶段。`,
summary: `[discussant] ${config.label}共识达成: ${synthesis.action_items.length}行动项`
})
TaskUpdate({ taskId: task.id, status: 'completed' })
} else {
// Consensus blocked - escalate to coordinator
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "discussant", to: "coordinator",
type: "discussion_blocked",
summary: `[discussant] ${config.label}讨论阻塞: ${criticalDivergences.length}个关键分歧需决策`,
data: {
reason: criticalDivergences.map(d => d.description).join('; '),
options: criticalDivergences.map(d => ({ label: d.topic, description: d.options?.join(' vs ') || d.description }))
}
})
SendMessage({
type: "message",
recipient: "coordinator",
content: `[discussant] ## 讨论阻塞: ${config.label}
**Task**: ${task.subject}
**状态**: 无法达成共识,需要 coordinator 介入
### 关键分歧
${criticalDivergences.map((d, i) => (i+1) + '. **' + d.topic + '**: ' + d.description).join('\n\n')}
请通过 AskUserQuestion 收集用户对分歧点的决策。`,
summary: `[discussant] ${config.label}阻塞: ${criticalDivergences.length}分歧`
})
// Keep task in_progress, wait for coordinator resolution
}
// Check for next DISCUSS task → back to Phase 1
```
## Error Handling
| Scenario | Resolution |
|----------|------------|
| No DISCUSS-* tasks available | Idle, wait for coordinator assignment |
| Target artifact not found | Notify coordinator with `[discussant]` tag, request prerequisite completion |
| CLI perspective analysis failure | Fallback to direct Claude analysis for that perspective |
| All CLI analyses fail | Generate basic discussion from direct reading |
| Consensus timeout (all perspectives diverge) | Escalate as discussion_blocked with `[discussant]` tag |
| Prior discussion records missing | Continue without continuity context |
| Session folder not found | Notify coordinator with `[discussant]` tag, request session path |
| Unexpected error | Log error via team_msg with `[discussant]` tag, report to coordinator |

View File

@@ -0,0 +1,356 @@
# Implement Command
## Purpose
Multi-backend code implementation with progress tracking and batch execution support.
## Execution Paths
### Path 1: Simple Task + Agent Backend (Direct Edit)
**Criteria**:
```javascript
function isSimpleTask(task) {
return task.description.length < 200 &&
!task.description.includes("refactor") &&
!task.description.includes("architecture") &&
!task.description.includes("multiple files")
}
```
**Execution**:
```javascript
if (isSimpleTask(task) && executor === "agent") {
// Direct file edit without subagent overhead
const targetFile = task.metadata?.target_file
if (targetFile) {
const content = Read(targetFile)
const prompt = buildExecutionPrompt(task, plan, [task])
// Apply edit directly
Edit(targetFile, oldContent, newContent)
return {
success: true,
files_modified: [targetFile],
method: "direct_edit"
}
}
}
```
### Path 2: Agent Backend (code-developer subagent)
**Execution**:
```javascript
if (executor === "agent") {
const prompt = buildExecutionPrompt(task, plan, [task])
const result = Subagent({
type: "code-developer",
prompt: prompt,
run_in_background: false // Synchronous execution
})
return {
success: result.success,
files_modified: result.files_modified || [],
method: "subagent"
}
}
```
### Path 3: Codex Backend (CLI)
**Execution**:
```javascript
if (executor === "codex") {
const prompt = buildExecutionPrompt(task, plan, [task])
team_msg({
to: "coordinator",
type: "progress_update",
task_id: task.task_id,
status: "executing_codex",
message: "Starting Codex implementation..."
}, "[executor]")
const result = Bash(
`ccw cli -p "${escapePrompt(prompt)}" --tool codex --mode write --cd ${task.metadata?.working_dir || "."}`,
{ run_in_background: true, timeout: 300000 }
)
// Wait for CLI completion via hook callback
return {
success: true,
files_modified: [], // Will be detected by git diff
method: "codex_cli"
}
}
```
### Path 4: Gemini Backend (CLI)
**Execution**:
```javascript
if (executor === "gemini") {
const prompt = buildExecutionPrompt(task, plan, [task])
team_msg({
to: "coordinator",
type: "progress_update",
task_id: task.task_id,
status: "executing_gemini",
message: "Starting Gemini implementation..."
}, "[executor]")
const result = Bash(
`ccw cli -p "${escapePrompt(prompt)}" --tool gemini --mode write --cd ${task.metadata?.working_dir || "."}`,
{ run_in_background: true, timeout: 300000 }
)
// Wait for CLI completion via hook callback
return {
success: true,
files_modified: [], // Will be detected by git diff
method: "gemini_cli"
}
}
```
## Prompt Building
### Single Task Prompt
```javascript
function buildExecutionPrompt(task, plan, tasks) {
const context = extractContextFromPlan(plan, task)
return `
# Implementation Task: ${task.task_id}
## Task Description
${task.description}
## Acceptance Criteria
${task.acceptance_criteria?.map((c, i) => `${i + 1}. ${c}`).join("\n") || "None specified"}
## Context from Plan
${context}
## Files to Modify
${task.metadata?.target_files?.join("\n") || "Auto-detect based on task"}
## Constraints
- Follow existing code style and patterns
- Preserve backward compatibility
- Add appropriate error handling
- Include inline comments for complex logic
- Update related tests if applicable
## Expected Output
- Modified files with implementation
- Brief summary of changes made
- Any assumptions or decisions made during implementation
`.trim()
}
```
### Batch Task Prompt
```javascript
function buildBatchPrompt(tasks, plan) {
const taskDescriptions = tasks.map((task, i) => `
### Task ${i + 1}: ${task.task_id}
**Description**: ${task.description}
**Acceptance Criteria**:
${task.acceptance_criteria?.map((c, j) => ` ${j + 1}. ${c}`).join("\n") || " None specified"}
**Target Files**: ${task.metadata?.target_files?.join(", ") || "Auto-detect"}
`).join("\n")
return `
# Batch Implementation: ${tasks.length} Tasks
## Tasks to Implement
${taskDescriptions}
## Context from Plan
${extractContextFromPlan(plan, tasks[0])}
## Batch Execution Guidelines
- Implement tasks in the order listed
- Ensure each task's acceptance criteria are met
- Maintain consistency across all implementations
- Report any conflicts or dependencies discovered
- Follow existing code patterns and style
## Expected Output
- All tasks implemented successfully
- Summary of changes per task
- Any cross-task considerations or conflicts
`.trim()
}
```
### Context Extraction
```javascript
function extractContextFromPlan(plan, task) {
// Extract relevant sections from plan
const sections = []
// Architecture context
const archMatch = plan.match(/## Architecture[\s\S]*?(?=##|$)/)
if (archMatch) {
sections.push("### Architecture\n" + archMatch[0])
}
// Technical stack
const techMatch = plan.match(/## Technical Stack[\s\S]*?(?=##|$)/)
if (techMatch) {
sections.push("### Technical Stack\n" + techMatch[0])
}
// Related tasks context
const taskSection = plan.match(new RegExp(`${task.task_id}[\\s\\S]*?(?=IMPL-\\d+|$)`))
if (taskSection) {
sections.push("### Task Context\n" + taskSection[0])
}
return sections.join("\n\n") || "No additional context available"
}
```
## Progress Tracking
### Batch Progress Updates
```javascript
function reportBatchProgress(batchIndex, totalBatches, currentTask) {
if (totalBatches > 1) {
team_msg({
to: "coordinator",
type: "progress_update",
batch_index: batchIndex + 1,
total_batches: totalBatches,
current_task: currentTask.task_id,
message: `Processing batch ${batchIndex + 1}/${totalBatches}: ${currentTask.task_id}`
}, "[executor]")
}
}
```
### Long-Running Task Updates
```javascript
function reportLongRunningTask(task, elapsedSeconds) {
if (elapsedSeconds > 60 && elapsedSeconds % 30 === 0) {
team_msg({
to: "coordinator",
type: "progress_update",
task_id: task.task_id,
elapsed_seconds: elapsedSeconds,
message: `Still processing ${task.task_id} (${elapsedSeconds}s elapsed)...`
}, "[executor]")
}
}
```
## Utility Functions
### Prompt Escaping
```javascript
function escapePrompt(prompt) {
return prompt
.replace(/\\/g, "\\\\")
.replace(/"/g, '\\"')
.replace(/\n/g, "\\n")
.replace(/\$/g, "\\$")
}
```
### File Change Detection
```javascript
function detectModifiedFiles() {
const gitDiff = Bash("git diff --name-only HEAD")
return gitDiff.stdout.split("\n").filter(f => f.trim())
}
```
### Simple Task Detection
```javascript
function isSimpleTask(task) {
const simpleIndicators = [
task.description.length < 200,
!task.description.toLowerCase().includes("refactor"),
!task.description.toLowerCase().includes("architecture"),
!task.description.toLowerCase().includes("multiple files"),
!task.description.toLowerCase().includes("complex"),
task.metadata?.target_files?.length === 1
]
return simpleIndicators.filter(Boolean).length >= 4
}
```
## Error Recovery
### Retry Logic
```javascript
function executeWithRetry(task, executor, maxRetries = 3) {
let attempt = 0
let lastError = null
while (attempt < maxRetries) {
try {
const result = executeTask(task, executor)
if (result.success) {
return result
}
lastError = result.error
} catch (error) {
lastError = error.message
}
attempt++
if (attempt < maxRetries) {
team_msg({
to: "coordinator",
type: "progress_update",
task_id: task.task_id,
message: `Retry attempt ${attempt}/${maxRetries} after error: ${lastError}`
}, "[executor]")
}
}
return {
success: false,
error: lastError,
retry_count: maxRetries
}
}
```
### Backend Fallback
```javascript
function executeWithFallback(task, primaryExecutor) {
const result = executeTask(task, primaryExecutor)
if (!result.success && primaryExecutor !== "agent") {
team_msg({
to: "coordinator",
type: "progress_update",
task_id: task.task_id,
message: `${primaryExecutor} failed, falling back to agent backend...`
}, "[executor]")
return executeTask(task, "agent")
}
return result
}
```

View File

@@ -0,0 +1,324 @@
# Executor Role
## 1. Role Identity
- **Name**: executor
- **Task Prefix**: IMPL-*
- **Output Tag**: `[executor]`
- **Responsibility**: Load plan → Route to backend → Implement code → Self-validate → Report
## 2. Role Boundaries
### MUST
- Only process IMPL-* tasks
- Follow approved plan exactly
- Use declared execution backends (agent/codex/gemini)
- Self-validate all implementations (syntax + acceptance criteria)
- Tag all outputs with `[executor]`
### MUST NOT
- Create tasks
- Contact other workers directly
- Modify plan files
- Skip self-validation
- Proceed without plan approval
## 3. Message Types
| Type | Direction | Purpose | Format |
|------|-----------|---------|--------|
| `task_request` | FROM coordinator | Receive IMPL-* task assignment | `{ type: "task_request", task_id, description }` |
| `task_complete` | TO coordinator | Report implementation success | `{ type: "task_complete", task_id, status: "success", files_modified, validation_results }` |
| `task_failed` | TO coordinator | Report implementation failure | `{ type: "task_failed", task_id, error, retry_count }` |
| `progress_update` | TO coordinator | Report batch progress | `{ type: "progress_update", task_id, batch_index, total_batches }` |
## 4. Message Bus
**Primary**: Use `team_msg` for all coordinator communication with `[executor]` tag:
```javascript
team_msg({
to: "coordinator",
type: "task_complete",
task_id: "IMPL-001",
status: "success",
files_modified: ["src/auth.ts"],
validation_results: { syntax: "pass", acceptance: "pass" }
}, "[executor]")
```
**CLI Fallback**: When message bus unavailable, write to `.workflow/.team/messages/executor-{timestamp}.json`
## 5. Toolbox
### Available Commands
- `commands/implement.md` - Multi-backend code implementation with progress tracking
### Subagent Capabilities
- `code-developer` - Synchronous agent execution for simple tasks and agent backend
### CLI Capabilities
- `ccw cli --tool codex --mode write` - Codex backend implementation
- `ccw cli --tool gemini --mode write` - Gemini backend implementation
## 6. Execution (5-Phase)
### Phase 1: Task & Plan Loading
**Task Discovery**:
```javascript
const tasks = Glob(".workflow/.team/tasks/IMPL-*.json")
.filter(task => task.status === "pending" && task.assigned_to === "executor")
```
**Plan Path Extraction**:
```javascript
const planPath = task.metadata?.plan_path || ".workflow/plan.md"
const plan = Read(planPath)
```
**Execution Backend Resolution**:
```javascript
function resolveExecutor(task, plan) {
// Priority 1: Task-level override
if (task.metadata?.executor) {
return task.metadata.executor // "agent" | "codex" | "gemini"
}
// Priority 2: Plan-level default
const planMatch = plan.match(/Execution Backend:\s*(agent|codex|gemini)/i)
if (planMatch) {
return planMatch[1].toLowerCase()
}
// Priority 3: Auto-select based on task complexity
const isSimple = task.description.length < 200 &&
!task.description.includes("refactor") &&
!task.description.includes("architecture")
return isSimple ? "agent" : "codex" // Default: codex for complex, agent for simple
}
```
**Code Review Resolution**:
```javascript
function resolveCodeReview(task, plan) {
// Priority 1: Task-level override
if (task.metadata?.code_review !== undefined) {
return task.metadata.code_review // boolean
}
// Priority 2: Plan-level default
const reviewMatch = plan.match(/Code Review:\s*(enabled|disabled)/i)
if (reviewMatch) {
return reviewMatch[1].toLowerCase() === "enabled"
}
// Priority 3: Default based on task type
const criticalKeywords = ["auth", "security", "payment", "api", "database"]
const isCritical = criticalKeywords.some(kw =>
task.description.toLowerCase().includes(kw)
)
return isCritical // Enable review for critical paths
}
```
### Phase 2: Task Grouping
**Dependency-Based Batching**:
```javascript
function createBatches(tasks, plan) {
// Extract dependencies from plan
const dependencies = new Map()
const depRegex = /IMPL-(\d+).*depends on.*IMPL-(\d+)/gi
let match
while ((match = depRegex.exec(plan)) !== null) {
const [_, taskId, depId] = match
if (!dependencies.has(`IMPL-${taskId}`)) {
dependencies.set(`IMPL-${taskId}`, [])
}
dependencies.get(`IMPL-${taskId}`).push(`IMPL-${depId}`)
}
// Topological sort for execution order
const batches = []
const completed = new Set()
const remaining = new Set(tasks.map(t => t.task_id))
while (remaining.size > 0) {
const batch = []
for (const taskId of remaining) {
const deps = dependencies.get(taskId) || []
const depsCompleted = deps.every(dep => completed.has(dep))
if (depsCompleted) {
batch.push(tasks.find(t => t.task_id === taskId))
}
}
if (batch.length === 0) {
// Circular dependency detected
throw new Error(`Circular dependency detected in remaining tasks: ${[...remaining].join(", ")}`)
}
batches.push(batch)
batch.forEach(task => {
completed.add(task.task_id)
remaining.delete(task.task_id)
})
}
return batches
}
```
### Phase 3: Code Implementation
**Delegate to Command**:
```javascript
const implementCommand = Read("commands/implement.md")
// Command handles:
// - buildExecutionPrompt (context + acceptance criteria)
// - buildBatchPrompt (multi-task batching)
// - 4 execution paths: simple+agent, agent, codex, gemini
// - Progress updates via team_msg
```
### Phase 4: Self-Validation
**Syntax Check**:
```javascript
const syntaxCheck = Bash("tsc --noEmit", { timeout: 30000 })
const syntaxPass = syntaxCheck.exitCode === 0
```
**Acceptance Criteria Verification**:
```javascript
function verifyAcceptance(task, implementation) {
const criteria = task.acceptance_criteria || []
const results = criteria.map(criterion => {
// Simple keyword matching for automated verification
const keywords = criterion.toLowerCase().match(/\b\w+\b/g) || []
const matched = keywords.some(kw =>
implementation.toLowerCase().includes(kw)
)
return { criterion, matched, status: matched ? "pass" : "manual_review" }
})
const allPassed = results.every(r => r.status === "pass")
return { allPassed, results }
}
```
**Test File Detection**:
```javascript
function findAffectedTests(modifiedFiles) {
const testFiles = []
for (const file of modifiedFiles) {
const baseName = file.replace(/\.(ts|js|tsx|jsx)$/, "")
const testVariants = [
`${baseName}.test.ts`,
`${baseName}.test.js`,
`${baseName}.spec.ts`,
`${baseName}.spec.js`,
`${file.replace(/^src\//, "tests/")}.test.ts`,
`${file.replace(/^src\//, "__tests__/")}.test.ts`
]
for (const variant of testVariants) {
if (Bash(`test -f ${variant}`).exitCode === 0) {
testFiles.push(variant)
}
}
}
return testFiles
}
```
**Optional Code Review**:
```javascript
const codeReviewEnabled = resolveCodeReview(task, plan)
if (codeReviewEnabled) {
const executor = resolveExecutor(task, plan)
if (executor === "gemini") {
// Gemini Review: Use Gemini CLI for review
const reviewResult = Bash(
`ccw cli -p "Review implementation for: ${task.description}. Check: code quality, security, architecture compliance." --tool gemini --mode analysis`,
{ run_in_background: true }
)
} else if (executor === "codex") {
// Codex Review: Use Codex CLI review mode
const reviewResult = Bash(
`ccw cli --tool codex --mode review --uncommitted`,
{ run_in_background: true }
)
}
// Wait for review results and append to validation
}
```
### Phase 5: Report to Coordinator
**Success Report**:
```javascript
team_msg({
to: "coordinator",
type: "task_complete",
task_id: task.task_id,
status: "success",
files_modified: modifiedFiles,
validation_results: {
syntax: syntaxPass ? "pass" : "fail",
acceptance: acceptanceResults.allPassed ? "pass" : "manual_review",
tests_found: affectedTests.length,
code_review: codeReviewEnabled ? "completed" : "skipped"
},
execution_backend: executor,
timestamp: new Date().toISOString()
}, "[executor]")
```
**Failure Report**:
```javascript
team_msg({
to: "coordinator",
type: "task_failed",
task_id: task.task_id,
error: errorMessage,
retry_count: task.retry_count || 0,
validation_results: {
syntax: syntaxPass ? "pass" : "fail",
acceptance: "not_verified"
},
timestamp: new Date().toISOString()
}, "[executor]")
```
## 7. Error Handling
| Error Type | Recovery Strategy | Escalation |
|------------|-------------------|------------|
| Syntax errors | Retry with error context (max 3 attempts) | Report to coordinator after 3 failures |
| Missing dependencies | Request dependency resolution from coordinator | Immediate escalation |
| Backend unavailable | Fallback to agent backend | Report backend switch |
| Validation failure | Include validation details in report | Manual review required |
| Circular dependencies | Abort batch, report dependency graph | Immediate escalation |
## 8. Execution Backends
| Backend | Tool | Invocation | Mode | Use Case |
|---------|------|------------|------|----------|
| **agent** | code-developer | Subagent call (synchronous) | N/A | Simple tasks, direct edits |
| **codex** | ccw cli | `ccw cli --tool codex --mode write` | write | Complex tasks, architecture changes |
| **gemini** | ccw cli | `ccw cli --tool gemini --mode write` | write | Alternative backend, analysis-heavy tasks |
**Backend Selection Logic**:
1. Task metadata override → Use specified backend
2. Plan default → Use plan-level backend
3. Auto-select → Simple tasks use agent, complex use codex

View File

@@ -0,0 +1,301 @@
# Explorer Role
专职代码搜索与模式发现。服务角色,被 analyst/planner/executor/discussant 按需调用。
## 1. Role Identity
- **Name**: explorer
- **Task Prefix**: EXPLORE-*
- **Output Tag**: `[explorer]`
- **Role Type**: Service按需调用不占主链路位置
- **Responsibility**: Parse request → Multi-strategy search → Dependency trace → Package results → Report
## 2. Role Boundaries
### MUST
- Only process EXPLORE-* tasks
- Output structured JSON for downstream consumption
- Use priority-ordered search strategies (ACE → Grep → cli-explore-agent)
- Tag all outputs with `[explorer]`
- Cache results in `{session}/explorations/` for cross-role reuse
### MUST NOT
- Create tasks
- Contact other workers directly
- Modify any source code files
- Execute analysis, planning, or implementation
- Make architectural decisions (only discover patterns)
## 3. Message Types
| Type | Direction | Purpose | Format |
|------|-----------|---------|--------|
| `explore_ready` | TO coordinator | Search complete | `{ type: "explore_ready", task_id, file_count, pattern_count, output_path }` |
| `explore_progress` | TO coordinator | Multi-angle progress | `{ type: "explore_progress", task_id, angle, status }` |
| `task_failed` | TO coordinator | Search failure | `{ type: "task_failed", task_id, error, fallback_used }` |
## 4. Message Bus
**Primary**: Use `team_msg` for all coordinator communication with `[explorer]` tag:
```javascript
team_msg({
to: "coordinator",
type: "explore_ready",
task_id: "EXPLORE-001",
file_count: 15,
pattern_count: 3,
output_path: `${sessionFolder}/explorations/explore-001.json`
}, "[explorer]")
```
**CLI Fallback**: When message bus unavailable:
```bash
ccw team log --team "${teamName}" --from "explorer" --to "coordinator" --type "explore_ready" --summary "[explorer] 15 files, 3 patterns" --json
```
## 5. Toolbox
### Available Commands
- None (inline execution, search logic is straightforward)
### Search Tools (priority order)
| Tool | Priority | Use Case |
|------|----------|----------|
| `mcp__ace-tool__search_context` | P0 | Semantic code search |
| `Grep` / `Glob` | P1 | Pattern matching, file discovery |
| `Read` | P1 | File content reading |
| `Bash` (rg, find) | P2 | Structured search fallback |
| `WebSearch` | P3 | External docs/best practices |
### Subagent Capabilities
- `cli-explore-agent` — Deep multi-angle codebase exploration
## 6. Execution (5-Phase)
### Phase 1: Task Discovery & Request Parsing
```javascript
const tasks = TaskList()
const myTasks = tasks.filter(t =>
t.subject.startsWith('EXPLORE-') &&
t.owner === 'explorer' &&
t.status === 'pending' &&
t.blockedBy.length === 0
)
if (myTasks.length === 0) return
const task = TaskGet({ taskId: myTasks[0].id })
TaskUpdate({ taskId: task.id, status: 'in_progress' })
// Parse structured request from task description
const sessionFolder = task.description.match(/Session:\s*([^\n]+)/)?.[1]?.trim()
const exploreMode = task.description.match(/Mode:\s*([^\n]+)/)?.[1]?.trim() || 'codebase'
const angles = (task.description.match(/Angles:\s*([^\n]+)/)?.[1] || 'general').split(',').map(a => a.trim())
const keywords = (task.description.match(/Keywords:\s*([^\n]+)/)?.[1] || '').split(',').map(k => k.trim()).filter(Boolean)
const requester = task.description.match(/Requester:\s*([^\n]+)/)?.[1]?.trim() || 'coordinator'
const outputDir = sessionFolder ? `${sessionFolder}/explorations` : '.workflow/.tmp'
Bash(`mkdir -p "${outputDir}"`)
```
### Phase 2: Multi-Strategy Search
```javascript
const findings = {
relevant_files: [], // { path, rationale, role, discovery_source, key_symbols }
patterns: [], // { name, description, files }
dependencies: [], // { file, imports[] }
external_refs: [], // { keyword, results[] }
_metadata: { angles, mode: exploreMode, requester, timestamp: new Date().toISOString() }
}
// === Strategy 1: ACE Semantic Search (P0) ===
if (exploreMode !== 'external') {
for (const kw of keywords) {
try {
const results = mcp__ace-tool__search_context({ project_root_path: '.', query: kw })
// Deduplicate and add to findings.relevant_files with discovery_source: 'ace-search'
} catch { /* ACE unavailable, fall through */ }
}
}
// === Strategy 2: Grep Pattern Scan (P1) ===
if (exploreMode !== 'external') {
for (const kw of keywords) {
// Find imports/exports/definitions
const defResults = Grep({
pattern: `(class|function|const|export|interface|type)\\s+.*${kw}`,
glob: '*.{ts,tsx,js,jsx,py,go,rs}',
'-n': true, output_mode: 'content'
})
// Add to findings with discovery_source: 'grep-scan'
}
}
// === Strategy 3: Dependency Tracing ===
if (exploreMode !== 'external') {
for (const file of findings.relevant_files.slice(0, 10)) {
try {
const content = Read(file.path)
const imports = (content.match(/from\s+['"]([^'"]+)['"]/g) || [])
.map(i => i.match(/['"]([^'"]+)['"]/)?.[1]).filter(Boolean)
if (imports.length > 0) {
findings.dependencies.push({ file: file.path, imports })
}
} catch {}
}
}
// === Strategy 4: Deep Exploration (multi-angle, via cli-explore-agent) ===
if (angles.length > 1 && exploreMode !== 'external') {
for (const angle of angles) {
Task({
subagent_type: "cli-explore-agent",
run_in_background: false,
description: `Explore: ${angle}`,
prompt: `## Exploration: ${angle} angle
Keywords: ${keywords.join(', ')}
## Steps
1. rg -l "${keywords[0]}" --type-add 'code:*.{ts,tsx,js,py,go,rs}' --type code
2. Read .workflow/project-tech.json (if exists)
3. Focus on ${angle} perspective
## Output
Write to: ${outputDir}/exploration-${angle}.json
Schema: { relevant_files[], patterns[], dependencies[] }`
})
// Merge angle results into main findings
try {
const angleData = JSON.parse(Read(`${outputDir}/exploration-${angle}.json`))
findings.relevant_files.push(...(angleData.relevant_files || []))
findings.patterns.push(...(angleData.patterns || []))
} catch {}
}
}
// === Strategy 5: External Search (P3) ===
if (exploreMode === 'external' || exploreMode === 'hybrid') {
for (const kw of keywords.slice(0, 3)) {
try {
const results = WebSearch({ query: `${kw} best practices documentation` })
findings.external_refs.push({ keyword: kw, results })
} catch {}
}
}
// Deduplicate relevant_files by path
const seen = new Set()
findings.relevant_files = findings.relevant_files.filter(f => {
if (seen.has(f.path)) return false
seen.add(f.path)
return true
})
```
### Phase 3: Wisdom Contribution
```javascript
// If wisdom directory exists, contribute discovered patterns
if (sessionFolder) {
try {
const conventionsPath = `${sessionFolder}/wisdom/conventions.md`
const existing = Read(conventionsPath)
if (findings.patterns.length > 0) {
const newPatterns = findings.patterns
.map(p => `- ${p.name}: ${p.description || ''}`)
.join('\n')
Edit({
file_path: conventionsPath,
old_string: '<!-- explorer-patterns -->',
new_string: `<!-- explorer-patterns -->\n${newPatterns}`
})
}
} catch {} // wisdom not initialized
}
```
### Phase 4: Package Results
```javascript
const outputPath = `${outputDir}/explore-${task.subject.replace(/[^a-zA-Z0-9-]/g, '-').toLowerCase()}.json`
Write(outputPath, JSON.stringify(findings, null, 2))
```
### Phase 5: Report to Coordinator
```javascript
const summary = `${findings.relevant_files.length} files, ${findings.patterns.length} patterns, ${findings.dependencies.length} deps`
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "explorer", to: "coordinator",
type: "explore_ready",
summary: `[explorer] EXPLORE complete: ${summary}`,
ref: outputPath
})
SendMessage({
type: "message",
recipient: "coordinator",
content: `[explorer] ## Exploration Results
**Task**: ${task.subject}
**Mode**: ${exploreMode} | **Angles**: ${angles.join(', ')} | **Requester**: ${requester}
### Files: ${findings.relevant_files.length}
${findings.relevant_files.slice(0, 8).map(f => `- \`${f.path}\` (${f.role}) — ${f.rationale}`).join('\n')}
### Patterns: ${findings.patterns.length}
${findings.patterns.slice(0, 5).map(p => `- ${p.name}: ${p.description || ''}`).join('\n') || 'None'}
### Output: ${outputPath}`,
summary: `[explorer] ${summary}`
})
TaskUpdate({ taskId: task.id, status: 'completed' })
// Check for next EXPLORE task → back to Phase 1
```
## 7. Coordinator Integration
Explorer 是服务角色coordinator 在以下场景按需创建 EXPLORE-* 任务:
| Trigger | Task Example | Requester |
|---------|-------------|-----------|
| RESEARCH-001 需要代码库上下文 | `EXPLORE-001: 代码库上下文搜索` | analyst |
| PLAN-001 需要多角度探索 | `EXPLORE-002: 实现相关代码探索` | planner |
| DISCUSS-004 需要外部最佳实践 | `EXPLORE-003: 外部文档搜索` | discussant |
| IMPL-001 遇到未知代码 | `EXPLORE-004: 依赖追踪` | executor |
**Task Description Template**:
```
搜索描述
Session: {sessionFolder}
Mode: codebase|external|hybrid
Angles: architecture,patterns,dependencies
Keywords: auth,middleware,session
Requester: analyst
```
## 8. Result Caching
```
{sessionFolder}/explorations/
├── explore-explore-001-*.json # Consolidated results
├── exploration-architecture.json # Angle-specific (from cli-explore-agent)
└── exploration-patterns.json
```
后续角色 Phase 2 可直接读取已有探索结果,避免重复搜索。
## 9. Error Handling
| Error Type | Recovery Strategy | Escalation |
|------------|-------------------|------------|
| ACE unavailable | Fallback to Grep + rg | Continue with degraded results |
| cli-explore-agent failure | Fallback to direct search | Report partial results |
| No results found | Report empty, suggest broader keywords | Coordinator decides |
| Web search fails | Skip external refs | Continue with codebase results |
| Session folder missing | Use .workflow/.tmp | Notify coordinator |

View File

@@ -0,0 +1,410 @@
# Role: fe-developer
前端开发。消费计划/架构产出,实现前端组件、页面、样式代码。
## Role Identity
- **Name**: `fe-developer`
- **Task Prefix**: `DEV-FE-*`
- **Output Tag**: `[fe-developer]`
- **Role Type**: Pipeline前端子流水线 worker
- **Responsibility**: Context loading → Design token consumption → Component implementation → Report
## Role Boundaries
### MUST
- 仅处理 `DEV-FE-*` 前缀的任务
- 所有输出带 `[fe-developer]` 标识
- 仅通过 SendMessage 与 coordinator 通信
- 遵循已有设计令牌和组件规范(如存在)
- 生成可访问性合规的前端代码(语义 HTML、ARIA 属性、键盘导航)
- 遵循项目已有的前端技术栈和约定
### MUST NOT
- ❌ 修改后端代码或 API 接口
- ❌ 直接与其他 worker 通信
- ❌ 为其他角色创建任务
- ❌ 跳过设计令牌/规范检查(如存在)
- ❌ 引入未经架构审查的新前端依赖
## Message Types
| Type | Direction | Trigger | Description |
|------|-----------|---------|-------------|
| `dev_fe_complete` | fe-developer → coordinator | Implementation done | 前端实现完成 |
| `dev_fe_progress` | fe-developer → coordinator | Long task progress | 进度更新 |
| `error` | fe-developer → coordinator | Implementation failure | 实现失败 |
## Message Bus
每次 SendMessage **前**,必须调用 `mcp__ccw-tools__team_msg` 记录:
```javascript
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "fe-developer", to: "coordinator",
type: "dev_fe_complete",
summary: "[fe-developer] DEV-FE complete: 3 components, 1 page",
ref: outputPath
})
```
### CLI 回退
```javascript
Bash(`ccw team log --team "${teamName}" --from "fe-developer" --to "coordinator" --type "dev_fe_complete" --summary "[fe-developer] DEV-FE complete" --ref "${outputPath}" --json`)
```
## Toolbox
### Available Commands
- None (inline execution — implementation delegated to subagent)
### Subagent Capabilities
| Agent Type | Purpose |
|------------|---------|
| `code-developer` | 组件/页面代码实现 |
### CLI Capabilities
| CLI Tool | Mode | Purpose |
|----------|------|---------|
| `ccw cli --tool gemini --mode write` | write | 前端代码生成 |
## Execution (5-Phase)
### Phase 1: Task Discovery
```javascript
const tasks = TaskList()
const myTasks = tasks.filter(t =>
t.subject.startsWith('DEV-FE-') &&
t.owner === 'fe-developer' &&
t.status === 'pending' &&
t.blockedBy.length === 0
)
if (myTasks.length === 0) return
const task = TaskGet({ taskId: myTasks[0].id })
TaskUpdate({ taskId: task.id, status: 'in_progress' })
```
### Phase 2: Context Loading
```javascript
const sessionFolder = task.description.match(/Session:\s*([^\n]+)/)?.[1]?.trim()
// Load plan context
let plan = null
try { plan = JSON.parse(Read(`${sessionFolder}/plan/plan.json`)) } catch {}
// Load design tokens (if architect produced them)
let designTokens = null
try { designTokens = JSON.parse(Read(`${sessionFolder}/architecture/design-tokens.json`)) } catch {}
// Load design intelligence (from analyst via ui-ux-pro-max)
let designIntel = {}
try { designIntel = JSON.parse(Read(`${sessionFolder}/analysis/design-intelligence.json`)) } catch {}
// Load component specs (if available)
let componentSpecs = []
try {
const specFiles = Glob({ pattern: `${sessionFolder}/architecture/component-specs/*.md` })
componentSpecs = specFiles.map(f => ({ path: f, content: Read(f) }))
} catch {}
// Load shared memory (cross-role state)
let sharedMemory = {}
try { sharedMemory = JSON.parse(Read(`${sessionFolder}/shared-memory.json`)) } catch {}
// Load wisdom
let wisdom = {}
if (sessionFolder) {
try { wisdom.conventions = Read(`${sessionFolder}/wisdom/conventions.md`) } catch {}
try { wisdom.decisions = Read(`${sessionFolder}/wisdom/decisions.md`) } catch {}
}
// Extract design constraints from design intelligence
const antiPatterns = designIntel.recommendations?.anti_patterns || []
const implementationChecklist = designIntel.design_system?.implementation_checklist || []
const stackGuidelines = designIntel.stack_guidelines || {}
// Detect frontend tech stack
let techStack = {}
try { techStack = JSON.parse(Read('.workflow/project-tech.json')) } catch {}
const feTech = detectFrontendStack(techStack)
// Override with design intelligence detection if available
if (designIntel.detected_stack) {
const diStack = designIntel.detected_stack
if (['react', 'nextjs', 'vue', 'svelte', 'nuxt'].includes(diStack)) feTech.framework = diStack
}
function detectFrontendStack(tech) {
const deps = tech?.dependencies || {}
const stack = { framework: 'html', styling: 'css', ui_lib: null }
if (deps.react || deps['react-dom']) stack.framework = 'react'
if (deps.vue) stack.framework = 'vue'
if (deps.svelte) stack.framework = 'svelte'
if (deps.next) stack.framework = 'nextjs'
if (deps.nuxt) stack.framework = 'nuxt'
if (deps.tailwindcss) stack.styling = 'tailwind'
if (deps['@shadcn/ui'] || deps['shadcn-ui']) stack.ui_lib = 'shadcn'
if (deps['@mui/material']) stack.ui_lib = 'mui'
if (deps['antd']) stack.ui_lib = 'antd'
return stack
}
```
### Phase 3: Frontend Implementation
#### Step 1: Generate Design Token CSS (if tokens available)
```javascript
if (designTokens && task.description.includes('Scope: tokens') || task.description.includes('Scope: full')) {
// Convert design-tokens.json to CSS custom properties
let cssVars = ':root {\n'
// Colors
if (designTokens.color) {
for (const [name, token] of Object.entries(designTokens.color)) {
const value = typeof token.$value === 'object' ? token.$value.light : token.$value
cssVars += ` --color-${name}: ${value};\n`
}
}
// Typography
if (designTokens.typography?.['font-family']) {
for (const [name, token] of Object.entries(designTokens.typography['font-family'])) {
const value = Array.isArray(token.$value) ? token.$value.join(', ') : token.$value
cssVars += ` --font-${name}: ${value};\n`
}
}
if (designTokens.typography?.['font-size']) {
for (const [name, token] of Object.entries(designTokens.typography['font-size'])) {
cssVars += ` --text-${name}: ${token.$value};\n`
}
}
// Spacing, border-radius, shadow, transition
for (const category of ['spacing', 'border-radius', 'shadow', 'transition']) {
const prefix = { spacing: 'space', 'border-radius': 'radius', shadow: 'shadow', transition: 'duration' }[category]
if (designTokens[category]) {
for (const [name, token] of Object.entries(designTokens[category])) {
cssVars += ` --${prefix}-${name}: ${token.$value};\n`
}
}
}
cssVars += '}\n'
// Dark mode overrides
if (designTokens.color) {
const darkOverrides = Object.entries(designTokens.color)
.filter(([, token]) => typeof token.$value === 'object' && token.$value.dark)
if (darkOverrides.length > 0) {
cssVars += '\n@media (prefers-color-scheme: dark) {\n :root {\n'
for (const [name, token] of darkOverrides) {
cssVars += ` --color-${name}: ${token.$value.dark};\n`
}
cssVars += ' }\n}\n'
}
}
Bash(`mkdir -p src/styles`)
Write('src/styles/tokens.css', cssVars)
}
```
#### Step 2: Implement Components
```javascript
const taskId = task.subject.match(/DEV-FE-(\d+)/)?.[0]
const taskDetail = plan?.task_ids?.includes(taskId)
? JSON.parse(Read(`${sessionFolder}/plan/.task/${taskId}.json`))
: { title: task.subject, description: task.description, files: [] }
const isSimple = (taskDetail.files || []).length <= 3 &&
!task.description.includes('system') &&
!task.description.includes('多组件')
if (isSimple) {
Task({
subagent_type: "code-developer",
run_in_background: false,
description: `Frontend implementation: ${taskDetail.title}`,
prompt: `## Frontend Implementation
Task: ${taskDetail.title}
Description: ${taskDetail.description}
${designTokens ? `## Design Tokens\nImport from: src/styles/tokens.css\nUse CSS custom properties (var(--color-primary), var(--space-md), etc.)\n${JSON.stringify(designTokens, null, 2).substring(0, 1000)}` : ''}
${componentSpecs.length > 0 ? `## Component Specs\n${componentSpecs.map(s => s.content.substring(0, 500)).join('\n---\n')}` : ''}
## Tech Stack
- Framework: ${feTech.framework}
- Styling: ${feTech.styling}
${feTech.ui_lib ? `- UI Library: ${feTech.ui_lib}` : ''}
## Stack-Specific Guidelines
${JSON.stringify(stackGuidelines, null, 2).substring(0, 500)}
## Implementation Checklist (MUST verify each item)
${implementationChecklist.map(item => `- [ ] ${item}`).join('\n') || '- [ ] Semantic HTML\n- [ ] Keyboard accessible\n- [ ] Responsive layout\n- [ ] Dark mode support'}
## Anti-Patterns to AVOID
${antiPatterns.map(p => `- ❌ ${p}`).join('\n') || 'None specified'}
## Coding Standards
- Use design token CSS variables, never hardcode colors/spacing
- All interactive elements must have cursor: pointer
- Transitions: 150-300ms (use var(--duration-normal))
- Text contrast: minimum 4.5:1 ratio
- Include focus-visible styles for keyboard navigation
- Support prefers-reduced-motion
- Responsive: mobile-first with md/lg breakpoints
- No emoji as functional icons
## Files to modify/create
${(taskDetail.files || []).map(f => `- ${f.path}: ${f.change}`).join('\n') || 'Determine from task description'}
## Conventions
${wisdom.conventions || 'Follow project existing patterns'}`
})
} else {
Bash({
command: `ccw cli -p "PURPOSE: Implement frontend components for '${taskDetail.title}'
TASK: ${taskDetail.description}
MODE: write
CONTEXT: @src/**/*.{tsx,jsx,vue,svelte,css,scss,html} @public/**/*
EXPECTED: Production-ready frontend code with accessibility, responsive design, design token usage
CONSTRAINTS: Framework=${feTech.framework}, Styling=${feTech.styling}${feTech.ui_lib ? ', UI=' + feTech.ui_lib : ''}
ANTI-PATTERNS: ${antiPatterns.join(', ') || 'None'}
CHECKLIST: ${implementationChecklist.join(', ') || 'Semantic HTML, keyboard accessible, responsive, dark mode'}" --tool gemini --mode write --rule development-implement-component-ui`,
run_in_background: true
})
}
```
### Phase 4: Self-Validation + Wisdom + Shared Memory
```javascript
// === Self-Validation (pre-QA check) ===
const implementedFiles = Glob({ pattern: 'src/**/*.{tsx,jsx,vue,svelte,html,css}' })
const selfCheck = { passed: [], failed: [] }
for (const file of implementedFiles.slice(0, 20)) {
try {
const content = Read(file)
// Check: no hardcoded colors (hex outside tokens.css)
if (file !== 'src/styles/tokens.css' && /#[0-9a-fA-F]{3,8}/.test(content)) {
selfCheck.failed.push({ file, check: 'hardcoded-color', message: 'Hardcoded color — use var(--color-*)' })
}
// Check: cursor-pointer on interactive elements
if (/button|<a |onClick|@click/.test(content) && !/cursor-pointer/.test(content)) {
selfCheck.failed.push({ file, check: 'cursor-pointer', message: 'Missing cursor-pointer on interactive element' })
}
// Check: focus styles
if (/button|input|select|textarea|<a /.test(content) && !/focus/.test(content)) {
selfCheck.failed.push({ file, check: 'focus-styles', message: 'Missing focus styles for keyboard navigation' })
}
// Check: responsive breakpoints
if (/className|class=/.test(content) && !/md:|lg:|@media/.test(content) && /\.(tsx|jsx|vue|html)$/.test(file)) {
selfCheck.failed.push({ file, check: 'responsive', message: 'No responsive breakpoints found' })
}
// Check: prefers-reduced-motion for animations
if (/animation|@keyframes/.test(content) && !/prefers-reduced-motion/.test(content)) {
selfCheck.failed.push({ file, check: 'reduced-motion', message: 'Animation without prefers-reduced-motion' })
}
// Check: emoji as icons
if (/[\u{1F300}-\u{1F9FF}]/u.test(content)) {
selfCheck.failed.push({ file, check: 'emoji-icon', message: 'Emoji used as icon — use SVG/icon library' })
}
} catch {}
}
// === Wisdom Contribution ===
if (sessionFolder) {
const timestamp = new Date().toISOString().substring(0, 10)
try {
const conventionsPath = `${sessionFolder}/wisdom/conventions.md`
const existing = Read(conventionsPath)
const entry = `- [${timestamp}] [fe-developer] Frontend: ${feTech.framework}/${feTech.styling}, component pattern used`
Write(conventionsPath, existing + '\n' + entry)
} catch {}
}
// === Update Shared Memory ===
if (sessionFolder) {
try {
sharedMemory.component_inventory = implementedFiles.map(f => ({ path: f, status: 'implemented' }))
Write(`${sessionFolder}/shared-memory.json`, JSON.stringify(sharedMemory, null, 2))
} catch {}
}
```
### Phase 5: Report to Coordinator
```javascript
const changedFiles = Bash(`git diff --name-only HEAD 2>/dev/null || echo "unknown"`)
.split('\n').filter(Boolean)
const feFiles = changedFiles.filter(f =>
/\.(tsx|jsx|vue|svelte|css|scss|html)$/.test(f)
)
const resultStatus = selfCheck.failed.length === 0 ? 'complete' : 'complete_with_warnings'
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "fe-developer", to: "coordinator",
type: "dev_fe_complete",
summary: `[fe-developer] DEV-FE complete: ${feFiles.length} files, self-check: ${selfCheck.failed.length} issues`,
ref: sessionFolder
})
SendMessage({
type: "message",
recipient: "coordinator",
content: `[fe-developer] ## Frontend Implementation Complete
**Task**: ${task.subject}
**Status**: ${resultStatus}
**Framework**: ${feTech.framework} | **Styling**: ${feTech.styling}
**Design Intelligence**: ${designIntel._source || 'not available'}
### Files Modified
${feFiles.slice(0, 10).map(f => `- \`${f}\``).join('\n') || 'See git diff'}
### Design Token Usage
${designTokens ? 'Applied design tokens from architecture → src/styles/tokens.css' : 'No design tokens available — used project defaults'}
### Self-Validation
${selfCheck.failed.length === 0 ? '✅ All checks passed' : `⚠️ ${selfCheck.failed.length} issues:\n${selfCheck.failed.slice(0, 5).map(f => `- [${f.check}] ${f.file}: ${f.message}`).join('\n')}`}
### Accessibility
- Semantic HTML structure
- ARIA attributes applied
- Keyboard navigation supported
- Focus-visible styles included`,
summary: `[fe-developer] DEV-FE complete: ${feFiles.length} files`
})
TaskUpdate({ taskId: task.id, status: 'completed' })
// Check for next DEV-FE task → back to Phase 1
```
## Error Handling
| Scenario | Resolution |
|----------|------------|
| No DEV-FE-* tasks | Idle, wait for coordinator |
| Design tokens not found | Use project defaults, note in report |
| Component spec missing | Implement from task description only |
| Tech stack undetected | Default to HTML + CSS, ask coordinator |
| Subagent failure | Fallback to CLI write mode |
| Build/lint errors | Report to coordinator for QA-FE review |

View File

@@ -0,0 +1,116 @@
# Command: pre-delivery-checklist
> 最终交付前的 CSS 级别精准检查清单,融合 ui-ux-pro-max Pre-Delivery Checklist 和 ux-guidelines Do/Don't 规则。
## When to Use
- Phase 3 of fe-qa role, Dimension 5: Pre-Delivery
- Final review or code-review type tasks
## Strategy
### Delegation Mode
**Mode**: Direct (inline pattern matching in fe-qa Phase 3)
## Checklist Items
### Accessibility
| # | Check | Pattern | Severity | Do | Don't |
|---|-------|---------|----------|-----|-------|
| 1 | Images have alt text | `<img` without `alt=` | CRITICAL | Always provide descriptive alt text | Leave alt empty without role="presentation" |
| 2 | Form inputs have labels | `<input` without `<label`/`aria-label` | HIGH | Associate every input with a label | Use placeholder as sole label |
| 3 | Focus states visible | Interactive elements without `focus` styles | HIGH | Add focus-visible outline | Remove default focus ring without replacement |
| 4 | Color contrast 4.5:1 | Light text on light background | HIGH | Ensure 4.5:1 minimum ratio | Use low-contrast decorative text for content |
| 5 | prefers-reduced-motion | Animations without media query | MEDIUM | Wrap in @media (prefers-reduced-motion: no-preference) | Force animations on all users |
| 6 | Heading hierarchy | Skipped heading levels (h1→h3) | MEDIUM | Use sequential heading levels | Skip levels for visual sizing |
### Interaction
| # | Check | Pattern | Severity | Do | Don't |
|---|-------|---------|----------|-----|-------|
| 7 | cursor-pointer on clickable | Buttons/links without cursor-pointer | MEDIUM | Add cursor: pointer to all clickable elements | Leave default cursor |
| 8 | Transitions 150-300ms | Duration outside range | LOW | Use 150-300ms for micro-interactions | Use >500ms or <100ms transitions |
| 9 | Loading states | Async ops without loading indicator | MEDIUM | Show skeleton/spinner during fetch | Leave blank screen while loading |
| 10 | Error states | Async ops without error handling | HIGH | Show user-friendly error message | Silently fail or show raw error |
### Design Compliance
| # | Check | Pattern | Severity | Do | Don't |
|---|-------|---------|----------|-----|-------|
| 11 | No hardcoded colors | Hex values outside tokens.css | HIGH | Use var(--color-*) tokens | Hardcode #hex values |
| 12 | No hardcoded spacing | px values for margin/padding | MEDIUM | Use var(--space-*) tokens | Hardcode pixel values |
| 13 | No emoji as icons | Unicode emoji in UI | HIGH | Use proper SVG/icon library | Use emoji for functional icons |
| 14 | Dark mode support | No prefers-color-scheme | MEDIUM | Support light/dark themes | Design for light mode only |
### Layout
| # | Check | Pattern | Severity | Do | Don't |
|---|-------|---------|----------|-----|-------|
| 15 | Responsive breakpoints | No md:/lg:/@media | MEDIUM | Mobile-first responsive design | Desktop-only layout |
| 16 | No horizontal scroll | Fixed widths > viewport | HIGH | Use relative/fluid widths | Set fixed pixel widths on containers |
## Execution
```javascript
function runPreDeliveryChecklist(fileContents) {
const results = { passed: 0, failed: 0, items: [] }
const checks = [
{ id: 1, check: "Images have alt text", test: (c) => /<img\s/.test(c) && !/<img\s[^>]*alt=/.test(c), severity: 'CRITICAL' },
{ id: 7, check: "cursor-pointer on clickable", test: (c) => /button|onClick/.test(c) && !/cursor-pointer/.test(c), severity: 'MEDIUM' },
{ id: 11, check: "No hardcoded colors", test: (c, f) => f !== 'src/styles/tokens.css' && /#[0-9a-fA-F]{6}/.test(c), severity: 'HIGH' },
{ id: 13, check: "No emoji as icons", test: (c) => /[\u{1F300}-\u{1F9FF}]/u.test(c), severity: 'HIGH' },
{ id: 14, check: "Dark mode support", test: (c) => !/prefers-color-scheme|dark:|\.dark/.test(c), severity: 'MEDIUM', global: true },
{ id: 15, check: "Responsive breakpoints", test: (c) => !/md:|lg:|@media.*min-width/.test(c), severity: 'MEDIUM', global: true }
]
// Per-file checks
for (const [file, content] of Object.entries(fileContents)) {
for (const check of checks.filter(c => !c.global)) {
if (check.test(content, file)) {
results.failed++
results.items.push({ ...check, file, status: 'FAIL' })
} else {
results.passed++
results.items.push({ ...check, file, status: 'PASS' })
}
}
}
// Global checks (across all content)
const allContent = Object.values(fileContents).join('\n')
for (const check of checks.filter(c => c.global)) {
if (check.test(allContent)) {
results.failed++
results.items.push({ ...check, file: 'global', status: 'FAIL' })
} else {
results.passed++
results.items.push({ ...check, file: 'global', status: 'PASS' })
}
}
return results
}
```
## Output Format
```
## Pre-Delivery Checklist Results
- Passed: X / Y
- Failed: Z
### Failed Items
- [CRITICAL] #1 Images have alt text — src/components/Hero.tsx
- [HIGH] #11 No hardcoded colors — src/styles/custom.css
```
## Error Handling
| Scenario | Resolution |
|----------|------------|
| No files to check | Report empty checklist, score 10/10 |
| File read error | Skip file, note in report |
| Regex error | Skip check, note in report |

View File

@@ -0,0 +1,510 @@
# Role: fe-qa
前端质量保证。5 维度代码审查 + Generator-Critic 循环确保前端代码质量。融合 ui-ux-pro-max 的 Pre-Delivery Checklist、ux-guidelines Do/Don't 规则、行业反模式库。
## Role Identity
- **Name**: `fe-qa`
- **Task Prefix**: `QA-FE-*`
- **Output Tag**: `[fe-qa]`
- **Role Type**: Pipeline前端子流水线 worker
- **Responsibility**: Context loading → Multi-dimension review → GC feedback → Report
## Role Boundaries
### MUST
- 仅处理 `QA-FE-*` 前缀的任务
- 所有输出带 `[fe-qa]` 标识
- 仅通过 SendMessage 与 coordinator 通信
- 执行 5 维度审查代码质量、可访问性、设计合规、UX 最佳实践、Pre-Delivery
- 提供可操作的修复建议Do/Don't 格式)
- 支持 Generator-Critic 循环(最多 2 轮)
- 加载 design-intelligence.json 用于行业反模式检查
### MUST NOT
- ❌ 直接修改源代码(仅提供审查意见)
- ❌ 直接与其他 worker 通信
- ❌ 为其他角色创建任务
- ❌ 跳过可访问性检查
- ❌ 在评分未达标时标记通过
## Message Types
| Type | Direction | Trigger | Description |
|------|-----------|---------|-------------|
| `qa_fe_passed` | fe-qa → coordinator | All dimensions pass | 前端质检通过 |
| `qa_fe_result` | fe-qa → coordinator | Review complete (may have issues) | 审查结果(含问题) |
| `fix_required` | fe-qa → coordinator | Critical issues found | 需要 fe-developer 修复 |
| `error` | fe-qa → coordinator | Review failure | 审查失败 |
## Message Bus
```javascript
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "fe-qa", to: "coordinator",
type: "qa_fe_result",
summary: "[fe-qa] QA-FE: score=8.5, 0 critical, 2 medium",
ref: outputPath
})
```
### CLI 回退
```javascript
Bash(`ccw team log --team "${teamName}" --from "fe-qa" --to "coordinator" --type "qa_fe_result" --summary "[fe-qa] QA-FE complete" --json`)
```
## Toolbox
### Available Commands
- [commands/pre-delivery-checklist.md](commands/pre-delivery-checklist.md) — CSS 级别精准交付检查
### CLI Capabilities
| CLI Tool | Mode | Purpose |
|----------|------|---------|
| `ccw cli --tool gemini --mode analysis` | analysis | 前端代码审查 |
| `ccw cli --tool codex --mode review` | review | Git-aware 代码审查 |
## Review Dimensions
| Dimension | Weight | Source | Focus |
|-----------|--------|--------|-------|
| Code Quality | 25% | Standard code review | TypeScript 类型安全、组件结构、状态管理、错误处理 |
| Accessibility | 25% | ux-guidelines rules | 语义 HTML、ARIA、键盘导航、色彩对比、focus-visible、prefers-reduced-motion |
| Design Compliance | 20% | design-intelligence.json | 设计令牌使用、行业反模式、emoji 检查、间距/排版一致性 |
| UX Best Practices | 15% | ux-guidelines Do/Don't | 加载状态、错误状态、空状态、cursor-pointer、响应式、动画时长 |
| Pre-Delivery | 15% | Pre-Delivery Checklist | 暗色模式、无 console.log、无硬编码、国际化就绪、must-have 检查 |
## Execution (5-Phase)
### Phase 1: Task Discovery
```javascript
const tasks = TaskList()
const myTasks = tasks.filter(t =>
t.subject.startsWith('QA-FE-') &&
t.owner === 'fe-qa' &&
t.status === 'pending' &&
t.blockedBy.length === 0
)
if (myTasks.length === 0) return
const task = TaskGet({ taskId: myTasks[0].id })
TaskUpdate({ taskId: task.id, status: 'in_progress' })
```
### Phase 2: Context Loading
```javascript
const sessionFolder = task.description.match(/Session:\s*([^\n]+)/)?.[1]?.trim()
// Load design tokens for compliance check
let designTokens = null
try { designTokens = JSON.parse(Read(`${sessionFolder}/architecture/design-tokens.json`)) } catch {}
// Load design intelligence (from analyst via ui-ux-pro-max)
let designIntel = {}
try { designIntel = JSON.parse(Read(`${sessionFolder}/analysis/design-intelligence.json`)) } catch {}
// Load shared memory for industry context + QA history
let sharedMemory = {}
try { sharedMemory = JSON.parse(Read(`${sessionFolder}/shared-memory.json`)) } catch {}
const industryContext = sharedMemory.industry_context || {}
const antiPatterns = designIntel.recommendations?.anti_patterns || []
const mustHave = designIntel.recommendations?.must_have || []
// Determine audit strictness from industry (standard / strict for medical/financial)
const strictness = industryContext.config?.strictness || 'standard'
// Load component specs
let componentSpecs = []
try {
const specFiles = Glob({ pattern: `${sessionFolder}/architecture/component-specs/*.md` })
componentSpecs = specFiles.map(f => ({ path: f, content: Read(f) }))
} catch {}
// Load previous QA results (for GC loop tracking)
let previousQA = []
try {
const qaFiles = Glob({ pattern: `${sessionFolder}/qa/audit-fe-*.json` })
previousQA = qaFiles.map(f => JSON.parse(Read(f)))
} catch {}
// Determine GC round
const gcRound = previousQA.filter(q => q.task_subject === task.subject).length + 1
const maxGCRounds = 2
// Get changed frontend files
const changedFiles = Bash(`git diff --name-only HEAD~1 2>/dev/null || git diff --name-only --cached 2>/dev/null || echo ""`)
.split('\n').filter(f => /\.(tsx|jsx|vue|svelte|css|scss|html|ts|js)$/.test(f))
// Read file contents for review
const fileContents = {}
for (const file of changedFiles.slice(0, 30)) {
try { fileContents[file] = Read(file) } catch {}
}
```
### Phase 3: 5-Dimension Review
```javascript
const review = {
task_subject: task.subject,
gc_round: gcRound,
timestamp: new Date().toISOString(),
dimensions: [],
issues: [],
overall_score: 0,
verdict: 'PENDING'
}
// === Dimension 1: Code Quality (25%) ===
const codeQuality = { name: 'code-quality', weight: 0.25, score: 10, issues: [] }
for (const [file, content] of Object.entries(fileContents)) {
if (/:\s*any\b/.test(content)) {
codeQuality.issues.push({ file, severity: 'medium', issue: 'Using `any` type', fix: 'Replace with specific type', do: 'Define proper TypeScript types', dont: 'Use `any` to bypass type checking' })
codeQuality.score -= 1.5
}
if (/\.tsx$/.test(file) && /export/.test(content) && !/ErrorBoundary/.test(content) && /throw/.test(content)) {
codeQuality.issues.push({ file, severity: 'low', issue: 'No error boundary for component with throw', fix: 'Wrap with ErrorBoundary' })
codeQuality.score -= 0.5
}
if (/style=\{?\{/.test(content) && designTokens) {
codeQuality.issues.push({ file, severity: 'medium', issue: 'Inline styles detected', fix: 'Use design tokens or CSS classes', do: 'Use var(--color-*) tokens', dont: 'Hardcode style values inline' })
codeQuality.score -= 1.5
}
if (/catch\s*\(\s*\)\s*\{[\s]*\}/.test(content)) {
codeQuality.issues.push({ file, severity: 'high', issue: 'Empty catch block', fix: 'Add error handling logic', do: 'Log or handle the error', dont: 'Silently swallow exceptions' })
codeQuality.score -= 2
}
if (content.split('\n').length > 300) {
codeQuality.issues.push({ file, severity: 'medium', issue: 'File exceeds 300 lines', fix: 'Split into smaller modules' })
codeQuality.score -= 1
}
}
codeQuality.score = Math.max(0, codeQuality.score)
review.dimensions.push(codeQuality)
// === Dimension 2: Accessibility (25%) ===
const a11y = { name: 'accessibility', weight: 0.25, score: 10, issues: [] }
for (const [file, content] of Object.entries(fileContents)) {
if (!/\.(tsx|jsx|vue|svelte|html)$/.test(file)) continue
if (/<img\s/.test(content) && !/<img\s[^>]*alt=/.test(content)) {
a11y.issues.push({ file, severity: 'high', issue: 'Image missing alt attribute', fix: 'Add descriptive alt text', do: 'Always provide alt text', dont: 'Leave alt empty without role="presentation"' })
a11y.score -= 3
}
if (/onClick/.test(content) && !/onKeyDown|onKeyPress|onKeyUp|role=.button/.test(content)) {
a11y.issues.push({ file, severity: 'medium', issue: 'Click handler without keyboard equivalent', fix: 'Add onKeyDown or role="button" tabIndex={0}' })
a11y.score -= 1.5
}
if (/<input\s/.test(content) && !/<label/.test(content) && !/aria-label/.test(content)) {
a11y.issues.push({ file, severity: 'high', issue: 'Form input without label', fix: 'Add <label> or aria-label', do: 'Associate every input with a label', dont: 'Use placeholder as sole label' })
a11y.score -= 2
}
if (/<button\s/.test(content) && /<button\s[^>]*>\s*</.test(content) && !/aria-label/.test(content)) {
a11y.issues.push({ file, severity: 'high', issue: 'Button may lack accessible text (icon-only?)', fix: 'Add aria-label', do: 'Add aria-label for icon-only buttons', dont: 'Use title as sole accessible name' })
a11y.score -= 2
}
// Heading hierarchy
const headings = content.match(/<h([1-6])/g)?.map(h => parseInt(h[2])) || []
for (let i = 1; i < headings.length; i++) {
if (headings[i] - headings[i-1] > 1) {
a11y.issues.push({ file, severity: 'medium', issue: `Heading level skipped: h${headings[i-1]} → h${headings[i]}`, fix: 'Use sequential heading levels' })
a11y.score -= 1
}
}
// Focus-visible styles
if (/button|<a |input|select/.test(content) && !/focus-visible|focus:/.test(content)) {
a11y.issues.push({ file, severity: 'high', issue: 'Interactive element missing focus styles', fix: 'Add focus-visible outline', do: 'Add focus-visible outline', dont: 'Remove default focus ring without replacement' })
a11y.score -= 2
}
// ARIA role with tabindex
if (/role="(button|link)"/.test(content) && !/tabindex/.test(content)) {
a11y.issues.push({ file, severity: 'medium', issue: 'Element with ARIA role may need tabindex', fix: 'Add tabindex={0}' })
a11y.score -= 1
}
// Hardcoded color contrast
if (/#[0-9a-f]{3,6}/i.test(content) && !/token|theme|var\(--/.test(content)) {
a11y.issues.push({ file, severity: 'low', issue: 'Hardcoded color — verify contrast ratio', fix: 'Use design tokens for consistent contrast' })
a11y.score -= 0.5
}
}
// Strict mode: additional checks for medical/financial
if (strictness === 'strict') {
for (const [file, content] of Object.entries(fileContents)) {
if (/animation|transition|@keyframes/.test(content) && !/prefers-reduced-motion/.test(content)) {
a11y.issues.push({ file, severity: 'high', issue: 'Animation without prefers-reduced-motion', fix: 'Wrap in @media (prefers-reduced-motion: no-preference)', do: 'Respect motion preferences', dont: 'Force animations on all users' })
a11y.score -= 2
}
}
}
a11y.score = Math.max(0, a11y.score)
review.dimensions.push(a11y)
// === Dimension 3: Design Compliance (20%) ===
const designCompliance = { name: 'design-compliance', weight: 0.20, score: 10, issues: [] }
for (const [file, content] of Object.entries(fileContents)) {
if (file !== 'src/styles/tokens.css' && /#[0-9a-fA-F]{3,8}/.test(content)) {
const count = (content.match(/#[0-9a-fA-F]{3,8}/g) || []).length
designCompliance.issues.push({ file, severity: 'high', issue: `${count} hardcoded color(s)`, fix: 'Use var(--color-*) tokens', do: 'Use var(--color-primary)', dont: 'Hardcode #hex values' })
designCompliance.score -= 2
}
if (/margin|padding/.test(content) && /:\s*\d+px/.test(content) && !/var\(--space/.test(content)) {
designCompliance.issues.push({ file, severity: 'medium', issue: 'Hardcoded spacing', fix: 'Use var(--space-*) tokens', do: 'Use var(--space-md)', dont: 'Hardcode 16px' })
designCompliance.score -= 1
}
if (/font-size:\s*\d+/.test(content) && !/var\(--/.test(content)) {
designCompliance.issues.push({ file, severity: 'medium', issue: 'Hardcoded font size', fix: 'Use var(--text-*) tokens' })
designCompliance.score -= 1
}
if (/[\u{1F300}-\u{1F9FF}]/u.test(content)) {
designCompliance.issues.push({ file, severity: 'high', issue: 'Emoji used as functional icon', fix: 'Use SVG/icon library', do: 'Use proper SVG/icon library', dont: 'Use emoji for functional icons' })
designCompliance.score -= 2
}
// Industry anti-patterns from design-intelligence.json
for (const pattern of antiPatterns) {
if (typeof pattern === 'string') {
const pl = pattern.toLowerCase()
if (pl.includes('gradient') && /gradient/.test(content)) {
designCompliance.issues.push({ file, severity: 'high', issue: `Industry anti-pattern: ${pattern}` })
designCompliance.score -= 3
}
if (pl.includes('emoji') && /[\u{1F300}-\u{1F9FF}]/u.test(content)) {
designCompliance.issues.push({ file, severity: 'high', issue: `Industry anti-pattern: ${pattern}` })
designCompliance.score -= 2
}
}
}
}
if (!designTokens) designCompliance.score = 7
designCompliance.score = Math.max(0, designCompliance.score)
review.dimensions.push(designCompliance)
// === Dimension 4: UX Best Practices (15%) ===
const uxPractices = { name: 'ux-practices', weight: 0.15, score: 10, issues: [] }
for (const [file, content] of Object.entries(fileContents)) {
// cursor-pointer on clickable (CSS files)
if (/button|<a |onClick|@click/.test(content) && !/cursor-pointer/.test(content) && /\.(css|scss)$/.test(file)) {
uxPractices.issues.push({ file, severity: 'medium', issue: 'Missing cursor: pointer on clickable', fix: 'Add cursor: pointer', do: 'Add cursor: pointer to all clickable elements', dont: 'Leave default cursor' })
uxPractices.score -= 1
}
// Transition duration range (150-300ms)
const durations = content.match(/duration[:-]\s*(\d+)/g) || []
for (const d of durations) {
const ms = parseInt(d.match(/\d+/)[0])
if (ms > 0 && (ms < 100 || ms > 500)) {
uxPractices.issues.push({ file, severity: 'low', issue: `Transition ${ms}ms outside 150-300ms range`, fix: 'Use 150-300ms for micro-interactions' })
uxPractices.score -= 0.5
}
}
if (!/\.(tsx|jsx|vue|svelte)$/.test(file)) continue
// Loading states
if (/fetch|useQuery|useSWR|axios/.test(content) && !/loading|isLoading|skeleton|spinner/i.test(content)) {
uxPractices.issues.push({ file, severity: 'medium', issue: 'Data fetching without loading state', fix: 'Add loading indicator', do: 'Show skeleton/spinner during fetch', dont: 'Leave blank screen while loading' })
uxPractices.score -= 1
}
// Error states
if (/fetch|useQuery|useSWR|axios/.test(content) && !/error|isError|catch/i.test(content)) {
uxPractices.issues.push({ file, severity: 'high', issue: 'Data fetching without error handling', fix: 'Add error state UI', do: 'Show user-friendly error message', dont: 'Silently fail or show raw error' })
uxPractices.score -= 2
}
// Empty states
if (/\.map\(/.test(content) && !/empty|no.*data|no.*result|length\s*===?\s*0/i.test(content)) {
uxPractices.issues.push({ file, severity: 'low', issue: 'List rendering without empty state', fix: 'Add empty state message' })
uxPractices.score -= 0.5
}
// Responsive breakpoints
if (/className|class=/.test(content) && !/md:|lg:|@media/.test(content)) {
uxPractices.issues.push({ file, severity: 'medium', issue: 'No responsive breakpoints', fix: 'Mobile-first responsive design', do: 'Mobile-first responsive design', dont: 'Design for desktop only' })
uxPractices.score -= 1
}
}
uxPractices.score = Math.max(0, uxPractices.score)
review.dimensions.push(uxPractices)
// === Dimension 5: Pre-Delivery (15%) ===
// Detailed checklist: commands/pre-delivery-checklist.md
const preDelivery = { name: 'pre-delivery', weight: 0.15, score: 10, issues: [] }
const allContent = Object.values(fileContents).join('\n')
// Per-file checks
for (const [file, content] of Object.entries(fileContents)) {
if (/console\.(log|debug|info)\(/.test(content) && !/test|spec|\.test\./.test(file)) {
preDelivery.issues.push({ file, severity: 'medium', issue: 'console.log in production code', fix: 'Remove or use proper logger' })
preDelivery.score -= 1
}
if (/\.(tsx|jsx)$/.test(file) && />\s*[A-Z][a-z]+\s+[a-z]+/.test(content) && !/t\(|intl|i18n|formatMessage/.test(content)) {
preDelivery.issues.push({ file, severity: 'low', issue: 'Hardcoded text — consider i18n', fix: 'Extract to translation keys' })
preDelivery.score -= 0.5
}
if (/TODO|FIXME|HACK|XXX/.test(content)) {
preDelivery.issues.push({ file, severity: 'low', issue: 'TODO/FIXME comment found', fix: 'Resolve or create issue' })
preDelivery.score -= 0.5
}
}
// Global checklist items (from pre-delivery-checklist.md)
const checklist = [
{ check: "No emoji as functional icons", test: () => /[\u{1F300}-\u{1F9FF}]/u.test(allContent), severity: 'high' },
{ check: "cursor-pointer on clickable", test: () => /button|onClick/.test(allContent) && !/cursor-pointer/.test(allContent), severity: 'medium' },
{ check: "Focus states visible", test: () => /button|input|<a /.test(allContent) && !/focus/.test(allContent), severity: 'high' },
{ check: "prefers-reduced-motion", test: () => /animation|@keyframes/.test(allContent) && !/prefers-reduced-motion/.test(allContent), severity: 'medium' },
{ check: "Responsive breakpoints", test: () => !/md:|lg:|@media.*min-width/.test(allContent), severity: 'medium' },
{ check: "No hardcoded colors", test: () => { const nt = Object.entries(fileContents).filter(([f]) => f !== 'src/styles/tokens.css'); return nt.some(([,c]) => /#[0-9a-fA-F]{6}/.test(c)) }, severity: 'high' },
{ check: "Dark mode support", test: () => !/prefers-color-scheme|dark:|\.dark/.test(allContent), severity: 'medium' }
]
for (const item of checklist) {
try {
if (item.test()) {
preDelivery.issues.push({ check: item.check, severity: item.severity, issue: `Pre-delivery: ${item.check}` })
preDelivery.score -= (item.severity === 'high' ? 2 : item.severity === 'medium' ? 1 : 0.5)
}
} catch {}
}
// Must-have checks from industry config
for (const req of mustHave) {
if (req === 'wcag-aaa' && !/aria-/.test(allContent)) {
preDelivery.issues.push({ severity: 'high', issue: 'WCAG AAA required but no ARIA attributes found' })
preDelivery.score -= 3
}
if (req === 'high-contrast' && !/high-contrast|forced-colors/.test(allContent)) {
preDelivery.issues.push({ severity: 'medium', issue: 'High contrast mode not supported' })
preDelivery.score -= 1
}
}
preDelivery.score = Math.max(0, preDelivery.score)
review.dimensions.push(preDelivery)
// === Calculate Overall Score ===
review.overall_score = review.dimensions.reduce((sum, d) => sum + d.score * d.weight, 0)
review.issues = review.dimensions.flatMap(d => d.issues)
const criticalCount = review.issues.filter(i => i.severity === 'high').length
if (review.overall_score >= 8 && criticalCount === 0) {
review.verdict = 'PASS'
} else if (gcRound >= maxGCRounds) {
review.verdict = review.overall_score >= 6 ? 'PASS_WITH_WARNINGS' : 'FAIL'
} else {
review.verdict = 'NEEDS_FIX'
}
```
### Phase 4: Package Results + Shared Memory
```javascript
const outputPath = sessionFolder
? `${sessionFolder}/qa/audit-fe-${task.subject.replace(/[^a-zA-Z0-9-]/g, '-').toLowerCase()}-r${gcRound}.json`
: '.workflow/.tmp/qa-fe-audit.json'
Bash(`mkdir -p "$(dirname '${outputPath}')"`)
Write(outputPath, JSON.stringify(review, null, 2))
// Wisdom contribution
if (sessionFolder && review.issues.length > 0) {
try {
const issuesPath = `${sessionFolder}/wisdom/issues.md`
const existing = Read(issuesPath)
const timestamp = new Date().toISOString().substring(0, 10)
const highIssues = review.issues.filter(i => i.severity === 'high')
if (highIssues.length > 0) {
const entries = highIssues.map(i => `- [${timestamp}] [fe-qa] ${i.issue} in ${i.file || 'global'}`).join('\n')
Write(issuesPath, existing + '\n' + entries)
}
} catch {}
}
// Update shared memory with QA history
if (sessionFolder) {
try {
sharedMemory.qa_history = sharedMemory.qa_history || []
sharedMemory.qa_history.push({
task_subject: task.subject,
gc_round: gcRound,
verdict: review.verdict,
score: review.overall_score,
critical_count: criticalCount,
total_issues: review.issues.length,
timestamp: new Date().toISOString()
})
Write(`${sessionFolder}/shared-memory.json`, JSON.stringify(sharedMemory, null, 2))
} catch {}
}
```
### Phase 5: Report to Coordinator
```javascript
const msgType = review.verdict === 'PASS' || review.verdict === 'PASS_WITH_WARNINGS'
? 'qa_fe_passed'
: criticalCount > 0 ? 'fix_required' : 'qa_fe_result'
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "fe-qa", to: "coordinator",
type: msgType,
summary: `[fe-qa] QA-FE R${gcRound}: ${review.verdict}, score=${review.overall_score.toFixed(1)}, ${criticalCount} critical`,
ref: outputPath
})
SendMessage({
type: "message",
recipient: "coordinator",
content: `[fe-qa] ## Frontend QA Review
**Task**: ${task.subject}
**Round**: ${gcRound}/${maxGCRounds}
**Verdict**: ${review.verdict}
**Score**: ${review.overall_score.toFixed(1)}/10
**Strictness**: ${strictness}
**Design Intelligence**: ${designIntel._source || 'not available'}
### Dimension Scores
${review.dimensions.map(d => `- **${d.name}**: ${d.score.toFixed(1)}/10 (${d.issues.length} issues)`).join('\n')}
### Critical Issues (${criticalCount})
${review.issues.filter(i => i.severity === 'high').map(i => `- \`${i.file || i.check}\`: ${i.issue}${i.fix || ''}${i.do ? `\n ✅ Do: ${i.do}` : ''}${i.dont ? `\n ❌ Don't: ${i.dont}` : ''}`).join('\n') || 'None'}
### Medium Issues
${review.issues.filter(i => i.severity === 'medium').slice(0, 5).map(i => `- \`${i.file || i.check}\`: ${i.issue}${i.fix || ''}`).join('\n') || 'None'}
${review.verdict === 'NEEDS_FIX' ? `\n### Action Required\nfe-developer 需修复 ${criticalCount} 个 critical 问题后重新提交。` : ''}
### Output: ${outputPath}`,
summary: `[fe-qa] QA-FE R${gcRound}: ${review.verdict}, ${review.overall_score.toFixed(1)}/10`
})
TaskUpdate({ taskId: task.id, status: 'completed' })
// Check for next QA-FE task → back to Phase 1
```
## Generator-Critic Loop
fe-developer ↔ fe-qa 循环由 coordinator 编排:
```
Round 1: DEV-FE-001 → QA-FE-001
if QA verdict = NEEDS_FIX:
coordinator creates DEV-FE-002 (fix task, blockedBy QA-FE-001)
coordinator creates QA-FE-002 (re-review, blockedBy DEV-FE-002)
Round 2: DEV-FE-002 → QA-FE-002
if still NEEDS_FIX: verdict = PASS_WITH_WARNINGS or FAIL (max 2 rounds)
```
**收敛条件**: `overall_score >= 8 && critical_count === 0`
## Error Handling
| Scenario | Resolution |
|----------|------------|
| No QA-FE-* tasks | Idle, wait for coordinator |
| No changed frontend files | Report empty review, score = N/A |
| Design tokens not found | Skip design compliance dimension, adjust weights |
| design-intelligence.json not found | Skip industry anti-patterns, use standard strictness |
| Git diff fails | Use Glob to find recent frontend files |
| Max GC rounds exceeded | Force verdict (PASS_WITH_WARNINGS or FAIL) |
| ui-ux-pro-max not installed | Continue without design intelligence, note in report |

View File

@@ -0,0 +1,466 @@
# Command: Multi-Angle Exploration
Phase 2 of planner execution - assess complexity, select exploration angles, and execute parallel exploration.
## Overview
This command performs multi-angle codebase exploration based on task complexity. Low complexity uses direct semantic search, while Medium/High complexity launches parallel cli-explore-agent subagents for comprehensive analysis.
## Complexity Assessment
### assessComplexity Function
```javascript
function assessComplexity(desc) {
let score = 0
if (/refactor|architect|restructure|模块|系统/.test(desc)) score += 2
if (/multiple|多个|across|跨/.test(desc)) score += 2
if (/integrate|集成|api|database/.test(desc)) score += 1
if (/security|安全|performance|性能/.test(desc)) score += 1
return score >= 4 ? 'High' : score >= 2 ? 'Medium' : 'Low'
}
const complexity = assessComplexity(task.description)
```
### Complexity Levels
| Level | Score | Characteristics | Angle Count |
|-------|-------|----------------|-------------|
| **Low** | 0-1 | Simple feature, single module, clear scope | 1 |
| **Medium** | 2-3 | Multiple modules, integration points, moderate scope | 3 |
| **High** | 4+ | Architecture changes, cross-cutting concerns, complex scope | 4 |
## Angle Selection
### ANGLE_PRESETS
```javascript
const ANGLE_PRESETS = {
architecture: ['architecture', 'dependencies', 'modularity', 'integration-points'],
security: ['security', 'auth-patterns', 'dataflow', 'validation'],
performance: ['performance', 'bottlenecks', 'caching', 'data-access'],
bugfix: ['error-handling', 'dataflow', 'state-management', 'edge-cases'],
feature: ['patterns', 'integration-points', 'testing', 'dependencies']
}
```
### selectAngles Function
```javascript
function selectAngles(desc, count) {
const text = desc.toLowerCase()
let preset = 'feature'
if (/refactor|architect|restructure|modular/.test(text)) preset = 'architecture'
else if (/security|auth|permission|access/.test(text)) preset = 'security'
else if (/performance|slow|optimi|cache/.test(text)) preset = 'performance'
else if (/fix|bug|error|issue|broken/.test(text)) preset = 'bugfix'
return ANGLE_PRESETS[preset].slice(0, count)
}
const angleCount = complexity === 'High' ? 4 : (complexity === 'Medium' ? 3 : 1)
const selectedAngles = selectAngles(task.description, angleCount)
```
### Angle Definitions
| Angle | Focus | Use Case |
|-------|-------|----------|
| **architecture** | System structure, layer boundaries, design patterns | Refactoring, restructuring |
| **dependencies** | Module dependencies, coupling, external libraries | Integration, modularity |
| **modularity** | Component boundaries, separation of concerns | Architecture changes |
| **integration-points** | API boundaries, data flow between modules | Feature development |
| **security** | Auth/authz, input validation, data protection | Security features |
| **auth-patterns** | Authentication flows, session management | Auth implementation |
| **dataflow** | Data transformation, state propagation | Bug fixes, features |
| **validation** | Input validation, error handling | Security, quality |
| **performance** | Bottlenecks, optimization opportunities | Performance tuning |
| **bottlenecks** | Slow operations, resource contention | Performance issues |
| **caching** | Cache strategies, invalidation patterns | Performance optimization |
| **data-access** | Database queries, data fetching patterns | Performance, features |
| **error-handling** | Error propagation, recovery strategies | Bug fixes |
| **state-management** | State updates, consistency | Bug fixes, features |
| **edge-cases** | Boundary conditions, error scenarios | Bug fixes, testing |
| **patterns** | Code patterns, conventions, best practices | Feature development |
| **testing** | Test coverage, test strategies | Feature development |
## Exploration Execution
### Low Complexity: Direct Semantic Search
```javascript
if (complexity === 'Low') {
// Direct exploration via semantic search
const results = mcp__ace-tool__search_context({
project_root_path: projectRoot,
query: task.description
})
// Transform ACE results to exploration JSON
const exploration = {
project_structure: "Analyzed via ACE semantic search",
relevant_files: results.files.map(f => ({
path: f.path,
rationale: f.relevance_reason || "Semantic match to task description",
role: "modify_target",
discovery_source: "ace-search",
key_symbols: f.symbols || []
})),
patterns: results.patterns || [],
dependencies: results.dependencies || [],
integration_points: results.integration_points || [],
constraints: [],
clarification_needs: [],
_metadata: {
exploration_angle: selectedAngles[0],
complexity: 'Low',
discovery_method: 'ace-semantic-search'
}
}
Write(`${planDir}/exploration-${selectedAngles[0]}.json`, JSON.stringify(exploration, null, 2))
}
```
### Medium/High Complexity: Parallel cli-explore-agent
```javascript
else {
// Launch parallel cli-explore-agent for each angle
selectedAngles.forEach((angle, index) => {
Task({
subagent_type: "cli-explore-agent",
run_in_background: false,
description: `Explore: ${angle}`,
prompt: `
## Task Objective
Execute **${angle}** exploration for task planning context.
## Output Location
**Session Folder**: ${sessionFolder}
**Output File**: ${planDir}/exploration-${angle}.json
## Assigned Context
- **Exploration Angle**: ${angle}
- **Task Description**: ${task.description}
- **Spec Context**: ${specContext ? 'Available — use spec/requirements, spec/architecture, spec/epics for informed exploration' : 'Not available (impl-only mode)'}
- **Exploration Index**: ${index + 1} of ${selectedAngles.length}
## MANDATORY FIRST STEPS
1. Run: rg -l "{relevant_keyword}" --type ts (locate relevant files)
2. Execute: cat ~/.ccw/workflows/cli-templates/schemas/explore-json-schema.json (get output schema)
3. Read: .workflow/project-tech.json (if exists - technology stack)
## Expected Output
Write JSON to: ${planDir}/exploration-${angle}.json
Follow explore-json-schema.json structure with ${angle}-focused findings.
**MANDATORY**: Every file in relevant_files MUST have:
- **rationale** (required): Specific selection basis tied to ${angle} topic (>10 chars, not generic)
- **role** (required): modify_target|dependency|pattern_reference|test_target|type_definition|integration_point|config|context_only
- **discovery_source** (recommended): bash-scan|cli-analysis|ace-search|dependency-trace|manual
- **key_symbols** (recommended): Key functions/classes/types relevant to task
## Exploration Focus by Angle
${getAngleFocusGuide(angle)}
## Output Schema Structure
\`\`\`json
{
"project_structure": "string - high-level architecture overview",
"relevant_files": [
{
"path": "string - relative file path",
"rationale": "string - WHY this file matters for ${angle} (>10 chars, specific)",
"role": "modify_target|dependency|pattern_reference|test_target|type_definition|integration_point|config|context_only",
"discovery_source": "bash-scan|cli-analysis|ace-search|dependency-trace|manual",
"key_symbols": ["function/class/type names"]
}
],
"patterns": ["string - code patterns relevant to ${angle}"],
"dependencies": ["string - module/library dependencies"],
"integration_points": ["string - API/interface boundaries"],
"constraints": ["string - technical constraints"],
"clarification_needs": ["string - questions needing user input"],
"_metadata": {
"exploration_angle": "${angle}",
"complexity": "${complexity}",
"discovery_method": "cli-explore-agent"
}
}
\`\`\`
`
})
})
}
```
### Angle Focus Guide
```javascript
function getAngleFocusGuide(angle) {
const guides = {
architecture: `
**Architecture Focus**:
- Identify layer boundaries (presentation, business, data)
- Map module dependencies and coupling
- Locate design patterns (factory, strategy, observer, etc.)
- Find architectural decision records (ADRs)
- Analyze component responsibilities`,
dependencies: `
**Dependencies Focus**:
- Map internal module dependencies (import/require statements)
- Identify external library usage (package.json, requirements.txt)
- Trace dependency chains and circular dependencies
- Locate shared utilities and common modules
- Analyze coupling strength between modules`,
modularity: `
**Modularity Focus**:
- Identify module boundaries and interfaces
- Analyze separation of concerns
- Locate tightly coupled code
- Find opportunities for extraction/refactoring
- Map public vs private APIs`,
'integration-points': `
**Integration Points Focus**:
- Locate API endpoints and routes
- Identify data flow between modules
- Find event emitters/listeners
- Map external service integrations
- Analyze interface contracts`,
security: `
**Security Focus**:
- Locate authentication/authorization logic
- Identify input validation points
- Find sensitive data handling
- Analyze access control mechanisms
- Locate security-related middleware`,
'auth-patterns': `
**Auth Patterns Focus**:
- Identify authentication flows (login, logout, refresh)
- Locate session management code
- Find token generation/validation
- Map user permission checks
- Analyze auth middleware`,
dataflow: `
**Dataflow Focus**:
- Trace data transformations
- Identify state propagation paths
- Locate data validation points
- Map data sources and sinks
- Analyze data mutation points`,
validation: `
**Validation Focus**:
- Locate input validation logic
- Identify schema definitions
- Find error handling for invalid data
- Map validation middleware
- Analyze sanitization functions`,
performance: `
**Performance Focus**:
- Identify computational bottlenecks
- Locate database queries (N+1 problems)
- Find synchronous blocking operations
- Map resource-intensive operations
- Analyze algorithm complexity`,
bottlenecks: `
**Bottlenecks Focus**:
- Locate slow operations (profiling data)
- Identify resource contention points
- Find inefficient algorithms
- Map hot paths in code
- Analyze concurrency issues`,
caching: `
**Caching Focus**:
- Locate existing cache implementations
- Identify cacheable operations
- Find cache invalidation logic
- Map cache key strategies
- Analyze cache hit/miss patterns`,
'data-access': `
**Data Access Focus**:
- Locate database query patterns
- Identify ORM/query builder usage
- Find data fetching strategies
- Map data access layers
- Analyze query optimization opportunities`,
'error-handling': `
**Error Handling Focus**:
- Locate try-catch blocks
- Identify error propagation paths
- Find error recovery strategies
- Map error logging points
- Analyze error types and handling`,
'state-management': `
**State Management Focus**:
- Locate state containers (Redux, Vuex, etc.)
- Identify state update patterns
- Find state synchronization logic
- Map state dependencies
- Analyze state consistency mechanisms`,
'edge-cases': `
**Edge Cases Focus**:
- Identify boundary conditions
- Locate null/undefined handling
- Find empty array/object handling
- Map error scenarios
- Analyze exceptional flows`,
patterns: `
**Patterns Focus**:
- Identify code patterns and conventions
- Locate design pattern implementations
- Find naming conventions
- Map code organization patterns
- Analyze best practices usage`,
testing: `
**Testing Focus**:
- Locate test files and test utilities
- Identify test coverage gaps
- Find test patterns (unit, integration, e2e)
- Map mocking/stubbing strategies
- Analyze test organization`
}
return guides[angle] || `**${angle} Focus**: Analyze codebase from ${angle} perspective`
}
```
## Explorations Manifest
```javascript
// Build explorations manifest
const explorationManifest = {
session_id: `${taskSlug}-${dateStr}`,
task_description: task.description,
complexity: complexity,
exploration_count: selectedAngles.length,
explorations: selectedAngles.map(angle => ({
angle: angle,
file: `exploration-${angle}.json`,
path: `${planDir}/exploration-${angle}.json`
}))
}
Write(`${planDir}/explorations-manifest.json`, JSON.stringify(explorationManifest, null, 2))
```
## Output Schema
### explore-json-schema.json Structure
```json
{
"project_structure": "string - high-level architecture overview",
"relevant_files": [
{
"path": "string - relative file path",
"rationale": "string - specific selection basis (>10 chars)",
"role": "modify_target|dependency|pattern_reference|test_target|type_definition|integration_point|config|context_only",
"discovery_source": "bash-scan|cli-analysis|ace-search|dependency-trace|manual",
"key_symbols": ["string - function/class/type names"]
}
],
"patterns": ["string - code patterns relevant to angle"],
"dependencies": ["string - module/library dependencies"],
"integration_points": ["string - API/interface boundaries"],
"constraints": ["string - technical constraints"],
"clarification_needs": ["string - questions needing user input"],
"_metadata": {
"exploration_angle": "string - angle name",
"complexity": "Low|Medium|High",
"discovery_method": "ace-semantic-search|cli-explore-agent"
}
}
```
## Integration with Phase 3
Phase 3 (Plan Generation) consumes:
1. `explorations-manifest.json` - list of exploration files
2. `exploration-{angle}.json` - per-angle exploration results
3. `specContext` (if available) - requirements, architecture, epics
These inputs are passed to cli-lite-planning-agent for plan generation.
## Error Handling
### Exploration Agent Failure
```javascript
try {
Task({
subagent_type: "cli-explore-agent",
run_in_background: false,
description: `Explore: ${angle}`,
prompt: `...`
})
} catch (error) {
// Skip exploration, continue with available explorations
console.error(`[planner] Exploration failed for angle: ${angle}`, error)
// Remove failed angle from manifest
explorationManifest.explorations = explorationManifest.explorations.filter(e => e.angle !== angle)
explorationManifest.exploration_count = explorationManifest.explorations.length
}
```
### All Explorations Fail
```javascript
if (explorationManifest.exploration_count === 0) {
// Fallback: Plan from task description only
console.warn(`[planner] All explorations failed, planning from task description only`)
// Proceed to Phase 3 with empty explorations
}
```
### ACE Search Failure (Low Complexity)
```javascript
try {
const results = mcp__ace-tool__search_context({
project_root_path: projectRoot,
query: task.description
})
} catch (error) {
// Fallback: Use ripgrep for basic file discovery
const rgResults = Bash(`rg -l "${task.description}" --type ts`)
const exploration = {
project_structure: "Basic file discovery via ripgrep",
relevant_files: rgResults.split('\n').map(path => ({
path: path.trim(),
rationale: "Matched task description keywords",
role: "modify_target",
discovery_source: "bash-scan",
key_symbols: []
})),
patterns: [],
dependencies: [],
integration_points: [],
constraints: [],
clarification_needs: [],
_metadata: {
exploration_angle: selectedAngles[0],
complexity: 'Low',
discovery_method: 'ripgrep-fallback'
}
}
Write(`${planDir}/exploration-${selectedAngles[0]}.json`, JSON.stringify(exploration, null, 2))
}
```

View File

@@ -0,0 +1,253 @@
# Role: planner
Multi-angle code exploration and structured implementation planning. Submits plans to the coordinator for approval.
## Role Identity
- **Name**: `planner`
- **Task Prefix**: `PLAN-*`
- **Output Tag**: `[planner]`
- **Responsibility**: Code exploration → Implementation planning → Coordinator approval
- **Communication**: SendMessage to coordinator only
## Role Boundaries
### MUST
- Only process PLAN-* tasks
- Communicate only with coordinator
- Write plan artifacts to `plan/` folder
- Tag all SendMessage and team_msg calls with `[planner]`
- Assess complexity (Low/Medium/High)
- Execute multi-angle exploration based on complexity
- Generate plan.json + .task/TASK-*.json following schemas
- Submit plan for coordinator approval
- Load spec context in full-lifecycle mode
### MUST NOT
- Create tasks
- Contact other workers directly
- Implement code
- Modify spec documents
- Skip complexity assessment
- Proceed without exploration (Medium/High complexity)
- Generate plan without schema validation
## Message Types
| Type | Direction | Trigger | Description |
|------|-----------|---------|-------------|
| `plan_ready` | planner → coordinator | Plan generation complete | With plan.json path and task count summary |
| `plan_revision` | planner → coordinator | Plan revised and resubmitted | Describes changes made |
| `impl_progress` | planner → coordinator | Exploration phase progress | Optional, for long explorations |
| `error` | planner → coordinator | Unrecoverable error | Exploration failure, schema missing, etc. |
## Message Bus
Before every `SendMessage`, MUST call `mcp__ccw-tools__team_msg` to log:
```javascript
// Plan ready
mcp__ccw-tools__team_msg({ operation: "log", team: teamName, from: "planner", to: "coordinator", type: "plan_ready", summary: "[planner] Plan ready: 3 tasks, Medium complexity", ref: `${sessionFolder}/plan/plan.json` })
// Plan revision
mcp__ccw-tools__team_msg({ operation: "log", team: teamName, from: "planner", to: "coordinator", type: "plan_revision", summary: "[planner] Split task-2 into two subtasks per feedback" })
// Error report
mcp__ccw-tools__team_msg({ operation: "log", team: teamName, from: "planner", to: "coordinator", type: "error", summary: "[planner] plan-overview-base-schema.json not found, using default structure" })
```
### CLI Fallback
When `mcp__ccw-tools__team_msg` MCP is unavailable:
```javascript
Bash(`ccw team log --team "${teamName}" --from "planner" --to "coordinator" --type "plan_ready" --summary "[planner] Plan ready: 3 tasks" --ref "${sessionFolder}/plan/plan.json" --json`)
```
## Toolbox
### Available Commands
- `commands/explore.md` - Multi-angle codebase exploration (Phase 2)
### Subagent Capabilities
- **cli-explore-agent**: Per-angle exploration (Medium/High complexity)
- **cli-lite-planning-agent**: Plan generation (Medium/High complexity)
### CLI Capabilities
None directly (delegates to subagents)
## Execution (5-Phase)
### Phase 1: Task Discovery
```javascript
const tasks = TaskList()
const myTasks = tasks.filter(t =>
t.subject.startsWith('PLAN-') &&
t.owner === 'planner' &&
t.status === 'pending' &&
t.blockedBy.length === 0
)
if (myTasks.length === 0) return // idle
const task = TaskGet({ taskId: myTasks[0].id })
TaskUpdate({ taskId: task.id, status: 'in_progress' })
```
### Phase 1.5: Load Spec Context (Full-Lifecycle Mode)
```javascript
// Extract session folder from task description (set by coordinator)
const sessionMatch = task.description.match(/Session:\s*(.+)/)
const sessionFolder = sessionMatch ? sessionMatch[1].trim() : `.workflow/.team/default`
const planDir = `${sessionFolder}/plan`
Bash(`mkdir -p ${planDir}`)
// Check if spec directory exists (full-lifecycle mode)
const specDir = `${sessionFolder}/spec`
let specContext = null
try {
const reqIndex = Read(`${specDir}/requirements/_index.md`)
const archIndex = Read(`${specDir}/architecture/_index.md`)
const epicsIndex = Read(`${specDir}/epics/_index.md`)
const specConfig = JSON.parse(Read(`${specDir}/spec-config.json`))
specContext = { reqIndex, archIndex, epicsIndex, specConfig }
} catch { /* impl-only mode has no spec */ }
```
### Phase 2: Multi-Angle Exploration
**Delegate to**: `Read("commands/explore.md")`
Execute complexity assessment, angle selection, and parallel exploration. See `commands/explore.md` for full implementation.
### Phase 3: Plan Generation
```javascript
// Read schema reference
const schema = Bash(`cat ~/.ccw/workflows/cli-templates/schemas/plan-overview-base-schema.json`)
if (complexity === 'Low') {
// Direct Claude planning
Bash(`mkdir -p ${planDir}/.task`)
// Generate plan.json + .task/TASK-*.json following schemas
const plan = {
session_id: `${taskSlug}-${dateStr}`,
task_description: task.description,
complexity: 'Low',
approach: "Direct implementation based on semantic search",
task_count: 1,
task_ids: ['TASK-001'],
exploration_refs: [`${planDir}/exploration-patterns.json`]
}
Write(`${planDir}/plan.json`, JSON.stringify(plan, null, 2))
const taskDetail = {
id: 'TASK-001',
title: task.subject,
description: task.description,
files: [],
convergence: { criteria: ["Implementation complete", "Tests pass"] },
depends_on: []
}
Write(`${planDir}/.task/TASK-001.json`, JSON.stringify(taskDetail, null, 2))
} else {
// Use cli-lite-planning-agent for Medium/High
Task({
subagent_type: "cli-lite-planning-agent",
run_in_background: false,
description: "Generate detailed implementation plan",
prompt: `Generate implementation plan.
Output: ${planDir}/plan.json + ${planDir}/.task/TASK-*.json
Schema: cat ~/.ccw/workflows/cli-templates/schemas/plan-overview-base-schema.json
Task Description: ${task.description}
Explorations: ${explorationManifest}
Complexity: ${complexity}
${specContext ? `Spec Context:
- Requirements: ${specContext.reqIndex.substring(0, 500)}
- Architecture: ${specContext.archIndex.substring(0, 500)}
- Epics: ${specContext.epicsIndex.substring(0, 500)}
Reference REQ-* IDs, follow ADR decisions, reuse Epic/Story decomposition.` : ''}
Requirements: 2-7 tasks, each with id, title, files[].change, convergence.criteria, depends_on`
})
}
```
### Phase 4: Submit for Approval
```javascript
const plan = JSON.parse(Read(`${planDir}/plan.json`))
const planTasks = plan.task_ids.map(id => JSON.parse(Read(`${planDir}/.task/${id}.json`)))
const taskCount = plan.task_count || plan.task_ids.length
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "planner", to: "coordinator",
type: "plan_ready",
summary: `[planner] Plan就绪: ${taskCount}个task, ${complexity}复杂度`,
ref: `${planDir}/plan.json`
})
SendMessage({
type: "message",
recipient: "coordinator",
content: `[planner] ## Plan Ready for Review
**Task**: ${task.subject}
**Complexity**: ${complexity}
**Tasks**: ${taskCount}
### Task Summary
${planTasks.map((t, i) => (i+1) + '. ' + t.title).join('\n')}
### Approach
${plan.approach}
### Plan Location
${planDir}/plan.json
Task Files: ${planDir}/.task/
Please review and approve or request revisions.`,
summary: `[planner] Plan ready: ${taskCount} tasks`
})
// Wait for coordinator response (approve → mark completed, revision → update and resubmit)
```
### Phase 5: After Approval
```javascript
TaskUpdate({ taskId: task.id, status: 'completed' })
// Check for next PLAN task → back to Phase 1
```
## Session Files
```
{sessionFolder}/plan/
├── exploration-{angle}.json
├── explorations-manifest.json
├── planning-context.md
├── plan.json
└── .task/
└── TASK-*.json
```
> **Note**: `sessionFolder` is extracted from task description (`Session: .workflow/.team/TLS-xxx`). Plan outputs go to `plan/` subdirectory. In full-lifecycle mode, spec products are available at `../spec/`.
## Error Handling
| Scenario | Resolution |
|----------|------------|
| No PLAN-* tasks available | Idle, wait for coordinator assignment |
| Exploration agent failure | Skip exploration, plan from task description only |
| Planning agent failure | Fallback to direct Claude planning |
| Plan rejected 3+ times | Notify coordinator with `[planner]` tag, suggest alternative approach |
| Schema file not found | Use basic plan structure without schema validation, log error with `[planner]` tag |
| Spec context load failure | Continue in impl-only mode (no spec context) |
| Session folder not found | Notify coordinator with `[planner]` tag, request session path |
| Unexpected error | Log error via team_msg with `[planner]` tag, report to coordinator |

View File

@@ -0,0 +1,689 @@
# Code Review Command
## Purpose
4-dimension code review analyzing quality, security, architecture, and requirements compliance.
## Review Dimensions
### 1. Quality Review
```javascript
function reviewQuality(files, gitDiff) {
const issues = {
critical: [],
high: [],
medium: [],
low: []
}
for (const file of files) {
const content = file.content
const lines = content.split("\n")
// Check for @ts-ignore / @ts-expect-error
lines.forEach((line, idx) => {
if (line.includes("@ts-ignore") || line.includes("@ts-expect-error")) {
const nextLine = lines[idx + 1] || ""
const hasJustification = line.includes("//") && line.split("//")[1].trim().length > 10
if (!hasJustification) {
issues.high.push({
file: file.path,
line: idx + 1,
type: "ts-ignore-without-justification",
message: "TypeScript error suppression without explanation",
code: line.trim()
})
}
}
})
// Check for 'any' type usage
const anyMatches = Grep("\\bany\\b", { path: file.path, "-n": true })
if (anyMatches) {
anyMatches.forEach(match => {
// Exclude comments and type definitions that are intentionally generic
if (!match.line.includes("//") && !match.line.includes("Generic")) {
issues.high.push({
file: file.path,
line: match.lineNumber,
type: "any-type-usage",
message: "Using 'any' type reduces type safety",
code: match.line.trim()
})
}
})
}
// Check for console.log in production code
const consoleMatches = Grep("console\\.(log|debug|info)", { path: file.path, "-n": true })
if (consoleMatches && !file.path.includes("test")) {
consoleMatches.forEach(match => {
issues.high.push({
file: file.path,
line: match.lineNumber,
type: "console-log",
message: "Console statements should be removed from production code",
code: match.line.trim()
})
})
}
// Check for empty catch blocks
const emptyCatchRegex = /catch\s*\([^)]*\)\s*\{\s*\}/g
let match
while ((match = emptyCatchRegex.exec(content)) !== null) {
const lineNumber = content.substring(0, match.index).split("\n").length
issues.critical.push({
file: file.path,
line: lineNumber,
type: "empty-catch",
message: "Empty catch block silently swallows errors",
code: match[0]
})
}
// Check for magic numbers
const magicNumberRegex = /(?<![a-zA-Z0-9_])((?!0|1|2|10|100|1000)\d{2,})(?![a-zA-Z0-9_])/g
while ((match = magicNumberRegex.exec(content)) !== null) {
const lineNumber = content.substring(0, match.index).split("\n").length
const line = lines[lineNumber - 1]
// Exclude if in comment or constant definition
if (!line.includes("//") && !line.includes("const") && !line.includes("=")) {
issues.medium.push({
file: file.path,
line: lineNumber,
type: "magic-number",
message: "Magic number should be extracted to named constant",
code: line.trim()
})
}
}
// Check for duplicate code (simple heuristic: identical lines)
const lineHashes = new Map()
lines.forEach((line, idx) => {
const trimmed = line.trim()
if (trimmed.length > 30 && !trimmed.startsWith("//")) {
if (!lineHashes.has(trimmed)) {
lineHashes.set(trimmed, [])
}
lineHashes.get(trimmed).push(idx + 1)
}
})
lineHashes.forEach((occurrences, line) => {
if (occurrences.length > 2) {
issues.medium.push({
file: file.path,
line: occurrences[0],
type: "duplicate-code",
message: `Duplicate code found at lines: ${occurrences.join(", ")}`,
code: line
})
}
})
}
return issues
}
```
### 2. Security Review
```javascript
function reviewSecurity(files) {
const issues = {
critical: [],
high: [],
medium: [],
low: []
}
for (const file of files) {
const content = file.content
// Check for eval/exec usage
const evalMatches = Grep("\\b(eval|exec|Function\\(|setTimeout\\(.*string|setInterval\\(.*string)\\b", {
path: file.path,
"-n": true
})
if (evalMatches) {
evalMatches.forEach(match => {
issues.high.push({
file: file.path,
line: match.lineNumber,
type: "dangerous-eval",
message: "eval/exec usage can lead to code injection vulnerabilities",
code: match.line.trim()
})
})
}
// Check for innerHTML/dangerouslySetInnerHTML
const innerHTMLMatches = Grep("(innerHTML|dangerouslySetInnerHTML)", {
path: file.path,
"-n": true
})
if (innerHTMLMatches) {
innerHTMLMatches.forEach(match => {
issues.high.push({
file: file.path,
line: match.lineNumber,
type: "xss-risk",
message: "Direct HTML injection can lead to XSS vulnerabilities",
code: match.line.trim()
})
})
}
// Check for hardcoded secrets
const secretPatterns = [
/api[_-]?key\s*=\s*['"][^'"]{20,}['"]/i,
/password\s*=\s*['"][^'"]+['"]/i,
/secret\s*=\s*['"][^'"]{20,}['"]/i,
/token\s*=\s*['"][^'"]{20,}['"]/i,
/aws[_-]?access[_-]?key/i,
/private[_-]?key\s*=\s*['"][^'"]+['"]/i
]
secretPatterns.forEach(pattern => {
const matches = content.match(new RegExp(pattern, "gm"))
if (matches) {
matches.forEach(match => {
const lineNumber = content.substring(0, content.indexOf(match)).split("\n").length
issues.critical.push({
file: file.path,
line: lineNumber,
type: "hardcoded-secret",
message: "Hardcoded secrets should be moved to environment variables",
code: match.replace(/['"][^'"]+['"]/, "'***'") // Redact secret
})
})
}
})
// Check for SQL injection vectors
const sqlInjectionMatches = Grep("(query|execute)\\s*\\(.*\\+.*\\)", {
path: file.path,
"-n": true
})
if (sqlInjectionMatches) {
sqlInjectionMatches.forEach(match => {
if (!match.line.includes("//") && !match.line.includes("prepared")) {
issues.critical.push({
file: file.path,
line: match.lineNumber,
type: "sql-injection",
message: "String concatenation in SQL queries can lead to SQL injection",
code: match.line.trim()
})
}
})
}
// Check for insecure random
const insecureRandomMatches = Grep("Math\\.random\\(\\)", {
path: file.path,
"-n": true
})
if (insecureRandomMatches) {
insecureRandomMatches.forEach(match => {
// Check if used for security purposes
const context = content.substring(
Math.max(0, content.indexOf(match.line) - 200),
content.indexOf(match.line) + 200
)
if (context.match(/token|key|secret|password|session/i)) {
issues.medium.push({
file: file.path,
line: match.lineNumber,
type: "insecure-random",
message: "Math.random() is not cryptographically secure, use crypto.randomBytes()",
code: match.line.trim()
})
}
})
}
// Check for missing input validation
const functionMatches = Grep("(function|const.*=.*\\(|async.*\\()", {
path: file.path,
"-n": true
})
if (functionMatches) {
functionMatches.forEach(match => {
// Simple heuristic: check if function has parameters but no validation
if (match.line.includes("(") && !match.line.includes("()")) {
const nextLines = content.split("\n").slice(match.lineNumber, match.lineNumber + 5).join("\n")
const hasValidation = nextLines.match(/if\s*\(|throw|assert|validate|check/)
if (!hasValidation && !match.line.includes("test") && !match.line.includes("mock")) {
issues.low.push({
file: file.path,
line: match.lineNumber,
type: "missing-validation",
message: "Function parameters should be validated",
code: match.line.trim()
})
}
}
})
}
}
return issues
}
```
### 3. Architecture Review
```javascript
function reviewArchitecture(files) {
const issues = {
critical: [],
high: [],
medium: [],
low: []
}
for (const file of files) {
const content = file.content
const lines = content.split("\n")
// Check for parent directory imports
const importMatches = Grep("from\\s+['\"](\\.\\./)+", {
path: file.path,
"-n": true
})
if (importMatches) {
importMatches.forEach(match => {
const parentLevels = (match.line.match(/\.\.\//g) || []).length
if (parentLevels > 2) {
issues.high.push({
file: file.path,
line: match.lineNumber,
type: "excessive-parent-imports",
message: `Import traverses ${parentLevels} parent directories, consider restructuring`,
code: match.line.trim()
})
} else if (parentLevels === 2) {
issues.medium.push({
file: file.path,
line: match.lineNumber,
type: "parent-imports",
message: "Consider using absolute imports or restructuring modules",
code: match.line.trim()
})
}
})
}
// Check for large files
const lineCount = lines.length
if (lineCount > 500) {
issues.medium.push({
file: file.path,
line: 1,
type: "large-file",
message: `File has ${lineCount} lines, consider splitting into smaller modules`,
code: `Total lines: ${lineCount}`
})
}
// Check for circular dependencies (simple heuristic)
const imports = lines
.filter(line => line.match(/^import.*from/))
.map(line => {
const match = line.match(/from\s+['"](.+?)['"]/)
return match ? match[1] : null
})
.filter(Boolean)
// Check if any imported file imports this file back
for (const importPath of imports) {
const resolvedPath = resolveImportPath(file.path, importPath)
if (resolvedPath && Bash(`test -f ${resolvedPath}`).exitCode === 0) {
const importedContent = Read(resolvedPath)
const reverseImport = importedContent.includes(file.path.replace(/\.[jt]sx?$/, ""))
if (reverseImport) {
issues.critical.push({
file: file.path,
line: 1,
type: "circular-dependency",
message: `Circular dependency detected with ${resolvedPath}`,
code: `${file.path}${resolvedPath}`
})
}
}
}
// Check for tight coupling (many imports from same module)
const importCounts = {}
imports.forEach(imp => {
const baseModule = imp.split("/")[0]
importCounts[baseModule] = (importCounts[baseModule] || 0) + 1
})
Object.entries(importCounts).forEach(([module, count]) => {
if (count > 5) {
issues.medium.push({
file: file.path,
line: 1,
type: "tight-coupling",
message: `File imports ${count} items from '${module}', consider facade pattern`,
code: `Imports from ${module}: ${count}`
})
}
})
// Check for missing abstractions (long functions)
const functionRegex = /(function|const.*=.*\(|async.*\()/g
let match
while ((match = functionRegex.exec(content)) !== null) {
const startLine = content.substring(0, match.index).split("\n").length
const functionBody = extractFunctionBody(content, match.index)
const functionLines = functionBody.split("\n").length
if (functionLines > 50) {
issues.medium.push({
file: file.path,
line: startLine,
type: "long-function",
message: `Function has ${functionLines} lines, consider extracting smaller functions`,
code: match[0].trim()
})
}
}
}
return issues
}
function resolveImportPath(fromFile, importPath) {
if (importPath.startsWith(".")) {
const dir = fromFile.substring(0, fromFile.lastIndexOf("/"))
const resolved = `${dir}/${importPath}`.replace(/\/\.\//g, "/")
// Try with extensions
for (const ext of [".ts", ".js", ".tsx", ".jsx"]) {
if (Bash(`test -f ${resolved}${ext}`).exitCode === 0) {
return `${resolved}${ext}`
}
}
}
return null
}
function extractFunctionBody(content, startIndex) {
let braceCount = 0
let inFunction = false
let body = ""
for (let i = startIndex; i < content.length; i++) {
const char = content[i]
if (char === "{") {
braceCount++
inFunction = true
} else if (char === "}") {
braceCount--
}
if (inFunction) {
body += char
}
if (inFunction && braceCount === 0) {
break
}
}
return body
}
```
### 4. Requirements Verification
```javascript
function verifyRequirements(plan, files, gitDiff) {
const issues = {
critical: [],
high: [],
medium: [],
low: []
}
// Extract acceptance criteria from plan
const acceptanceCriteria = extractAcceptanceCriteria(plan)
// Verify each criterion
for (const criterion of acceptanceCriteria) {
const verified = verifyCriterion(criterion, files, gitDiff)
if (!verified.met) {
issues.high.push({
file: "plan",
line: criterion.lineNumber,
type: "unmet-acceptance-criteria",
message: `Acceptance criterion not met: ${criterion.text}`,
code: criterion.text
})
} else if (verified.partial) {
issues.medium.push({
file: "plan",
line: criterion.lineNumber,
type: "partial-acceptance-criteria",
message: `Acceptance criterion partially met: ${criterion.text}`,
code: criterion.text
})
}
}
// Check for missing error handling
const errorHandlingRequired = plan.match(/error handling|exception|validation/i)
if (errorHandlingRequired) {
const hasErrorHandling = files.some(file =>
file.content.match(/try\s*\{|catch\s*\(|throw\s+new|\.catch\(/)
)
if (!hasErrorHandling) {
issues.high.push({
file: "implementation",
line: 1,
type: "missing-error-handling",
message: "Plan requires error handling but none found in implementation",
code: "No try-catch or error handling detected"
})
}
}
// Check for missing tests
const testingRequired = plan.match(/test|testing|coverage/i)
if (testingRequired) {
const hasTests = files.some(file =>
file.path.match(/\.(test|spec)\.[jt]sx?$/)
)
if (!hasTests) {
issues.medium.push({
file: "implementation",
line: 1,
type: "missing-tests",
message: "Plan requires tests but no test files found",
code: "No test files detected"
})
}
}
return issues
}
function extractAcceptanceCriteria(plan) {
const criteria = []
const lines = plan.split("\n")
let inAcceptanceSection = false
lines.forEach((line, idx) => {
if (line.match(/acceptance criteria/i)) {
inAcceptanceSection = true
} else if (line.match(/^##/)) {
inAcceptanceSection = false
} else if (inAcceptanceSection && line.match(/^[-*]\s+/)) {
criteria.push({
text: line.replace(/^[-*]\s+/, "").trim(),
lineNumber: idx + 1
})
}
})
return criteria
}
function verifyCriterion(criterion, files, gitDiff) {
// Extract keywords from criterion
const keywords = criterion.text.toLowerCase().match(/\b\w{4,}\b/g) || []
// Check if keywords appear in implementation
let matchCount = 0
for (const file of files) {
const content = file.content.toLowerCase()
for (const keyword of keywords) {
if (content.includes(keyword)) {
matchCount++
}
}
}
const matchRatio = matchCount / keywords.length
return {
met: matchRatio >= 0.7,
partial: matchRatio >= 0.4 && matchRatio < 0.7,
matchRatio: matchRatio
}
}
```
## Verdict Determination
```javascript
function determineVerdict(qualityIssues, securityIssues, architectureIssues, requirementIssues) {
const allIssues = {
critical: [
...qualityIssues.critical,
...securityIssues.critical,
...architectureIssues.critical,
...requirementIssues.critical
],
high: [
...qualityIssues.high,
...securityIssues.high,
...architectureIssues.high,
...requirementIssues.high
],
medium: [
...qualityIssues.medium,
...securityIssues.medium,
...architectureIssues.medium,
...requirementIssues.medium
],
low: [
...qualityIssues.low,
...securityIssues.low,
...architectureIssues.low,
...requirementIssues.low
]
}
// BLOCK: Any critical issues
if (allIssues.critical.length > 0) {
return {
verdict: "BLOCK",
reason: `${allIssues.critical.length} critical issue(s) must be fixed`,
blocking_issues: allIssues.critical
}
}
// CONDITIONAL: High or medium issues
if (allIssues.high.length > 0 || allIssues.medium.length > 0) {
return {
verdict: "CONDITIONAL",
reason: `${allIssues.high.length} high and ${allIssues.medium.length} medium issue(s) should be addressed`,
blocking_issues: []
}
}
// APPROVE: Only low issues or none
return {
verdict: "APPROVE",
reason: allIssues.low.length > 0
? `${allIssues.low.length} low-priority issue(s) noted`
: "No issues found",
blocking_issues: []
}
}
```
## Report Formatting
```javascript
function formatCodeReviewReport(report) {
const { verdict, dimensions, recommendations, blocking_issues } = report
let markdown = `# Code Review Report\n\n`
markdown += `**Verdict**: ${verdict}\n\n`
if (blocking_issues.length > 0) {
markdown += `## Blocking Issues\n\n`
blocking_issues.forEach(issue => {
markdown += `- **${issue.type}** (${issue.file}:${issue.line})\n`
markdown += ` ${issue.message}\n`
markdown += ` \`\`\`\n ${issue.code}\n \`\`\`\n\n`
})
}
markdown += `## Review Dimensions\n\n`
markdown += `### Quality Issues\n`
markdown += formatIssuesByDimension(dimensions.quality)
markdown += `### Security Issues\n`
markdown += formatIssuesByDimension(dimensions.security)
markdown += `### Architecture Issues\n`
markdown += formatIssuesByDimension(dimensions.architecture)
markdown += `### Requirements Issues\n`
markdown += formatIssuesByDimension(dimensions.requirements)
if (recommendations.length > 0) {
markdown += `## Recommendations\n\n`
recommendations.forEach((rec, i) => {
markdown += `${i + 1}. ${rec}\n`
})
}
return markdown
}
function formatIssuesByDimension(issues) {
let markdown = ""
const severities = ["critical", "high", "medium", "low"]
severities.forEach(severity => {
if (issues[severity].length > 0) {
markdown += `\n**${severity.toUpperCase()}** (${issues[severity].length})\n\n`
issues[severity].forEach(issue => {
markdown += `- ${issue.message} (${issue.file}:${issue.line})\n`
markdown += ` \`${issue.code}\`\n\n`
})
}
})
return markdown || "No issues found.\n\n"
}
```

View File

@@ -0,0 +1,845 @@
# Spec Quality Command
## Purpose
5-dimension spec quality check with readiness report generation and quality gate determination.
## Quality Dimensions
### 1. Completeness (Weight: 25%)
```javascript
function scoreCompleteness(specDocs) {
const requiredSections = {
"product-brief": [
"Vision Statement",
"Problem Statement",
"Target Audience",
"Success Metrics",
"Constraints"
],
"prd": [
"Goals",
"Requirements",
"User Stories",
"Acceptance Criteria",
"Non-Functional Requirements"
],
"architecture": [
"System Overview",
"Component Design",
"Data Models",
"API Specifications",
"Technology Stack"
],
"user-stories": [
"Story List",
"Acceptance Criteria",
"Priority",
"Estimation"
],
"implementation-plan": [
"Task Breakdown",
"Dependencies",
"Timeline",
"Resource Allocation"
],
"test-strategy": [
"Test Scope",
"Test Cases",
"Coverage Goals",
"Test Environment"
]
}
let totalScore = 0
let totalWeight = 0
const details = []
for (const doc of specDocs) {
const phase = doc.phase
const expectedSections = requiredSections[phase] || []
if (expectedSections.length === 0) continue
let presentCount = 0
let substantialCount = 0
for (const section of expectedSections) {
const sectionRegex = new RegExp(`##\\s+${section}`, "i")
const sectionMatch = doc.content.match(sectionRegex)
if (sectionMatch) {
presentCount++
// Check if section has substantial content (not just header)
const sectionIndex = doc.content.indexOf(sectionMatch[0])
const nextSectionIndex = doc.content.indexOf("\n##", sectionIndex + 1)
const sectionContent = nextSectionIndex > -1
? doc.content.substring(sectionIndex, nextSectionIndex)
: doc.content.substring(sectionIndex)
// Substantial = more than 100 chars excluding header
const contentWithoutHeader = sectionContent.replace(sectionRegex, "").trim()
if (contentWithoutHeader.length > 100) {
substantialCount++
}
}
}
const presentRatio = presentCount / expectedSections.length
const substantialRatio = substantialCount / expectedSections.length
// Score: 50% for presence, 50% for substance
const docScore = (presentRatio * 50) + (substantialRatio * 50)
totalScore += docScore
totalWeight += 100
details.push({
phase: phase,
score: docScore,
present: presentCount,
substantial: substantialCount,
expected: expectedSections.length,
missing: expectedSections.filter(s => !doc.content.match(new RegExp(`##\\s+${s}`, "i")))
})
}
const overallScore = totalWeight > 0 ? (totalScore / totalWeight) * 100 : 0
return {
score: overallScore,
weight: 25,
weighted_score: overallScore * 0.25,
details: details
}
}
```
### 2. Consistency (Weight: 20%)
```javascript
function scoreConsistency(specDocs) {
const issues = []
// 1. Terminology consistency
const terminologyMap = new Map()
for (const doc of specDocs) {
// Extract key terms (capitalized phrases, technical terms)
const terms = doc.content.match(/\b[A-Z][a-z]+(?:\s+[A-Z][a-z]+)*\b/g) || []
terms.forEach(term => {
const normalized = term.toLowerCase()
if (!terminologyMap.has(normalized)) {
terminologyMap.set(normalized, new Set())
}
terminologyMap.get(normalized).add(term)
})
}
// Find inconsistent terminology (same concept, different casing/spelling)
terminologyMap.forEach((variants, normalized) => {
if (variants.size > 1) {
issues.push({
type: "terminology",
severity: "medium",
message: `Inconsistent terminology: ${[...variants].join(", ")}`,
suggestion: `Standardize to one variant`
})
}
})
// 2. Format consistency
const headerStyles = new Map()
for (const doc of specDocs) {
const headers = doc.content.match(/^#{1,6}\s+.+$/gm) || []
headers.forEach(header => {
const level = header.match(/^#+/)[0].length
const style = header.includes("**") ? "bold" : "plain"
const key = `level-${level}`
if (!headerStyles.has(key)) {
headerStyles.set(key, new Set())
}
headerStyles.get(key).add(style)
})
}
headerStyles.forEach((styles, level) => {
if (styles.size > 1) {
issues.push({
type: "format",
severity: "low",
message: `Inconsistent header style at ${level}: ${[...styles].join(", ")}`,
suggestion: "Use consistent header formatting"
})
}
})
// 3. Reference consistency
const references = new Map()
for (const doc of specDocs) {
// Extract references to other documents/sections
const refs = doc.content.match(/\[.*?\]\(.*?\)/g) || []
refs.forEach(ref => {
const linkMatch = ref.match(/\((.*?)\)/)
if (linkMatch) {
const link = linkMatch[1]
if (!references.has(link)) {
references.set(link, [])
}
references.get(link).push(doc.phase)
}
})
}
// Check for broken references
references.forEach((sources, link) => {
if (link.startsWith("./") || link.startsWith("../")) {
// Check if file exists
const exists = Bash(`test -f ${link}`).exitCode === 0
if (!exists) {
issues.push({
type: "reference",
severity: "high",
message: `Broken reference: ${link} (referenced in ${sources.join(", ")})`,
suggestion: "Fix or remove broken reference"
})
}
}
})
// 4. Naming convention consistency
const namingPatterns = {
camelCase: /\b[a-z]+(?:[A-Z][a-z]+)+\b/g,
PascalCase: /\b[A-Z][a-z]+(?:[A-Z][a-z]+)+\b/g,
snake_case: /\b[a-z]+(?:_[a-z]+)+\b/g,
kebab_case: /\b[a-z]+(?:-[a-z]+)+\b/g
}
const namingCounts = {}
for (const doc of specDocs) {
Object.entries(namingPatterns).forEach(([pattern, regex]) => {
const matches = doc.content.match(regex) || []
namingCounts[pattern] = (namingCounts[pattern] || 0) + matches.length
})
}
const dominantPattern = Object.entries(namingCounts)
.sort((a, b) => b[1] - a[1])[0]?.[0]
Object.entries(namingCounts).forEach(([pattern, count]) => {
if (pattern !== dominantPattern && count > 10) {
issues.push({
type: "naming",
severity: "low",
message: `Mixed naming conventions: ${pattern} (${count} occurrences) vs ${dominantPattern}`,
suggestion: `Standardize to ${dominantPattern}`
})
}
})
// Calculate score based on issues
const severityWeights = { high: 10, medium: 5, low: 2 }
const totalPenalty = issues.reduce((sum, issue) => sum + severityWeights[issue.severity], 0)
const maxPenalty = 100 // Arbitrary max for normalization
const score = Math.max(0, 100 - (totalPenalty / maxPenalty) * 100)
return {
score: score,
weight: 20,
weighted_score: score * 0.20,
issues: issues,
details: {
terminology_issues: issues.filter(i => i.type === "terminology").length,
format_issues: issues.filter(i => i.type === "format").length,
reference_issues: issues.filter(i => i.type === "reference").length,
naming_issues: issues.filter(i => i.type === "naming").length
}
}
}
```
### 3. Traceability (Weight: 25%)
```javascript
function scoreTraceability(specDocs) {
const chains = []
// Extract traceability elements
const goals = extractElements(specDocs, "product-brief", /^[-*]\s+Goal:\s*(.+)$/gm)
const requirements = extractElements(specDocs, "prd", /^[-*]\s+(?:REQ-\d+|Requirement):\s*(.+)$/gm)
const components = extractElements(specDocs, "architecture", /^[-*]\s+(?:Component|Module):\s*(.+)$/gm)
const stories = extractElements(specDocs, "user-stories", /^[-*]\s+(?:US-\d+|Story):\s*(.+)$/gm)
// Build traceability chains: Goals → Requirements → Components → Stories
for (const goal of goals) {
const chain = {
goal: goal.text,
requirements: [],
components: [],
stories: [],
complete: false
}
// Find requirements that reference this goal
const goalKeywords = extractKeywords(goal.text)
for (const req of requirements) {
if (hasKeywordOverlap(req.text, goalKeywords, 0.3)) {
chain.requirements.push(req.text)
// Find components that implement this requirement
const reqKeywords = extractKeywords(req.text)
for (const comp of components) {
if (hasKeywordOverlap(comp.text, reqKeywords, 0.3)) {
chain.components.push(comp.text)
}
}
// Find stories that implement this requirement
for (const story of stories) {
if (hasKeywordOverlap(story.text, reqKeywords, 0.3)) {
chain.stories.push(story.text)
}
}
}
}
// Check if chain is complete
chain.complete = chain.requirements.length > 0 &&
chain.components.length > 0 &&
chain.stories.length > 0
chains.push(chain)
}
// Calculate score
const completeChains = chains.filter(c => c.complete).length
const totalChains = chains.length
const score = totalChains > 0 ? (completeChains / totalChains) * 100 : 0
// Identify weak links
const weakLinks = []
chains.forEach((chain, idx) => {
if (!chain.complete) {
if (chain.requirements.length === 0) {
weakLinks.push(`Goal ${idx + 1} has no linked requirements`)
}
if (chain.components.length === 0) {
weakLinks.push(`Goal ${idx + 1} has no linked components`)
}
if (chain.stories.length === 0) {
weakLinks.push(`Goal ${idx + 1} has no linked stories`)
}
}
})
return {
score: score,
weight: 25,
weighted_score: score * 0.25,
details: {
total_chains: totalChains,
complete_chains: completeChains,
weak_links: weakLinks
},
chains: chains
}
}
function extractElements(specDocs, phase, regex) {
const elements = []
const doc = specDocs.find(d => d.phase === phase)
if (doc) {
let match
while ((match = regex.exec(doc.content)) !== null) {
elements.push({
text: match[1].trim(),
phase: phase
})
}
}
return elements
}
function extractKeywords(text) {
// Extract meaningful words (4+ chars, not common words)
const commonWords = new Set(["that", "this", "with", "from", "have", "will", "should", "must", "can"])
const words = text.toLowerCase().match(/\b\w{4,}\b/g) || []
return words.filter(w => !commonWords.has(w))
}
function hasKeywordOverlap(text, keywords, threshold) {
const textLower = text.toLowerCase()
const matchCount = keywords.filter(kw => textLower.includes(kw)).length
return matchCount / keywords.length >= threshold
}
```
### 4. Depth (Weight: 20%)
```javascript
function scoreDepth(specDocs) {
const dimensions = []
// 1. Acceptance Criteria Testability
const acDoc = specDocs.find(d => d.phase === "prd" || d.phase === "user-stories")
if (acDoc) {
const acMatches = acDoc.content.match(/Acceptance Criteria:[\s\S]*?(?=\n##|\n\n[-*]|$)/gi) || []
let testableCount = 0
let totalCount = 0
acMatches.forEach(section => {
const criteria = section.match(/^[-*]\s+(.+)$/gm) || []
totalCount += criteria.length
criteria.forEach(criterion => {
// Testable if contains measurable verbs or specific conditions
const testablePatterns = [
/\b(should|must|will)\s+(display|show|return|validate|check|verify|calculate|send|receive)\b/i,
/\b(when|if|given)\b.*\b(then|should|must)\b/i,
/\b\d+\b/, // Contains numbers (measurable)
/\b(success|error|fail|pass)\b/i
]
const isTestable = testablePatterns.some(pattern => pattern.test(criterion))
if (isTestable) testableCount++
})
})
const acScore = totalCount > 0 ? (testableCount / totalCount) * 100 : 0
dimensions.push({
name: "Acceptance Criteria Testability",
score: acScore,
testable: testableCount,
total: totalCount
})
}
// 2. ADR Justification
const archDoc = specDocs.find(d => d.phase === "architecture")
if (archDoc) {
const adrMatches = archDoc.content.match(/##\s+(?:ADR|Decision)[\s\S]*?(?=\n##|$)/gi) || []
let justifiedCount = 0
let totalCount = adrMatches.length
adrMatches.forEach(adr => {
// Justified if contains rationale, alternatives, or consequences
const hasJustification = adr.match(/\b(rationale|reason|because|alternative|consequence|trade-?off)\b/i)
if (hasJustification) justifiedCount++
})
const adrScore = totalCount > 0 ? (justifiedCount / totalCount) * 100 : 100 // Default 100 if no ADRs
dimensions.push({
name: "ADR Justification",
score: adrScore,
justified: justifiedCount,
total: totalCount
})
}
// 3. User Stories Estimability
const storiesDoc = specDocs.find(d => d.phase === "user-stories")
if (storiesDoc) {
const storyMatches = storiesDoc.content.match(/^[-*]\s+(?:US-\d+|Story)[\s\S]*?(?=\n[-*]|$)/gim) || []
let estimableCount = 0
let totalCount = storyMatches.length
storyMatches.forEach(story => {
// Estimable if has clear scope, AC, and no ambiguity
const hasScope = story.match(/\b(as a|I want|so that)\b/i)
const hasAC = story.match(/acceptance criteria/i)
const hasEstimate = story.match(/\b(points?|hours?|days?|estimate)\b/i)
if ((hasScope && hasAC) || hasEstimate) estimableCount++
})
const storiesScore = totalCount > 0 ? (estimableCount / totalCount) * 100 : 0
dimensions.push({
name: "User Stories Estimability",
score: storiesScore,
estimable: estimableCount,
total: totalCount
})
}
// 4. Technical Detail Sufficiency
const techDocs = specDocs.filter(d => d.phase === "architecture" || d.phase === "implementation-plan")
let detailScore = 0
if (techDocs.length > 0) {
const detailIndicators = [
/```[\s\S]*?```/, // Code blocks
/\b(API|endpoint|schema|model|interface|class|function)\b/i,
/\b(GET|POST|PUT|DELETE|PATCH)\b/, // HTTP methods
/\b(database|table|collection|index)\b/i,
/\b(authentication|authorization|security)\b/i
]
let indicatorCount = 0
techDocs.forEach(doc => {
detailIndicators.forEach(pattern => {
if (pattern.test(doc.content)) indicatorCount++
})
})
detailScore = Math.min(100, (indicatorCount / (detailIndicators.length * techDocs.length)) * 100)
dimensions.push({
name: "Technical Detail Sufficiency",
score: detailScore,
indicators_found: indicatorCount,
indicators_expected: detailIndicators.length * techDocs.length
})
}
// Calculate overall depth score
const overallScore = dimensions.reduce((sum, d) => sum + d.score, 0) / dimensions.length
return {
score: overallScore,
weight: 20,
weighted_score: overallScore * 0.20,
dimensions: dimensions
}
}
```
### 5. Requirement Coverage (Weight: 10%)
```javascript
function scoreRequirementCoverage(specDocs, originalRequirements) {
// Extract original requirements from task description or initial brief
const originalReqs = originalRequirements || extractOriginalRequirements(specDocs)
if (originalReqs.length === 0) {
return {
score: 100, // No requirements to cover
weight: 10,
weighted_score: 10,
details: {
total: 0,
covered: 0,
uncovered: []
}
}
}
// Extract all requirements from spec documents
const specReqs = []
for (const doc of specDocs) {
const reqMatches = doc.content.match(/^[-*]\s+(?:REQ-\d+|Requirement|Feature):\s*(.+)$/gm) || []
reqMatches.forEach(match => {
specReqs.push(match.replace(/^[-*]\s+(?:REQ-\d+|Requirement|Feature):\s*/, "").trim())
})
}
// Map original requirements to spec requirements
const coverage = []
for (const origReq of originalReqs) {
const keywords = extractKeywords(origReq)
const covered = specReqs.some(specReq => hasKeywordOverlap(specReq, keywords, 0.4))
coverage.push({
requirement: origReq,
covered: covered
})
}
const coveredCount = coverage.filter(c => c.covered).length
const score = (coveredCount / originalReqs.length) * 100
return {
score: score,
weight: 10,
weighted_score: score * 0.10,
details: {
total: originalReqs.length,
covered: coveredCount,
uncovered: coverage.filter(c => !c.covered).map(c => c.requirement)
}
}
}
function extractOriginalRequirements(specDocs) {
// Try to find original requirements in product brief
const briefDoc = specDocs.find(d => d.phase === "product-brief")
if (!briefDoc) return []
const reqSection = briefDoc.content.match(/##\s+(?:Requirements|Objectives)[\s\S]*?(?=\n##|$)/i)
if (!reqSection) return []
const reqs = reqSection[0].match(/^[-*]\s+(.+)$/gm) || []
return reqs.map(r => r.replace(/^[-*]\s+/, "").trim())
}
```
## Quality Gate Determination
```javascript
function determineQualityGate(overallScore, coverageScore) {
// PASS: Score ≥80% AND coverage ≥70%
if (overallScore >= 80 && coverageScore >= 70) {
return {
gate: "PASS",
message: "Specification meets quality standards and is ready for implementation",
action: "Proceed to implementation phase"
}
}
// FAIL: Score <60% OR coverage <50%
if (overallScore < 60 || coverageScore < 50) {
return {
gate: "FAIL",
message: "Specification requires major revisions before implementation",
action: "Address critical gaps and resubmit for review"
}
}
// REVIEW: Between PASS and FAIL
return {
gate: "REVIEW",
message: "Specification needs improvements but may proceed with caution",
action: "Address recommendations and consider re-review"
}
}
```
## Readiness Report Generation
```javascript
function formatReadinessReport(report, specDocs) {
const { overall_score, quality_gate, dimensions, phase_gates } = report
let markdown = `# Specification Readiness Report\n\n`
markdown += `**Generated**: ${new Date().toISOString()}\n\n`
markdown += `**Overall Score**: ${overall_score.toFixed(1)}%\n\n`
markdown += `**Quality Gate**: ${quality_gate.gate} - ${quality_gate.message}\n\n`
markdown += `**Recommended Action**: ${quality_gate.action}\n\n`
markdown += `---\n\n`
markdown += `## Dimension Scores\n\n`
markdown += `| Dimension | Score | Weight | Weighted Score |\n`
markdown += `|-----------|-------|--------|----------------|\n`
Object.entries(dimensions).forEach(([name, data]) => {
markdown += `| ${name} | ${data.score.toFixed(1)}% | ${data.weight}% | ${data.weighted_score.toFixed(1)}% |\n`
})
markdown += `\n---\n\n`
// Completeness Details
markdown += `## Completeness Analysis\n\n`
dimensions.completeness.details.forEach(detail => {
markdown += `### ${detail.phase}\n`
markdown += `- Score: ${detail.score.toFixed(1)}%\n`
markdown += `- Sections Present: ${detail.present}/${detail.expected}\n`
markdown += `- Substantial Content: ${detail.substantial}/${detail.expected}\n`
if (detail.missing.length > 0) {
markdown += `- Missing: ${detail.missing.join(", ")}\n`
}
markdown += `\n`
})
// Consistency Details
markdown += `## Consistency Analysis\n\n`
if (dimensions.consistency.issues.length > 0) {
markdown += `**Issues Found**: ${dimensions.consistency.issues.length}\n\n`
dimensions.consistency.issues.forEach(issue => {
markdown += `- **${issue.severity.toUpperCase()}**: ${issue.message}\n`
markdown += ` *Suggestion*: ${issue.suggestion}\n\n`
})
} else {
markdown += `No consistency issues found.\n\n`
}
// Traceability Details
markdown += `## Traceability Analysis\n\n`
markdown += `- Complete Chains: ${dimensions.traceability.details.complete_chains}/${dimensions.traceability.details.total_chains}\n\n`
if (dimensions.traceability.details.weak_links.length > 0) {
markdown += `**Weak Links**:\n`
dimensions.traceability.details.weak_links.forEach(link => {
markdown += `- ${link}\n`
})
markdown += `\n`
}
// Depth Details
markdown += `## Depth Analysis\n\n`
dimensions.depth.dimensions.forEach(dim => {
markdown += `### ${dim.name}\n`
markdown += `- Score: ${dim.score.toFixed(1)}%\n`
if (dim.testable !== undefined) {
markdown += `- Testable: ${dim.testable}/${dim.total}\n`
}
if (dim.justified !== undefined) {
markdown += `- Justified: ${dim.justified}/${dim.total}\n`
}
if (dim.estimable !== undefined) {
markdown += `- Estimable: ${dim.estimable}/${dim.total}\n`
}
markdown += `\n`
})
// Coverage Details
markdown += `## Requirement Coverage\n\n`
markdown += `- Covered: ${dimensions.coverage.details.covered}/${dimensions.coverage.details.total}\n`
if (dimensions.coverage.details.uncovered.length > 0) {
markdown += `\n**Uncovered Requirements**:\n`
dimensions.coverage.details.uncovered.forEach(req => {
markdown += `- ${req}\n`
})
}
markdown += `\n`
// Phase Gates
if (phase_gates) {
markdown += `---\n\n`
markdown += `## Phase-Level Quality Gates\n\n`
Object.entries(phase_gates).forEach(([phase, gate]) => {
markdown += `### ${phase}\n`
markdown += `- Gate: ${gate.status}\n`
markdown += `- Score: ${gate.score.toFixed(1)}%\n`
if (gate.issues.length > 0) {
markdown += `- Issues: ${gate.issues.join(", ")}\n`
}
markdown += `\n`
})
}
return markdown
}
```
## Spec Summary Generation
```javascript
function formatSpecSummary(specDocs, report) {
let markdown = `# Specification Summary\n\n`
markdown += `**Overall Quality Score**: ${report.overall_score.toFixed(1)}%\n`
markdown += `**Quality Gate**: ${report.quality_gate.gate}\n\n`
markdown += `---\n\n`
// Document Overview
markdown += `## Documents Reviewed\n\n`
specDocs.forEach(doc => {
markdown += `### ${doc.phase}\n`
markdown += `- Path: ${doc.path}\n`
markdown += `- Size: ${doc.content.length} characters\n`
// Extract key sections
const sections = doc.content.match(/^##\s+(.+)$/gm) || []
if (sections.length > 0) {
markdown += `- Sections: ${sections.map(s => s.replace(/^##\s+/, "")).join(", ")}\n`
}
markdown += `\n`
})
markdown += `---\n\n`
// Key Findings
markdown += `## Key Findings\n\n`
// Strengths
const strengths = []
Object.entries(report.dimensions).forEach(([name, data]) => {
if (data.score >= 80) {
strengths.push(`${name}: ${data.score.toFixed(1)}%`)
}
})
if (strengths.length > 0) {
markdown += `### Strengths\n`
strengths.forEach(s => markdown += `- ${s}\n`)
markdown += `\n`
}
// Areas for Improvement
const improvements = []
Object.entries(report.dimensions).forEach(([name, data]) => {
if (data.score < 70) {
improvements.push(`${name}: ${data.score.toFixed(1)}%`)
}
})
if (improvements.length > 0) {
markdown += `### Areas for Improvement\n`
improvements.forEach(i => markdown += `- ${i}\n`)
markdown += `\n`
}
// Recommendations
if (report.recommendations && report.recommendations.length > 0) {
markdown += `### Recommendations\n`
report.recommendations.forEach((rec, i) => {
markdown += `${i + 1}. ${rec}\n`
})
markdown += `\n`
}
return markdown
}
```
## Phase-Level Quality Gates
```javascript
function calculatePhaseGates(specDocs) {
const gates = {}
for (const doc of specDocs) {
const phase = doc.phase
const issues = []
let score = 100
// Check minimum content threshold
if (doc.content.length < 500) {
issues.push("Insufficient content")
score -= 30
}
// Check for required sections (phase-specific)
const requiredSections = getRequiredSections(phase)
const missingSections = requiredSections.filter(section =>
!doc.content.match(new RegExp(`##\\s+${section}`, "i"))
)
if (missingSections.length > 0) {
issues.push(`Missing sections: ${missingSections.join(", ")}`)
score -= missingSections.length * 15
}
// Determine gate status
let status = "PASS"
if (score < 60) status = "FAIL"
else if (score < 80) status = "REVIEW"
gates[phase] = {
status: status,
score: Math.max(0, score),
issues: issues
}
}
return gates
}
function getRequiredSections(phase) {
const sectionMap = {
"product-brief": ["Vision", "Problem", "Target Audience"],
"prd": ["Goals", "Requirements", "User Stories"],
"architecture": ["Overview", "Components", "Data Models"],
"user-stories": ["Stories", "Acceptance Criteria"],
"implementation-plan": ["Tasks", "Dependencies"],
"test-strategy": ["Test Cases", "Coverage"]
}
return sectionMap[phase] || []
}
```

View File

@@ -0,0 +1,429 @@
# Reviewer Role
## 1. Role Identity
- **Name**: reviewer
- **Task Prefix**: REVIEW-* + QUALITY-*
- **Output Tag**: `[reviewer]`
- **Responsibility**: Discover Task → Branch by Prefix → Review/Score → Report
## 2. Role Boundaries
### MUST
- Only process REVIEW-* and QUALITY-* tasks
- Communicate only with coordinator
- Generate readiness-report.md for QUALITY tasks
- Tag all outputs with `[reviewer]`
### MUST NOT
- Create tasks
- Contact other workers directly
- Modify source code
- Skip quality dimensions
- Approve without verification
## 3. Message Types
| Type | Direction | Purpose | Format |
|------|-----------|---------|--------|
| `task_request` | FROM coordinator | Receive REVIEW-*/QUALITY-* task assignment | `{ type: "task_request", task_id, description, review_mode }` |
| `task_complete` | TO coordinator | Report review success | `{ type: "task_complete", task_id, status: "success", verdict, score, issues }` |
| `task_failed` | TO coordinator | Report review failure | `{ type: "task_failed", task_id, error }` |
## 4. Message Bus
**Primary**: Use `team_msg` for all coordinator communication with `[reviewer]` tag:
```javascript
// Code review completion
team_msg({
to: "coordinator",
type: "task_complete",
task_id: "REVIEW-001",
status: "success",
verdict: "APPROVE",
issues: { critical: 0, high: 2, medium: 5, low: 3 },
recommendations: ["Fix console.log statements", "Add error handling"]
}, "[reviewer]")
// Spec quality completion
team_msg({
to: "coordinator",
type: "task_complete",
task_id: "QUALITY-001",
status: "success",
overall_score: 85.5,
quality_gate: "PASS",
dimensions: {
completeness: 90,
consistency: 85,
traceability: 80,
depth: 88,
coverage: 82
}
}, "[reviewer]")
```
**CLI Fallback**: When message bus unavailable, write to `.workflow/.team/messages/reviewer-{timestamp}.json`
## 5. Toolbox
### Available Commands
- `commands/code-review.md` - 4-dimension code review (quality, security, architecture, requirements)
- `commands/spec-quality.md` - 5-dimension spec quality check (completeness, consistency, traceability, depth, coverage)
### CLI Capabilities
- None (uses Grep-based analysis)
## 6. Execution (5-Phase) - Dual-Prefix
### Phase 1: Task Discovery
**Dual Prefix Filter**:
```javascript
const tasks = Glob(".workflow/.team/tasks/{REVIEW,QUALITY}-*.json")
.filter(task => task.status === "pending" && task.assigned_to === "reviewer")
// Determine review mode
const reviewMode = task.task_id.startsWith("REVIEW-") ? "code" : "spec"
```
### Phase 2: Context Loading (Branch by Mode)
**Code Review Context (REVIEW-*)**:
```javascript
if (reviewMode === "code") {
// Load plan
const planPath = task.metadata?.plan_path || ".workflow/plan.md"
const plan = Read(planPath)
// Get git diff
const implTaskId = task.metadata?.impl_task_id
const gitDiff = Bash("git diff HEAD").stdout
// Load modified files
const modifiedFiles = Bash("git diff --name-only HEAD").stdout.split("\n").filter(Boolean)
const fileContents = modifiedFiles.map(f => ({
path: f,
content: Read(f)
}))
// Load test results if available
const testTaskId = task.metadata?.test_task_id
const testResults = testTaskId ? Read(`.workflow/.team/tasks/${testTaskId}.json`) : null
}
```
**Spec Quality Context (QUALITY-*)**:
```javascript
if (reviewMode === "spec") {
// Load session folder
const sessionFolder = task.metadata?.session_folder || ".workflow/.sessions/latest"
// Load quality gates
const qualityGates = task.metadata?.quality_gates || {
pass_threshold: 80,
fail_threshold: 60,
coverage_threshold: 70
}
// Load all spec documents
const specDocs = Glob(`${sessionFolder}/**/*.md`).map(path => ({
path: path,
content: Read(path),
phase: extractPhase(path)
}))
}
```
### Phase 3: Review Execution (Delegate by Mode)
**Code Review**:
```javascript
if (reviewMode === "code") {
const codeReviewCommand = Read("commands/code-review.md")
// Command handles:
// - reviewQuality (ts-ignore, any, console.log, empty catch)
// - reviewSecurity (eval/exec, secrets, SQL injection, XSS)
// - reviewArchitecture (parent imports, large files)
// - verifyRequirements (plan acceptance criteria vs implementation)
// - Verdict determination (BLOCK/CONDITIONAL/APPROVE)
}
```
**Spec Quality**:
```javascript
if (reviewMode === "spec") {
const specQualityCommand = Read("commands/spec-quality.md")
// Command handles:
// - scoreCompleteness (section content checks)
// - scoreConsistency (terminology, format, references)
// - scoreTraceability (goals → reqs → arch → stories chain)
// - scoreDepth (AC testable, ADRs justified, stories estimable)
// - scoreRequirementCoverage (original requirements → document mapping)
// - Quality gate determination (PASS ≥80%, FAIL <60%, else REVIEW)
// - readiness-report.md generation
// - spec-summary.md generation
}
```
### Phase 4: Report Generation (Branch by Mode)
**Code Review Report**:
```javascript
if (reviewMode === "code") {
const report = {
verdict: verdict, // BLOCK | CONDITIONAL | APPROVE
dimensions: {
quality: qualityIssues,
security: securityIssues,
architecture: architectureIssues,
requirements: requirementIssues
},
recommendations: recommendations,
blocking_issues: blockingIssues
}
// Write review report
Write(`.workflow/.team/reviews/${task.task_id}-report.md`, formatCodeReviewReport(report))
}
```
**Spec Quality Report**:
```javascript
if (reviewMode === "spec") {
const report = {
overall_score: overallScore,
quality_gate: qualityGate, // PASS | REVIEW | FAIL
dimensions: {
completeness: completenessScore,
consistency: consistencyScore,
traceability: traceabilityScore,
depth: depthScore,
coverage: coverageScore
},
phase_gates: phaseGates,
recommendations: recommendations
}
// Write readiness report
Write(`${sessionFolder}/readiness-report.md`, formatReadinessReport(report))
// Write spec summary
Write(`${sessionFolder}/spec-summary.md`, formatSpecSummary(specDocs, report))
}
```
### Phase 5: Report to Coordinator (Branch by Mode)
**Code Review Completion**:
```javascript
if (reviewMode === "code") {
team_msg({
to: "coordinator",
type: "task_complete",
task_id: task.task_id,
status: "success",
verdict: verdict,
issues: {
critical: blockingIssues.length,
high: highIssues.length,
medium: mediumIssues.length,
low: lowIssues.length
},
recommendations: recommendations,
report_path: `.workflow/.team/reviews/${task.task_id}-report.md`,
timestamp: new Date().toISOString()
}, "[reviewer]")
}
```
**Spec Quality Completion**:
```javascript
if (reviewMode === "spec") {
team_msg({
to: "coordinator",
type: "task_complete",
task_id: task.task_id,
status: "success",
overall_score: overallScore,
quality_gate: qualityGate,
dimensions: {
completeness: completenessScore,
consistency: consistencyScore,
traceability: traceabilityScore,
depth: depthScore,
coverage: coverageScore
},
report_path: `${sessionFolder}/readiness-report.md`,
summary_path: `${sessionFolder}/spec-summary.md`,
timestamp: new Date().toISOString()
}, "[reviewer]")
}
```
## 7. Code Review Dimensions
### Quality Dimension
**Anti-patterns**:
- `@ts-ignore` / `@ts-expect-error` without justification
- `any` type usage
- `console.log` in production code
- Empty catch blocks
- Magic numbers
- Duplicate code
**Severity**:
- Critical: Empty catch, any in public APIs
- High: @ts-ignore without comment, console.log
- Medium: Magic numbers, duplicate code
- Low: Minor style issues
### Security Dimension
**Vulnerabilities**:
- `eval()` / `exec()` usage
- `innerHTML` / `dangerouslySetInnerHTML`
- Hardcoded secrets (API keys, passwords)
- SQL injection vectors
- XSS vulnerabilities
- Insecure dependencies
**Severity**:
- Critical: Hardcoded secrets, SQL injection
- High: eval/exec, innerHTML
- Medium: Insecure dependencies
- Low: Missing input validation
### Architecture Dimension
**Issues**:
- Parent directory imports (`../../../`)
- Large files (>500 lines)
- Circular dependencies
- Missing abstractions
- Tight coupling
**Severity**:
- Critical: Circular dependencies
- High: Excessive parent imports (>2 levels)
- Medium: Large files, tight coupling
- Low: Minor structure issues
### Requirements Dimension
**Verification**:
- Acceptance criteria coverage
- Feature completeness
- Edge case handling
- Error handling
**Severity**:
- Critical: Missing core functionality
- High: Incomplete acceptance criteria
- Medium: Missing edge cases
- Low: Minor feature gaps
## 8. Spec Quality Dimensions
### Completeness (Weight: 25%)
**Checks**:
- All required sections present
- Section content depth (not just headers)
- Cross-phase coverage
- Artifact completeness
**Scoring**:
- 100%: All sections with substantial content
- 75%: All sections present, some thin
- 50%: Missing 1-2 sections
- 25%: Missing 3+ sections
- 0%: Critical sections missing
### Consistency (Weight: 20%)
**Checks**:
- Terminology consistency
- Format consistency
- Reference consistency
- Naming conventions
**Scoring**:
- 100%: Fully consistent
- 75%: Minor inconsistencies (1-2)
- 50%: Moderate inconsistencies (3-5)
- 25%: Major inconsistencies (6+)
- 0%: Chaotic inconsistency
### Traceability (Weight: 25%)
**Checks**:
- Goals → Requirements chain
- Requirements → Architecture chain
- Architecture → User Stories chain
- Bidirectional references
**Scoring**:
- 100%: Full traceability chain
- 75%: 1 weak link
- 50%: 2 weak links
- 25%: 3+ weak links
- 0%: No traceability
### Depth (Weight: 20%)
**Checks**:
- Acceptance criteria testable
- ADRs justified
- User stories estimable
- Technical details sufficient
**Scoring**:
- 100%: All items detailed
- 75%: 1-2 shallow items
- 50%: 3-5 shallow items
- 25%: 6+ shallow items
- 0%: All items shallow
### Coverage (Weight: 10%)
**Checks**:
- Original requirements mapped
- All features documented
- All constraints addressed
- All stakeholders considered
**Scoring**:
- 100%: Full coverage (100%)
- 75%: High coverage (80-99%)
- 50%: Moderate coverage (60-79%)
- 25%: Low coverage (40-59%)
- 0%: Minimal coverage (<40%)
## 9. Verdict/Gate Determination
### Code Review Verdicts
| Verdict | Criteria | Action |
|---------|----------|--------|
| **BLOCK** | Critical issues present | Must fix before merge |
| **CONDITIONAL** | High/medium issues only | Fix recommended, merge allowed |
| **APPROVE** | Low issues or none | Ready to merge |
### Spec Quality Gates
| Gate | Criteria | Action |
|------|----------|--------|
| **PASS** | Score ≥80% AND coverage ≥70% | Ready for implementation |
| **REVIEW** | Score 60-79% OR coverage 50-69% | Revisions recommended |
| **FAIL** | Score <60% OR coverage <50% | Major revisions required |
## 10. Error Handling
| Error Type | Recovery Strategy | Escalation |
|------------|-------------------|------------|
| Missing context | Request from coordinator | Immediate escalation |
| Invalid review mode | Abort with error | Report to coordinator |
| Analysis failure | Retry with verbose logging | Report after 2 failures |
| Report generation failure | Use fallback template | Report with partial results |

View File

@@ -0,0 +1,538 @@
# Validate Command
## Purpose
Test-fix cycle with strategy engine for automated test failure resolution.
## Configuration
```javascript
const MAX_ITERATIONS = 10
const PASS_RATE_TARGET = 95 // percentage
```
## Main Iteration Loop
```javascript
function runTestFixCycle(task, framework, affectedTests, modifiedFiles) {
let iteration = 0
let bestPassRate = 0
let bestResults = null
while (iteration < MAX_ITERATIONS) {
iteration++
// Phase 1: Run Tests
const testCommand = buildTestCommand(framework, affectedTests, iteration === 1)
const testOutput = Bash(testCommand, { timeout: 120000 })
const results = parseTestResults(testOutput.stdout + testOutput.stderr, framework)
const passRate = results.total > 0 ? (results.passed / results.total * 100) : 0
// Track best result
if (passRate > bestPassRate) {
bestPassRate = passRate
bestResults = results
}
// Progress update for long cycles
if (iteration > 5) {
team_msg({
to: "coordinator",
type: "progress_update",
task_id: task.task_id,
iteration: iteration,
pass_rate: passRate.toFixed(1),
tests_passed: results.passed,
tests_failed: results.failed,
message: `Test-fix cycle iteration ${iteration}/${MAX_ITERATIONS}`
}, "[tester]")
}
// Phase 2: Check Success
if (passRate >= PASS_RATE_TARGET) {
// Quality gate: Run full suite if only affected tests passed
if (affectedTests.length > 0 && iteration === 1) {
team_msg({
to: "coordinator",
type: "progress_update",
task_id: task.task_id,
message: "Affected tests passed, running full suite..."
}, "[tester]")
const fullSuiteCommand = buildTestCommand(framework, [], false)
const fullOutput = Bash(fullSuiteCommand, { timeout: 300000 })
const fullResults = parseTestResults(fullOutput.stdout + fullOutput.stderr, framework)
const fullPassRate = fullResults.total > 0 ? (fullResults.passed / fullResults.total * 100) : 0
if (fullPassRate >= PASS_RATE_TARGET) {
return {
success: true,
results: fullResults,
iterations: iteration,
full_suite_run: true
}
} else {
// Full suite failed, continue fixing
results = fullResults
passRate = fullPassRate
}
} else {
return {
success: true,
results: results,
iterations: iteration,
full_suite_run: affectedTests.length === 0
}
}
}
// Phase 3: Analyze Failures
if (results.failures.length === 0) {
break // No failures to fix
}
const classified = classifyFailures(results.failures)
// Phase 4: Select Strategy
const strategy = selectStrategy(iteration, passRate, results.failures)
team_msg({
to: "coordinator",
type: "progress_update",
task_id: task.task_id,
iteration: iteration,
strategy: strategy,
failures: {
critical: classified.critical.length,
high: classified.high.length,
medium: classified.medium.length,
low: classified.low.length
}
}, "[tester]")
// Phase 5: Apply Fixes
const fixResult = applyFixes(strategy, results.failures, framework, modifiedFiles)
if (!fixResult.success) {
// Fix application failed, try next iteration with different strategy
continue
}
}
// Max iterations reached
return {
success: false,
results: bestResults,
iterations: MAX_ITERATIONS,
best_pass_rate: bestPassRate,
error: "Max iterations reached without achieving target pass rate"
}
}
```
## Strategy Selection
```javascript
function selectStrategy(iteration, passRate, failures) {
const classified = classifyFailures(failures)
// Conservative: Early iterations or high pass rate
if (iteration <= 3 || passRate >= 80) {
return "conservative"
}
// Surgical: Specific failure patterns
if (classified.critical.length > 0 && classified.critical.length < 5) {
return "surgical"
}
// Aggressive: Low pass rate or many iterations
if (passRate < 50 || iteration > 7) {
return "aggressive"
}
return "conservative"
}
```
## Fix Application
### Conservative Strategy
```javascript
function applyConservativeFixes(failures, framework, modifiedFiles) {
const classified = classifyFailures(failures)
// Fix only the first critical failure
if (classified.critical.length > 0) {
const failure = classified.critical[0]
return fixSingleFailure(failure, framework, modifiedFiles)
}
// If no critical, fix first high priority
if (classified.high.length > 0) {
const failure = classified.high[0]
return fixSingleFailure(failure, framework, modifiedFiles)
}
return { success: false, error: "No fixable failures found" }
}
```
### Surgical Strategy
```javascript
function applySurgicalFixes(failures, framework, modifiedFiles) {
// Identify common pattern
const pattern = identifyCommonPattern(failures)
if (!pattern) {
return { success: false, error: "No common pattern identified" }
}
// Apply pattern-based fix across all occurrences
const fixes = []
for (const failure of failures) {
if (matchesPattern(failure, pattern)) {
const fix = generatePatternFix(failure, pattern, framework)
fixes.push(fix)
}
}
// Apply all fixes in batch
for (const fix of fixes) {
applyFix(fix, modifiedFiles)
}
return {
success: true,
fixes_applied: fixes.length,
pattern: pattern
}
}
function identifyCommonPattern(failures) {
// Group failures by error type
const errorTypes = {}
for (const failure of failures) {
const errorType = extractErrorType(failure.error)
if (!errorTypes[errorType]) {
errorTypes[errorType] = []
}
errorTypes[errorType].push(failure)
}
// Find most common error type
let maxCount = 0
let commonPattern = null
for (const [errorType, instances] of Object.entries(errorTypes)) {
if (instances.length > maxCount) {
maxCount = instances.length
commonPattern = {
type: errorType,
instances: instances,
count: instances.length
}
}
}
return maxCount >= 3 ? commonPattern : null
}
function extractErrorType(error) {
const errorLower = error.toLowerCase()
if (errorLower.includes("cannot find module")) return "missing_import"
if (errorLower.includes("is not defined")) return "undefined_variable"
if (errorLower.includes("expected") && errorLower.includes("received")) return "assertion_mismatch"
if (errorLower.includes("timeout")) return "timeout"
if (errorLower.includes("syntaxerror")) return "syntax_error"
return "unknown"
}
```
### Aggressive Strategy
```javascript
function applyAggressiveFixes(failures, framework, modifiedFiles) {
const classified = classifyFailures(failures)
const fixes = []
// Fix all critical failures
for (const failure of classified.critical) {
const fix = generateFix(failure, framework, modifiedFiles)
if (fix) {
fixes.push(fix)
}
}
// Fix all high priority failures
for (const failure of classified.high) {
const fix = generateFix(failure, framework, modifiedFiles)
if (fix) {
fixes.push(fix)
}
}
// Apply all fixes
for (const fix of fixes) {
applyFix(fix, modifiedFiles)
}
return {
success: fixes.length > 0,
fixes_applied: fixes.length
}
}
```
### Fix Generation
```javascript
function generateFix(failure, framework, modifiedFiles) {
const errorType = extractErrorType(failure.error)
switch (errorType) {
case "missing_import":
return generateImportFix(failure, modifiedFiles)
case "undefined_variable":
return generateVariableFix(failure, modifiedFiles)
case "assertion_mismatch":
return generateAssertionFix(failure, framework)
case "timeout":
return generateTimeoutFix(failure, framework)
case "syntax_error":
return generateSyntaxFix(failure, modifiedFiles)
default:
return null
}
}
function generateImportFix(failure, modifiedFiles) {
// Extract module name from error
const moduleMatch = failure.error.match(/Cannot find module ['"](.+?)['"]/)
if (!moduleMatch) return null
const moduleName = moduleMatch[1]
// Find test file
const testFile = extractTestFile(failure.test)
if (!testFile) return null
// Check if module exists in modified files
const sourceFile = modifiedFiles.find(f =>
f.includes(moduleName) || f.endsWith(`${moduleName}.ts`) || f.endsWith(`${moduleName}.js`)
)
if (!sourceFile) return null
// Generate import statement
const relativePath = calculateRelativePath(testFile, sourceFile)
const importStatement = `import { } from '${relativePath}'`
return {
file: testFile,
type: "add_import",
content: importStatement,
line: 1 // Add at top of file
}
}
function generateAssertionFix(failure, framework) {
// Extract expected vs received values
const expectedMatch = failure.error.match(/Expected:\s*(.+?)(?:\n|$)/)
const receivedMatch = failure.error.match(/Received:\s*(.+?)(?:\n|$)/)
if (!expectedMatch || !receivedMatch) return null
const expected = expectedMatch[1].trim()
const received = receivedMatch[1].trim()
// Find test file and line
const testFile = extractTestFile(failure.test)
const testLine = extractTestLine(failure.error)
if (!testFile || !testLine) return null
return {
file: testFile,
type: "update_assertion",
line: testLine,
old_value: expected,
new_value: received,
note: "Auto-updated assertion based on actual behavior"
}
}
```
## Test Result Parsing
```javascript
function parseTestResults(output, framework) {
const results = {
total: 0,
passed: 0,
failed: 0,
skipped: 0,
failures: []
}
if (framework === "jest" || framework === "vitest") {
// Parse summary line
const summaryMatch = output.match(/Tests:\s+(?:(\d+)\s+failed,\s+)?(?:(\d+)\s+passed,\s+)?(\d+)\s+total/)
if (summaryMatch) {
results.failed = summaryMatch[1] ? parseInt(summaryMatch[1]) : 0
results.passed = summaryMatch[2] ? parseInt(summaryMatch[2]) : 0
results.total = parseInt(summaryMatch[3])
}
// Alternative format
if (results.total === 0) {
const altMatch = output.match(/(\d+)\s+passed.*?(\d+)\s+total/)
if (altMatch) {
results.passed = parseInt(altMatch[1])
results.total = parseInt(altMatch[2])
results.failed = results.total - results.passed
}
}
// Extract failure details
const failureRegex = /●\s+(.*?)\n\n([\s\S]*?)(?=\n\n●|\n\nTest Suites:|\n\n$)/g
let match
while ((match = failureRegex.exec(output)) !== null) {
results.failures.push({
test: match[1].trim(),
error: match[2].trim()
})
}
} else if (framework === "pytest") {
// Parse pytest summary
const summaryMatch = output.match(/=+\s+(?:(\d+)\s+failed,?\s+)?(?:(\d+)\s+passed)?/)
if (summaryMatch) {
results.failed = summaryMatch[1] ? parseInt(summaryMatch[1]) : 0
results.passed = summaryMatch[2] ? parseInt(summaryMatch[2]) : 0
results.total = results.failed + results.passed
}
// Extract failure details
const failureRegex = /FAILED\s+(.*?)\s+-\s+([\s\S]*?)(?=\n_+|FAILED|=+\s+\d+)/g
let match
while ((match = failureRegex.exec(output)) !== null) {
results.failures.push({
test: match[1].trim(),
error: match[2].trim()
})
}
}
return results
}
```
## Test Command Building
```javascript
function buildTestCommand(framework, affectedTests, isFirstRun) {
const testFiles = affectedTests.length > 0 ? affectedTests.join(" ") : ""
switch (framework) {
case "vitest":
return testFiles
? `vitest run ${testFiles} --reporter=verbose`
: `vitest run --reporter=verbose`
case "jest":
return testFiles
? `jest ${testFiles} --no-coverage --verbose`
: `jest --no-coverage --verbose`
case "mocha":
return testFiles
? `mocha ${testFiles} --reporter spec`
: `mocha --reporter spec`
case "pytest":
return testFiles
? `pytest ${testFiles} -v --tb=short`
: `pytest -v --tb=short`
default:
throw new Error(`Unsupported test framework: ${framework}`)
}
}
```
## Utility Functions
### Extract Test File
```javascript
function extractTestFile(testName) {
// Extract file path from test name
// Format: "path/to/file.test.ts > describe block > test name"
const fileMatch = testName.match(/^(.*?\.(?:test|spec)\.[jt]sx?)/)
return fileMatch ? fileMatch[1] : null
}
```
### Extract Test Line
```javascript
function extractTestLine(error) {
// Extract line number from error stack
const lineMatch = error.match(/:(\d+):\d+/)
return lineMatch ? parseInt(lineMatch[1]) : null
}
```
### Calculate Relative Path
```javascript
function calculateRelativePath(fromFile, toFile) {
const fromParts = fromFile.split("/")
const toParts = toFile.split("/")
// Remove filename
fromParts.pop()
// Find common base
let commonLength = 0
while (commonLength < fromParts.length &&
commonLength < toParts.length &&
fromParts[commonLength] === toParts[commonLength]) {
commonLength++
}
// Build relative path
const upLevels = fromParts.length - commonLength
const downPath = toParts.slice(commonLength)
const relativeParts = []
for (let i = 0; i < upLevels; i++) {
relativeParts.push("..")
}
relativeParts.push(...downPath)
let path = relativeParts.join("/")
// Remove file extension
path = path.replace(/\.[jt]sx?$/, "")
// Ensure starts with ./
if (!path.startsWith(".")) {
path = "./" + path
}
return path
}
```

View File

@@ -0,0 +1,385 @@
# Tester Role
## 1. Role Identity
- **Name**: tester
- **Task Prefix**: TEST-*
- **Output Tag**: `[tester]`
- **Responsibility**: Detect Framework → Run Tests → Fix Cycle → Report Results
## 2. Role Boundaries
### MUST
- Only process TEST-* tasks
- Communicate only with coordinator
- Use detected test framework
- Run affected tests before full suite
- Tag all outputs with `[tester]`
### MUST NOT
- Create tasks
- Contact other workers directly
- Modify production code beyond test fixes
- Skip framework detection
- Run full suite without affected tests first
## 3. Message Types
| Type | Direction | Purpose | Format |
|------|-----------|---------|--------|
| `task_request` | FROM coordinator | Receive TEST-* task assignment | `{ type: "task_request", task_id, description, impl_task_id }` |
| `task_complete` | TO coordinator | Report test success | `{ type: "task_complete", task_id, status: "success", pass_rate, tests_run, iterations }` |
| `task_failed` | TO coordinator | Report test failure | `{ type: "task_failed", task_id, error, failures, pass_rate }` |
| `progress_update` | TO coordinator | Report fix cycle progress | `{ type: "progress_update", task_id, iteration, pass_rate, strategy }` |
## 4. Message Bus
**Primary**: Use `team_msg` for all coordinator communication with `[tester]` tag:
```javascript
team_msg({
to: "coordinator",
type: "task_complete",
task_id: "TEST-001",
status: "success",
pass_rate: 98.5,
tests_run: 45,
iterations: 3,
framework: "vitest"
}, "[tester]")
```
**CLI Fallback**: When message bus unavailable, write to `.workflow/.team/messages/tester-{timestamp}.json`
## 5. Toolbox
### Available Commands
- `commands/validate.md` - Test-fix cycle with strategy engine
### CLI Capabilities
- None (uses project's test framework directly via Bash)
## 6. Execution (5-Phase)
### Phase 1: Task Discovery
**Task Loading**:
```javascript
const tasks = Glob(".workflow/.team/tasks/TEST-*.json")
.filter(task => task.status === "pending" && task.assigned_to === "tester")
```
**Implementation Task Linking**:
```javascript
const implTaskId = task.metadata?.impl_task_id
const implTask = implTaskId ? Read(`.workflow/.team/tasks/${implTaskId}.json`) : null
const modifiedFiles = implTask?.metadata?.files_modified || []
```
### Phase 2: Test Framework Detection
**Framework Detection**:
```javascript
function detectTestFramework() {
// Check package.json for test frameworks
const packageJson = Read("package.json")
const pkg = JSON.parse(packageJson)
// Priority 1: Check dependencies
if (pkg.devDependencies?.vitest || pkg.dependencies?.vitest) {
return "vitest"
}
if (pkg.devDependencies?.jest || pkg.dependencies?.jest) {
return "jest"
}
if (pkg.devDependencies?.mocha || pkg.dependencies?.mocha) {
return "mocha"
}
if (pkg.devDependencies?.pytest || pkg.dependencies?.pytest) {
return "pytest"
}
// Priority 2: Check test scripts
const testScript = pkg.scripts?.test || ""
if (testScript.includes("vitest")) return "vitest"
if (testScript.includes("jest")) return "jest"
if (testScript.includes("mocha")) return "mocha"
if (testScript.includes("pytest")) return "pytest"
// Priority 3: Check config files
const configFiles = Glob("{vitest,jest,mocha}.config.{js,ts,json}")
if (configFiles.some(f => f.includes("vitest"))) return "vitest"
if (configFiles.some(f => f.includes("jest"))) return "jest"
if (configFiles.some(f => f.includes("mocha"))) return "mocha"
if (Bash("test -f pytest.ini").exitCode === 0) return "pytest"
return "unknown"
}
```
**Affected Test Discovery**:
```javascript
function findAffectedTests(modifiedFiles) {
const testFiles = []
for (const file of modifiedFiles) {
const baseName = file.replace(/\.(ts|js|tsx|jsx|py)$/, "")
const dir = file.substring(0, file.lastIndexOf("/"))
const testVariants = [
// Same directory variants
`${baseName}.test.ts`,
`${baseName}.test.js`,
`${baseName}.spec.ts`,
`${baseName}.spec.js`,
`${baseName}_test.py`,
`test_${baseName.split("/").pop()}.py`,
// Test directory variants
`${file.replace(/^src\//, "tests/")}`,
`${file.replace(/^src\//, "__tests__/")}`,
`${file.replace(/^src\//, "test/")}`,
`${dir}/__tests__/${file.split("/").pop().replace(/\.(ts|js|tsx|jsx)$/, ".test.ts")}`,
// Python variants
`${file.replace(/^src\//, "tests/").replace(/\.py$/, "_test.py")}`,
`${file.replace(/^src\//, "tests/test_")}`
]
for (const variant of testVariants) {
if (Bash(`test -f ${variant}`).exitCode === 0) {
testFiles.push(variant)
}
}
}
return [...new Set(testFiles)] // Deduplicate
}
```
### Phase 3: Test Execution & Fix Cycle
**Delegate to Command**:
```javascript
const validateCommand = Read("commands/validate.md")
// Command handles:
// - MAX_ITERATIONS=10, PASS_RATE_TARGET=95
// - Main iteration loop with strategy selection
// - Quality gate check (affected tests → full suite)
// - applyFixes by strategy (conservative/aggressive/surgical)
// - Progress updates for long cycles (iteration > 5)
```
### Phase 4: Result Analysis
**Test Result Parsing**:
```javascript
function parseTestResults(output, framework) {
const results = {
total: 0,
passed: 0,
failed: 0,
skipped: 0,
failures: []
}
if (framework === "jest" || framework === "vitest") {
// Parse Jest/Vitest output
const totalMatch = output.match(/Tests:\s+(\d+)\s+total/)
const passedMatch = output.match(/(\d+)\s+passed/)
const failedMatch = output.match(/(\d+)\s+failed/)
const skippedMatch = output.match(/(\d+)\s+skipped/)
results.total = totalMatch ? parseInt(totalMatch[1]) : 0
results.passed = passedMatch ? parseInt(passedMatch[1]) : 0
results.failed = failedMatch ? parseInt(failedMatch[1]) : 0
results.skipped = skippedMatch ? parseInt(skippedMatch[1]) : 0
// Extract failure details
const failureRegex = /\s+(.*?)\n\n\s+(.*?)(?=\n\n|\n\nTest Suites:)/gs
let match
while ((match = failureRegex.exec(output)) !== null) {
results.failures.push({
test: match[1].trim(),
error: match[2].trim()
})
}
} else if (framework === "pytest") {
// Parse pytest output
const summaryMatch = output.match(/=+\s+(\d+)\s+failed,\s+(\d+)\s+passed/)
if (summaryMatch) {
results.failed = parseInt(summaryMatch[1])
results.passed = parseInt(summaryMatch[2])
results.total = results.failed + results.passed
}
// Extract failure details
const failureRegex = /FAILED\s+(.*?)\s+-\s+(.*?)(?=\n_+|\nFAILED|$)/gs
let match
while ((match = failureRegex.exec(output)) !== null) {
results.failures.push({
test: match[1].trim(),
error: match[2].trim()
})
}
}
return results
}
```
**Failure Classification**:
```javascript
function classifyFailures(failures) {
const classified = {
critical: [], // Syntax errors, missing imports
high: [], // Assertion failures, logic errors
medium: [], // Timeout, flaky tests
low: [] // Warnings, deprecations
}
for (const failure of failures) {
const error = failure.error.toLowerCase()
if (error.includes("syntaxerror") ||
error.includes("cannot find module") ||
error.includes("is not defined")) {
classified.critical.push(failure)
} else if (error.includes("expected") ||
error.includes("assertion") ||
error.includes("toBe") ||
error.includes("toEqual")) {
classified.high.push(failure)
} else if (error.includes("timeout") ||
error.includes("async")) {
classified.medium.push(failure)
} else {
classified.low.push(failure)
}
}
return classified
}
```
### Phase 5: Report to Coordinator
**Success Report**:
```javascript
team_msg({
to: "coordinator",
type: "task_complete",
task_id: task.task_id,
status: "success",
pass_rate: (results.passed / results.total * 100).toFixed(1),
tests_run: results.total,
tests_passed: results.passed,
tests_failed: results.failed,
iterations: iterationCount,
framework: framework,
affected_tests: affectedTests.length,
full_suite_run: fullSuiteRun,
timestamp: new Date().toISOString()
}, "[tester]")
```
**Failure Report**:
```javascript
const classified = classifyFailures(results.failures)
team_msg({
to: "coordinator",
type: "task_failed",
task_id: task.task_id,
error: "Test failures exceeded threshold",
pass_rate: (results.passed / results.total * 100).toFixed(1),
tests_run: results.total,
failures: {
critical: classified.critical.length,
high: classified.high.length,
medium: classified.medium.length,
low: classified.low.length
},
failure_details: classified,
iterations: iterationCount,
framework: framework,
timestamp: new Date().toISOString()
}, "[tester]")
```
## 7. Strategy Engine
### Strategy Selection
```javascript
function selectStrategy(iteration, passRate, failures) {
const classified = classifyFailures(failures)
// Conservative: Early iterations or high pass rate
if (iteration <= 3 || passRate >= 80) {
return "conservative"
}
// Surgical: Specific failure patterns
if (classified.critical.length > 0 && classified.critical.length < 5) {
return "surgical"
}
// Aggressive: Low pass rate or many iterations
if (passRate < 50 || iteration > 7) {
return "aggressive"
}
return "conservative"
}
```
### Fix Application
```javascript
function applyFixes(strategy, failures, framework) {
if (strategy === "conservative") {
// Fix only critical failures one at a time
const critical = classifyFailures(failures).critical
if (critical.length > 0) {
return fixFailure(critical[0], framework)
}
} else if (strategy === "surgical") {
// Fix specific pattern across all occurrences
const pattern = identifyCommonPattern(failures)
return fixPattern(pattern, framework)
} else if (strategy === "aggressive") {
// Fix all failures in batch
return fixAllFailures(failures, framework)
}
}
```
## 8. Error Handling
| Error Type | Recovery Strategy | Escalation |
|------------|-------------------|------------|
| Framework not detected | Prompt user for framework | Immediate escalation |
| No tests found | Report to coordinator | Manual intervention |
| Test command fails | Retry with verbose output | Report after 2 failures |
| Infinite fix loop | Abort after MAX_ITERATIONS | Report iteration history |
| Pass rate below target | Report best attempt | Include failure classification |
## 9. Configuration
| Parameter | Default | Description |
|-----------|---------|-------------|
| MAX_ITERATIONS | 10 | Maximum fix-test cycles |
| PASS_RATE_TARGET | 95 | Target pass rate (%) |
| AFFECTED_TESTS_FIRST | true | Run affected tests before full suite |
| PARALLEL_TESTS | true | Enable parallel test execution |
| TIMEOUT_PER_TEST | 30000 | Timeout per test (ms) |
## 10. Test Framework Commands
| Framework | Affected Tests Command | Full Suite Command |
|-----------|------------------------|-------------------|
| vitest | `vitest run ${files.join(" ")}` | `vitest run` |
| jest | `jest ${files.join(" ")} --no-coverage` | `jest --no-coverage` |
| mocha | `mocha ${files.join(" ")}` | `mocha` |
| pytest | `pytest ${files.join(" ")} -v` | `pytest -v` |

View File

@@ -0,0 +1,698 @@
# Command: Generate Document
Multi-CLI document generation for 4 document types: Product Brief, Requirements/PRD, Architecture, Epics & Stories.
## Pre-Steps (All Document Types)
```javascript
// 1. Load document standards
const docStandards = Read('../../specs/document-standards.md')
// 2. Load appropriate template
const templateMap = {
'product-brief': '../../templates/product-brief.md',
'requirements': '../../templates/requirements-prd.md',
'architecture': '../../templates/architecture-doc.md',
'epics': '../../templates/epics-template.md'
}
const template = Read(templateMap[docType])
// 3. Build shared context
const seedAnalysis = specConfig?.seed_analysis ||
(priorDocs.discoveryContext ? JSON.parse(priorDocs.discoveryContext).seed_analysis : {})
const sharedContext = `
SEED: ${specConfig?.topic || ''}
PROBLEM: ${seedAnalysis.problem_statement || ''}
TARGET USERS: ${(seedAnalysis.target_users || []).join(', ')}
DOMAIN: ${seedAnalysis.domain || ''}
CONSTRAINTS: ${(seedAnalysis.constraints || []).join(', ')}
FOCUS AREAS: ${(specConfig?.focus_areas || []).join(', ')}
${priorDocs.discoveryContext ? `
CODEBASE CONTEXT:
- Existing patterns: ${JSON.parse(priorDocs.discoveryContext).existing_patterns?.slice(0,5).join(', ') || 'none'}
- Tech stack: ${JSON.stringify(JSON.parse(priorDocs.discoveryContext).tech_stack || {})}
` : ''}`
// 4. Route to specific document type
```
## DRAFT-001: Product Brief
3-way parallel CLI analysis (product/technical/user perspectives), then synthesize.
```javascript
if (docType === 'product-brief') {
// === Parallel CLI Analysis ===
// Product Perspective (Gemini)
Bash({
command: `ccw cli -p "PURPOSE: Product analysis for specification - identify market fit, user value, and success criteria.
Success: Clear vision, measurable goals, competitive positioning.
${sharedContext}
TASK:
- Define product vision (1-3 sentences, aspirational)
- Analyze market/competitive landscape
- Define 3-5 measurable success metrics
- Identify scope boundaries (in-scope vs out-of-scope)
- Assess user value proposition
- List assumptions that need validation
MODE: analysis
EXPECTED: Structured product analysis with: vision, goals with metrics, scope, competitive positioning, assumptions
CONSTRAINTS: Focus on 'what' and 'why', not 'how'
" --tool gemini --mode analysis`,
run_in_background: true
})
// Technical Perspective (Codex)
Bash({
command: `ccw cli -p "PURPOSE: Technical feasibility analysis for specification - assess implementation viability and constraints.
Success: Clear technical constraints, integration complexity, technology recommendations.
${sharedContext}
TASK:
- Assess technical feasibility of the core concept
- Identify technical constraints and blockers
- Evaluate integration complexity with existing systems
- Recommend technology approach (high-level)
- Identify technical risks and dependencies
- Estimate complexity: simple/moderate/complex
MODE: analysis
EXPECTED: Technical analysis with: feasibility assessment, constraints, integration complexity, tech recommendations, risks
CONSTRAINTS: Focus on feasibility and constraints, not detailed architecture
" --tool codex --mode analysis`,
run_in_background: true
})
// User Perspective (Claude)
Bash({
command: `ccw cli -p "PURPOSE: User experience analysis for specification - understand user journeys, pain points, and UX considerations.
Success: Clear user personas, journey maps, UX requirements.
${sharedContext}
TASK:
- Elaborate user personas with goals and frustrations
- Map primary user journey (happy path)
- Identify key pain points in current experience
- Define UX success criteria
- List accessibility and usability considerations
- Suggest interaction patterns
MODE: analysis
EXPECTED: User analysis with: personas, journey map, pain points, UX criteria, interaction recommendations
CONSTRAINTS: Focus on user needs and experience, not implementation
" --tool claude --mode analysis`,
run_in_background: true
})
// STOP: Wait for all 3 CLI results
// === Synthesize Three Perspectives ===
const synthesis = {
convergent_themes: [], // Themes consistent across all three perspectives
conflicts: [], // Conflicting viewpoints
product_insights: [], // Unique product perspective insights
technical_insights: [], // Unique technical perspective insights
user_insights: [] // Unique user perspective insights
}
// Parse CLI outputs and identify:
// - Common themes mentioned by 2+ perspectives
// - Conflicts (e.g., product wants feature X, technical says infeasible)
// - Unique insights from each perspective
// === Integrate Discussion Feedback ===
if (discussionFeedback) {
// Extract consensus and adjustments from discuss-001-scope.md
// Merge discussion conclusions into synthesis
}
// === Generate Document from Template ===
const frontmatter = `---
session_id: ${specConfig?.session_id || 'unknown'}
phase: 2
document_type: product-brief
status: draft
generated_at: ${new Date().toISOString()}
version: 1
dependencies:
- spec-config.json
- discovery-context.json
---`
// Fill template sections:
// - Vision (from product perspective + synthesis)
// - Problem Statement (from seed analysis + user perspective)
// - Target Users (from user perspective + personas)
// - Goals (from product perspective + metrics)
// - Scope (from product perspective + technical constraints)
// - Success Criteria (from all three perspectives)
// - Assumptions (from product + technical perspectives)
const filledContent = fillTemplate(template, {
vision: productPerspective.vision,
problem: seedAnalysis.problem_statement,
users: userPerspective.personas,
goals: productPerspective.goals,
scope: synthesis.scope_boundaries,
success_criteria: synthesis.convergent_themes,
assumptions: [...productPerspective.assumptions, ...technicalPerspective.assumptions]
})
Write(`${sessionFolder}/spec/product-brief.md`, `${frontmatter}\n\n${filledContent}`)
return {
outputPath: 'spec/product-brief.md',
documentSummary: `Product Brief generated with ${synthesis.convergent_themes.length} convergent themes, ${synthesis.conflicts.length} conflicts resolved`
}
}
```
## DRAFT-002: Requirements/PRD
Gemini CLI expansion to generate REQ-NNN and NFR-{type}-NNN files.
```javascript
if (docType === 'requirements') {
// === Requirements Expansion CLI ===
Bash({
command: `ccw cli -p "PURPOSE: Generate detailed functional and non-functional requirements from product brief.
Success: Complete PRD with testable acceptance criteria for every requirement.
PRODUCT BRIEF CONTEXT:
${priorDocs.productBrief?.slice(0, 3000) || ''}
${sharedContext}
TASK:
- For each goal in the product brief, generate 3-7 functional requirements
- Each requirement must have:
- Unique ID: REQ-NNN (zero-padded)
- Clear title
- Detailed description
- User story: As a [persona], I want [action] so that [benefit]
- 2-4 specific, testable acceptance criteria
- Generate non-functional requirements:
- Performance (response times, throughput)
- Security (authentication, authorization, data protection)
- Scalability (user load, data volume)
- Usability (accessibility, learnability)
- Assign MoSCoW priority: Must/Should/Could/Won't
- Output structure per requirement: ID, title, description, user_story, acceptance_criteria[], priority, traces
MODE: analysis
EXPECTED: Structured requirements with: ID, title, description, user story, acceptance criteria, priority, traceability to goals
CONSTRAINTS: Every requirement must be specific enough to estimate and test. No vague requirements.
" --tool gemini --mode analysis`,
run_in_background: true
})
// Wait for CLI result
// === Integrate Discussion Feedback ===
if (discussionFeedback) {
// Extract requirement adjustments from discuss-002-brief.md
// Merge new/modified/deleted requirements
}
// === Generate requirements/ Directory ===
Bash(`mkdir -p "${sessionFolder}/spec/requirements"`)
const timestamp = new Date().toISOString()
// Parse CLI output → funcReqs[], nfReqs[]
const funcReqs = parseFunctionalRequirements(cliOutput)
const nfReqs = parseNonFunctionalRequirements(cliOutput)
// Write individual REQ-*.md files (one per functional requirement)
funcReqs.forEach(req => {
const reqFrontmatter = `---
id: REQ-${req.id}
title: "${req.title}"
priority: ${req.priority}
status: draft
traces:
- product-brief.md
---`
const reqContent = `${reqFrontmatter}
# REQ-${req.id}: ${req.title}
## Description
${req.description}
## User Story
${req.user_story}
## Acceptance Criteria
${req.acceptance_criteria.map((ac, i) => `${i+1}. ${ac}`).join('\n')}
`
Write(`${sessionFolder}/spec/requirements/REQ-${req.id}-${req.slug}.md`, reqContent)
})
// Write individual NFR-*.md files
nfReqs.forEach(nfr => {
const nfrFrontmatter = `---
id: NFR-${nfr.type}-${nfr.id}
type: ${nfr.type}
title: "${nfr.title}"
status: draft
traces:
- product-brief.md
---`
const nfrContent = `${nfrFrontmatter}
# NFR-${nfr.type}-${nfr.id}: ${nfr.title}
## Requirement
${nfr.requirement}
## Metric & Target
${nfr.metric} — Target: ${nfr.target}
`
Write(`${sessionFolder}/spec/requirements/NFR-${nfr.type}-${nfr.id}-${nfr.slug}.md`, nfrContent)
})
// Write _index.md (summary + links)
const indexFrontmatter = `---
session_id: ${specConfig?.session_id || 'unknown'}
phase: 3
document_type: requirements-index
status: draft
generated_at: ${timestamp}
version: 1
dependencies:
- product-brief.md
---`
const indexContent = `${indexFrontmatter}
# Requirements (PRD)
## Summary
Total: ${funcReqs.length} functional + ${nfReqs.length} non-functional requirements
## Functional Requirements
| ID | Title | Priority | Status |
|----|-------|----------|--------|
${funcReqs.map(r => `| [REQ-${r.id}](REQ-${r.id}-${r.slug}.md) | ${r.title} | ${r.priority} | draft |`).join('\n')}
## Non-Functional Requirements
| ID | Type | Title |
|----|------|-------|
${nfReqs.map(n => `| [NFR-${n.type}-${n.id}](NFR-${n.type}-${n.id}-${n.slug}.md) | ${n.type} | ${n.title} |`).join('\n')}
## MoSCoW Summary
- **Must**: ${funcReqs.filter(r => r.priority === 'Must').length}
- **Should**: ${funcReqs.filter(r => r.priority === 'Should').length}
- **Could**: ${funcReqs.filter(r => r.priority === 'Could').length}
- **Won't**: ${funcReqs.filter(r => r.priority === "Won't").length}
`
Write(`${sessionFolder}/spec/requirements/_index.md`, indexContent)
return {
outputPath: 'spec/requirements/_index.md',
documentSummary: `Requirements generated: ${funcReqs.length} functional, ${nfReqs.length} non-functional`
}
}
```
## DRAFT-003: Architecture
Two-stage CLI: Gemini architecture design + Codex architecture review.
```javascript
if (docType === 'architecture') {
// === Stage 1: Architecture Design (Gemini) ===
Bash({
command: `ccw cli -p "PURPOSE: Generate technical architecture for the specified requirements.
Success: Complete component architecture, tech stack, and ADRs with justified decisions.
PRODUCT BRIEF (summary):
${priorDocs.productBrief?.slice(0, 3000) || ''}
REQUIREMENTS:
${priorDocs.requirementsIndex?.slice(0, 5000) || ''}
${sharedContext}
TASK:
- Define system architecture style (monolith, microservices, serverless, etc.) with justification
- Identify core components and their responsibilities
- Create component interaction diagram (Mermaid graph TD format)
- Specify technology stack: languages, frameworks, databases, infrastructure
- Generate 2-4 Architecture Decision Records (ADRs):
- Each ADR: context, decision, 2-3 alternatives with pros/cons, consequences
- Focus on: data storage, API design, authentication, key technical choices
- Define data model: key entities and relationships (Mermaid erDiagram format)
- Identify security architecture: auth, authorization, data protection
- List API endpoints (high-level)
MODE: analysis
EXPECTED: Complete architecture with: style justification, component diagram, tech stack table, ADRs, data model, security controls, API overview
CONSTRAINTS: Architecture must support all Must-have requirements. Prefer proven technologies.
" --tool gemini --mode analysis`,
run_in_background: true
})
// Wait for Gemini result
// === Stage 2: Architecture Review (Codex) ===
Bash({
command: `ccw cli -p "PURPOSE: Critical review of proposed architecture - identify weaknesses and risks.
Success: Actionable feedback with specific concerns and improvement suggestions.
PROPOSED ARCHITECTURE:
${geminiArchitectureOutput.slice(0, 5000)}
REQUIREMENTS CONTEXT:
${priorDocs.requirementsIndex?.slice(0, 2000) || ''}
TASK:
- Challenge each ADR: are the alternatives truly the best options?
- Identify scalability bottlenecks in the component design
- Assess security gaps: authentication, authorization, data protection
- Evaluate technology choices: maturity, community support, fit
- Check for over-engineering or under-engineering
- Verify architecture covers all Must-have requirements
- Rate overall architecture quality: 1-5 with justification
MODE: analysis
EXPECTED: Architecture review with: per-ADR feedback, scalability concerns, security gaps, technology risks, quality rating
CONSTRAINTS: Be genuinely critical, not just validating. Focus on actionable improvements.
" --tool codex --mode analysis`,
run_in_background: true
})
// Wait for Codex result
// === Integrate Discussion Feedback ===
if (discussionFeedback) {
// Extract architecture feedback from discuss-003-requirements.md
// Merge into architecture design
}
// === Codebase Integration Mapping (conditional) ===
let integrationMapping = null
if (priorDocs.discoveryContext) {
const dc = JSON.parse(priorDocs.discoveryContext)
if (dc.relevant_files) {
integrationMapping = dc.relevant_files.map(f => ({
new_component: '...',
existing_module: f.path,
integration_type: 'Extend|Replace|New',
notes: f.rationale
}))
}
}
// === Generate architecture/ Directory ===
Bash(`mkdir -p "${sessionFolder}/spec/architecture"`)
const timestamp = new Date().toISOString()
const adrs = parseADRs(geminiArchitectureOutput, codexReviewOutput)
// Write individual ADR-*.md files
adrs.forEach(adr => {
const adrFrontmatter = `---
id: ADR-${adr.id}
title: "${adr.title}"
status: draft
traces:
- ../requirements/_index.md
---`
const adrContent = `${adrFrontmatter}
# ADR-${adr.id}: ${adr.title}
## Context
${adr.context}
## Decision
${adr.decision}
## Alternatives
${adr.alternatives.map((alt, i) => `### Option ${i+1}: ${alt.name}\n- **Pros**: ${alt.pros.join(', ')}\n- **Cons**: ${alt.cons.join(', ')}`).join('\n\n')}
## Consequences
${adr.consequences}
## Review Feedback
${adr.reviewFeedback || 'N/A'}
`
Write(`${sessionFolder}/spec/architecture/ADR-${adr.id}-${adr.slug}.md`, adrContent)
})
// Write _index.md (with Mermaid component diagram + ER diagram + links)
const archIndexFrontmatter = `---
session_id: ${specConfig?.session_id || 'unknown'}
phase: 4
document_type: architecture-index
status: draft
generated_at: ${timestamp}
version: 1
dependencies:
- ../product-brief.md
- ../requirements/_index.md
---`
const archIndexContent = `${archIndexFrontmatter}
# Architecture Document
## System Overview
${geminiArchitectureOutput.system_overview}
## Component Diagram
\`\`\`mermaid
${geminiArchitectureOutput.component_diagram}
\`\`\`
## Technology Stack
${geminiArchitectureOutput.tech_stack_table}
## Architecture Decision Records
| ID | Title | Status |
|----|-------|--------|
${adrs.map(a => `| [ADR-${a.id}](ADR-${a.id}-${a.slug}.md) | ${a.title} | draft |`).join('\n')}
## Data Model
\`\`\`mermaid
${geminiArchitectureOutput.data_model_diagram}
\`\`\`
## API Design
${geminiArchitectureOutput.api_overview}
## Security Controls
${geminiArchitectureOutput.security_controls}
## Review Summary
${codexReviewOutput.summary}
Quality Rating: ${codexReviewOutput.quality_rating}/5
`
Write(`${sessionFolder}/spec/architecture/_index.md`, archIndexContent)
return {
outputPath: 'spec/architecture/_index.md',
documentSummary: `Architecture generated with ${adrs.length} ADRs, quality rating ${codexReviewOutput.quality_rating}/5`
}
}
```
## DRAFT-004: Epics & Stories
Gemini CLI decomposition to generate EPIC-*.md files.
```javascript
if (docType === 'epics') {
// === Epic Decomposition CLI ===
Bash({
command: `ccw cli -p "PURPOSE: Decompose requirements into executable Epics and Stories for implementation planning.
Success: 3-7 Epics with prioritized Stories, dependency map, and MVP subset clearly defined.
PRODUCT BRIEF (summary):
${priorDocs.productBrief?.slice(0, 2000) || ''}
REQUIREMENTS:
${priorDocs.requirementsIndex?.slice(0, 5000) || ''}
ARCHITECTURE (summary):
${priorDocs.architectureIndex?.slice(0, 3000) || ''}
TASK:
- Group requirements into 3-7 logical Epics:
- Each Epic: EPIC-NNN ID, title, description, priority (Must/Should/Could)
- Group by functional domain or user journey stage
- Tag MVP Epics (minimum set for initial release)
- For each Epic, generate 2-5 Stories:
- Each Story: STORY-{EPIC}-NNN ID, title
- User story format: As a [persona], I want [action] so that [benefit]
- 2-4 acceptance criteria per story (testable)
- Relative size estimate: S/M/L/XL
- Trace to source requirement(s): REQ-NNN
- Create dependency map:
- Cross-Epic dependencies (which Epics block others)
- Mermaid graph LR format
- Recommended execution order with rationale
- Define MVP:
- Which Epics are in MVP
- MVP definition of done (3-5 criteria)
- What is explicitly deferred post-MVP
MODE: analysis
EXPECTED: Structured output with: Epic list (ID, title, priority, MVP flag), Stories per Epic (ID, user story, AC, size, trace), dependency Mermaid diagram, execution order, MVP definition
CONSTRAINTS: Every Must-have requirement must appear in at least one Story. Stories must be small enough to implement independently. Dependencies should be minimized across Epics.
" --tool gemini --mode analysis`,
run_in_background: true
})
// Wait for CLI result
// === Integrate Discussion Feedback ===
if (discussionFeedback) {
// Extract execution feedback from discuss-004-architecture.md
// Adjust Epic granularity, MVP scope
}
// === Generate epics/ Directory ===
Bash(`mkdir -p "${sessionFolder}/spec/epics"`)
const timestamp = new Date().toISOString()
const epicsList = parseEpics(cliOutput)
// Write individual EPIC-*.md files (with stories)
epicsList.forEach(epic => {
const epicFrontmatter = `---
id: EPIC-${epic.id}
title: "${epic.title}"
priority: ${epic.priority}
mvp: ${epic.mvp}
size: ${epic.size}
requirements:
${epic.reqs.map(r => ` - ${r}`).join('\n')}
architecture:
${epic.adrs.map(a => ` - ${a}`).join('\n')}
dependencies:
${epic.deps.map(d => ` - ${d}`).join('\n')}
status: draft
---`
const storiesContent = epic.stories.map(s => `### ${s.id}: ${s.title}
**User Story**: ${s.user_story}
**Size**: ${s.size}
**Traces**: ${s.traces.join(', ')}
**Acceptance Criteria**:
${s.acceptance_criteria.map((ac, i) => `${i+1}. ${ac}`).join('\n')}
`).join('\n')
const epicContent = `${epicFrontmatter}
# EPIC-${epic.id}: ${epic.title}
## Description
${epic.description}
## Stories
${storiesContent}
## Requirements
${epic.reqs.map(r => `- [${r}](../requirements/${r}.md)`).join('\n')}
## Architecture
${epic.adrs.map(a => `- [${a}](../architecture/${a}.md)`).join('\n')}
`
Write(`${sessionFolder}/spec/epics/EPIC-${epic.id}-${epic.slug}.md`, epicContent)
})
// Write _index.md (with Mermaid dependency diagram + MVP + links)
const epicsIndexFrontmatter = `---
session_id: ${specConfig?.session_id || 'unknown'}
phase: 5
document_type: epics-index
status: draft
generated_at: ${timestamp}
version: 1
dependencies:
- ../requirements/_index.md
- ../architecture/_index.md
---`
const epicsIndexContent = `${epicsIndexFrontmatter}
# Epics & Stories
## Epic Overview
| ID | Title | Priority | MVP | Size | Status |
|----|-------|----------|-----|------|--------|
${epicsList.map(e => `| [EPIC-${e.id}](EPIC-${e.id}-${e.slug}.md) | ${e.title} | ${e.priority} | ${e.mvp ? '✓' : ''} | ${e.size} | draft |`).join('\n')}
## Dependency Map
\`\`\`mermaid
${cliOutput.dependency_diagram}
\`\`\`
## Execution Order
${cliOutput.execution_order}
## MVP Scope
${cliOutput.mvp_definition}
### MVP Epics
${epicsList.filter(e => e.mvp).map(e => `- EPIC-${e.id}: ${e.title}`).join('\n')}
### Post-MVP
${epicsList.filter(e => !e.mvp).map(e => `- EPIC-${e.id}: ${e.title}`).join('\n')}
## Traceability Matrix
${generateTraceabilityMatrix(epicsList, funcReqs)}
`
Write(`${sessionFolder}/spec/epics/_index.md`, epicsIndexContent)
return {
outputPath: 'spec/epics/_index.md',
documentSummary: `Epics generated: ${epicsList.length} total, ${epicsList.filter(e => e.mvp).length} in MVP`
}
}
```
## Helper Functions
```javascript
function parseFunctionalRequirements(cliOutput) {
// Parse CLI JSON output to extract functional requirements
// Returns: [{ id, title, description, user_story, acceptance_criteria[], priority, slug }]
}
function parseNonFunctionalRequirements(cliOutput) {
// Parse CLI JSON output to extract non-functional requirements
// Returns: [{ id, type, title, requirement, metric, target, slug }]
}
function parseADRs(geminiOutput, codexOutput) {
// Parse architecture outputs to extract ADRs with review feedback
// Returns: [{ id, title, context, decision, alternatives[], consequences, reviewFeedback, slug }]
}
function parseEpics(cliOutput) {
// Parse CLI JSON output to extract Epics and Stories
// Returns: [{ id, title, description, priority, mvp, size, stories[], reqs[], adrs[], deps[], slug }]
}
function fillTemplate(template, data) {
// Fill template placeholders with data
// Apply document-standards.md formatting rules
}
function generateTraceabilityMatrix(epics, requirements) {
// Generate traceability matrix showing Epic → Requirement mappings
}
```

View File

@@ -0,0 +1,257 @@
# Role: writer
Product Brief, Requirements/PRD, Architecture, and Epics & Stories document generation. Maps to spec-generator Phases 2-5.
## Role Identity
- **Name**: `writer`
- **Task Prefix**: `DRAFT-*`
- **Output Tag**: `[writer]`
- **Responsibility**: Load Context → Generate Document → Incorporate Feedback → Report
- **Communication**: SendMessage to coordinator only
## Role Boundaries
### MUST
- Only process DRAFT-* tasks
- Read templates before generating documents
- Follow document-standards.md formatting rules
- Integrate discussion feedback when available
- Generate proper frontmatter for all documents
### MUST NOT
- Create tasks for other roles
- Contact other workers directly
- Skip template loading
- Modify discussion records
- Generate documents without loading prior dependencies
## Message Types
| Type | Direction | Trigger | Description |
|------|-----------|---------|-------------|
| `draft_ready` | writer → coordinator | Document writing complete | With document path and type |
| `draft_revision` | writer → coordinator | Document revised and resubmitted | Describes changes made |
| `impl_progress` | writer → coordinator | Long writing progress | Multi-document stage progress |
| `error` | writer → coordinator | Unrecoverable error | Template missing, insufficient context, etc. |
## Message Bus
Before every `SendMessage`, MUST call `mcp__ccw-tools__team_msg` to log:
```javascript
// Document ready
mcp__ccw-tools__team_msg({
operation: "log",
team: teamName,
from: "writer",
to: "coordinator",
type: "draft_ready",
summary: "[writer] Product Brief complete",
ref: `${sessionFolder}/product-brief.md`
})
// Document revision
mcp__ccw-tools__team_msg({
operation: "log",
team: teamName,
from: "writer",
to: "coordinator",
type: "draft_revision",
summary: "[writer] Requirements revised per discussion feedback"
})
// Error report
mcp__ccw-tools__team_msg({
operation: "log",
team: teamName,
from: "writer",
to: "coordinator",
type: "error",
summary: "[writer] Input artifact missing, cannot generate document"
})
```
### CLI Fallback
When `mcp__ccw-tools__team_msg` MCP is unavailable:
```bash
ccw team log --team "${teamName}" --from "writer" --to "coordinator" --type "draft_ready" --summary "[writer] Brief complete" --ref "${sessionFolder}/product-brief.md" --json
```
## Toolbox
### Available Commands
- `commands/generate-doc.md` - Multi-CLI document generation for 4 doc types
### Subagent Capabilities
- None
### CLI Capabilities
- `gemini`, `codex`, `claude` for multi-perspective analysis
## Execution (5-Phase)
### Phase 1: Task Discovery
```javascript
const tasks = TaskList()
const myTasks = tasks.filter(t =>
t.subject.startsWith('DRAFT-') &&
t.owner === 'writer' &&
t.status === 'pending' &&
t.blockedBy.length === 0
)
if (myTasks.length === 0) return // idle
const task = TaskGet({ taskId: myTasks[0].id })
TaskUpdate({ taskId: task.id, status: 'in_progress' })
```
### Phase 2: Context & Discussion Loading
```javascript
// Extract session folder from task description
const sessionMatch = task.description.match(/Session:\s*(.+)/)
const sessionFolder = sessionMatch ? sessionMatch[1].trim() : ''
// Load session config
let specConfig = null
try { specConfig = JSON.parse(Read(`${sessionFolder}/spec/spec-config.json`)) } catch {}
// Determine document type from task subject
const docType = task.subject.includes('Product Brief') ? 'product-brief'
: task.subject.includes('Requirements') || task.subject.includes('PRD') ? 'requirements'
: task.subject.includes('Architecture') ? 'architecture'
: task.subject.includes('Epics') ? 'epics'
: 'unknown'
// Load discussion feedback (from preceding DISCUSS task)
const discussionFiles = {
'product-brief': 'discussions/discuss-001-scope.md',
'requirements': 'discussions/discuss-002-brief.md',
'architecture': 'discussions/discuss-003-requirements.md',
'epics': 'discussions/discuss-004-architecture.md'
}
let discussionFeedback = null
try { discussionFeedback = Read(`${sessionFolder}/${discussionFiles[docType]}`) } catch {}
// Load prior documents progressively
const priorDocs = {}
if (docType !== 'product-brief') {
try { priorDocs.discoveryContext = Read(`${sessionFolder}/spec/discovery-context.json`) } catch {}
}
if (['requirements', 'architecture', 'epics'].includes(docType)) {
try { priorDocs.productBrief = Read(`${sessionFolder}/spec/product-brief.md`) } catch {}
}
if (['architecture', 'epics'].includes(docType)) {
try { priorDocs.requirementsIndex = Read(`${sessionFolder}/spec/requirements/_index.md`) } catch {}
}
if (docType === 'epics') {
try { priorDocs.architectureIndex = Read(`${sessionFolder}/spec/architecture/_index.md`) } catch {}
}
```
### Phase 3: Document Generation
**Delegate to command file**:
```javascript
// Load and execute document generation command
const generateDocCommand = Read('commands/generate-doc.md')
// Execute command with context:
// - docType
// - sessionFolder
// - specConfig
// - discussionFeedback
// - priorDocs
// - task
// Command will handle:
// - Loading document standards
// - Loading appropriate template
// - Building shared context
// - Routing to type-specific generation (DRAFT-001/002/003/004)
// - Integrating discussion feedback
// - Writing output files
// Returns: { outputPath, documentSummary }
```
### Phase 4: Self-Validation
```javascript
const docContent = Read(`${sessionFolder}/${outputPath}`)
const validationChecks = {
has_frontmatter: /^---\n[\s\S]+?\n---/.test(docContent),
sections_complete: /* verify all required sections present */,
cross_references: docContent.includes('session_id'),
discussion_integrated: !discussionFeedback || docContent.includes('Discussion')
}
const allValid = Object.values(validationChecks).every(v => v)
```
### Phase 5: Report to Coordinator
```javascript
const docTypeLabel = {
'product-brief': 'Product Brief',
'requirements': 'Requirements/PRD',
'architecture': 'Architecture Document',
'epics': 'Epics & Stories'
}
mcp__ccw-tools__team_msg({
operation: "log", team: teamName,
from: "writer", to: "coordinator",
type: "draft_ready",
summary: `[writer] ${docTypeLabel[docType]} 完成: ${allValid ? '验证通过' : '部分验证失败'}`,
ref: `${sessionFolder}/${outputPath}`
})
SendMessage({
type: "message",
recipient: "coordinator",
content: `[writer] ## 文档撰写结果
**Task**: ${task.subject}
**文档类型**: ${docTypeLabel[docType]}
**验证状态**: ${allValid ? 'PASS' : 'PARTIAL'}
### 文档摘要
${documentSummary}
### 讨论反馈整合
${discussionFeedback ? '已整合前序讨论反馈' : '首次撰写'}
### 自验证结果
${Object.entries(validationChecks).map(([k, v]) => '- ' + k + ': ' + (v ? 'PASS' : 'FAIL')).join('\n')}
### 输出位置
${sessionFolder}/${outputPath}
文档已就绪,可进入讨论轮次。`,
summary: `[writer] ${docTypeLabel[docType]} 就绪`
})
TaskUpdate({ taskId: task.id, status: 'completed' })
// Check for next DRAFT task → back to Phase 1
```
## Error Handling
| Scenario | Resolution |
|----------|------------|
| No DRAFT-* tasks available | Idle, wait for coordinator assignment |
| Prior document not found | Notify coordinator, request prerequisite |
| CLI analysis failure | Retry with fallback tool, then direct generation |
| Template sections incomplete | Generate best-effort, note gaps in report |
| Discussion feedback contradicts prior docs | Note conflict in document, flag for next discussion |
| Session folder missing | Notify coordinator, request session path |
| Unexpected error | Log error via team_msg, report to coordinator |

View File

@@ -0,0 +1,192 @@
# Document Standards
Defines format conventions, YAML frontmatter schema, naming rules, and content structure for all spec-generator outputs.
## When to Use
| Phase | Usage | Section |
|-------|-------|---------|
| All Phases | Frontmatter format | YAML Frontmatter Schema |
| All Phases | File naming | Naming Conventions |
| Phase 2-5 | Document structure | Content Structure |
| Phase 6 | Validation reference | All sections |
---
## YAML Frontmatter Schema
Every generated document MUST begin with YAML frontmatter:
```yaml
---
session_id: SPEC-{slug}-{YYYY-MM-DD}
phase: {1-6}
document_type: {product-brief|requirements|architecture|epics|readiness-report|spec-summary}
status: draft|review|complete
generated_at: {ISO8601 timestamp}
stepsCompleted: []
version: 1
dependencies:
- {list of input documents used}
---
```
### Field Definitions
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `session_id` | string | Yes | Session identifier matching spec-config.json |
| `phase` | number | Yes | Phase number that generated this document (1-6) |
| `document_type` | string | Yes | One of: product-brief, requirements, architecture, epics, readiness-report, spec-summary |
| `status` | enum | Yes | draft (initial), review (user reviewed), complete (finalized) |
| `generated_at` | string | Yes | ISO8601 timestamp of generation |
| `stepsCompleted` | array | Yes | List of step IDs completed during generation |
| `version` | number | Yes | Document version, incremented on re-generation |
| `dependencies` | array | No | List of input files this document depends on |
### Status Transitions
```
draft -> review -> complete
| ^
+-------------------+ (direct promotion in auto mode)
```
- **draft**: Initial generation, not yet user-reviewed
- **review**: User has reviewed and provided feedback
- **complete**: Finalized, ready for downstream consumption
In auto mode (`-y`), documents are promoted directly from `draft` to `complete`.
---
## Naming Conventions
### Session ID Format
```
SPEC-{slug}-{YYYY-MM-DD}
```
- **slug**: Lowercase, alphanumeric + Chinese characters, hyphens as separators, max 40 chars
- **date**: UTC+8 date in YYYY-MM-DD format
Examples:
- `SPEC-task-management-system-2026-02-11`
- `SPEC-user-auth-oauth-2026-02-11`
### Output Files
| File | Phase | Description |
|------|-------|-------------|
| `spec-config.json` | 1 | Session configuration and state |
| `discovery-context.json` | 1 | Codebase exploration results (optional) |
| `product-brief.md` | 2 | Product brief document |
| `requirements.md` | 3 | PRD document |
| `architecture.md` | 4 | Architecture decisions document |
| `epics.md` | 5 | Epic/Story breakdown document |
| `readiness-report.md` | 6 | Quality validation report |
| `spec-summary.md` | 6 | One-page executive summary |
### Output Directory
```
.workflow/.spec/{session-id}/
```
---
## Content Structure
### Heading Hierarchy
- `#` (H1): Document title only (one per document)
- `##` (H2): Major sections
- `###` (H3): Subsections
- `####` (H4): Detail items (use sparingly)
Maximum depth: 4 levels. Prefer flat structures.
### Section Ordering
Every document follows this general pattern:
1. **YAML Frontmatter** (mandatory)
2. **Title** (H1)
3. **Executive Summary** (2-3 sentences)
4. **Core Content Sections** (H2, document-specific)
5. **Open Questions / Risks** (if applicable)
6. **References / Traceability** (links to upstream/downstream docs)
### Formatting Rules
| Element | Format | Example |
|---------|--------|---------|
| Requirements | `REQ-{NNN}` prefix | REQ-001: User login |
| Acceptance criteria | Checkbox list | `- [ ] User can log in with email` |
| Architecture decisions | `ADR-{NNN}` prefix | ADR-001: Use PostgreSQL |
| Epics | `EPIC-{NNN}` prefix | EPIC-001: Authentication |
| Stories | `STORY-{EPIC}-{NNN}` prefix | STORY-001-001: Login form |
| Priority tags | MoSCoW labels | `[Must]`, `[Should]`, `[Could]`, `[Won't]` |
| Mermaid diagrams | Fenced code blocks | ````mermaid ... ``` `` |
| Code examples | Language-tagged blocks | ````typescript ... ``` `` |
### Cross-Reference Format
Use relative references between documents:
```markdown
See [Product Brief](product-brief.md#section-name) for details.
Derived from [REQ-001](requirements.md#req-001).
```
### Language
- Document body: Follow user's input language (Chinese or English)
- Technical identifiers: Always English (REQ-001, ADR-001, EPIC-001)
- YAML frontmatter keys: Always English
---
## spec-config.json Schema
```json
{
"session_id": "string (required)",
"seed_input": "string (required) - original user input",
"input_type": "text|file (required)",
"timestamp": "ISO8601 (required)",
"mode": "interactive|auto (required)",
"complexity": "simple|moderate|complex (required)",
"depth": "light|standard|comprehensive (required)",
"focus_areas": ["string array"],
"seed_analysis": {
"problem_statement": "string",
"target_users": ["string array"],
"domain": "string",
"constraints": ["string array"],
"dimensions": ["string array - 3-5 exploration dimensions"]
},
"has_codebase": "boolean",
"phasesCompleted": [
{
"phase": "number (1-6)",
"name": "string (phase name)",
"output_file": "string (primary output file)",
"completed_at": "ISO8601"
}
]
}
```
---
## Validation Checklist
- [ ] Every document starts with valid YAML frontmatter
- [ ] `session_id` matches across all documents in a session
- [ ] `status` field reflects current document state
- [ ] All cross-references resolve to valid targets
- [ ] Heading hierarchy is correct (no skipped levels)
- [ ] Technical identifiers use correct prefixes
- [ ] Output files are in the correct directory

View File

@@ -0,0 +1,207 @@
# Quality Gates
Per-phase quality gate criteria and scoring dimensions for spec-generator outputs.
## When to Use
| Phase | Usage | Section |
|-------|-------|---------|
| Phase 2-5 | Post-generation self-check | Per-Phase Gates |
| Phase 6 | Cross-document validation | Cross-Document Validation |
| Phase 6 | Final scoring | Scoring Dimensions |
---
## Quality Thresholds
| Gate | Score | Action |
|------|-------|--------|
| **Pass** | >= 80% | Continue to next phase |
| **Review** | 60-79% | Log warnings, continue with caveats |
| **Fail** | < 60% | Must address issues before continuing |
In auto mode (`-y`), Review-level issues are logged but do not block progress.
---
## Scoring Dimensions
### 1. Completeness (25%)
All required sections present with substantive content.
| Score | Criteria |
|-------|----------|
| 100% | All template sections filled with detailed content |
| 75% | All sections present, some lack detail |
| 50% | Major sections present but minor sections missing |
| 25% | Multiple major sections missing or empty |
| 0% | Document is a skeleton only |
### 2. Consistency (25%)
Terminology, formatting, and references are uniform across documents.
| Score | Criteria |
|-------|----------|
| 100% | All terms consistent, all references valid, formatting uniform |
| 75% | Minor terminology variations, all references valid |
| 50% | Some inconsistent terms, 1-2 broken references |
| 25% | Frequent inconsistencies, multiple broken references |
| 0% | Documents contradict each other |
### 3. Traceability (25%)
Requirements, architecture decisions, and stories trace back to goals.
| Score | Criteria |
|-------|----------|
| 100% | Every story traces to a requirement, every requirement traces to a goal |
| 75% | Most items traceable, few orphans |
| 50% | Partial traceability, some disconnected items |
| 25% | Weak traceability, many orphan items |
| 0% | No traceability between documents |
### 4. Depth (25%)
Content provides sufficient detail for execution teams.
| Score | Criteria |
|-------|----------|
| 100% | Acceptance criteria specific and testable, architecture decisions justified, stories estimable |
| 75% | Most items detailed enough, few vague areas |
| 50% | Mix of detailed and vague content |
| 25% | Mostly high-level, lacking actionable detail |
| 0% | Too abstract for execution |
---
## Per-Phase Quality Gates
### Phase 1: Discovery
| Check | Criteria | Severity |
|-------|----------|----------|
| Session ID valid | Matches `SPEC-{slug}-{date}` format | Error |
| Problem statement exists | Non-empty, >= 20 characters | Error |
| Target users identified | >= 1 user group | Error |
| Dimensions generated | 3-5 exploration dimensions | Warning |
| Constraints listed | >= 0 (can be empty with justification) | Info |
### Phase 2: Product Brief
| Check | Criteria | Severity |
|-------|----------|----------|
| Vision statement | Clear, 1-3 sentences | Error |
| Problem statement | Specific and measurable | Error |
| Target users | >= 1 persona with needs described | Error |
| Goals defined | >= 2 measurable goals | Error |
| Success metrics | >= 2 quantifiable metrics | Warning |
| Scope boundaries | In-scope and out-of-scope listed | Warning |
| Multi-perspective | >= 2 CLI perspectives synthesized | Info |
### Phase 3: Requirements (PRD)
| Check | Criteria | Severity |
|-------|----------|----------|
| Functional requirements | >= 3 with REQ-NNN IDs | Error |
| Acceptance criteria | Every requirement has >= 1 criterion | Error |
| MoSCoW priority | Every requirement tagged | Error |
| Non-functional requirements | >= 1 (performance, security, etc.) | Warning |
| User stories | >= 1 per Must-have requirement | Warning |
| Traceability | Requirements trace to product brief goals | Warning |
### Phase 4: Architecture
| Check | Criteria | Severity |
|-------|----------|----------|
| Component diagram | Present (Mermaid or ASCII) | Error |
| Tech stack specified | Languages, frameworks, key libraries | Error |
| ADR present | >= 1 Architecture Decision Record | Error |
| ADR has alternatives | Each ADR lists >= 2 options considered | Warning |
| Integration points | External systems/APIs identified | Warning |
| Data model | Key entities and relationships described | Warning |
| Codebase mapping | Mapped to existing code (if has_codebase) | Info |
### Phase 5: Epics & Stories
| Check | Criteria | Severity |
|-------|----------|----------|
| Epics defined | 3-7 epics with EPIC-NNN IDs | Error |
| MVP subset | >= 1 epic tagged as MVP | Error |
| Stories per epic | 2-5 stories per epic | Error |
| Story format | "As a...I want...So that..." pattern | Warning |
| Dependency map | Cross-epic dependencies documented | Warning |
| Estimation hints | Relative sizing (S/M/L/XL) per story | Info |
| Traceability | Stories trace to requirements | Warning |
### Phase 6: Readiness Check
| Check | Criteria | Severity |
|-------|----------|----------|
| All documents exist | product-brief, requirements, architecture, epics | Error |
| Frontmatter valid | All YAML frontmatter parseable and correct | Error |
| Cross-references valid | All document links resolve | Error |
| Overall score >= 60% | Weighted average across 4 dimensions | Error |
| No unresolved Errors | All Error-severity issues addressed | Error |
| Summary generated | spec-summary.md created | Warning |
---
## Cross-Document Validation
Checks performed during Phase 6 across all documents:
### Completeness Matrix
```
Product Brief goals -> Requirements (each goal has >= 1 requirement)
Requirements -> Architecture (each Must requirement has design coverage)
Requirements -> Epics (each Must requirement appears in >= 1 story)
Architecture ADRs -> Epics (tech choices reflected in implementation stories)
```
### Consistency Checks
| Check | Documents | Rule |
|-------|-----------|------|
| Terminology | All | Same term used consistently (no synonyms for same concept) |
| User personas | Brief + PRD + Epics | Same user names/roles throughout |
| Scope | Brief + PRD | PRD scope does not exceed brief scope |
| Tech stack | Architecture + Epics | Stories reference correct technologies |
### Traceability Matrix Format
```markdown
| Goal | Requirements | Architecture | Epics |
|------|-------------|--------------|-------|
| G-001: ... | REQ-001, REQ-002 | ADR-001 | EPIC-001 |
| G-002: ... | REQ-003 | ADR-002 | EPIC-002, EPIC-003 |
```
---
## Issue Classification
### Error (Must Fix)
- Missing required document or section
- Broken cross-references
- Contradictory information between documents
- Empty acceptance criteria on Must-have requirements
- No MVP subset defined in epics
### Warning (Should Fix)
- Vague acceptance criteria
- Missing non-functional requirements
- No success metrics defined
- Incomplete traceability
- Missing architecture review notes
### Info (Nice to Have)
- Could add more detailed personas
- Consider additional ADR alternatives
- Story estimation hints missing
- Mermaid diagrams could be more detailed

View File

@@ -0,0 +1,156 @@
{
"team_name": "team-lifecycle",
"team_display_name": "Team Lifecycle",
"description": "Unified team skill covering spec-to-dev-to-test full lifecycle",
"version": "2.0.0",
"architecture": "folder-based",
"role_structure": "roles/{name}/role.md + roles/{name}/commands/*.md",
"roles": {
"coordinator": {
"task_prefix": null,
"responsibility": "Pipeline orchestration, requirement clarification, task chain creation, message dispatch",
"message_types": ["plan_approved", "plan_revision", "task_unblocked", "fix_required", "error", "shutdown"]
},
"analyst": {
"task_prefix": "RESEARCH",
"responsibility": "Seed analysis, codebase exploration, multi-dimensional context gathering",
"message_types": ["research_ready", "research_progress", "error"]
},
"writer": {
"task_prefix": "DRAFT",
"responsibility": "Product Brief / PRD / Architecture / Epics document generation",
"message_types": ["draft_ready", "draft_revision", "impl_progress", "error"]
},
"discussant": {
"task_prefix": "DISCUSS",
"responsibility": "Multi-perspective critique, consensus building, conflict escalation",
"message_types": ["discussion_ready", "discussion_blocked", "impl_progress", "error"]
},
"planner": {
"task_prefix": "PLAN",
"responsibility": "Multi-angle code exploration, structured implementation planning",
"message_types": ["plan_ready", "plan_revision", "impl_progress", "error"]
},
"executor": {
"task_prefix": "IMPL",
"responsibility": "Code implementation following approved plans",
"message_types": ["impl_complete", "impl_progress", "error"]
},
"tester": {
"task_prefix": "TEST",
"responsibility": "Adaptive test-fix cycles, progressive testing, quality gates",
"message_types": ["test_result", "impl_progress", "fix_required", "error"]
},
"reviewer": {
"task_prefix": "REVIEW",
"additional_prefixes": ["QUALITY"],
"responsibility": "Code review (REVIEW-*) + Spec quality validation (QUALITY-*)",
"message_types": ["review_result", "quality_result", "fix_required", "error"]
},
"explorer": {
"task_prefix": "EXPLORE",
"responsibility": "Code search, pattern discovery, dependency tracing. Service role — on-demand by coordinator",
"role_type": "service",
"message_types": ["explore_ready", "explore_progress", "task_failed"]
},
"architect": {
"task_prefix": "ARCH",
"responsibility": "Architecture assessment, tech feasibility, design pattern review. Consulting role — on-demand by coordinator",
"role_type": "consulting",
"consultation_modes": ["spec-review", "plan-review", "code-review", "consult", "feasibility"],
"message_types": ["arch_ready", "arch_concern", "arch_progress", "error"]
},
"fe-developer": {
"task_prefix": "DEV-FE",
"responsibility": "Frontend component/page implementation, design token consumption, responsive UI",
"role_type": "frontend-pipeline",
"message_types": ["dev_fe_complete", "dev_fe_progress", "error"]
},
"fe-qa": {
"task_prefix": "QA-FE",
"responsibility": "5-dimension frontend review (quality, a11y, design compliance, UX, pre-delivery), GC loop",
"role_type": "frontend-pipeline",
"message_types": ["qa_fe_passed", "qa_fe_result", "fix_required", "error"]
}
},
"pipelines": {
"spec-only": {
"description": "Specification pipeline: research → discuss → draft → quality",
"task_chain": [
"RESEARCH-001",
"DISCUSS-001", "DRAFT-001", "DISCUSS-002",
"DRAFT-002", "DISCUSS-003", "DRAFT-003", "DISCUSS-004",
"DRAFT-004", "DISCUSS-005", "QUALITY-001", "DISCUSS-006"
]
},
"impl-only": {
"description": "Implementation pipeline: plan → implement → test + review",
"task_chain": ["PLAN-001", "IMPL-001", "TEST-001", "REVIEW-001"]
},
"full-lifecycle": {
"description": "Full lifecycle: spec pipeline → implementation pipeline",
"task_chain": "spec-only + impl-only (PLAN-001 blockedBy DISCUSS-006)"
},
"fe-only": {
"description": "Frontend-only pipeline: plan → frontend dev → frontend QA",
"task_chain": ["PLAN-001", "DEV-FE-001", "QA-FE-001"],
"gc_loop": { "max_rounds": 2, "convergence": "score >= 8 && critical === 0" }
},
"fullstack": {
"description": "Fullstack pipeline: plan → backend + frontend parallel → test + QA",
"task_chain": ["PLAN-001", "IMPL-001||DEV-FE-001", "TEST-001||QA-FE-001", "REVIEW-001"],
"sync_points": ["REVIEW-001"]
},
"full-lifecycle-fe": {
"description": "Full lifecycle with frontend: spec → plan → backend + frontend → test + QA",
"task_chain": "spec-only + fullstack (PLAN-001 blockedBy DISCUSS-006)"
}
},
"frontend_detection": {
"keywords": ["component", "page", "UI", "前端", "frontend", "CSS", "HTML", "React", "Vue", "Tailwind", "组件", "页面", "样式", "layout", "responsive", "Svelte", "Next.js", "Nuxt", "shadcn", "设计系统", "design system"],
"file_patterns": ["*.tsx", "*.jsx", "*.vue", "*.svelte", "*.css", "*.scss", "*.html"],
"routing_rules": {
"frontend_only": "All tasks match frontend keywords, no backend/API mentions",
"fullstack": "Mix of frontend and backend tasks",
"backend_only": "No frontend keywords detected (default impl-only)"
}
},
"ui_ux_pro_max": {
"skill_name": "ui-ux-pro-max",
"install_command": "/plugin install ui-ux-pro-max@ui-ux-pro-max-skill",
"invocation": "Skill(skill=\"ui-ux-pro-max\", args=\"...\")",
"domains": ["product", "style", "typography", "color", "landing", "chart", "ux", "web"],
"stacks": ["html-tailwind", "react", "nextjs", "vue", "svelte", "shadcn", "swiftui", "react-native", "flutter"],
"fallback": "llm-general-knowledge",
"design_intelligence_chain": ["analyst → design-intelligence.json", "architect → design-tokens.json", "fe-developer → tokens.css", "fe-qa → anti-pattern audit"]
},
"shared_memory": {
"file": "shared-memory.json",
"schema": {
"design_intelligence": "From analyst via ui-ux-pro-max",
"design_token_registry": "From architect, consumed by fe-developer/fe-qa",
"component_inventory": "From fe-developer, list of implemented components",
"style_decisions": "Accumulated design decisions",
"qa_history": "From fe-qa, audit trail",
"industry_context": "Industry + strictness config"
}
},
"collaboration_patterns": ["CP-1", "CP-2", "CP-4", "CP-5", "CP-6", "CP-10"],
"session_dirs": {
"base": ".workflow/.team/TLS-{slug}-{YYYY-MM-DD}/",
"spec": "spec/",
"discussions": "discussions/",
"plan": "plan/",
"explorations": "explorations/",
"architecture": "architecture/",
"wisdom": "wisdom/",
"messages": ".workflow/.team-msg/{team-name}/"
}
}

View File

@@ -0,0 +1,254 @@
# Architecture Document Template (Directory Structure)
Template for generating architecture decision documents as a directory of individual ADR files in Phase 4.
## Usage Context
| Phase | Usage |
|-------|-------|
| Phase 4 (Architecture) | Generate `architecture/` directory from requirements analysis |
| Output Location | `{workDir}/architecture/` |
## Output Structure
```
{workDir}/architecture/
├── _index.md # Overview, components, tech stack, data model, security
├── ADR-001-{slug}.md # Individual Architecture Decision Record
├── ADR-002-{slug}.md
└── ...
```
---
## Template: _index.md
```markdown
---
session_id: {session_id}
phase: 4
document_type: architecture-index
status: draft
generated_at: {timestamp}
version: 1
dependencies:
- ../spec-config.json
- ../product-brief.md
- ../requirements/_index.md
---
# Architecture: {product_name}
{executive_summary - high-level architecture approach and key decisions}
## System Overview
### Architecture Style
{description of chosen architecture style: microservices, monolith, serverless, etc.}
### System Context Diagram
```mermaid
C4Context
title System Context Diagram
Person(user, "User", "Primary user")
System(system, "{product_name}", "Core system")
System_Ext(ext1, "{external_system}", "{description}")
Rel(user, system, "Uses")
Rel(system, ext1, "Integrates with")
```
## Component Architecture
### Component Diagram
```mermaid
graph TD
subgraph "{product_name}"
A[Component A] --> B[Component B]
B --> C[Component C]
A --> D[Component D]
end
B --> E[External Service]
```
### Component Descriptions
| Component | Responsibility | Technology | Dependencies |
|-----------|---------------|------------|--------------|
| {component_name} | {what it does} | {tech stack} | {depends on} |
## Technology Stack
### Core Technologies
| Layer | Technology | Version | Rationale |
|-------|-----------|---------|-----------|
| Frontend | {technology} | {version} | {why chosen} |
| Backend | {technology} | {version} | {why chosen} |
| Database | {technology} | {version} | {why chosen} |
| Infrastructure | {technology} | {version} | {why chosen} |
### Key Libraries & Frameworks
| Library | Purpose | License |
|---------|---------|---------|
| {library_name} | {purpose} | {license} |
## Architecture Decision Records
| ADR | Title | Status | Key Choice |
|-----|-------|--------|------------|
| [ADR-001](ADR-001-{slug}.md) | {title} | Accepted | {one-line summary} |
| [ADR-002](ADR-002-{slug}.md) | {title} | Accepted | {one-line summary} |
| [ADR-003](ADR-003-{slug}.md) | {title} | Proposed | {one-line summary} |
## Data Architecture
### Data Model
```mermaid
erDiagram
ENTITY_A ||--o{ ENTITY_B : "has many"
ENTITY_A {
string id PK
string name
datetime created_at
}
ENTITY_B {
string id PK
string entity_a_id FK
string value
}
```
### Data Storage Strategy
| Data Type | Storage | Retention | Backup |
|-----------|---------|-----------|--------|
| {type} | {storage solution} | {retention policy} | {backup strategy} |
## API Design
### API Overview
| Endpoint | Method | Purpose | Auth |
|----------|--------|---------|------|
| {/api/resource} | {GET/POST/etc} | {purpose} | {auth type} |
## Security Architecture
### Security Controls
| Control | Implementation | Requirement |
|---------|---------------|-------------|
| Authentication | {approach} | [NFR-S-{NNN}](../requirements/NFR-S-{NNN}-{slug}.md) |
| Authorization | {approach} | [NFR-S-{NNN}](../requirements/NFR-S-{NNN}-{slug}.md) |
| Data Protection | {approach} | [NFR-S-{NNN}](../requirements/NFR-S-{NNN}-{slug}.md) |
## Infrastructure & Deployment
### Deployment Architecture
{description of deployment model: containers, serverless, VMs, etc.}
### Environment Strategy
| Environment | Purpose | Configuration |
|-------------|---------|---------------|
| Development | Local development | {config} |
| Staging | Pre-production testing | {config} |
| Production | Live system | {config} |
## Codebase Integration
{if has_codebase is true:}
### Existing Code Mapping
| New Component | Existing Module | Integration Type | Notes |
|--------------|----------------|------------------|-------|
| {component} | {existing module path} | Extend/Replace/New | {notes} |
### Migration Notes
{any migration considerations for existing code}
## Quality Attributes
| Attribute | Target | Measurement | ADR Reference |
|-----------|--------|-------------|---------------|
| Performance | {target} | {how measured} | [ADR-{NNN}](ADR-{NNN}-{slug}.md) |
| Scalability | {target} | {how measured} | [ADR-{NNN}](ADR-{NNN}-{slug}.md) |
| Reliability | {target} | {how measured} | [ADR-{NNN}](ADR-{NNN}-{slug}.md) |
## Risks & Mitigations
| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| {risk} | High/Medium/Low | High/Medium/Low | {mitigation approach} |
## Open Questions
- [ ] {architectural question 1}
- [ ] {architectural question 2}
## References
- Derived from: [Requirements](../requirements/_index.md), [Product Brief](../product-brief.md)
- Next: [Epics & Stories](../epics/_index.md)
```
---
## Template: ADR-NNN-{slug}.md (Individual Architecture Decision Record)
```markdown
---
id: ADR-{NNN}
status: Accepted
traces_to: [{REQ-NNN}, {NFR-X-NNN}]
date: {timestamp}
---
# ADR-{NNN}: {decision_title}
## Context
{what is the situation that motivates this decision}
## Decision
{what is the chosen approach}
## Alternatives Considered
| Option | Pros | Cons |
|--------|------|------|
| {option_1 - chosen} | {pros} | {cons} |
| {option_2} | {pros} | {cons} |
| {option_3} | {pros} | {cons} |
## Consequences
- **Positive**: {positive outcomes}
- **Negative**: {tradeoffs accepted}
- **Risks**: {risks to monitor}
## Traces
- **Requirements**: [REQ-{NNN}](../requirements/REQ-{NNN}-{slug}.md), [NFR-X-{NNN}](../requirements/NFR-X-{NNN}-{slug}.md)
- **Implemented by**: [EPIC-{NNN}](../epics/EPIC-{NNN}-{slug}.md) (added in Phase 5)
```
---
## Variable Descriptions
| Variable | Source | Description |
|----------|--------|-------------|
| `{session_id}` | spec-config.json | Session identifier |
| `{timestamp}` | Runtime | ISO8601 generation timestamp |
| `{product_name}` | product-brief.md | Product/feature name |
| `{NNN}` | Auto-increment | ADR/requirement number |
| `{slug}` | Auto-generated | Kebab-case from decision title |
| `{has_codebase}` | spec-config.json | Whether existing codebase exists |

View File

@@ -0,0 +1,196 @@
# Epics & Stories Template (Directory Structure)
Template for generating epic/story breakdown as a directory of individual Epic files in Phase 5.
## Usage Context
| Phase | Usage |
|-------|-------|
| Phase 5 (Epics & Stories) | Generate `epics/` directory from requirements decomposition |
| Output Location | `{workDir}/epics/` |
## Output Structure
```
{workDir}/epics/
├── _index.md # Overview table + dependency map + MVP scope + execution order
├── EPIC-001-{slug}.md # Individual Epic with its Stories
├── EPIC-002-{slug}.md
└── ...
```
---
## Template: _index.md
```markdown
---
session_id: {session_id}
phase: 5
document_type: epics-index
status: draft
generated_at: {timestamp}
version: 1
dependencies:
- ../spec-config.json
- ../product-brief.md
- ../requirements/_index.md
- ../architecture/_index.md
---
# Epics & Stories: {product_name}
{executive_summary - overview of epic structure and MVP scope}
## Epic Overview
| Epic ID | Title | Priority | MVP | Stories | Est. Size |
|---------|-------|----------|-----|---------|-----------|
| [EPIC-001](EPIC-001-{slug}.md) | {title} | Must | Yes | {n} | {S/M/L/XL} |
| [EPIC-002](EPIC-002-{slug}.md) | {title} | Must | Yes | {n} | {S/M/L/XL} |
| [EPIC-003](EPIC-003-{slug}.md) | {title} | Should | No | {n} | {S/M/L/XL} |
## Dependency Map
```mermaid
graph LR
EPIC-001 --> EPIC-002
EPIC-001 --> EPIC-003
EPIC-002 --> EPIC-004
EPIC-003 --> EPIC-005
```
### Dependency Notes
{explanation of why these dependencies exist and suggested execution order}
### Recommended Execution Order
1. [EPIC-{NNN}](EPIC-{NNN}-{slug}.md): {reason - foundational}
2. [EPIC-{NNN}](EPIC-{NNN}-{slug}.md): {reason - depends on #1}
3. ...
## MVP Scope
### MVP Epics
{list of epics included in MVP with justification, linking to each}
### MVP Definition of Done
- [ ] {MVP completion criterion 1}
- [ ] {MVP completion criterion 2}
- [ ] {MVP completion criterion 3}
## Traceability Matrix
| Requirement | Epic | Stories | Architecture |
|-------------|------|---------|--------------|
| [REQ-001](../requirements/REQ-001-{slug}.md) | [EPIC-001](EPIC-001-{slug}.md) | STORY-001-001, STORY-001-002 | [ADR-001](../architecture/ADR-001-{slug}.md) |
| [REQ-002](../requirements/REQ-002-{slug}.md) | [EPIC-001](EPIC-001-{slug}.md) | STORY-001-003 | Component B |
| [REQ-003](../requirements/REQ-003-{slug}.md) | [EPIC-002](EPIC-002-{slug}.md) | STORY-002-001 | [ADR-002](../architecture/ADR-002-{slug}.md) |
## Estimation Summary
| Size | Meaning | Count |
|------|---------|-------|
| S | Small - well-understood, minimal risk | {n} |
| M | Medium - some complexity, moderate risk | {n} |
| L | Large - significant complexity, should consider splitting | {n} |
| XL | Extra Large - high complexity, must split before implementation | {n} |
## Risks & Considerations
| Risk | Affected Epics | Mitigation |
|------|---------------|------------|
| {risk description} | [EPIC-{NNN}](EPIC-{NNN}-{slug}.md) | {mitigation} |
## Open Questions
- [ ] {question about scope or implementation 1}
- [ ] {question about scope or implementation 2}
## References
- Derived from: [Requirements](../requirements/_index.md), [Architecture](../architecture/_index.md)
- Handoff to: execution workflows (lite-plan, plan, req-plan)
```
---
## Template: EPIC-NNN-{slug}.md (Individual Epic)
```markdown
---
id: EPIC-{NNN}
priority: {Must|Should|Could}
mvp: {true|false}
size: {S|M|L|XL}
requirements: [REQ-{NNN}]
architecture: [ADR-{NNN}]
dependencies: [EPIC-{NNN}]
status: draft
---
# EPIC-{NNN}: {epic_title}
**Priority**: {Must|Should|Could}
**MVP**: {Yes|No}
**Estimated Size**: {S|M|L|XL}
## Description
{detailed epic description}
## Requirements
- [REQ-{NNN}](../requirements/REQ-{NNN}-{slug}.md): {title}
- [REQ-{NNN}](../requirements/REQ-{NNN}-{slug}.md): {title}
## Architecture
- [ADR-{NNN}](../architecture/ADR-{NNN}-{slug}.md): {title}
- Component: {component_name}
## Dependencies
- [EPIC-{NNN}](EPIC-{NNN}-{slug}.md) (blocking): {reason}
- [EPIC-{NNN}](EPIC-{NNN}-{slug}.md) (soft): {reason}
## Stories
### STORY-{EPIC}-001: {story_title}
**User Story**: As a {persona}, I want to {action} so that {benefit}.
**Acceptance Criteria**:
- [ ] {criterion 1}
- [ ] {criterion 2}
- [ ] {criterion 3}
**Size**: {S|M|L|XL}
**Traces to**: [REQ-{NNN}](../requirements/REQ-{NNN}-{slug}.md)
---
### STORY-{EPIC}-002: {story_title}
**User Story**: As a {persona}, I want to {action} so that {benefit}.
**Acceptance Criteria**:
- [ ] {criterion 1}
- [ ] {criterion 2}
**Size**: {S|M|L|XL}
**Traces to**: [REQ-{NNN}](../requirements/REQ-{NNN}-{slug}.md)
```
---
## Variable Descriptions
| Variable | Source | Description |
|----------|--------|-------------|
| `{session_id}` | spec-config.json | Session identifier |
| `{timestamp}` | Runtime | ISO8601 generation timestamp |
| `{product_name}` | product-brief.md | Product/feature name |
| `{EPIC}` | Auto-increment | Epic number (3 digits) |
| `{NNN}` | Auto-increment | Story/requirement number |
| `{slug}` | Auto-generated | Kebab-case from epic/story title |
| `{S\|M\|L\|XL}` | CLI analysis | Relative size estimate |

View File

@@ -0,0 +1,133 @@
# Product Brief Template
Template for generating product brief documents in Phase 2.
## Usage Context
| Phase | Usage |
|-------|-------|
| Phase 2 (Product Brief) | Generate product-brief.md from multi-CLI analysis |
| Output Location | `{workDir}/product-brief.md` |
---
## Template
```markdown
---
session_id: {session_id}
phase: 2
document_type: product-brief
status: draft
generated_at: {timestamp}
stepsCompleted: []
version: 1
dependencies:
- spec-config.json
---
# Product Brief: {product_name}
{executive_summary - 2-3 sentences capturing the essence of the product/feature}
## Vision
{vision_statement - clear, aspirational 1-3 sentence statement of what success looks like}
## Problem Statement
### Current Situation
{description of the current state and pain points}
### Impact
{quantified impact of the problem - who is affected, how much, how often}
## Target Users
{for each user persona:}
### {Persona Name}
- **Role**: {user's role/context}
- **Needs**: {primary needs related to this product}
- **Pain Points**: {current frustrations}
- **Success Criteria**: {what success looks like for this user}
## Goals & Success Metrics
| Goal ID | Goal | Success Metric | Target |
|---------|------|----------------|--------|
| G-001 | {goal description} | {measurable metric} | {specific target} |
| G-002 | {goal description} | {measurable metric} | {specific target} |
## Scope
### In Scope
- {feature/capability 1}
- {feature/capability 2}
- {feature/capability 3}
### Out of Scope
- {explicitly excluded item 1}
- {explicitly excluded item 2}
### Assumptions
- {key assumption 1}
- {key assumption 2}
## Competitive Landscape
| Aspect | Current State | Proposed Solution | Advantage |
|--------|--------------|-------------------|-----------|
| {aspect} | {how it's done now} | {our approach} | {differentiator} |
## Constraints & Dependencies
### Technical Constraints
- {constraint 1}
- {constraint 2}
### Business Constraints
- {constraint 1}
### Dependencies
- {external dependency 1}
- {external dependency 2}
## Multi-Perspective Synthesis
### Product Perspective
{summary of product/market analysis findings}
### Technical Perspective
{summary of technical feasibility and constraints}
### User Perspective
{summary of user journey and UX considerations}
### Convergent Themes
{themes where all perspectives agree}
### Conflicting Views
{areas where perspectives differ, with notes on resolution approach}
## Open Questions
- [ ] {unresolved question 1}
- [ ] {unresolved question 2}
## References
- Derived from: [spec-config.json](spec-config.json)
- Next: [Requirements PRD](requirements.md)
```
## Variable Descriptions
| Variable | Source | Description |
|----------|--------|-------------|
| `{session_id}` | spec-config.json | Session identifier |
| `{timestamp}` | Runtime | ISO8601 generation timestamp |
| `{product_name}` | Seed analysis | Product/feature name |
| `{executive_summary}` | CLI synthesis | 2-3 sentence summary |
| `{vision_statement}` | CLI product perspective | Aspirational vision |
| All `{...}` fields | CLI analysis outputs | Filled from multi-perspective analysis |

View File

@@ -0,0 +1,224 @@
# Requirements PRD Template (Directory Structure)
Template for generating Product Requirements Document as a directory of individual requirement files in Phase 3.
## Usage Context
| Phase | Usage |
|-------|-------|
| Phase 3 (Requirements) | Generate `requirements/` directory from product brief expansion |
| Output Location | `{workDir}/requirements/` |
## Output Structure
```
{workDir}/requirements/
├── _index.md # Summary + MoSCoW table + traceability matrix + links
├── REQ-001-{slug}.md # Individual functional requirement
├── REQ-002-{slug}.md
├── NFR-P-001-{slug}.md # Non-functional: Performance
├── NFR-S-001-{slug}.md # Non-functional: Security
├── NFR-SC-001-{slug}.md # Non-functional: Scalability
├── NFR-U-001-{slug}.md # Non-functional: Usability
└── ...
```
---
## Template: _index.md
```markdown
---
session_id: {session_id}
phase: 3
document_type: requirements-index
status: draft
generated_at: {timestamp}
version: 1
dependencies:
- ../spec-config.json
- ../product-brief.md
---
# Requirements: {product_name}
{executive_summary - brief overview of what this PRD covers and key decisions}
## Requirement Summary
| Priority | Count | Coverage |
|----------|-------|----------|
| Must Have | {n} | {description of must-have scope} |
| Should Have | {n} | {description of should-have scope} |
| Could Have | {n} | {description of could-have scope} |
| Won't Have | {n} | {description of explicitly excluded} |
## Functional Requirements
| ID | Title | Priority | Traces To |
|----|-------|----------|-----------|
| [REQ-001](REQ-001-{slug}.md) | {title} | Must | [G-001](../product-brief.md#goals--success-metrics) |
| [REQ-002](REQ-002-{slug}.md) | {title} | Must | [G-001](../product-brief.md#goals--success-metrics) |
| [REQ-003](REQ-003-{slug}.md) | {title} | Should | [G-002](../product-brief.md#goals--success-metrics) |
## Non-Functional Requirements
### Performance
| ID | Title | Target |
|----|-------|--------|
| [NFR-P-001](NFR-P-001-{slug}.md) | {title} | {target value} |
### Security
| ID | Title | Standard |
|----|-------|----------|
| [NFR-S-001](NFR-S-001-{slug}.md) | {title} | {standard/framework} |
### Scalability
| ID | Title | Target |
|----|-------|--------|
| [NFR-SC-001](NFR-SC-001-{slug}.md) | {title} | {target value} |
### Usability
| ID | Title | Target |
|----|-------|--------|
| [NFR-U-001](NFR-U-001-{slug}.md) | {title} | {target value} |
## Data Requirements
### Data Entities
| Entity | Description | Key Attributes |
|--------|-------------|----------------|
| {entity_name} | {description} | {attr1, attr2, attr3} |
### Data Flows
{description of key data flows, optionally with Mermaid diagram}
## Integration Requirements
| System | Direction | Protocol | Data Format | Notes |
|--------|-----------|----------|-------------|-------|
| {system_name} | Inbound/Outbound/Both | {REST/gRPC/etc} | {JSON/XML/etc} | {notes} |
## Constraints & Assumptions
### Constraints
- {technical or business constraint 1}
- {technical or business constraint 2}
### Assumptions
- {assumption 1 - must be validated}
- {assumption 2 - must be validated}
## Priority Rationale
{explanation of MoSCoW prioritization decisions, especially for Should/Could boundaries}
## Traceability Matrix
| Goal | Requirements |
|------|-------------|
| G-001 | [REQ-001](REQ-001-{slug}.md), [REQ-002](REQ-002-{slug}.md), [NFR-P-001](NFR-P-001-{slug}.md) |
| G-002 | [REQ-003](REQ-003-{slug}.md), [NFR-S-001](NFR-S-001-{slug}.md) |
## Open Questions
- [ ] {unresolved question 1}
- [ ] {unresolved question 2}
## References
- Derived from: [Product Brief](../product-brief.md)
- Next: [Architecture](../architecture/_index.md)
```
---
## Template: REQ-NNN-{slug}.md (Individual Functional Requirement)
```markdown
---
id: REQ-{NNN}
type: functional
priority: {Must|Should|Could|Won't}
traces_to: [G-{NNN}]
status: draft
---
# REQ-{NNN}: {requirement_title}
**Priority**: {Must|Should|Could|Won't}
## Description
{detailed requirement description}
## User Story
As a {persona}, I want to {action} so that {benefit}.
## Acceptance Criteria
- [ ] {specific, testable criterion 1}
- [ ] {specific, testable criterion 2}
- [ ] {specific, testable criterion 3}
## Traces
- **Goal**: [G-{NNN}](../product-brief.md#goals--success-metrics)
- **Architecture**: [ADR-{NNN}](../architecture/ADR-{NNN}-{slug}.md) (if applicable)
- **Implemented by**: [EPIC-{NNN}](../epics/EPIC-{NNN}-{slug}.md) (added in Phase 5)
```
---
## Template: NFR-{type}-NNN-{slug}.md (Individual Non-Functional Requirement)
```markdown
---
id: NFR-{type}-{NNN}
type: non-functional
category: {Performance|Security|Scalability|Usability}
priority: {Must|Should|Could}
status: draft
---
# NFR-{type}-{NNN}: {requirement_title}
**Category**: {Performance|Security|Scalability|Usability}
**Priority**: {Must|Should|Could}
## Requirement
{detailed requirement description}
## Metric & Target
| Metric | Target | Measurement Method |
|--------|--------|--------------------|
| {metric} | {target value} | {how measured} |
## Traces
- **Goal**: [G-{NNN}](../product-brief.md#goals--success-metrics)
- **Architecture**: [ADR-{NNN}](../architecture/ADR-{NNN}-{slug}.md) (if applicable)
```
---
## Variable Descriptions
| Variable | Source | Description |
|----------|--------|-------------|
| `{session_id}` | spec-config.json | Session identifier |
| `{timestamp}` | Runtime | ISO8601 generation timestamp |
| `{product_name}` | product-brief.md | Product/feature name |
| `{NNN}` | Auto-increment | Requirement number (zero-padded 3 digits) |
| `{slug}` | Auto-generated | Kebab-case from requirement title |
| `{type}` | Category | P (Performance), S (Security), SC (Scalability), U (Usability) |
| `{Must\|Should\|Could\|Won't}` | User input / auto | MoSCoW priority tag |