maestro-flow 0.5.1 → 0.5.3

package/.agents/skills/insight-challenge/SKILL.md

@@ -0,0 +1,228 @@
+---
+name: insight-challenge
+description: "Adversarial review of code quality findings. Challenges insights with counter-evidence, verifies claims against source code, and produces structured verdicts. Triggers on 'insight-challenge', 'challenge finding', '审查发现'."
+allowed-tools: read(*), glob(*), grep(*), bash(*), write(*)
+---
+<!-- Open-standard mirror generated by scripts/build-agents-standard.mjs — do not edit; re-run after editing .claude/ source. -->
+
+
+# Insight Challenge
+
+Adversarial review of code quality findings. Challenges insights with counter-evidence, verifies claims against source code, and produces structured verdicts.
+
+**适用场景**: 当需要对代码审查、质量分析、或架构评估中的发现进行对抗性验证时使用。
+
+## Architecture
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│  Insight Challenge (SKILL.md) — Adversarial Review          │
+│  → Parse finding → Read source → Challenge → Verdict        │
+└─────────────────────────────────────────────────────────────┘
+                           │
+    ┌──────────┬───────────┼───────────┬──────────┐
+    ↓          ↓           ↓           ↓          │
+┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐      │
+│Phase 1 │ │Phase 2 │ │Phase 3 │ │Phase 4 │      │
+│ Parse  │ │ Source │ │Challenge│ │Verdict │      │
+│Finding │ │ Review │ │Analysis │ │Report  │      │
+└───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘      │
+    │          │          │          │             │
+ finding    source     counter-   structured      │
+ parsed     code       evidence   verdict         │
+```
+
+## Key Design Principles
+
+1. **Adversarial by Default**: Assume findings may be incorrect; seek counter-evidence first
+2. **Source-Code Anchored**: All claims must be verified against actual code, not assumptions
+3. **Structured Output**: Verdicts follow a fixed schema for downstream consumption
+4. **Fair Challenge**: If evidence supports the finding, confirm it; don't manufacture doubt
+5. **Transparent Reasoning**: Show the chain of evidence and reasoning
+
+## Finding Input Format
+
+Findings can be provided as JSON or structured text:
+
+```json
+{
+  "id": "HIGH-01",
+  "title": "知识边类型 resolves/documents 未在 types.ts 声明",
+  "severity": "high",
+  "file": "src/graph/kg/db/types.ts",
+  "line": 58,
+  "description": "issue-extractor 使用 'resolves' 边类型...",
+  "evidence": "types.ts KnowledgeEdgeKind: defines, constrains...",
+  "suggestion": "补齐缺失的边类型声明",
+  "design_ref": "Gap 2 — 12 CodeEdgeKind + 9 KnowledgeEdgeKind"
+}
+```
+
+Or structured text:
+```
+HIGH-01: 知识边类型 resolves/documents 未在 types.ts 声明
+Severity: high
+File: src/graph/kg/db/types.ts:58
+Claim: issue-extractor 使用 'resolves' 边类型但未在类型系统中声明
+Evidence: types.ts KnowledgeEdgeKind 列表中缺少 'resolves'
+```
+
+## Execution Flow
+
+### Phase 1: Parse Finding
+
+1. Extract finding ID, title, severity, file reference, and claims
+2. Identify all verifiable assertions:
+   - File existence claims
+   - Code structure claims (types, functions, variables)
+   - Behavioral claims (usage patterns, dependencies)
+   - Design conformance claims
+3. Create verification checklist
+
+### Phase 2: Source Review
+
+1. Read the referenced file(s) at the specified lines
+2. Search for related code using Grep/Glob
+3. Document actual state of the code:
+   - What types/functions actually exist
+   - What values are actually declared
+   - What the actual implementation looks like
+4. Compare claims against reality
+
+### Phase 3: Challenge Analysis
+
+For each claim in the finding:
+
+1. **Seek confirming evidence**: Does the source code support this claim?
+2. **Seek disconfirming evidence**: Does the source code contradict this claim?
+3. **Check for misinterpretation**: Could the claim be based on outdated code or misunderstanding?
+4. **Verify design references**: Are cited design docs accurate?
+
+Challenge strategies:
+- **Direct contradiction**: Source code explicitly shows the opposite
+- **Context omission**: Finding omits relevant context that changes the interpretation
+- **Stale reference**: Finding references code that has been updated
+- **Miscounted**: Numeric claims (missing N types) are incorrect
+- **Scope error**: Finding applies wrong scope (e.g., confuses edge types with language types)
+
+### Phase 4: Verdict Report
+
+Produce structured output:
+
+```json
+{
+  "finding_id": "HIGH-01",
+  "challenge_result": "overturned|weakened|confirmed",
+  "confidence": 95,
+  "reasoning": "Detailed explanation of why the finding was challenged or confirmed",
+  "counter_evidence": [
+    "Source file line 64: 'resolves' IS declared in KnowledgeEdgeKind",
+    "Design doc specifies 20 edge types, not 28"
+  ],
+  "supporting_evidence": [],
+  "adjusted_severity": "none|high|medium|low",
+  "recommendation": "Dismiss this finding; the claimed gap does not exist"
+}
+```
+
+## Verdict Definitions
+
+| Verdict | Meaning | When to Use |
+|---------|---------|-------------|
+| **overturned** | Finding is factually incorrect | Source code directly contradicts the claim |
+| **weakened** | Finding is partially correct but overstated | Some evidence supports it, but severity/scope is wrong |
+| **confirmed** | Finding is accurate | Source code supports all claims |
+
+## Challenge Patterns
+
+### Pattern 1: Type Declaration Check
+```
+Claim: "Type X is not declared"
+Challenge: Read the type file → check if X exists in type union/enum
+Counter: "Line N shows X IS declared in the type definition"
+```
+
+### Pattern 2: Design Reference Verification
+```
+Claim: "Design requires N items, implementation has M"
+Challenge: Read design doc → verify the claimed requirement
+Counter: "Design doc actually specifies K items, not N"
+```
+
+### Pattern 3: Usage Verification
+```
+Claim: "Code uses type X but X is not defined"
+Challenge: Check both usage site AND definition site
+Counter: "X is defined at line N in file Y"
+```
+
+### Pattern 4: Scope Confusion
+```
+Claim: "Missing 7 edge types (total should be 28)"
+Challenge: Check what the "28" actually refers to
+Counter: "The 28 refers to language types, not edge types; edge types are 21"
+```
+
+## Output Format
+
+The challenge produces a markdown report:
+
+```markdown
+## Challenge Report: <finding_id>
+
+**Verdict**: <overturned|weakened|confirmed>
+**Confidence**: <0-100>%
+**Adjusted Severity**: <none|high|medium|low>
+
+### Original Finding
+<finding summary>
+
+### Counter-Evidence
+- <evidence point 1>
+- <evidence point 2>
+
+### Supporting Evidence
+- <evidence point 1> (if any)
+
+### Reasoning
+<detailed explanation>
+
+### Recommendation
+<action recommendation>
+```
+
+## Error Handling
+
+| Scenario | Resolution |
+|----------|------------|
+| Referenced file not found | Report file missing; verdict = weakened (potentially stale) |
+| Line number out of range | Search for the claimed content; adjust line reference |
+| Design doc not found | Skip design verification; note in report |
+| Ambiguous evidence | Present both sides; lower confidence score |
+| Multiple findings batch | Process each independently; produce per-finding verdicts |
+
+## Usage Examples
+
+### Single Finding Challenge
+```
+invoke_skill(skill="insight-challenge", args='{"id":"HIGH-01","title":"...","file":"src/types.ts","line":58,...}')
+```
+
+### Batch Challenge
+```
+invoke_skill(skill="insight-challenge", args='findings.json')
+```
+
+### Inline Challenge
+```
+Challenge this finding:
+Claim: Function X is not exported
+File: src/utils.ts:45
+Evidence: grep shows no export keyword
+```
+
+## Related Skills
+
+- **team-adversarial-swarm**: Multi-agent adversarial analysis
+- **team-quality-assurance**: QA pipeline with issue discovery
+- **codify-to-knowhow**: Capturing verified knowledge

package/.agents/skills/insight-challenge/specs/challenge-protocol.md

@@ -0,0 +1,154 @@
+# Challenge Protocol Specification
+
+## Overview
+
+This protocol defines the systematic approach to challenging code quality findings. The goal is to ensure findings are accurate before action is taken, reducing false positives and wasted effort.
+
+## Challenge Methodology
+
+### Step 1: Claim Decomposition
+
+Break the finding into atomic, verifiable claims:
+
+1. **Existence claims**: "X exists/does not exist in file Y"
+2. **Behavior claims**: "Function X does Y when Z"
+3. **Structure claims**: "Type X has N members"
+4. **Conformance claims**: "Implementation deviates from design by X"
+5. **Numeric claims**: "Missing N items (expected M, found K)"
+
+Each claim must be independently verifiable.
+
+### Step 2: Evidence Collection
+
+For each claim, collect:
+
+1. **Primary evidence**: Direct source code reading
+2. **Secondary evidence**: Related files, imports, type definitions
+3. **Design evidence**: Referenced design documents
+4. **Usage evidence**: How the code is actually used
+
+Evidence hierarchy:
+- Source code > Design docs > Comments > Assumptions
+
+### Step 3: Adversarial Analysis
+
+Apply these challenge strategies:
+
+#### Strategy A: Direct Verification
+Read the exact file and line referenced. Does the claim match reality?
+
+```
+Claim: "Line 58: type X is missing"
+Action: Read line 58 of the file
+Result: Line 58 shows type X IS present → claim overturned
+```
+
+#### Strategy B: Context Expansion
+The claim may be technically correct but misleadingly decontextualized.
+
+```
+Claim: "Function X has no error handling"
+Action: Read the full function and its callers
+Result: Error handling is done by callers → claim weakened
+```
+
+#### Strategy C: Scope Correction
+The claim may confuse different scopes or namespaces.
+
+```
+Claim: "28 edge types required, only 21 found"
+Action: Check what "28" refers to in design docs
+Result: 28 = language types, not edge types → claim overturned
+```
+
+#### Strategy D: Temporal Check
+The claim may reference outdated code.
+
+```
+Claim: "File X uses deprecated API Y"
+Action: Check git history and current code
+Result: API was updated last week → claim overturned
+```
+
+#### Strategy E: Completeness Check
+The claim may be partially correct but incomplete.
+
+```
+Claim: "Type X is missing from union"
+Action: Check all union members
+Result: X is present but Y is actually missing → claim weakened
+```
+
+### Step 4: Verdict Determination
+
+Use this decision tree:
+
+```
+Is the primary claim factually incorrect?
+  ├─ Yes → verdict = "overturned"
+  └─ No → Is the severity/scope overstated?
+       ├─ Yes → verdict = "weakened"
+       └─ No → Is the claim accurate?
+            ├─ Yes → verdict = "confirmed"
+            └─ Uncertain → verdict = "weakened" (lower confidence)
+```
+
+### Step 5: Confidence Scoring
+
+| Confidence | Meaning |
+|------------|---------|
+| 90-100% | Clear, unambiguous evidence |
+| 70-89% | Strong evidence with minor uncertainty |
+| 50-69% | Mixed evidence; judgment call |
+| Below 50% | Insufficient evidence; recommend further investigation |
+
+Factors affecting confidence:
+- Source code clarity
+- Design doc availability
+- Claim specificity
+- Evidence completeness
+
+## Anti-Patterns
+
+### 1. Confirmation Bias
+**Wrong**: Looking only for evidence that supports the finding
+**Right**: Actively seeking counter-evidence first
+
+### 2. Manufactured Doubt
+**Wrong**: Challenging findings without real counter-evidence
+**Right**: Only challenge when evidence genuinely contradicts
+
+### 3. Nitpicking
+**Wrong**: Challenging trivial details while ignoring core issues
+**Right**: Focus on claims that affect the finding's validity
+
+### 4. Scope Creep
+**Wrong**: Expanding the challenge beyond the finding's claims
+**Right**: Address only what the finding asserts
+
+## Output Quality Criteria
+
+A good challenge report:
+
+1. **Specific**: References exact file paths and line numbers
+2. **Verifiable**: Counter-evidence can be independently checked
+3. **Fair**: Acknowledges supporting evidence when present
+4. **Actionable**: Provides clear recommendation
+5. **Proportional**: Confidence matches evidence strength
+
+## Integration Points
+
+### With Quality Pipeline
+- Challenge can be triggered automatically for high-severity findings
+- Results feed back into finding confidence scores
+- Overturned findings are flagged for template improvement
+
+### With Knowledge System
+- Confirmed findings can be captured as knowhow
+- Challenge patterns can be codified as review specs
+- Common false-positive patterns become learning material
+
+### With Team Skills
+- Challenge can be delegated to specialized agents
+- Results inform team scoring and convergence
+- Adversarial patterns align with team-adversarial-swarm

package/.agents/skills/insight-challenge/specs/verdict-schema.md

@@ -0,0 +1,239 @@
+# Verdict Schema Specification
+
+## Overview
+
+This document defines the structured output format for insight challenge verdicts. The schema ensures consistent, machine-readable results that can be consumed by downstream systems.
+
+## Verdict JSON Schema
+
+```json
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "type": "object",
+  "required": ["finding_id", "challenge_result", "confidence", "reasoning"],
+  "properties": {
+    "finding_id": {
+      "type": "string",
+      "description": "Original finding identifier"
+    },
+    "challenge_result": {
+      "type": "string",
+      "enum": ["overturned", "weakened", "confirmed"],
+      "description": "Verdict of the challenge"
+    },
+    "confidence": {
+      "type": "integer",
+      "minimum": 0,
+      "maximum": 100,
+      "description": "Confidence score (0-100)"
+    },
+    "reasoning": {
+      "type": "string",
+      "description": "Detailed explanation of the verdict"
+    },
+    "counter_evidence": {
+      "type": "array",
+      "items": { "type": "string" },
+      "description": "Evidence that contradicts the finding"
+    },
+    "supporting_evidence": {
+      "type": "array",
+      "items": { "type": "string" },
+      "description": "Evidence that supports the finding"
+    },
+    "adjusted_severity": {
+      "type": "string",
+      "enum": ["none", "critical", "high", "medium", "low"],
+      "description": "Recommended severity after challenge"
+    },
+    "recommendation": {
+      "type": "string",
+      "description": "Recommended action"
+    },
+    "metadata": {
+      "type": "object",
+      "properties": {
+        "challenge_duration_ms": { "type": "integer" },
+        "files_reviewed": { "type": "array", "items": { "type": "string" } },
+        "design_docs_checked": { "type": "array", "items": { "type": "string" } },
+        "challenge_strategies_applied": { "type": "array", "items": { "type": "string" } }
+      }
+    }
+  }
+}
+```
+
+## Field Definitions
+
+### finding_id
+- **Type**: string
+- **Required**: yes
+- **Description**: The original finding identifier (e.g., "HIGH-01", "CRIT-03")
+- **Example**: "HIGH-01"
+
+### challenge_result
+- **Type**: string (enum)
+- **Required**: yes
+- **Values**:
+  - `overturned`: Finding is factually incorrect; source code directly contradicts claims
+  - `weakened`: Finding is partially correct but overstated, misscoped, or missing context
+  - `confirmed`: Finding is accurate; source code supports all claims
+
+### confidence
+- **Type**: integer (0-100)
+- **Required**: yes
+- **Description**: How confident the challenger is in the verdict
+- **Scale**:
+  - 90-100: Clear, unambiguous evidence
+  - 70-89: Strong evidence with minor uncertainty
+  - 50-69: Mixed evidence; judgment call
+  - Below 50: Insufficient evidence
+
+### reasoning
+- **Type**: string
+- **Required**: yes
+- **Description**: Detailed explanation of why the verdict was reached
+- **Should include**:
+  - Summary of the original claim
+  - What evidence was found
+  - Why the evidence supports the verdict
+  - Any caveats or limitations
+
+### counter_evidence
+- **Type**: array of strings
+- **Required**: no (but expected for overturned/weakened)
+- **Description**: Specific evidence that contradicts the finding
+- **Format**: Each item should reference a specific file and line
+- **Example**: ["src/types.ts line 64: 'resolves' IS declared in KnowledgeEdgeKind"]
+
+### supporting_evidence
+- **Type**: array of strings
+- **Required**: no (but expected for confirmed)
+- **Description**: Specific evidence that supports the finding
+- **Format**: Same as counter_evidence
+
+### adjusted_severity
+- **Type**: string (enum)
+- **Required**: no
+- **Values**:
+  - `none`: Finding should be dismissed entirely
+  - `critical`, `high`, `medium`, `low`: Adjusted severity level
+- **Description**: Recommended severity after considering challenge evidence
+- **Default**: Original severity if not specified
+
+### recommendation
+- **Type**: string
+- **Required**: no
+- **Description**: Recommended next action
+- **Examples**:
+  - "Dismiss this finding; the claimed gap does not exist"
+  - "Downgrade to medium severity; the issue exists but is less critical than claimed"
+  - "Confirm and prioritize; the finding is accurate and important"
+
+### metadata
+- **Type**: object
+- **Required**: no
+- **Description**: Additional context about the challenge process
+- **Fields**:
+  - `challenge_duration_ms`: Time spent on the challenge
+  - `files_reviewed`: List of files examined
+  - `design_docs_checked`: Design documents consulted
+  - `challenge_strategies_applied`: Which challenge strategies were used
+
+## Example Verdicts
+
+### Overturned Finding
+
+```json
+{
+  "finding_id": "HIGH-01",
+  "challenge_result": "overturned",
+  "confidence": 97,
+  "reasoning": "The finding's central claim is factually incorrect. Both 'resolves' and 'documents' ARE declared in KnowledgeEdgeKind in types.ts (lines 64 and 61 respectively). The '28 edge types' design requirement is a misattribution -- the design doc specifies 12 CodeEdgeKind + 8 KnowledgeEdgeKind = 20, and the implementation has 21.",
+  "counter_evidence": [
+    "types.ts lines 58-67: KnowledgeEdgeKind explicitly declares all 9 types including 'resolves' (L64) and 'documents' (L61)",
+    "Design doc plan-maestrograph.md L1327: specifies '12 + 8 种知识关系' = 20 total, not 28",
+    "The '28' number in the finding matches LANGUAGES constant (L1344), not edge types"
+  ],
+  "supporting_evidence": [],
+  "adjusted_severity": "none",
+  "recommendation": "Dismiss this finding; the claimed type gap does not exist"
+}
+```
+
+### Weakened Finding
+
+```json
+{
+  "finding_id": "MED-02",
+  "challenge_result": "weakened",
+  "confidence": 75,
+  "reasoning": "The finding correctly identifies that function X lacks input validation, but overstates the severity. The function is only called internally with pre-validated data, reducing the actual risk.",
+  "counter_evidence": [
+    "src/service.ts: Function X is only called from Y() which validates inputs",
+    "No external API exposes this function directly"
+  ],
+  "supporting_evidence": [
+    "src/utils.ts line 45: Function X确实没有输入验证"
+  ],
+  "adjusted_severity": "low",
+  "recommendation": "Add defensive validation as a best practice, but do not prioritize as high severity"
+}
+```
+
+### Confirmed Finding
+
+```json
+{
+  "finding_id": "CRIT-03",
+  "challenge_result": "confirmed",
+  "confidence": 95,
+  "reasoning": "The finding accurately identifies a SQL injection vulnerability. User input is directly concatenated into the query string without parameterization.",
+  "counter_evidence": [],
+  "supporting_evidence": [
+    "src/db.ts line 78: query = 'SELECT * FROM users WHERE id = ' + userId",
+    "userId comes directly from req.params.id without sanitization"
+  ],
+  "adjusted_severity": "critical",
+  "recommendation": "Immediate fix required; use parameterized queries"
+}
+```
+
+## Batch Processing
+
+When processing multiple findings:
+
+```json
+{
+  "batch_id": "review-2026-06-12",
+  "total_findings": 5,
+  "verdicts": [
+    { "finding_id": "HIGH-01", "challenge_result": "overturned", ... },
+    { "finding_id": "HIGH-02", "challenge_result": "confirmed", ... },
+    { "finding_id": "MED-01", "challenge_result": "weakened", ... }
+  ],
+  "summary": {
+    "overturned": 1,
+    "weakened": 1,
+    "confirmed": 3,
+    "adjusted_effort_savings": "40% of original findings dismissed or downgraded"
+  }
+}
+```
+
+## Integration with Downstream Systems
+
+### Quality Dashboard
+- Verdicts update finding status in quality tracking
+- Confidence scores affect finding priority
+- Adjusted severities trigger appropriate workflows
+
+### Knowledge System
+- Confirmed findings become knowhow candidates
+- Challenge patterns become review specs
+- Overturned findings improve future detection
+
+### Team Skills
+- Verdicts feed into team scoring algorithms
+- Challenge results inform convergence criteria
+- Adversarial patterns enhance team review quality

package/.agents/skills/maestro/SKILL.md

@@ -52,7 +52,7 @@ $ARGUMENTS — user intent text, or special keywords.
 4. **Decomposition contract shared with maestro-ralph** — broad/lifecycle intents run S_DECOMPOSE producing the SAME additive block (`boundary_contract`, `execution_criteria`, `task_decomposition`)。Reference maestro-ralph `A_DECOMPOSE_TASKS`
 5. **status.json 唯一真源** — 不生成 `goal-checklist.md` 或外部清单
 6. **执行步骤统一通过 `maestro ralph next` 加载** — `command_scope`/`command_path` 由 `maestro ralph skills --platform agent --json --quiet` 预校验（project 覆盖 global，限定 `.claude/`）；decision 节点不走 CLI，走 `invoke_skill("maestro-ralph")` handoff
-7. **Topology awareness** — chain catalog 含 grill / brainstorm / blueprint / analyze-macro / analyze / roadmap / plan(三路径) / execute / verify / ...；scope_verdict 由 ralph 在 `post-analyze-scope` 决定
+7. **Topology awareness** — chain catalog 含 grill / brainstorm / blueprint / analyze-macro / analyze / roadmap / plan(三路径) / execute / ...；scope_verdict 由 ralph 在 `post-analyze-scope` 决定
 8. **Grill is interactive-only** — `-y` auto mode MUST skip grill stage and route directly to brainstorm; grill requires Socratic Q&A with the user
 9. **D-007 milestone 反查** — 数字 phase 的 `milestone_id` 由 `state.json.milestones[].phase_slugs` 反查
 10. **每个 step 必须 `completion_confirmed: true`** — 由 `maestro ralph complete N --status DONE|DONE_WITH_CONCERNS` 写入
@@ -143,9 +143,9 @@ S_FALLBACK:
    - 正式规格/spec-generate/7-phase → `blueprint`
    - 项目初始化 → `init`
    - 宽/中等意图 + 无数字 phase → `analyze-macro`（产 scope_verdict，由 ralph 在 `post-analyze-scope` 决定是否插入 roadmap+analyze 或直跳 plan --from analyze）
-   - 数字 phase 上下文 → `analyze {phase}` → `plan {phase}` → `execute {phase}` → `verify {phase}` → quality pipeline
-   - 已有 analyze artifact 想直达执行 → `plan --from analyze:{ANL_ID}` → execute → verify
-   - 已有 blueprint artifact → `plan --from blueprint:{BLP_ID}` → execute → verify
+   - 数字 phase 上下文 → `analyze {phase}` → `plan {phase}` → `execute {phase}` → quality pipeline
+   - 已有 analyze artifact 想直达执行 → `plan --from analyze:{ANL_ID}` → execute → quality pipeline
+   - 已有 blueprint artifact → `plan --from blueprint:{BLP_ID}` → execute → quality pipeline
 4. 执行 step：`shell("maestro ralph skills --platform agent --json --quiet")` 预校验 skill 名，命中写绝对路径到 `command_path`，未命中标 `missing`；同时写 `step.stage` / `step.scope` / `step.source_artifact_ref`。decision 节点不解析 command_path
 
 ### A_CLARIFY
@@ -161,7 +161,7 @@ S_FALLBACK:
 2. broad/medium → `ask_user` ≤3 轮：Scope / Constraints / Definition of Done
 3. 派生 `execution_criteria` + `task_decomposition`（每个 sub-goal 含 `done_when` + `evidence` + `lifecycle` + `completion_confirmed: false`）
 4. **status.json 唯一真源**：写入 `boundary_contract` / `execution_criteria` / `task_decomposition`；不生成 markdown 清单
-5. 在最后一个 evidence-producing stage（verify/review/test）之后、`milestone-complete` 之前追加 `decision:post-goal-audit`。ralph-execute 在该节点按需动态生长 `steps[]`
+5. 在最后一个 evidence-producing stage（execute/review/test）之后、`milestone-complete` 之前追加 `decision:post-goal-audit`。ralph-execute 在该节点按需动态生长 `steps[]`
 6. **输出 `/goal` 绑定提示词（不阻塞，用户可在执行过程中随时输入）：**
    ```
    📋 任务分解完成。可随时复制下面一行设定目标（执行过程中输入即可）：
@@ -223,7 +223,7 @@ S_FALLBACK:
 ### Success Criteria
 
 - [ ] Intent classified with task_type, complexity, clarity_score
-- [ ] Chain catalog 覆盖 grill / brainstorm / blueprint / analyze-macro / analyze / roadmap / plan(三路径) / execute / verify / quality pipeline
+- [ ] Chain catalog 覆盖 grill / brainstorm / blueprint / analyze-macro / analyze / roadmap / plan(三路径) / execute / quality pipeline
 - [ ] `-y` 模式不触发 grill（交互式压力测试不支持自动模式，跳过直接走 brainstorm）
 - [ ] D-007: 数字 phase 步骤的 `milestone_id` 通过 `state.json.milestones[].phase_slugs` 反查
 - [ ] macro analyze 后跟 `decision:post-analyze-scope`（由 ralph 评估 scope_verdict 决定下游链路）

package/.agents/skills/maestro-help/SKILL.md

@@ -293,7 +293,7 @@ Roadmap > Milestone > Phase > Task
 
 - **Slash 命令**: 56 个（7 个分类）
 - **CLI 命令**: 21 个
-- **Skills**: 10 个（3 个分类）
+- **Skills**: 11 个（4 个分类）
 - **Agents**: 22 个（5 个分类）
 - **Guide 文档**: 17 个
 - **工作流路径**: 6 个合法路径 (Path A-F) + 3 个辅助流程