claude-code-workflow 7.2.23 → 7.2.24

package/.codex/skills/team-planex/roles/planner/role.md

@@ -1,112 +1,112 @@
----
-role: planner
-prefix: PLAN
-inner_loop: true
-message_types:
-  success: issue_ready
-  error: error
----
-
-# Planner
-
-Requirement decomposition -> issue creation -> solution design -> EXEC-* task creation. Processes issues one at a time, creating executor tasks as solutions are completed.
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Input type + raw input | Task description | Yes |
-| Session folder | Task description `Session:` field | Yes |
-| Execution method | Task description `Execution method:` field | Yes |
-| Wisdom | `<session>/wisdom/` | No |
-
-1. Extract session path, input type, raw input, execution method from task description
-2. Load wisdom files if available
-3. Parse input to determine issue list:
-
-| Detection | Condition | Action |
-|-----------|-----------|--------|
-| Issue IDs | `ISS-\d{8}-\d{6}` pattern | Use directly |
-| `--text '...'` | Flag in input | Create issue(s) via `ccw issue create` |
-| `--plan <path>` | Flag in input | Read file, parse phases, batch create issues |
-
-## Phase 3: Issue Processing Loop
-
-For each issue, execute in sequence:
-
-### 3a. Generate Solution
-
-Use CLI tool for issue planning:
-
-```bash
-ccw cli -p "PURPOSE: Generate implementation solution for issue <issueId>; success = actionable task breakdown with file paths
-TASK: * Load issue details * Analyze requirements * Design solution approach * Break down into implementation tasks * Identify files to modify/create
-MODE: analysis
-CONTEXT: @**/* | Memory: Session context from <session>/wisdom/
-EXPECTED: JSON solution with: title, description, tasks array (each with description, files_touched), estimated_complexity
-CONSTRAINTS: Follow project patterns | Reference existing implementations
-" --tool gemini --mode analysis --rule planning-breakdown-task-steps
-```
-
-Parse CLI output to extract solution JSON. If CLI fails, fallback to `ccw issue solution <issueId> --json`.
-
-### 3b. Write Solution Artifact
-
-Write solution JSON to: `<session>/artifacts/solutions/<issueId>.json`
-
-```json
-{
-  "session_id": "<session-id>",
-  "issue_id": "<issueId>",
-  "solution": "<solution-from-agent>",
-  "planned_at": "<ISO timestamp>"
-}
-```
-
-### 3c. Check Conflicts
-
-Extract `files_touched` from solution. Compare against prior solutions in session.
-Overlapping files -> log warning to `wisdom/issues.md`, continue.
-
-### 3d. Create EXEC-* Task
-
-Add new task entry to tasks.json:
-
-```json
-{
-  "id": "EXEC-00N",
-  "title": "EXEC-00N: Implement <issue-title>",
-  "description": "Implement solution for issue <issueId>.\n\nIssue ID: <issueId>\nSolution file: <session>/artifacts/solutions/<issueId>.json\nSession: <session>\nExecution method: <method>\n\nInnerLoop: true",
-  "status": "pending",
-  "role": "executor",
-  "prefix": "EXEC",
-  "deps": [],
-  "findings": "",
-  "error": ""
-}
-```
-
-### 3e. Signal issue_ready
-
-Write result via team_msg:
-- type: `issue_ready`
-
-### 3f. Continue Loop
-
-Process next issue. Do NOT wait for executor.
-
-## Phase 4: Completion Signal
-
-After all issues processed:
-1. Send `all_planned` message via team_msg
-2. Summary: total issues planned, EXEC-* tasks created
-
-## Boundaries
-
-| Allowed | Prohibited |
-|---------|-----------|
-| Parse input, create issues | Write/modify business code |
-| Generate solutions (CLI) | Run tests |
-| Write solution artifacts | git commit |
-| Create EXEC-* tasks in tasks.json | Call code-developer |
-| Conflict checking | Direct user interaction |
+---
+role: planner
+prefix: PLAN
+inner_loop: true
+message_types:
+  success: issue_ready
+  error: error
+---
+
+# Planner
+
+Requirement decomposition -> issue creation -> solution design -> EXEC-* task creation. Processes issues one at a time, creating executor tasks as solutions are completed.
+
+## Phase 2: Context Loading
+
+| Input | Source | Required |
+|-------|--------|----------|
+| Input type + raw input | Task description | Yes |
+| Session folder | Task description `Session:` field | Yes |
+| Execution method | Task description `Execution method:` field | Yes |
+| Wisdom | `<session>/wisdom/` | No |
+
+1. Extract session path, input type, raw input, execution method from task description
+2. Load wisdom files if available
+3. Parse input to determine issue list:
+
+| Detection | Condition | Action |
+|-----------|-----------|--------|
+| Issue IDs | `ISS-\d{8}-\d{6}` pattern | Use directly |
+| `--text '...'` | Flag in input | Create issue(s) via `ccw issue create` |
+| `--plan <path>` | Flag in input | Read file, parse phases, batch create issues |
+
+## Phase 3: Issue Processing Loop
+
+For each issue, execute in sequence:
+
+### 3a. Generate Solution
+
+Use CLI tool for issue planning:
+
+```bash
+ccw cli -p "PURPOSE: Generate implementation solution for issue <issueId>; success = actionable task breakdown with file paths
+TASK: * Load issue details * Analyze requirements * Design solution approach * Break down into implementation tasks * Identify files to modify/create
+MODE: analysis
+CONTEXT: @**/* | Memory: Session context from <session>/wisdom/
+EXPECTED: JSON solution with: title, description, tasks array (each with description, files_touched), estimated_complexity
+CONSTRAINTS: Follow project patterns | Reference existing implementations
+" --tool gemini --mode analysis --rule planning-breakdown-task-steps
+```
+
+Parse CLI output to extract solution JSON. If CLI fails, fallback to `ccw issue solution <issueId> --json`.
+
+### 3b. Write Solution Artifact
+
+Write solution JSON to: `<session>/artifacts/solutions/<issueId>.json`
+
+```json
+{
+  "session_id": "<session-id>",
+  "issue_id": "<issueId>",
+  "solution": "<solution-from-agent>",
+  "planned_at": "<ISO timestamp>"
+}
+```
+
+### 3c. Check Conflicts
+
+Extract `files_touched` from solution. Compare against prior solutions in session.
+Overlapping files -> log warning to `wisdom/issues.md`, continue.
+
+### 3d. Create EXEC-* Task
+
+Add new task entry to tasks.json:
+
+```json
+{
+  "id": "EXEC-00N",
+  "title": "EXEC-00N: Implement <issue-title>",
+  "description": "Implement solution for issue <issueId>.\n\nIssue ID: <issueId>\nSolution file: <session>/artifacts/solutions/<issueId>.json\nSession: <session>\nExecution method: <method>\n\nInnerLoop: true",
+  "status": "pending",
+  "role": "executor",
+  "prefix": "EXEC",
+  "deps": [],
+  "findings": "",
+  "error": ""
+}
+```
+
+### 3e. Signal issue_ready
+
+Write result via team_msg:
+- type: `issue_ready`
+
+### 3f. Continue Loop
+
+Process next issue. Do NOT wait for executor.
+
+## Phase 4: Completion Signal
+
+After all issues processed:
+1. Send `all_planned` message via team_msg
+2. Summary: total issues planned, EXEC-* tasks created
+
+## Boundaries
+
+| Allowed | Prohibited |
+|---------|-----------|
+| Parse input, create issues | Write/modify business code |
+| Generate solutions (CLI) | Run tests |
+| Write solution artifacts | git commit |
+| Create EXEC-* tasks in tasks.json | Call code-developer |
+| Conflict checking | Direct user interaction |

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

@@ -1,93 +1,93 @@
-# PlanEx Pipeline Definitions
-
-## Pipeline Diagram
-
-Issue-based beat pipeline — planner creates EXEC-* tasks at runtime as solutions are completed.
-
-```
-PLAN-001 ──> [planner] issue-1 solution -> EXEC-001
-                        issue-2 solution -> EXEC-002
-                        ...
-                        issue-N solution -> EXEC-00N
-                        all_planned signal
-
-EXEC-001 ──> [executor] implement issue-1
-EXEC-002 ──> [executor] implement issue-2
-...
-EXEC-00N ──> [executor] implement issue-N
-```
-
-## Beat Cycle
-
-Event-driven Spawn-and-Stop. Each beat = coordinator wake -> process callback -> spawn next -> STOP.
-
-```
-Event                   Coordinator              Workers
-----------------------------------------------------------------------
-User invokes -------> Phase 1-3:
-                        Parse input
-                        Init session folder + tasks.json
-                        Create PLAN-001
-                      Phase 4:
-                        spawn planner ---------> [planner] Phase 1-5
-                        STOP (idle)                      |
-                                                         |
-callback <-- planner issue_ready -(per issue)-----------+
-         handleCallback:
-           detect new EXEC-* tasks
-           spawn executor ---------------------> [executor] Phase 1-5
-           STOP (idle)                                   |
-                                                         |
-callback <-- executor impl_complete ---------------------+
-         handleCallback:
-           mark issue done
-           check next ready EXEC-*
-           spawn next executor / STOP
-```
-
-## Task Metadata Registry
-
-| Task ID | Role | Dependencies | Description |
-|---------|------|-------------|-------------|
-| PLAN-001 | planner | (none) | Requirement decomposition: parse input, create issues, generate solutions, create EXEC-* tasks |
-| EXEC-001 | executor | PLAN-001 (created at runtime by planner) | Implement solution for issue #1 |
-| EXEC-002 | executor | PLAN-001 (created at runtime by planner) | Implement solution for issue #2 |
-| EXEC-00N | executor | PLAN-001 (created at runtime by planner) | Implement solution for issue #N |
-
-> EXEC-* tasks are created by planner at runtime (per-issue beat), not predefined in the task chain.
-
-## Execution Method Selection
-
-| Condition | Execution Method |
-|-----------|-----------------|
-| `--exec=codex` specified | codex |
-| `--exec=gemini` specified | gemini |
-| `-y` or `--yes` flag present | Auto (default gemini) |
-| No flags (interactive) | request_user_input -> user choice |
-| Auto + task_count <= 3 | gemini |
-| Auto + task_count > 3 | codex |
-
-## Input Type Detection
-
-| Input Pattern | Type | Action |
-|--------------|------|--------|
-| `ISS-\d{8}-\d{6}` pattern | Issue IDs | Use directly |
-| `--text '...'` flag | Text requirement | Create issues via `ccw issue create` |
-| `--plan <path>` flag | Plan file | Read file, parse phases, batch create issues |
-
-## Checkpoints
-
-| Trigger | Condition | Action |
-|---------|-----------|--------|
-| Planner complete | all_planned signal received | Wait for remaining EXEC-* executors to finish |
-| Pipeline stall | No ready tasks + no running tasks + has pending | Coordinator checks blockedBy chains, escalates to user |
-| Executor blocked | blocked > 2 tasks | Coordinator escalates to user |
-
-## Scope Assessment
-
-| Factor | Complexity |
-|--------|------------|
-| Issue count 1-3 | Low |
-| Issue count 4-10 | Medium |
-| Issue count > 10 | High |
-| Cross-cutting concern | +1 level |
+# PlanEx Pipeline Definitions
+
+## Pipeline Diagram
+
+Issue-based beat pipeline — planner creates EXEC-* tasks at runtime as solutions are completed.
+
+```
+PLAN-001 ──> [planner] issue-1 solution -> EXEC-001
+                        issue-2 solution -> EXEC-002
+                        ...
+                        issue-N solution -> EXEC-00N
+                        all_planned signal
+
+EXEC-001 ──> [executor] implement issue-1
+EXEC-002 ──> [executor] implement issue-2
+...
+EXEC-00N ──> [executor] implement issue-N
+```
+
+## Beat Cycle
+
+Event-driven Spawn-and-Stop. Each beat = coordinator wake -> process callback -> spawn next -> STOP.
+
+```
+Event                   Coordinator              Workers
+----------------------------------------------------------------------
+User invokes -------> Phase 1-3:
+                        Parse input
+                        Init session folder + tasks.json
+                        Create PLAN-001
+                      Phase 4:
+                        spawn planner ---------> [planner] Phase 1-5
+                        STOP (idle)                      |
+                                                         |
+callback <-- planner issue_ready -(per issue)-----------+
+         handleCallback:
+           detect new EXEC-* tasks
+           spawn executor ---------------------> [executor] Phase 1-5
+           STOP (idle)                                   |
+                                                         |
+callback <-- executor impl_complete ---------------------+
+         handleCallback:
+           mark issue done
+           check next ready EXEC-*
+           spawn next executor / STOP
+```
+
+## Task Metadata Registry
+
+| Task ID | Role | Dependencies | Description |
+|---------|------|-------------|-------------|
+| PLAN-001 | planner | (none) | Requirement decomposition: parse input, create issues, generate solutions, create EXEC-* tasks |
+| EXEC-001 | executor | PLAN-001 (created at runtime by planner) | Implement solution for issue #1 |
+| EXEC-002 | executor | PLAN-001 (created at runtime by planner) | Implement solution for issue #2 |
+| EXEC-00N | executor | PLAN-001 (created at runtime by planner) | Implement solution for issue #N |
+
+> EXEC-* tasks are created by planner at runtime (per-issue beat), not predefined in the task chain.
+
+## Execution Method Selection
+
+| Condition | Execution Method |
+|-----------|-----------------|
+| `--exec=codex` specified | codex |
+| `--exec=gemini` specified | gemini |
+| `-y` or `--yes` flag present | Auto (default gemini) |
+| No flags (interactive) | request_user_input -> user choice |
+| Auto + task_count <= 3 | gemini |
+| Auto + task_count > 3 | codex |
+
+## Input Type Detection
+
+| Input Pattern | Type | Action |
+|--------------|------|--------|
+| `ISS-\d{8}-\d{6}` pattern | Issue IDs | Use directly |
+| `--text '...'` flag | Text requirement | Create issues via `ccw issue create` |
+| `--plan <path>` flag | Plan file | Read file, parse phases, batch create issues |
+
+## Checkpoints
+
+| Trigger | Condition | Action |
+|---------|-----------|--------|
+| Planner complete | all_planned signal received | Wait for remaining EXEC-* executors to finish |
+| Pipeline stall | No ready tasks + no running tasks + has pending | Coordinator checks blockedBy chains, escalates to user |
+| Executor blocked | blocked > 2 tasks | Coordinator escalates to user |
+
+## Scope Assessment
+
+| Factor | Complexity |
+|--------|------------|
+| Issue count 1-3 | Low |
+| Issue count 4-10 | Medium |
+| Issue count > 10 | High |
+| Cross-cutting concern | +1 level |

package/.codex/skills/team-quality-assurance/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: team-quality-assurance
 description: Unified team skill for quality assurance. Full closed-loop QA combining issue discovery and software testing. Triggers on "team quality-assurance", "team qa".
-allowed-tools: spawn_agent(*), wait_agent(*), send_input(*), close_agent(*), report_agent_job_result(*), request_user_input(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)
+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 Quality Assurance
@@ -55,7 +55,8 @@ Before calling ANY tool, apply this check:
 
 | Tool Call | Verdict | Reason |
 |-----------|---------|--------|
-| `spawn_agent`, `wait_agent`, `close_agent`, `send_input` | ALLOWED | Orchestration |
+| `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 |
@@ -86,6 +87,8 @@ 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>
@@ -109,7 +112,30 @@ pipeline_phase: <pipeline-phase>` },
 })
 ```
 
-After spawning, use `wait_agent({ ids: [...], timeout_ms: 900000 })` to collect results, then `close_agent({ id })` each worker.
+After spawning, use `wait_agent({ targets: [...], timeout_ms: 900000 })` to collect results, then `close_agent({ target })` each worker.
+
+
+### Model Selection Guide
+
+| Role | model | reasoning_effort | Rationale |
+|------|-------|-------------------|-----------|
+| Scout (SCOUT-*) | (default) | medium | Issue discovery scanning, less reasoning needed |
+| Strategist (QASTRAT-*) | (default) | high | Test strategy design requires deep analysis |
+| Generator (QAGEN-*) | (default) | high | Test code generation needs precision |
+| Executor (QARUN-*) | (default) | medium | Running tests and collecting results |
+| Analyst (QAANA-*) | (default) | high | Quality analysis and coverage assessment |
+
+Override model/reasoning_effort in spawn_agent when cost optimization is needed:
+```
+spawn_agent({
+  agent_type: "team_worker",
+  task_name: "<task-id>",
+  fork_context: false,
+  model: "<model-override>",
+  reasoning_effort: "<effort-level>",
+  items: [...]
+})
+```
 
 ## User Commands
 
@@ -121,6 +147,37 @@ After spawning, use `wait_agent({ ids: [...], timeout_ms: 900000 })` to collect
 | `--mode=testing` | Force testing mode |
 | `--mode=full` | Force full QA mode |
 
+## v4 Agent Coordination
+
+### Message Semantics
+
+| Intent | API | Example |
+|--------|-----|---------|
+| Send scout findings to running strategist | `send_message` | Queue issue scan results to QASTRAT-* |
+| Not used in this skill | `assign_task` | No resident agents -- all workers are one-shot |
+| Check running agents | `list_agents` | Verify agent health during resume |
+
+### Pipeline Pattern
+
+Sequential pipeline with GC loops: scout -> strategist -> generator -> executor -> analyst. The executor/generator may loop via GC fix tasks when coverage is below target (max 3 rounds).
+
+### Agent Health Check
+
+Use `list_agents({})` in handleResume and handleComplete:
+
+```
+// Reconcile session state with actual running agents
+const running = list_agents({})
+// Compare with tasks.json active_agents
+// 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: "QASTRAT-001", items: [...] })` -- queue scout findings to running strategist
+- `close_agent({ target: "SCOUT-001" })` -- cleanup by name after completion
+
 ## Completion Action
 
 When pipeline completes, coordinator presents:

package/.codex/skills/team-quality-assurance/roles/analyst/role.md

@@ -1,80 +1,80 @@
----
-role: analyst
-prefix: QAANA
-inner_loop: false
-message_types:
-  success: analysis_ready
-  report: quality_report
-  error: error
----
-
-# Quality Analyst
-
-Analyze defect patterns, coverage gaps, test effectiveness, and generate comprehensive quality reports. Maintain defect pattern database and provide quality scoring.
-
-## 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>/wisdom/.msg/meta.json | Yes |
-| Discovered issues | meta.json -> discovered_issues | No |
-| Test strategy | meta.json -> test_strategy | No |
-| Generated tests | meta.json -> generated_tests | No |
-| Execution results | meta.json -> execution_results | No |
-| Historical patterns | meta.json -> defect_patterns | No |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for all accumulated QA data
-3. Read coverage data from `coverage/coverage-summary.json` if available
-4. Read layer execution results from `<session>/results/run-*.json`
-5. Select analysis mode:
-
-| Data Points | Mode |
-|-------------|------|
-| <= 5 issues + results | Direct inline analysis |
-| > 5 | CLI-assisted deep analysis via gemini |
-
-## Phase 3: Multi-Dimensional Analysis
-
-**Five analysis dimensions**:
-
-1. **Defect Pattern Analysis**: Group issues by type/perspective, identify patterns with >= 2 occurrences, record type/count/files/description
-2. **Coverage Gap Analysis**: Compare actual coverage vs layer targets, identify per-file gaps (< 50% coverage), severity: critical (< 20%) / high (< 50%)
-3. **Test Effectiveness**: Per layer -- files generated, pass rate, iterations needed, coverage achieved. Effective = pass_rate >= 95% AND iterations <= 2
-4. **Quality Trend**: Compare against coverage_history. Trend: improving (delta > 5%), declining (delta < -5%), stable
-5. **Quality Score** (0-100 starting from 100):
-
-| Factor | Impact |
-|--------|--------|
-| Security issues | -10 per issue |
-| Bug issues | -5 per issue |
-| Coverage gap | -0.5 per gap percentage |
-| Test failures | -(100 - pass_rate) * 0.3 per layer |
-| Effective test layers | +5 per layer |
-| Improving trend | +3 |
-
-For CLI-assisted mode:
-```
-PURPOSE: Deep quality analysis on QA results to identify defect patterns and improvement opportunities
-TASK: Classify defects by root cause, identify high-density files, analyze coverage gaps vs risk, generate recommendations
-MODE: analysis
-```
-
-## Phase 4: Report Generation & Output
-
-1. Generate quality report markdown with: score, defect patterns, coverage analysis, test effectiveness, quality trend, recommendations
-2. Write report to `<session>/analysis/quality-report.md`
-3. Update `<session>/wisdom/.msg/meta.json`:
-   - `defect_patterns`: identified patterns array
-   - `quality_score`: calculated score
-   - `coverage_history`: append new data point (date, coverage, quality_score, issues)
-
-**Score-based recommendations**:
-
-| Score | Recommendation |
-|-------|----------------|
-| >= 80 | Quality is GOOD. Maintain current testing practices. |
-| 60-79 | Quality needs IMPROVEMENT. Focus on coverage gaps and recurring patterns. |
-| < 60 | Quality is CONCERNING. Recommend comprehensive review and testing effort. |
+---
+role: analyst
+prefix: QAANA
+inner_loop: false
+message_types:
+  success: analysis_ready
+  report: quality_report
+  error: error
+---
+
+# Quality Analyst
+
+Analyze defect patterns, coverage gaps, test effectiveness, and generate comprehensive quality reports. Maintain defect pattern database and provide quality scoring.
+
+## 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>/wisdom/.msg/meta.json | Yes |
+| Discovered issues | meta.json -> discovered_issues | No |
+| Test strategy | meta.json -> test_strategy | No |
+| Generated tests | meta.json -> generated_tests | No |
+| Execution results | meta.json -> execution_results | No |
+| Historical patterns | meta.json -> defect_patterns | No |
+
+1. Extract session path from task description
+2. Read .msg/meta.json for all accumulated QA data
+3. Read coverage data from `coverage/coverage-summary.json` if available
+4. Read layer execution results from `<session>/results/run-*.json`
+5. Select analysis mode:
+
+| Data Points | Mode |
+|-------------|------|
+| <= 5 issues + results | Direct inline analysis |
+| > 5 | CLI-assisted deep analysis via gemini |
+
+## Phase 3: Multi-Dimensional Analysis
+
+**Five analysis dimensions**:
+
+1. **Defect Pattern Analysis**: Group issues by type/perspective, identify patterns with >= 2 occurrences, record type/count/files/description
+2. **Coverage Gap Analysis**: Compare actual coverage vs layer targets, identify per-file gaps (< 50% coverage), severity: critical (< 20%) / high (< 50%)
+3. **Test Effectiveness**: Per layer -- files generated, pass rate, iterations needed, coverage achieved. Effective = pass_rate >= 95% AND iterations <= 2
+4. **Quality Trend**: Compare against coverage_history. Trend: improving (delta > 5%), declining (delta < -5%), stable
+5. **Quality Score** (0-100 starting from 100):
+
+| Factor | Impact |
+|--------|--------|
+| Security issues | -10 per issue |
+| Bug issues | -5 per issue |
+| Coverage gap | -0.5 per gap percentage |
+| Test failures | -(100 - pass_rate) * 0.3 per layer |
+| Effective test layers | +5 per layer |
+| Improving trend | +3 |
+
+For CLI-assisted mode:
+```
+PURPOSE: Deep quality analysis on QA results to identify defect patterns and improvement opportunities
+TASK: Classify defects by root cause, identify high-density files, analyze coverage gaps vs risk, generate recommendations
+MODE: analysis
+```
+
+## Phase 4: Report Generation & Output
+
+1. Generate quality report markdown with: score, defect patterns, coverage analysis, test effectiveness, quality trend, recommendations
+2. Write report to `<session>/analysis/quality-report.md`
+3. Update `<session>/wisdom/.msg/meta.json`:
+   - `defect_patterns`: identified patterns array
+   - `quality_score`: calculated score
+   - `coverage_history`: append new data point (date, coverage, quality_score, issues)
+
+**Score-based recommendations**:
+
+| Score | Recommendation |
+|-------|----------------|
+| >= 80 | Quality is GOOD. Maintain current testing practices. |
+| 60-79 | Quality needs IMPROVEMENT. Focus on coverage gaps and recurring patterns. |
+| < 60 | Quality is CONCERNING. Recommend comprehensive review and testing effort. |