claude-code-workflow 7.2.23 → 7.2.24

package/.codex/skills/team-iterdev/roles/reviewer/role.md

@@ -1,66 +1,66 @@
----
-role: reviewer
-prefix: REVIEW
-inner_loop: false
-message_types:
-  success: review_passed
-  revision: review_revision
-  critical: review_critical
-  error: error
----
-
-# Reviewer
-
-Code reviewer. Multi-dimensional review, quality scoring, improvement suggestions. Acts as Critic in Generator-Critic loop (paired with developer).
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-| Design document | <session>/design/design-001.md | For requirements alignment |
-| Changed files | Git diff | Yes |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for shared context and previous review_feedback_trends
-3. Read design document for requirements alignment
-4. Get changed files via git diff, read file contents (limit 20 files)
-
-## Phase 3: Multi-Dimensional Review
-
-**Review dimensions**:
-
-| Dimension | Weight | Focus Areas |
-|-----------|--------|-------------|
-| Correctness | 30% | Logic correctness, boundary handling |
-| Completeness | 25% | Coverage of design requirements |
-| Maintainability | 25% | Readability, code style, DRY |
-| Security | 20% | Vulnerabilities, input validation |
-
-Per-dimension: scan modified files, record findings with severity (CRITICAL/HIGH/MEDIUM/LOW), include file:line references and suggestions.
-
-**Scoring**: Weighted average of dimension scores (1-10 each).
-
-**Output review report** (`<session>/review/review-<num>.md`):
-- Files reviewed count, quality score, issue counts by severity
-- Per-finding: severity, file:line, dimension, description, suggestion
-- Scoring breakdown by dimension
-- Signal: CRITICAL / REVISION_NEEDED / APPROVED
-- Design alignment notes
-
-## Phase 4: Trend Analysis + Verdict
-
-1. Compare with previous review_feedback_trends from .msg/meta.json
-2. Identify recurring issues, improvement areas, new issues
-
-| Verdict Condition | Message Type |
-|-------------------|--------------|
-| criticalCount > 0 | review_critical |
-| score < 7 | review_revision |
-| else | review_passed |
-
-3. Update review_feedback_trends in .msg/meta.json:
-   - review_id, score, critical count, high count, dimensions, gc_round
-4. Write discoveries to wisdom/learnings.md
+---
+role: reviewer
+prefix: REVIEW
+inner_loop: false
+message_types:
+  success: review_passed
+  revision: review_revision
+  critical: review_critical
+  error: error
+---
+
+# Reviewer
+
+Code reviewer. Multi-dimensional review, quality scoring, improvement suggestions. Acts as Critic in Generator-Critic loop (paired with developer).
+
+## Phase 2: Context Loading
+
+| Input | Source | Required |
+|-------|--------|----------|
+| Task description | From task subject/description | Yes |
+| Session path | Extracted from task description | Yes |
+| .msg/meta.json | <session>/.msg/meta.json | Yes |
+| Design document | <session>/design/design-001.md | For requirements alignment |
+| Changed files | Git diff | Yes |
+
+1. Extract session path from task description
+2. Read .msg/meta.json for shared context and previous review_feedback_trends
+3. Read design document for requirements alignment
+4. Get changed files via git diff, read file contents (limit 20 files)
+
+## Phase 3: Multi-Dimensional Review
+
+**Review dimensions**:
+
+| Dimension | Weight | Focus Areas |
+|-----------|--------|-------------|
+| Correctness | 30% | Logic correctness, boundary handling |
+| Completeness | 25% | Coverage of design requirements |
+| Maintainability | 25% | Readability, code style, DRY |
+| Security | 20% | Vulnerabilities, input validation |
+
+Per-dimension: scan modified files, record findings with severity (CRITICAL/HIGH/MEDIUM/LOW), include file:line references and suggestions.
+
+**Scoring**: Weighted average of dimension scores (1-10 each).
+
+**Output review report** (`<session>/review/review-<num>.md`):
+- Files reviewed count, quality score, issue counts by severity
+- Per-finding: severity, file:line, dimension, description, suggestion
+- Scoring breakdown by dimension
+- Signal: CRITICAL / REVISION_NEEDED / APPROVED
+- Design alignment notes
+
+## Phase 4: Trend Analysis + Verdict
+
+1. Compare with previous review_feedback_trends from .msg/meta.json
+2. Identify recurring issues, improvement areas, new issues
+
+| Verdict Condition | Message Type |
+|-------------------|--------------|
+| criticalCount > 0 | review_critical |
+| score < 7 | review_revision |
+| else | review_passed |
+
+3. Update review_feedback_trends in .msg/meta.json:
+   - review_id, score, critical count, high count, dimensions, gc_round
+4. Write discoveries to wisdom/learnings.md

package/.codex/skills/team-iterdev/roles/tester/role.md

@@ -1,88 +1,88 @@
----
-role: tester
-prefix: VERIFY
-inner_loop: false
-message_types:
-  success: verify_passed
-  failure: verify_failed
-  fix: fix_required
-  error: error
----
-
-# Tester
-
-Test validator. Test execution, fix cycles, and regression detection.
-
-## Phase 2: Environment Detection
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-| Changed files | Git diff | Yes |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for shared context
-3. Get changed files via git diff
-4. Detect test framework and command:
-
-| Detection | Method |
-|-----------|--------|
-| Test command | Check package.json scripts, pytest.ini, Makefile |
-| Coverage tool | Check for nyc, coverage.py, jest --coverage config |
-
-Common commands: npm test, pytest, go test ./..., cargo test
-
-## Phase 3: Execution + Fix Cycle
-
-**Iterative test-fix cycle** (max 5 iterations):
-
-| Step | Action |
-|------|--------|
-| 1 | Run test command |
-| 2 | Parse results, check pass rate |
-| 3 | Pass rate >= 95% -> exit loop (success) |
-| 4 | Extract failing test details |
-| 5 | Apply fix using CLI tool |
-| 6 | Increment iteration counter |
-| 7 | iteration >= MAX (5) -> exit loop (report failures) |
-| 8 | Go to Step 1 |
-
-**Fix delegation**: Use CLI tool to fix failing tests:
-
-```bash
-ccw cli -p "PURPOSE: Fix failing tests; success = all listed tests pass
-TASK: • Analyze test failure output • Identify root cause in changed files • Apply minimal fix
-MODE: write
-CONTEXT: @<changed-files> | Memory: Test output from current iteration
-EXPECTED: Code fixes that make failing tests pass without breaking other tests
-CONSTRAINTS: Only modify files in changed list | Minimal changes
-Test output: <test-failure-details>
-Changed files: <file-list>" --tool gemini --mode write --rule development-debug-runtime-issues
-```
-
-Wait for CLI completion before re-running tests.
-
-## Phase 4: Regression Check + Report
-
-1. Run full test suite for regression: `<test-command> --all`
-
-| Check | Method | Pass Criteria |
-|-------|--------|---------------|
-| Regression | Run full test suite | No FAIL in output |
-| Coverage | Run coverage tool | >= 80% (if configured) |
-
-2. Write verification results to `<session>/verify/verify-<num>.json`:
-   - verify_id, pass_rate, iterations, passed, timestamp, regression_passed
-
-3. Determine message type:
-
-| Condition | Message Type |
-|-----------|--------------|
-| passRate >= 0.95 | verify_passed |
-| passRate < 0.95 && iterations >= MAX | fix_required |
-| passRate < 0.95 | verify_failed |
-
-4. Update .msg/meta.json with test_patterns entry
-5. Write discoveries to wisdom/issues.md
+---
+role: tester
+prefix: VERIFY
+inner_loop: false
+message_types:
+  success: verify_passed
+  failure: verify_failed
+  fix: fix_required
+  error: error
+---
+
+# Tester
+
+Test validator. Test execution, fix cycles, and regression detection.
+
+## Phase 2: Environment Detection
+
+| Input | Source | Required |
+|-------|--------|----------|
+| Task description | From task subject/description | Yes |
+| Session path | Extracted from task description | Yes |
+| .msg/meta.json | <session>/.msg/meta.json | Yes |
+| Changed files | Git diff | Yes |
+
+1. Extract session path from task description
+2. Read .msg/meta.json for shared context
+3. Get changed files via git diff
+4. Detect test framework and command:
+
+| Detection | Method |
+|-----------|--------|
+| Test command | Check package.json scripts, pytest.ini, Makefile |
+| Coverage tool | Check for nyc, coverage.py, jest --coverage config |
+
+Common commands: npm test, pytest, go test ./..., cargo test
+
+## Phase 3: Execution + Fix Cycle
+
+**Iterative test-fix cycle** (max 5 iterations):
+
+| Step | Action |
+|------|--------|
+| 1 | Run test command |
+| 2 | Parse results, check pass rate |
+| 3 | Pass rate >= 95% -> exit loop (success) |
+| 4 | Extract failing test details |
+| 5 | Apply fix using CLI tool |
+| 6 | Increment iteration counter |
+| 7 | iteration >= MAX (5) -> exit loop (report failures) |
+| 8 | Go to Step 1 |
+
+**Fix delegation**: Use CLI tool to fix failing tests:
+
+```bash
+ccw cli -p "PURPOSE: Fix failing tests; success = all listed tests pass
+TASK: • Analyze test failure output • Identify root cause in changed files • Apply minimal fix
+MODE: write
+CONTEXT: @<changed-files> | Memory: Test output from current iteration
+EXPECTED: Code fixes that make failing tests pass without breaking other tests
+CONSTRAINTS: Only modify files in changed list | Minimal changes
+Test output: <test-failure-details>
+Changed files: <file-list>" --tool gemini --mode write --rule development-debug-runtime-issues
+```
+
+Wait for CLI completion before re-running tests.
+
+## Phase 4: Regression Check + Report
+
+1. Run full test suite for regression: `<test-command> --all`
+
+| Check | Method | Pass Criteria |
+|-------|--------|---------------|
+| Regression | Run full test suite | No FAIL in output |
+| Coverage | Run coverage tool | >= 80% (if configured) |
+
+2. Write verification results to `<session>/verify/verify-<num>.json`:
+   - verify_id, pass_rate, iterations, passed, timestamp, regression_passed
+
+3. Determine message type:
+
+| Condition | Message Type |
+|-----------|--------------|
+| passRate >= 0.95 | verify_passed |
+| passRate < 0.95 && iterations >= MAX | fix_required |
+| passRate < 0.95 | verify_failed |
+
+4. Update .msg/meta.json with test_patterns entry
+5. Write discoveries to wisdom/issues.md

package/.codex/skills/team-iterdev/specs/pipelines.md

@@ -1,94 +1,94 @@
-# IterDev Pipeline Definitions
-
-## Three-Pipeline Architecture
-
-### Patch Pipeline (2 beats, serial)
-
-```
-DEV-001 -> VERIFY-001
-[developer]  [tester]
-```
-
-### Sprint Pipeline (4 beats, with parallel window)
-
-```
-DESIGN-001 -> DEV-001 -> [VERIFY-001 + REVIEW-001] (parallel)
-[architect]   [developer]  [tester]       [reviewer]
-```
-
-### Multi-Sprint Pipeline (N beats, iterative)
-
-```
-Sprint 1: DESIGN-001 -> DEV-001 -> DEV-002(incremental) -> VERIFY-001 -> DEV-fix -> REVIEW-001
-Sprint 2: DESIGN-002(refined) -> DEV-003 -> VERIFY-002 -> REVIEW-002
-...
-```
-
-## Generator-Critic Loop (developer <-> reviewer)
-
-```
-DEV -> REVIEW -> (if review.critical_count > 0 || review.score < 7)
-              -> DEV-fix -> REVIEW-2 -> (if still issues) -> DEV-fix-2 -> REVIEW-3
-              -> (max 3 rounds, then accept with warning)
-```
-
-## Pipeline Selection Logic
-
-| Signal | Score |
-|--------|-------|
-| Changed files > 10 | +3 |
-| Changed files 3-10 | +2 |
-| Structural change | +3 |
-| Cross-cutting concern | +2 |
-| Simple fix | -2 |
-
-| Score | Pipeline |
-|-------|----------|
-| >= 5 | multi-sprint |
-| 2-4 | sprint |
-| 0-1 | patch |
-
-## Task Metadata Registry
-
-| Task ID | Role | Pipeline | Dependencies | Description |
-|---------|------|----------|-------------|-------------|
-| DESIGN-001 | architect | sprint/multi | (none) | Technical design and task breakdown |
-| DEV-001 | developer | all | DESIGN-001 (sprint/multi) or (none for patch) | Code implementation |
-| DEV-002 | developer | multi | DEV-001 | Incremental implementation |
-| DEV-fix | developer | sprint/multi | REVIEW-* (GC loop trigger) | Fix issues from review |
-| VERIFY-001 | tester | all | DEV-001 (or last DEV) | Test execution and fix cycles |
-| REVIEW-001 | reviewer | sprint/multi | DEV-001 (or last DEV) | Code review and quality scoring |
-
-## Checkpoints
-
-| Trigger Condition | Location | Behavior |
-|-------------------|----------|----------|
-| GC loop exceeds max rounds | After REVIEW-3 | Stop iteration, accept with warning, record in wisdom |
-| Sprint transition | End of Sprint N | Pause, retrospective, user confirms `resume` for Sprint N+1 |
-| Pipeline stall | No ready + no running tasks | Check missing tasks, report blockedBy chain to user |
-
-## Multi-Sprint Dynamic Downgrade
-
-If Sprint N metrics are strong (velocity >= expected, review avg >= 8), coordinator may downgrade Sprint N+1 from multi-sprint to sprint pipeline for efficiency.
-
-## Task Ledger Schema
-
-| Field | Description |
-|-------|-------------|
-| `sprint_id` | Current sprint identifier |
-| `sprint_goal` | Sprint objective |
-| `tasks[]` | Array of task entries |
-| `metrics` | Aggregated metrics: total, completed, in_progress, blocked, velocity |
-
-**Task Entry Fields**:
-
-| Field | Description |
-|-------|-------------|
-| `id` | Task identifier |
-| `title` | Task title |
-| `owner` | Assigned role |
-| `status` | pending / in_progress / completed / blocked |
-| `started_at` / `completed_at` | Timestamps |
-| `gc_rounds` | Generator-Critic iteration count |
-| `review_score` | Reviewer score (null until reviewed) |
-| `test_pass_rate` | Tester pass rate (null until tested) |
+# IterDev Pipeline Definitions
+
+## Three-Pipeline Architecture
+
+### Patch Pipeline (2 beats, serial)
+
+```
+DEV-001 -> VERIFY-001
+[developer]  [tester]
+```
+
+### Sprint Pipeline (4 beats, with parallel window)
+
+```
+DESIGN-001 -> DEV-001 -> [VERIFY-001 + REVIEW-001] (parallel)
+[architect]   [developer]  [tester]       [reviewer]
+```
+
+### Multi-Sprint Pipeline (N beats, iterative)
+
+```
+Sprint 1: DESIGN-001 -> DEV-001 -> DEV-002(incremental) -> VERIFY-001 -> DEV-fix -> REVIEW-001
+Sprint 2: DESIGN-002(refined) -> DEV-003 -> VERIFY-002 -> REVIEW-002
+...
+```
+
+## Generator-Critic Loop (developer <-> reviewer)
+
+```
+DEV -> REVIEW -> (if review.critical_count > 0 || review.score < 7)
+              -> DEV-fix -> REVIEW-2 -> (if still issues) -> DEV-fix-2 -> REVIEW-3
+              -> (max 3 rounds, then accept with warning)
+```
+
+## Pipeline Selection Logic
+
+| Signal | Score |
+|--------|-------|
+| Changed files > 10 | +3 |
+| Changed files 3-10 | +2 |
+| Structural change | +3 |
+| Cross-cutting concern | +2 |
+| Simple fix | -2 |
+
+| Score | Pipeline |
+|-------|----------|
+| >= 5 | multi-sprint |
+| 2-4 | sprint |
+| 0-1 | patch |
+
+## Task Metadata Registry
+
+| Task ID | Role | Pipeline | Dependencies | Description |
+|---------|------|----------|-------------|-------------|
+| DESIGN-001 | architect | sprint/multi | (none) | Technical design and task breakdown |
+| DEV-001 | developer | all | DESIGN-001 (sprint/multi) or (none for patch) | Code implementation |
+| DEV-002 | developer | multi | DEV-001 | Incremental implementation |
+| DEV-fix | developer | sprint/multi | REVIEW-* (GC loop trigger) | Fix issues from review |
+| VERIFY-001 | tester | all | DEV-001 (or last DEV) | Test execution and fix cycles |
+| REVIEW-001 | reviewer | sprint/multi | DEV-001 (or last DEV) | Code review and quality scoring |
+
+## Checkpoints
+
+| Trigger Condition | Location | Behavior |
+|-------------------|----------|----------|
+| GC loop exceeds max rounds | After REVIEW-3 | Stop iteration, accept with warning, record in wisdom |
+| Sprint transition | End of Sprint N | Pause, retrospective, user confirms `resume` for Sprint N+1 |
+| Pipeline stall | No ready + no running tasks | Check missing tasks, report blockedBy chain to user |
+
+## Multi-Sprint Dynamic Downgrade
+
+If Sprint N metrics are strong (velocity >= expected, review avg >= 8), coordinator may downgrade Sprint N+1 from multi-sprint to sprint pipeline for efficiency.
+
+## Task Ledger Schema
+
+| Field | Description |
+|-------|-------------|
+| `sprint_id` | Current sprint identifier |
+| `sprint_goal` | Sprint objective |
+| `tasks[]` | Array of task entries |
+| `metrics` | Aggregated metrics: total, completed, in_progress, blocked, velocity |
+
+**Task Entry Fields**:
+
+| Field | Description |
+|-------|-------------|
+| `id` | Task identifier |
+| `title` | Task title |
+| `owner` | Assigned role |
+| `status` | pending / in_progress / completed / blocked |
+| `started_at` / `completed_at` | Timestamps |
+| `gc_rounds` | Generator-Critic iteration count |
+| `review_score` | Reviewer score (null until reviewed) |
+| `test_pass_rate` | Tester pass rate (null until tested) |

package/.codex/skills/team-lifecycle-v4/MIGRATION-PLAN.md

@@ -19,7 +19,7 @@
 | Worker spawn | `Agent({ subagent_type: "team-worker", prompt })` | `spawn_agent({ agent_type: "tlv4_worker", items })` |
 | Supervisor spawn | `Agent({ subagent_type: "team-supervisor", prompt })` | `spawn_agent({ agent_type: "tlv4_supervisor", items })` |
 | Supervisor wake | `SendMessage({ recipient: "supervisor", content })` | `send_input({ id: supervisorId, items })` |
-| Supervisor shutdown | `SendMessage({ type: "shutdown_request" })` | `close_agent({ id: supervisorId })` |
+| Supervisor shutdown | `SendMessage({ type: "shutdown_request" })` | `close_agent({ target: supervisorId })` |
 | 等待完成 | 后台回调 -> monitor.md | `wait_agent({ ids, timeout_ms })` |
 | 任务状态 | `TaskCreate` / `TaskUpdate` | `tasks.json` 文件读写 |
 | 团队管理 | `TeamCreate` / `TeamDelete` | session folder init / cleanup |
@@ -222,14 +222,14 @@ scope: [${task.deps}]
 pipeline_progress: ${done}/${total} tasks completed` }
   ]
 })
-wait_agent({ ids: [supervisorId], timeout_ms: 300000 })
+wait_agent({ targets: [supervisorId], timeout_ms: 300000 })
 ```
 
 ### Supervisor Shutdown
 
 ```javascript
 // 对齐 Claude Code SendMessage({ type: "shutdown_request" })
-close_agent({ id: supervisorId })
+close_agent({ target: supervisorId })
 ```
 
 ### Wave 执行引擎
@@ -300,7 +300,7 @@ pipeline_phase: ${task.pipeline_phase}` },
 
   // 2) 批量等待
   if (agentMap.length > 0) {
-    wait_agent({ ids: agentMap.map(a => a.agentId), timeout_ms: 900000 })
+    wait_agent({ targets: agentMap.map(a => a.agentId), timeout_ms: 900000 })
   }
 
   // 3) 收集结果，合并到 tasks.json
@@ -315,7 +315,7 @@ pipeline_phase: ${task.pipeline_phase}` },
       state.tasks[taskId].status = 'failed'
       state.tasks[taskId].error = 'No discovery file produced'
     }
-    close_agent({ id: agentId })
+    close_agent({ target: agentId })
   }
 
   // 4) 执行 CHECKPOINT 任务 (send_input 唤醒 supervisor)
@@ -329,7 +329,7 @@ scope: [${task.deps.join(', ')}]
 pipeline_progress: ${completedCount}/${totalCount} tasks completed` }
       ]
     })
-    wait_agent({ ids: [supervisorId], timeout_ms: 300000 })
+    wait_agent({ targets: [supervisorId], timeout_ms: 300000 })
 
     // 读取 checkpoint 报告
     try {