claude-code-workflow 6.3.54 → 7.0.0

package/.claude/skills/team-lifecycle-v3/roles/architect/role.md

@@ -0,0 +1,103 @@
+# 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.
+
+**Frontend project outputs** (when frontend tech stack detected in shared-memory or discovery-context):
+- `<session-folder>/architecture/design-tokens.json` — color, spacing, typography, shadow tokens
+- `<session-folder>/architecture/component-specs/*.md` — per-component design spec
+
+**Report**: mode, verdict, concern count, recommendations, output path(s).
+
+---
+
+## 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 |

package/.claude/skills/team-lifecycle-v3/roles/coordinator/commands/dispatch.md

@@ -0,0 +1,142 @@
+# Command: dispatch
+
+## Purpose
+
+Create task chains based on execution mode. Each mode maps to a predefined pipeline from SKILL.md Task Metadata Registry. Tasks are created with proper dependency chains, owner assignments, and session references.
+
+## Phase 2: Context Loading
+
+| Input | Source | Required |
+|-------|--------|----------|
+| Mode | Phase 1 requirements (spec-only, impl-only, etc.) | Yes |
+| Session folder | `<session-folder>` from Phase 2 | Yes |
+| Scope | User requirements description | Yes |
+| Spec file | User-provided path (impl-only mode only) | Conditional |
+
+## Phase 3: Task Chain Creation
+
+### Mode-to-Pipeline Routing
+
+| Mode | Tasks | Pipeline | First Task |
+|------|-------|----------|------------|
+| spec-only | 12 | Spec pipeline | RESEARCH-001 |
+| impl-only | 4 | Impl pipeline | PLAN-001 |
+| fe-only | 3 | FE pipeline | PLAN-001 |
+| fullstack | 6 | Fullstack pipeline | PLAN-001 |
+| full-lifecycle | 16 | Spec + Impl | RESEARCH-001 |
+| full-lifecycle-fe | 18 | Spec + Fullstack | RESEARCH-001 |
+
+---
+
+### Spec Pipeline (12 tasks)
+
+Used by: spec-only, full-lifecycle, full-lifecycle-fe
+
+| # | Subject | Owner | BlockedBy | Description |
+|---|---------|-------|-----------|-------------|
+| 1 | RESEARCH-001 | analyst | (none) | Seed analysis and context gathering |
+| 2 | DISCUSS-001 | discussant | RESEARCH-001 | Critique research findings |
+| 3 | DRAFT-001 | writer | DISCUSS-001 | Generate Product Brief |
+| 4 | DISCUSS-002 | discussant | DRAFT-001 | Critique Product Brief |
+| 5 | DRAFT-002 | writer | DISCUSS-002 | Generate Requirements/PRD |
+| 6 | DISCUSS-003 | discussant | DRAFT-002 | Critique Requirements/PRD |
+| 7 | DRAFT-003 | writer | DISCUSS-003 | Generate Architecture Document |
+| 8 | DISCUSS-004 | discussant | DRAFT-003 | Critique Architecture Document |
+| 9 | DRAFT-004 | writer | DISCUSS-004 | Generate Epics |
+| 10 | DISCUSS-005 | discussant | DRAFT-004 | Critique Epics |
+| 11 | QUALITY-001 | reviewer | DISCUSS-005 | 5-dimension spec quality validation |
+| 12 | DISCUSS-006 | discussant | QUALITY-001 | Final review discussion and sign-off |
+
+### Impl Pipeline (4 tasks)
+
+Used by: impl-only, full-lifecycle (PLAN-001 blockedBy DISCUSS-006)
+
+| # | Subject | Owner | BlockedBy | Description |
+|---|---------|-------|-----------|-------------|
+| 1 | PLAN-001 | planner | (none) | Multi-angle exploration and planning |
+| 2 | IMPL-001 | executor | PLAN-001 | Code implementation |
+| 3 | TEST-001 | tester | IMPL-001 | Test-fix cycles |
+| 4 | REVIEW-001 | reviewer | IMPL-001 | 4-dimension code review |
+
+### FE Pipeline (3 tasks)
+
+Used by: fe-only
+
+| # | Subject | Owner | BlockedBy | Description |
+|---|---------|-------|-----------|-------------|
+| 1 | PLAN-001 | planner | (none) | Planning (frontend focus) |
+| 2 | DEV-FE-001 | fe-developer | PLAN-001 | Frontend implementation |
+| 3 | QA-FE-001 | fe-qa | DEV-FE-001 | 5-dimension frontend QA |
+
+GC loop (max 2 rounds): QA-FE verdict=NEEDS_FIX → create DEV-FE-002 + QA-FE-002 dynamically.
+
+### Fullstack Pipeline (6 tasks)
+
+Used by: fullstack, full-lifecycle-fe (PLAN-001 blockedBy DISCUSS-006)
+
+| # | Subject | Owner | BlockedBy | Description |
+|---|---------|-------|-----------|-------------|
+| 1 | PLAN-001 | planner | (none) | Fullstack planning |
+| 2 | IMPL-001 | executor | PLAN-001 | Backend implementation |
+| 3 | DEV-FE-001 | fe-developer | PLAN-001 | Frontend implementation |
+| 4 | TEST-001 | tester | IMPL-001 | Backend test-fix cycles |
+| 5 | QA-FE-001 | fe-qa | DEV-FE-001 | Frontend QA |
+| 6 | REVIEW-001 | reviewer | TEST-001, QA-FE-001 | Full code review |
+
+### Composite Modes
+
+| Mode | Construction | PLAN-001 BlockedBy |
+|------|-------------|-------------------|
+| full-lifecycle | Spec (12) + Impl (4) | DISCUSS-006 |
+| full-lifecycle-fe | Spec (12) + Fullstack (6) | DISCUSS-006 |
+
+---
+
+### Impl-Only Pre-check
+
+Before creating impl-only tasks, verify specification exists:
+
+```
+Spec exists?
+  ├─ YES → read spec path → proceed with task creation
+  └─ NO → error: "impl-only requires existing spec, use spec-only or full-lifecycle"
+```
+
+### Task Description Template
+
+Every task description includes session and scope context:
+
+```
+TaskCreate({
+  subject: "<TASK-ID>",
+  owner: "<role>",
+  description: "<task description from pipeline table>\nSession: <session-folder>\nScope: <scope>",
+  blockedBy: [<dependency-list>],
+  status: "pending"
+})
+```
+
+### Execution Method
+
+| Method | Behavior |
+|--------|----------|
+| sequential | One task active at a time; next activated after predecessor completes |
+| parallel | Tasks with all deps met run concurrently (e.g., TEST-001 + REVIEW-001) |
+
+## Phase 4: Validation
+
+| Check | Criteria |
+|-------|----------|
+| Task count | Matches mode total from routing table |
+| Dependencies | Every blockedBy references an existing task subject |
+| Owner assignment | Each task owner matches SKILL.md Role Registry prefix |
+| Session reference | Every task description contains `Session: <session-folder>` |
+
+## Error Handling
+
+| Scenario | Resolution |
+|----------|------------|
+| Unknown mode | Reject with supported mode list |
+| Missing spec for impl-only | Error, suggest spec-only or full-lifecycle |
+| TaskCreate fails | Log error, report to user |
+| Duplicate task subject | Skip creation, log warning |

package/.claude/skills/team-lifecycle-v3/roles/coordinator/commands/monitor.md

@@ -0,0 +1,180 @@
+# Command: monitor
+
+## Purpose
+
+Event-driven pipeline coordination with Spawn-and-Stop pattern. Three wake-up sources drive pipeline advancement: worker callbacks (auto-advance), user `check` (status report), user `resume` (manual advance).
+
+## Constants
+
+| Constant | Value | Description |
+|----------|-------|-------------|
+| SPAWN_MODE | background | All workers spawned via `Task(run_in_background: true)` |
+| ONE_STEP_PER_INVOCATION | true | Coordinator does one operation then STOPS |
+
+## Phase 2: Context Loading
+
+| Input | Source | Required |
+|-------|--------|----------|
+| Session file | `<session-folder>/team-session.json` | Yes |
+| Task list | `TaskList()` | Yes |
+| Active workers | session.active_workers[] | Yes |
+| Pipeline mode | session.mode | Yes |
+
+## Phase 3: Handler Routing
+
+### Wake-up Source Detection
+
+Parse `$ARGUMENTS` to determine handler:
+
+| Priority | Condition | Handler |
+|----------|-----------|---------|
+| 1 | Message contains `[<role-name>]` from known worker role | handleCallback |
+| 2 | Contains "check" or "status" | handleCheck |
+| 3 | Contains "resume", "continue", or "next" | handleResume |
+| 4 | None of the above (initial spawn after dispatch) | handleSpawnNext |
+
+Known worker roles: analyst, writer, discussant, planner, executor, tester, reviewer, explorer, architect, fe-developer, fe-qa.
+
+---
+
+### Handler: handleCallback
+
+Worker completed a task. Verify completion, update state, auto-advance.
+
+```
+Receive callback from [<role>]
+  ├─ Find matching active worker by role
+  ├─ Task status = completed?
+  │   ├─ YES → remove from active_workers → update session
+  │   │   ├─ Handle checkpoints (see below)
+  │   │   └─ → handleSpawnNext
+  │   └─ NO → progress message, do not advance → STOP
+  └─ No matching worker found
+      ├─ Scan all active workers for completed tasks
+      ├─ Found completed → process each → handleSpawnNext
+      └─ None completed → STOP
+```
+
+---
+
+### Handler: handleCheck
+
+Read-only status report. No pipeline advancement.
+
+**Output format**:
+
+```
+[coordinator] Pipeline Status
+[coordinator] Mode: <mode> | Progress: <completed>/<total> (<percent>%)
+
+[coordinator] Execution Graph:
+  Spec Phase:  (if applicable)
+    [<icon> RESEARCH-001] → [<icon> DISCUSS-001] → ...
+  Impl Phase:  (if applicable)
+    [<icon> PLAN-001]
+      ├─ BE: [<icon> IMPL-001] → [<icon> TEST-001] → [<icon> REVIEW-001]
+      └─ FE: [<icon> DEV-FE-001] → [<icon> QA-FE-001]
+
+  done=completed  >>>=running  o=pending  .=not created
+
+[coordinator] Active Workers:
+  > <subject> (<role>) - running <elapsed>
+
+[coordinator] Ready to spawn: <subjects>
+[coordinator] Commands: 'resume' to advance | 'check' to refresh
+```
+
+**Icon mapping**: completed=done, in_progress=>>>, pending=o, not created=.
+
+Then STOP.
+
+---
+
+### Handler: handleResume
+
+Check active worker completion, process results, advance pipeline.
+
+```
+Load active_workers from session
+  ├─ No active workers → handleSpawnNext
+  └─ Has active workers → check each:
+      ├─ status = completed → mark done, log
+      ├─ status = in_progress → still running, log
+      └─ other status → worker failure → reset to pending
+      After processing:
+        ├─ Some completed → handleSpawnNext
+        ├─ All still running → report status → STOP
+        └─ All failed → handleSpawnNext (retry)
+```
+
+---
+
+### Handler: handleSpawnNext
+
+Find all ready tasks, spawn workers in background, update session, STOP.
+
+```
+Collect task states from TaskList()
+  ├─ completedSubjects: status = completed
+  ├─ inProgressSubjects: status = in_progress
+  └─ readySubjects: pending + all blockedBy in completedSubjects
+
+Ready tasks found?
+  ├─ NONE + work in progress → report waiting → STOP
+  ├─ NONE + nothing in progress → PIPELINE_COMPLETE → Phase 5
+  └─ HAS ready tasks → for each:
+      ├─ TaskUpdate → in_progress
+      ├─ team_msg log → task_unblocked
+      ├─ Spawn worker (see tool call below)
+      └─ Add to session.active_workers
+      Update session file → output summary → STOP
+```
+
+**Spawn worker tool call** (one per ready task):
+
+```bash
+Task({
+  subagent_type: "general-purpose",
+  description: "Spawn <role> worker for <subject>",
+  team_name: <team-name>,
+  name: "<role>",
+  run_in_background: true,
+  prompt: "<worker prompt from SKILL.md Coordinator Spawn Template>"
+})
+```
+
+---
+
+### Checkpoints
+
+| Completed Task | Mode Condition | Action |
+|---------------|----------------|--------|
+| DISCUSS-006 | full-lifecycle or full-lifecycle-fe | Output "SPEC PHASE COMPLETE" checkpoint, pause for user review before impl |
+
+---
+
+### Worker Failure Handling
+
+When a worker has unexpected status (not completed, not in_progress):
+
+1. Reset task → pending via TaskUpdate
+2. Log via team_msg (type: error)
+3. Report to user: task reset, will retry on next resume
+
+## Phase 4: Validation
+
+| Check | Criteria |
+|-------|----------|
+| Session state consistent | active_workers matches TaskList in_progress tasks |
+| No orphaned tasks | Every in_progress task has an active_worker entry |
+| Pipeline completeness | All expected tasks exist per mode |
+| Completion detection | readySubjects=0 + inProgressSubjects=0 → PIPELINE_COMPLETE |
+
+## Error Handling
+
+| Scenario | Resolution |
+|----------|------------|
+| Session file not found | Error, suggest re-initialization |
+| Worker callback from unknown role | Log info, scan for other completions |
+| All workers still running on resume | Report status, suggest check later |
+| Pipeline stall (no ready, no running) | Check for missing tasks, report to user |

package/.claude/skills/team-lifecycle-v3/roles/coordinator/role.md

@@ -0,0 +1,209 @@
+# 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
+
+---
+
+## Command Execution Protocol
+
+When coordinator needs to execute a command (dispatch, monitor):
+
+1. **Read the command file**: `roles/coordinator/commands/<command-name>.md`
+2. **Follow the workflow** defined in the command file (Phase 2-4 structure)
+3. **Commands are inline execution guides** - NOT separate agents or subprocesses
+4. **Execute synchronously** - complete the command workflow before proceeding
+
+Example:
+```
+Phase 3 needs task dispatch
+  -> Read roles/coordinator/commands/dispatch.md
+  -> Execute Phase 2 (Context Loading)
+  -> Execute Phase 3 (Task Chain Creation)
+  -> Execute Phase 4 (Validation)
+  -> Continue to Phase 4
+```
+
+---
+
+## 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 |
+| Interrupted session | Active/paused session exists in `.workflow/.team/TLS-*` | → Phase 0 (Session Resume Check) |
+| New session | None of the above | → Phase 1 (Requirement Clarification) |
+
+For callback/check/resume: load `commands/monitor.md` and execute the appropriate handler, then STOP.
+
+### Router Implementation
+
+1. **Load session context** (if exists):
+   - Scan `.workflow/.team/TLS-*/team-session.json` for active/paused sessions
+   - If found, extract known worker roles from session or SKILL.md Role Registry
+
+2. **Parse $ARGUMENTS** for detection keywords
+
+3. **Route to handler**:
+   - For monitor handlers: Read `commands/monitor.md`, execute matched handler section, STOP
+   - For Phase 0: Execute Session Resume Check below
+   - For Phase 1: Execute Requirement Clarification below
+
+---
+
+## 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 |