claude-code-workflow 7.2.24 → 7.2.25

package/.codex/skills/team-iterdev/SKILL.md

@@ -1,219 +0,0 @@
----
-name: team-iterdev
-description: Unified team skill for iterative development team. Pure router — all roles read this file. Beat model is coordinator-only in monitor.md. Generator-Critic loops (developer<->reviewer, max 3 rounds). Triggers on "team iterdev".
-allowed-tools: spawn_agent(*), wait_agent(*), send_message(*), assign_task(*), close_agent(*), list_agents(*), report_agent_job_result(*), request_user_input(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)
----
-
-# Team IterDev
-
-Iterative development team skill. Generator-Critic loops (developer<->reviewer, max 3 rounds), task ledger (task-ledger.json) for real-time progress, shared memory (cross-sprint learning), and dynamic pipeline selection for incremental delivery.
-
-## Architecture
-
-```
-Skill(skill="team-iterdev", args="task description")
-                    |
-         SKILL.md (this file) = Router
-                    |
-     +--------------+--------------+
-     |                             |
-  no --role flag              --role <name>
-     |                             |
-  Coordinator                  Worker
-  roles/coordinator/role.md    roles/<name>/role.md
-     |
-     +-- analyze -> dispatch -> spawn workers -> STOP
-                                    |
-                    +-------+-------+-------+
-                    v       v       v       v
-               [architect] [developer] [tester] [reviewer]
-              (team-worker agents, each loads roles/<role>/role.md)
-```
-
-## Role Registry
-
-| Role | Path | Prefix | Inner Loop |
-|------|------|--------|------------|
-| coordinator | [roles/coordinator/role.md](roles/coordinator/role.md) | — | — |
-| architect | [roles/architect/role.md](roles/architect/role.md) | DESIGN-* | false |
-| developer | [roles/developer/role.md](roles/developer/role.md) | DEV-* | true |
-| tester | [roles/tester/role.md](roles/tester/role.md) | VERIFY-* | false |
-| reviewer | [roles/reviewer/role.md](roles/reviewer/role.md) | REVIEW-* | false |
-
-## Role Router
-
-Parse `$ARGUMENTS`:
-- Has `--role <name>` → Read `roles/<name>/role.md`, execute Phase 2-4
-- No `--role` → `roles/coordinator/role.md`, execute entry router
-
-## Delegation Lock
-
-**Coordinator is a PURE ORCHESTRATOR. It coordinates, it does NOT do.**
-
-Before calling ANY tool, apply this check:
-
-| Tool Call | Verdict | Reason |
-|-----------|---------|--------|
-| `spawn_agent`, `wait_agent`, `close_agent`, `send_message`, `assign_task` | ALLOWED | Orchestration |
-| `list_agents` | ALLOWED | Agent health check |
-| `request_user_input` | ALLOWED | User interaction |
-| `mcp__ccw-tools__team_msg` | ALLOWED | Message bus |
-| `Read/Write` on `.workflow/.team/` files | ALLOWED | Session state |
-| `Read` on `roles/`, `commands/`, `specs/` | ALLOWED | Loading own instructions |
-| `Read/Grep/Glob` on project source code | BLOCKED | Delegate to worker |
-| `Edit` on any file outside `.workflow/` | BLOCKED | Delegate to worker |
-| `Bash("ccw cli ...")` | BLOCKED | Only workers call CLI |
-| `Bash` running build/test/lint commands | BLOCKED | Delegate to worker |
-
-**If a tool call is BLOCKED**: STOP. Create a task, spawn a worker.
-
-**No exceptions for "simple" tasks.** Even a single-file read-and-report MUST go through spawn_agent.
-
----
-
-## Shared Constants
-
-- **Session prefix**: `IDS`
-- **Session path**: `.workflow/.team/IDS-<slug>-<date>/`
-- **CLI tools**: `ccw cli --mode analysis` (read-only), `ccw cli --mode write` (modifications)
-- **Message bus**: `mcp__ccw-tools__team_msg(session_id=<session-id>, ...)`
-
-## Worker Spawn Template
-
-Coordinator spawns workers using this template:
-
-```
-spawn_agent({
-  agent_type: "team_worker",
-  task_name: "<task-id>",
-  fork_context: false,
-  items: [
-    { type: "text", text: `## Role Assignment
-role: <role>
-role_spec: <skill_root>/roles/<role>/role.md
-session: <session-folder>
-session_id: <session-id>
-requirement: <task-description>
-inner_loop: <true|false>
-
-Read role_spec file (<skill_root>/roles/<role>/role.md) to load Phase 2-4 domain instructions.` },
-
-    { type: "text", text: `## Task Context
-task_id: <task-id>
-title: <task-title>
-description: <task-description>
-pipeline_phase: <pipeline-phase>` },
-
-    { type: "text", text: `## Upstream Context
-<prev_context>` }
-  ]
-})
-```
-
-After spawning, use `wait_agent({ targets: [...], timeout_ms: 900000 })` to collect results, then `close_agent({ target })` each worker.
-
-
-### Model Selection Guide
-
-Iterative development uses Generator-Critic loops. Developer and reviewer need high reasoning for code generation and review quality.
-
-| Role | reasoning_effort | Rationale |
-|------|-------------------|-----------|
-| architect | high | Design decisions require careful tradeoff analysis |
-| developer | high | Code generation needs precision, inner loop role |
-| tester | medium | Test execution follows defined verification plan |
-| reviewer | high | Critical review quality drives GC loop effectiveness |
-
-## User Commands
-
-| Command | Action |
-|---------|--------|
-| `check` / `status` | View execution status graph |
-| `resume` / `continue` | Advance to next step |
-
-## Session Directory
-
-```
-.workflow/.team/IDS-<slug>-<YYYY-MM-DD>/
-├── .msg/
-│   ├── messages.jsonl          # Team message bus
-│   └── meta.json               # Session state
-├── task-analysis.json          # Coordinator analyze output
-├── task-ledger.json            # Real-time task progress ledger
-├── wisdom/                     # Cross-task knowledge accumulation
-│   ├── learnings.md
-│   ├── decisions.md
-│   ├── conventions.md
-│   └── issues.md
-├── design/                     # Architect output
-│   ├── design-001.md
-│   └── task-breakdown.json
-├── code/                       # Developer tracking
-│   └── dev-log.md
-├── verify/                     # Tester output
-│   └── verify-001.json
-└── review/                     # Reviewer output
-    └── review-001.md
-```
-
-## Specs Reference
-
-- [specs/pipelines.md](specs/pipelines.md) — Pipeline definitions and task registry
-
-## v4 Agent Coordination
-
-### Message Semantics
-
-| Intent | API | Example |
-|--------|-----|---------|
-| Queue supplementary info (don't interrupt) | `send_message` | Send design context to running developer |
-| Assign GC iteration round | `assign_task` | Assign revision to developer after reviewer feedback |
-| Check running agents | `list_agents` | Verify agent health during resume |
-
-### Agent Health Check
-
-Use `list_agents({})` in handleResume and handleComplete:
-
-```
-// Reconcile session state with actual running agents
-const running = list_agents({})
-// Compare with task-ledger.json active tasks
-// Reset orphaned tasks (in_progress but agent gone) to pending
-```
-
-### Named Agent Targeting
-
-Workers are spawned with `task_name: "<task-id>"` enabling direct addressing:
-- `send_message({ target: "DEV-001", items: [...] })` -- send design context to developer
-- `assign_task({ target: "DEV-001", items: [...] })` -- assign revision after reviewer feedback
-- `close_agent({ target: "REVIEW-001" })` -- cleanup after GC loop completes
-
-### Generator-Critic Loop via assign_task (Deep Interaction Pattern)
-
-The developer-reviewer GC loop uses `assign_task` for iteration rounds:
-```
-// Round N: Reviewer found issues -> coordinator assigns revision to developer
-assign_task({
-  target: "DEV-001",
-  items: [
-    { type: "text", text: `## GC Revision Round ${N}
-review_feedback: <reviewer findings from REVIEW-001>
-iteration: ${N}/3
-instruction: Address reviewer feedback. Focus on: <specific issues>.` }
-  ]
-})
-```
-
-After developer completes revision, coordinator spawns/assigns reviewer for next round. Max 3 rounds per GC cycle.
-
-## Error Handling
-
-| Scenario | Resolution |
-|----------|------------|
-| Unknown command | Error with available command list |
-| Role not found | Error with role registry |
-| GC loop exceeds 3 rounds | Accept with warning, record in shared memory |
-| Sprint velocity drops below 50% | Coordinator alerts user, suggests scope reduction |
-| Task ledger corrupted | Rebuild from TaskList state |
-| Conflict detected | Update conflict_info, notify coordinator, create DEV-fix task |
-| Pipeline deadlock | Check blockedBy chain, report blocking point |

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

@@ -1,65 +0,0 @@
----
-role: architect
-prefix: DESIGN
-inner_loop: false
-message_types:
-  success: design_ready
-  revision: design_revision
-  error: error
----
-
-# Architect
-
-Technical design, task decomposition, and architecture decision records for iterative development.
-
-## Phase 2: Context Loading + Codebase Exploration
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | No |
-| Wisdom files | <session>/wisdom/ | No |
-
-1. Extract session path and requirement from task description
-2. Read .msg/meta.json for shared context (architecture_decisions, implementation_context)
-3. Read wisdom files if available (learnings.md, decisions.md, conventions.md)
-4. Explore codebase for existing patterns, module structure, dependencies:
-   - Use mcp__ace-tool__search_context for semantic discovery
-   - Identify similar implementations and integration points
-
-## Phase 3: Technical Design + Task Decomposition
-
-**Design strategy selection**:
-
-| Condition | Strategy |
-|-----------|----------|
-| Single module change | Direct inline design |
-| Cross-module change | Multi-component design with integration points |
-| Large refactoring | Phased approach with milestones |
-
-**Outputs**:
-
-1. **Design Document** (`<session>/design/design-<num>.md`):
-   - Architecture decision: approach, rationale, alternatives
-   - Component design: responsibility, dependencies, files, complexity
-   - Task breakdown: files, estimated complexity, dependencies, acceptance criteria
-   - Integration points and risks with mitigations
-
-2. **Task Breakdown JSON** (`<session>/design/task-breakdown.json`):
-   - Array of tasks with id, title, files, complexity, dependencies, acceptance_criteria
-   - Execution order for developer to follow
-
-## Phase 4: Design Validation
-
-| Check | Method | Pass Criteria |
-|-------|--------|---------------|
-| Components defined | Verify component list | At least 1 component |
-| Task breakdown exists | Verify task list | At least 1 task |
-| Dependencies mapped | All components have dependencies field | All present (can be empty) |
-| Integration points | Verify integration section | Key integrations documented |
-
-1. Run validation checks above
-2. Write architecture_decisions entry to .msg/meta.json:
-   - design_id, approach, rationale, components, task_count
-3. Write discoveries to wisdom/decisions.md and wisdom/conventions.md

package/.codex/skills/team-iterdev/roles/coordinator/commands/analyze.md

@@ -1,62 +0,0 @@
-# Analyze Task
-
-Parse iterative development task -> detect capabilities -> assess pipeline complexity -> design roles.
-
-**CONSTRAINT**: Text-level analysis only. NO source code reading, NO codebase exploration.
-
-## Signal Detection
-
-| Keywords | Capability | Role |
-|----------|------------|------|
-| design, architect, restructure, refactor plan | architect | architect |
-| implement, build, code, fix, develop | developer | developer |
-| test, verify, validate, coverage | tester | tester |
-| review, audit, quality, check | reviewer | reviewer |
-
-## Pipeline Selection
-
-| Signal | Score |
-|--------|-------|
-| Changed files > 10 | +3 |
-| Changed files 3-10 | +2 |
-| Structural change (refactor, architect, restructure) | +3 |
-| Cross-cutting (multiple, across, cross) | +2 |
-| Simple fix (fix, bug, typo, patch) | -2 |
-
-| Score | Pipeline |
-|-------|----------|
-| >= 5 | multi-sprint |
-| 2-4 | sprint |
-| 0-1 | patch |
-
-## Dependency Graph
-
-Natural ordering tiers:
-- Tier 0: architect (design must come first)
-- Tier 1: developer (implementation requires design)
-- Tier 2: tester, reviewer (validation requires artifacts, can run parallel)
-
-## Complexity Assessment
-
-| Factor | Points |
-|--------|--------|
-| Cross-module changes | +2 |
-| Serial depth > 3 | +1 |
-| Multiple developers needed | +2 |
-| GC loop likely needed | +1 |
-
-## Output
-
-Write <session>/task-analysis.json:
-```json
-{
-  "task_description": "<original>",
-  "pipeline_type": "<patch|sprint|multi-sprint>",
-  "capabilities": [{ "name": "<cap>", "role": "<role>", "keywords": ["..."] }],
-  "roles": [{ "name": "<role>", "prefix": "<PREFIX>", "inner_loop": false }],
-  "complexity": { "score": 0, "level": "Low|Medium|High" },
-  "needs_architecture": true,
-  "needs_testing": true,
-  "needs_review": true
-}
-```

package/.codex/skills/team-iterdev/roles/coordinator/commands/dispatch.md

@@ -1,187 +0,0 @@
-# Command: Dispatch
-
-Create the iterative development task chain with correct dependencies and structured task descriptions.
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| User requirement | From coordinator Phase 1 | Yes |
-| Session folder | From coordinator Phase 2 | Yes |
-| Pipeline definition | From SKILL.md Pipeline Definitions | Yes |
-| Pipeline mode | From tasks.json `pipeline_mode` | Yes |
-
-1. Load user requirement and scope from tasks.json
-2. Load pipeline stage definitions from SKILL.md Task Metadata Registry
-3. Read `pipeline_mode` from tasks.json (patch / sprint / multi-sprint)
-
-## Phase 3: Task Chain Creation
-
-### Task Entry Template
-
-Each task in tasks.json `tasks` object:
-```json
-{
-  "<TASK-ID>": {
-    "title": "<concise title>",
-    "description": "PURPOSE: <what this task achieves> | Success: <measurable completion criteria>\nTASK:\n  - <step 1: specific action>\n  - <step 2: specific action>\n  - <step 3: specific action>\nCONTEXT:\n  - Session: <session-folder>\n  - Scope: <task-scope>\n  - Upstream artifacts: <artifact-1>, <artifact-2>\n  - Shared memory: <session>/.msg/meta.json\nEXPECTED: <deliverable path> + <quality criteria>\nCONSTRAINTS: <scope limits, focus areas>\n---\nInnerLoop: <true|false>",
-    "role": "<role-name>",
-    "prefix": "<PREFIX>",
-    "deps": ["<dependency-list>"],
-    "status": "pending",
-    "findings": "",
-    "error": ""
-  }
-}
-```
-
-### Mode Router
-
-| Mode | Action |
-|------|--------|
-| `patch` | Create DEV-001 + VERIFY-001 |
-| `sprint` | Create DESIGN-001 + DEV-001 + VERIFY-001 + REVIEW-001 |
-| `multi-sprint` | Create Sprint 1 chain, subsequent sprints created dynamically |
-
----
-
-### Patch Pipeline
-
-**DEV-001** (developer):
-```json
-{
-  "DEV-001": {
-    "title": "Implement fix",
-    "description": "PURPOSE: Implement fix | Success: Fix applied, syntax clean\nTASK:\n  - Load target files and understand context\n  - Apply fix changes\n  - Validate syntax\nCONTEXT:\n  - Session: <session-folder>\n  - Scope: <task-scope>\n  - Shared memory: <session>/.msg/meta.json\nEXPECTED: Modified source files + <session>/code/dev-log.md | Syntax clean\nCONSTRAINTS: Minimal changes | Preserve existing behavior\n---\nInnerLoop: true",
-    "role": "developer",
-    "prefix": "DEV",
-    "deps": [],
-    "status": "pending",
-    "findings": "",
-    "error": ""
-  }
-}
-```
-
-**VERIFY-001** (tester):
-```json
-{
-  "VERIFY-001": {
-    "title": "Verify fix correctness",
-    "description": "PURPOSE: Verify fix correctness | Success: Tests pass, no regressions\nTASK:\n  - Detect test framework\n  - Run targeted tests for changed files\n  - Run regression test suite\nCONTEXT:\n  - Session: <session-folder>\n  - Scope: <task-scope>\n  - Upstream artifacts: code/dev-log.md\n  - Shared memory: <session>/.msg/meta.json\nEXPECTED: <session>/verify/verify-001.json | Pass rate >= 95%\nCONSTRAINTS: Focus on changed files | Report any regressions\n---\nInnerLoop: false",
-    "role": "tester",
-    "prefix": "VERIFY",
-    "deps": ["DEV-001"],
-    "status": "pending",
-    "findings": "",
-    "error": ""
-  }
-}
-```
-
----
-
-### Sprint Pipeline
-
-**DESIGN-001** (architect):
-```json
-{
-  "DESIGN-001": {
-    "title": "Technical design and task breakdown",
-    "description": "PURPOSE: Technical design and task breakdown | Success: Design document + task breakdown ready\nTASK:\n  - Explore codebase for patterns and dependencies\n  - Create component design with integration points\n  - Break down into implementable tasks with acceptance criteria\nCONTEXT:\n  - Session: <session-folder>\n  - Scope: <task-scope>\n  - Shared memory: <session>/.msg/meta.json\nEXPECTED: <session>/design/design-001.md + <session>/design/task-breakdown.json | Components defined, tasks actionable\nCONSTRAINTS: Focus on <task-scope> | Risk assessment required\n---\nInnerLoop: false",
-    "role": "architect",
-    "prefix": "DESIGN",
-    "deps": [],
-    "status": "pending",
-    "findings": "",
-    "error": ""
-  }
-}
-```
-
-**DEV-001** (developer):
-```json
-{
-  "DEV-001": {
-    "title": "Implement design",
-    "description": "PURPOSE: Implement design | Success: All design tasks implemented, syntax clean\nTASK:\n  - Load design and task breakdown\n  - Implement tasks in execution order\n  - Validate syntax after changes\nCONTEXT:\n  - Session: <session-folder>\n  - Scope: <task-scope>\n  - Upstream artifacts: design/design-001.md, design/task-breakdown.json\n  - Shared memory: <session>/.msg/meta.json\nEXPECTED: Modified source files + <session>/code/dev-log.md | Syntax clean, all tasks done\nCONSTRAINTS: Follow design | Preserve existing behavior | Follow code conventions\n---\nInnerLoop: true",
-    "role": "developer",
-    "prefix": "DEV",
-    "deps": ["DESIGN-001"],
-    "status": "pending",
-    "findings": "",
-    "error": ""
-  }
-}
-```
-
-**VERIFY-001** (tester, parallel with REVIEW-001):
-```json
-{
-  "VERIFY-001": {
-    "title": "Verify implementation",
-    "description": "PURPOSE: Verify implementation | Success: Tests pass, no regressions\nTASK:\n  - Detect test framework\n  - Run tests for changed files\n  - Run regression test suite\nCONTEXT:\n  - Session: <session-folder>\n  - Scope: <task-scope>\n  - Upstream artifacts: code/dev-log.md\n  - Shared memory: <session>/.msg/meta.json\nEXPECTED: <session>/verify/verify-001.json | Pass rate >= 95%\nCONSTRAINTS: Focus on changed files | Report regressions\n---\nInnerLoop: false",
-    "role": "tester",
-    "prefix": "VERIFY",
-    "deps": ["DEV-001"],
-    "status": "pending",
-    "findings": "",
-    "error": ""
-  }
-}
-```
-
-**REVIEW-001** (reviewer, parallel with VERIFY-001):
-```json
-{
-  "REVIEW-001": {
-    "title": "Code review for correctness and quality",
-    "description": "PURPOSE: Code review for correctness and quality | Success: All dimensions reviewed, verdict issued\nTASK:\n  - Load changed files and design document\n  - Review across 4 dimensions: correctness, completeness, maintainability, security\n  - Score quality (1-10) and issue verdict\nCONTEXT:\n  - Session: <session-folder>\n  - Scope: <task-scope>\n  - Upstream artifacts: design/design-001.md, code/dev-log.md\n  - Shared memory: <session>/.msg/meta.json\nEXPECTED: <session>/review/review-001.md | Per-dimension findings with severity\nCONSTRAINTS: Focus on implementation changes | Provide file:line references\n---\nInnerLoop: false",
-    "role": "reviewer",
-    "prefix": "REVIEW",
-    "deps": ["DEV-001"],
-    "status": "pending",
-    "findings": "",
-    "error": ""
-  }
-}
-```
-
----
-
-### Multi-Sprint Pipeline
-
-Sprint 1: DESIGN-001 -> DEV-001 -> DEV-002(incremental) -> VERIFY-001 -> DEV-fix -> REVIEW-001
-
-Create Sprint 1 tasks using sprint templates above, plus:
-
-**DEV-002** (developer, incremental):
-```json
-{
-  "DEV-002": {
-    "title": "Incremental implementation",
-    "description": "PURPOSE: Incremental implementation | Success: Remaining tasks implemented\nTASK:\n  - Load remaining tasks from breakdown\n  - Implement incrementally\n  - Validate syntax\nCONTEXT:\n  - Session: <session-folder>\n  - Scope: <task-scope>\n  - Upstream artifacts: design/task-breakdown.json, code/dev-log.md\n  - Shared memory: <session>/.msg/meta.json\nEXPECTED: Modified source files + updated dev-log.md\nCONSTRAINTS: Incremental delivery | Follow existing patterns\n---\nInnerLoop: true",
-    "role": "developer",
-    "prefix": "DEV",
-    "deps": ["DEV-001"],
-    "status": "pending",
-    "findings": "",
-    "error": ""
-  }
-}
-```
-
-Subsequent sprints created dynamically after Sprint N completes.
-
-## Phase 4: Validation
-
-Verify task chain integrity:
-
-| Check | Method | Expected |
-|-------|--------|----------|
-| Task count correct | tasks.json count | patch: 2, sprint: 4, multi: 5+ |
-| Dependencies correct | Trace deps graph | Acyclic, correct ordering |
-| No circular dependencies | Trace full graph | Acyclic |
-| Structured descriptions | Each has PURPOSE/TASK/CONTEXT/EXPECTED | All present |
-
-If validation fails, fix the specific task and re-validate.