ln-310-multi-agent-validator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Paths: File paths (
shared/
,
references/
,
../ln-*
) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root.
路径说明: 文件路径(
shared/
references/
../ln-*
)是相对于技能仓库根目录的。如果在当前工作目录(CWD)中未找到,请定位到本SKILL.md所在目录,然后向上一级即可到达仓库根目录。

Multi-Agent Validator

多Agent验证器

Validates Stories/Tasks (mode=story) or arbitrary context (mode=context) with parallel multi-agent review and critical verification.
通过并行多Agent评审和严格验证,对需求故事/任务(mode=story模式)或任意上下文(mode=context模式)进行校验。

Inputs

输入参数

InputRequiredSourceDescription
storyId
mode=storyargs, git branch, kanban, userStory to process
context {files}
mode=contextargsFile paths to review
identifier
Noargs or autoShort label for file naming (default:
review_YYYYMMDD_HHMMSS
)
focus
NoargsAreas to focus on (default: all)
review_title
NoargsHuman-readable title (default:
"Context Review"
)
tech_stack
Noargs or auto-detectTechnology stack override (e.g.,
"Python FastAPI"
). Auto-detected if not provided
Mode detection:
"context {file1} {file2}..."
→ mode=context. Anything else → mode=story. Resolution (mode=story): Story Resolution Chain. Status filter: Backlog
输入项是否必填来源描述
storyId
mode=story模式下必填参数、Git分支、看板、用户输入待处理的需求故事ID
context {files}
mode=context模式下必填参数待评审的文件路径
identifier
参数或自动生成用于文件命名的短标签(默认值:
review_YYYYMMDD_HHMMSS
focus
参数评审重点领域(默认:全部领域)
review_title
参数易读的评审标题(默认:
"Context Review"
tech_stack
参数或自动检测技术栈覆盖配置(例如:
"Python FastAPI"
)。未提供时将自动检测
模式检测规则: 输入为
"context {file1} {file2}..."
时自动切换为mode=context模式;其他输入则默认使用mode=story模式。 需求故事解析(mode=story模式): 遵循需求故事解析链。状态过滤: 仅处理Backlog状态的需求

Purpose & Scope

目标与适用范围

  • mode=story: Validate Story plus child Tasks against industry standards and project patterns. Calculate Penalty Points, auto-fix violations, delegate to ln-002 for documentation. Approve Story (Backlog -> Todo).
  • mode=context: Review plans, documents, architecture proposals via multi-agent review + MCP Ref research. Advisory output only (no status changes).
  • Both modes: Launch external agents (Codex + Gemini) in parallel with own validation. Merge findings, critically verify, debate, apply accepted changes.
  • Support Plan Mode: show audit results, wait for approval, then fix
  • mode=story模式: 对照行业标准和项目规范,验证需求故事及其子任务。计算违规扣分、自动修复问题、委托ln-002工具生成文档。将需求故事状态从Backlog更新为Todo。
  • mode=context模式: 通过多Agent评审+MCP Ref研究,对计划、文档、架构提案进行评审。仅输出咨询建议(不修改状态)。
  • 两种模式通用: 并行启动外部Agent(Codex + Gemini)与内置验证逻辑。合并评审结果、进行严格校验、开展辩论分析、应用已确认的修改。
  • 支持计划模式:展示审计结果,等待用户批准后再执行修复

When to Use

使用场景

  • mode=story: Reviewing Stories before approval (Backlog -> Todo), validating implementation path, ensuring standards fit
  • mode=context: Reviewing plans, decisions, documents, architecture proposals for independent second opinion
  • Optimizing or correcting proposed approaches with multi-agent verification
  • mode=story模式: 需求故事批准前的评审(从Backlog到Todo)、验证实现路径、确保符合标准规范
  • mode=context模式: 对计划、决策、文档、架构提案进行独立的二次评审
  • 通过多Agent验证优化或修正拟采用的方案

Penalty Points System

违规扣分系统

Goal: Quantitative assessment of Story/Tasks quality. Before score = raw quality; After score = post-fix quality.
SeverityPointsDescription
CRITICAL10RFC/OWASP/security violations
HIGH5Outdated libraries, architecture issues
MEDIUM3Best practices violations
LOW1Structural/cosmetic issues
Workflow:
  1. Audit: Calculate penalty points for all 27 criteria (Before)
  2. Fix: Auto-fix fixable violations; FLAGGED items keep their penalty
  3. Report: Before → After (0 if all fixed; >0 if FLAGGED remain)
目标: 对需求故事/任务的质量进行量化评估。修复前分数=原始质量得分;修复后分数=修复完成后的质量得分。
严重程度扣分数值描述
CRITICAL(严重)10违反RFC/OWASP/安全规范
HIGH(高)5使用过时库、架构设计问题
MEDIUM(中)3违反最佳实践
LOW(低)1结构/格式问题
工作流程:
  1. 审计:针对全部27项评审标准计算违规扣分(修复前)
  2. 修复:自动修复可修正的违规问题;标记为FLAGGED的问题将保留扣分
  3. 报告:展示修复前→修复后的扣分变化(全部修复则为0;若有FLAGGED问题则分数>0)

Mode Detection

模式检测

Detect operating mode at startup:
Plan Mode Active:
  • Phase 1-2: Full audit (discovery + research + penalty calculation)
  • Phase 3: Show results + fix plan -> WAIT for user approval
  • Phase 4-6: After approval -> execute fixes
Normal Mode:
  • Phase 1-6: Standard workflow without stopping
  • Automatically fix and approve
在启动时自动检测运行模式:
计划模式激活时:
  • 阶段1-2:完成完整审计(发现问题+研究分析+扣分计算)
  • 阶段3:展示结果+修复方案→等待用户批准
  • 阶段4-6:获得批准后→执行修复
普通模式:
  • 阶段1-6:执行标准工作流程,无需中途停顿
  • 自动完成修复并批准需求

Plan Mode: Progress Tracking with TodoWrite

计划模式:通过TodoWrite跟踪进度

When operating in any mode, skill MUST create detailed todo checklist tracking ALL phases and steps.
Rules:
  1. Create todos IMMEDIATELY before Phase 1
  2. Each phase step = separate todo item
  3. Mark
    in_progress
    before starting step,
    completed
    after finishing
Todo Template (~21 items):
Phase 1: Discovery & Loading
  - Auto-discover configuration (Team ID, docs)
  - Load Story metadata (ID, title, status, labels)
  - Load Tasks metadata (1-8 implementation tasks)

Phase 2: Research & Audit
  - Extract technical domains from Story/Tasks
  - Delegate documentation creation to ln-002
  - Research via MCP Ref (RFC, OWASP, library versions)
  - Verify technical claims (Anti-Hallucination)
  - Pre-mortem Analysis (complex Stories)
  - Calculate Penalty Points (27 criteria)

Phase 3: Audit Results & Fix Plan
  - Display Penalty Points table and fix plan
  - Wait for user approval (Plan Mode only)

Phase 4: Auto-Fix (11 groups)
  - Fix Structural violations (#1-#4, #24)
  - Fix Standards violations (#5)
  - Fix Solution violations (#6, #21)
  - Fix Workflow violations (#7-#13)
  - Fix Quality violations (#14-#15)
  - Fix Dependencies violations (#18-#19/#19b)
  - Fix Cross-Reference violations (#25-#26)
  - Fix Risk violations (#20)
  - Fix Pre-mortem violations (#27)
  - Fix Verification violations (#22)
  - Fix Traceability violations (#16-#17)

Phase 1b: Agent Launch (mode=story)
  - Health check: agent availability
  - Build prompt from review_base.md + modes/story.md (per shared workflow "Step: Build Prompt")
  - Launch codex-review + gemini-review as background tasks

Phase 1b: Agent Launch (mode=context)
  - Health check: agent availability
  - Build prompt from review_base.md + modes/context.md (per shared workflow "Step: Build Prompt")
  - Launch codex-review + gemini-review as background tasks

Phase 5: Merge + Critical Verification (MANDATORY)
  - Wait for agent results (process-as-arrive)
  - Re-read lines modified in Phase 4 auto-fix (agents saw pre-fix state)
  - Dedup against Claude's findings + review history
  - Critical Verification + Debate per shared workflow
  - Apply accepted suggestions
  - Save review summary to .agent-review/review_history.md

Phase 6: Approve & Notify (mode=story only)
  - Set Story/Tasks to Todo status in Linear
  - Update kanban_board.md with APPROVED marker
  - Add Linear comment with validation summary
  - Display tabular output to terminal
无论使用哪种模式,本工具必须创建详细的待办事项清单,跟踪所有阶段和步骤。
规则:
  1. 在阶段1开始前立即创建待办事项
  2. 每个阶段的每个步骤对应单独的待办项
  3. 开始步骤前标记为
    in_progress
    ,完成后标记为
    completed
待办事项模板(约21项):
Phase 1: 发现与加载
  - 自动发现配置信息(团队ID、文档)
  - 加载需求故事元数据(ID、标题、状态、标签)
  - 加载子任务元数据(1-8个实现任务)

Phase 2: 研究与审计
  - 从需求故事/任务中提取技术领域
  - 委托ln-002生成文档
  - 通过MCP Ref进行研究(RFC、OWASP、库版本)
  - 验证技术声明(防幻觉校验)
  - 事前分析(针对复杂需求故事)
  - 计算违规扣分(27项标准)

Phase 3: 审计结果与修复方案
  - 展示违规扣分表格和修复方案
  - 等待用户批准(仅计划模式)

Phase 4: 自动修复(11类问题)
  - 修复结构违规问题(#1-#4、#24)
  - 修复标准违规问题(#5)
  - 修复方案违规问题(#6、#21)
  - 修复工作流违规问题(#7-#13)
  - 修复质量违规问题(#14-#15)
  - 修复依赖违规问题(#18-#19/#19b)
  - 修复交叉引用违规问题(#25-#26)
  - 修复风险违规问题(#20)
  - 修复事前分析违规问题(#27)
  - 修复验证违规问题(#22)
  - 修复可追溯性违规问题(#16-#17)

Phase 1b: Agent启动(mode=story模式)
  - 健康检查:Agent可用性
  - 根据review_base.md + modes/story.md构建提示词(遵循共享工作流"Step: Build Prompt")
  - 启动codex-review + gemini-review作为后台任务

Phase 1b: Agent启动(mode=context模式)
  - 健康检查:Agent可用性
  - 根据review_base.md + modes/context.md构建提示词(遵循共享工作流"Step: Build Prompt")
  - 启动codex-review + gemini-review作为后台任务

Phase 5: 合并 + 严格校验(必填步骤)
  - 等待Agent结果(到达即处理)
  - 重新阅读Phase4自动修复中修改的代码行(Agent看到的是修复前的状态)
  - 去重Claude的发现结果 + 历史评审记录
  - 严格校验 + 辩论分析(遵循共享工作流)
  - 应用已接受的建议
  - 将评审摘要保存到.agent-review/review_history.md

Phase 6: 批准与通知(仅mode=story模式)
  - 在Linear中将需求故事/任务状态设置为Todo
  - 在kanban_board.md中添加APPROVED标记
  - 在Linear中添加包含验证摘要的评论
  - 在终端展示表格形式的输出结果

Workflow

工作流程

Phase 0: Tools Config

Phase 0: 工具配置

MANDATORY READ: Load
shared/references/tools_config_guide.md
,
shared/references/storage_mode_detection.md
, and
shared/references/input_resolution_pattern.md
Extract:
task_provider
= Task Management → Provider (
linear
|
file
).
All subsequent phases use
task_provider
to select operations per storage_mode_detection.md.
必读要求: 加载
shared/references/tools_config_guide.md
shared/references/storage_mode_detection.md
shared/references/input_resolution_pattern.md
提取配置:
task_provider
= 任务管理工具提供商(
linear
|
file
)。
后续所有阶段将根据
task_provider
,按照storage_mode_detection.md中的规则选择对应操作。

Phase 1: Discovery & Loading

Phase 1: 发现与加载

Step 1: Resolve storyId (per input_resolution_pattern.md):
  • IF args provided → use args
  • ELSE IF git branch matches
    feature/{id}-*
    → extract id
  • ELSE IF kanban has exactly 1 Story in [Backlog] → suggest
  • ELSE → AskUserQuestion: show Stories from kanban filtered by [Backlog]
Step 2: Configuration & Metadata Loading
  • Auto-discover configuration: Team ID (
    docs/tasks/kanban_board.md
    ), project docs (
    CLAUDE.md
    ), epic from Story.project
  • Load metadata only: Story ID/title/status/labels, child Task IDs/titles/status/labels
    • IF
      task_provider
      =
      linear
      :
      get_issue(storyId)
      +
      list_issues(parentId=storyId)
    • IF
      task_provider
      =
      file
      :
      Read story.md
      +
      Glob("docs/tasks/epics/*/stories/*/tasks/*.md")
  • Expect 1-8 implementation tasks; record parentId for filtering
  • Rationale: keep loading light; full descriptions arrive in Phase 2
Step 1: 解析storyId(遵循input_resolution_pattern.md规则):
  • 若提供了参数 → 使用参数中的storyId
  • 若Git分支匹配
    feature/{id}-*
    格式 → 提取其中的id
  • 若看板中Backlog状态的需求故事恰好有1个 → 自动选择该需求
  • 其他情况 → 向用户提问:展示看板中Backlog状态的所有需求故事供选择
Step 2: 配置与元数据加载
  • 自动发现配置信息:团队ID(
    docs/tasks/kanban_board.md
    )、项目文档(
    CLAUDE.md
    )、需求故事所属的epic
  • 仅加载元数据:需求故事的ID/标题/状态/标签、子任务的ID/标题/状态/标签
    • task_provider
      =
      linear
      :调用
      get_issue(storyId)
      +
      list_issues(parentId=storyId)
      接口
    • task_provider
      =
      file
      :读取
      story.md
      + 匹配
      Glob("docs/tasks/epics/*/stories/*/tasks/*.md")
      路径
  • 预期包含1-8个实现任务;记录parentId用于过滤
  • 设计思路:轻量加载;完整描述将在Phase2中获取

Phase 1b: Agent Launch

Phase 1b: Agent启动

MANDATORY READ: Load
shared/references/agent_review_workflow.md
,
shared/references/agent_delegation_pattern.md
mode=story:
  1. Health Check (per shared workflow "Step: Health Check"):
    • Read
      docs/environment_state.json
      → exclude agents with
      disabled: true
    • Run
      python shared/agents/agent_runner.py --health-check
      for remaining agents
    • If 0 agents available → skip agent review, proceed with Claude-only validation
  2. Get references:
    • IF
      task_provider
      =
      linear
      :
      get_issue(storyId)
      → Story URL,
      list_issues(parent=storyId)
      → Task URLs
    • IF
      task_provider
      =
      file
      : Read story.md, Glob tasks → paths
  3. Build prompt: Assemble from
    shared/agents/prompt_templates/review_base.md
    +
    modes/story.md
    (per shared workflow "Step: Build Prompt"), replace
    {story_ref}
    ,
    {task_refs}
    . Save to
    .agent-review/{identifier}_storyreview_prompt.md
  4. Launch BOTH agents as background tasks (per shared workflow "Step: Run Agents")
mode=context:
  1. Health Check: same as above
  2. Resolve identifier: If not provided, generate
    review_YYYYMMDD_HHMMSS
  3. Materialize context (if needed): If context is from chat → write to
    .agent-review/context/{identifier}_context.md
  4. Build prompt: Assemble from
    shared/agents/prompt_templates/review_base.md
    +
    modes/context.md
    (per shared workflow "Step: Build Prompt"), replace
    {review_title}
    ,
    {context_refs}
    ,
    {focus_areas}
    . Save to
    .agent-review/{identifier}_contextreview_prompt.md
  5. Launch BOTH agents as background tasks
Agents now run in background. Claude proceeds to foreground work.
必读要求: 加载
shared/references/agent_review_workflow.md
shared/references/agent_delegation_pattern.md
mode=story模式:
  1. 健康检查(遵循共享工作流"Step: Health Check"):
    • 读取
      docs/environment_state.json
      → 排除标记为
      disabled: true
      的Agent
    • 对剩余Agent执行
      python shared/agents/agent_runner.py --health-check
      命令
    • 若没有可用Agent → 跳过Agent评审,仅使用Claude进行验证
  2. 获取参考信息:
    • task_provider
      =
      linear
      :调用
      get_issue(storyId)
      获取需求故事URL,调用
      list_issues(parent=storyId)
      获取子任务URL
    • task_provider
      =
      file
      :读取story.md文件,匹配子任务路径
  3. 构建提示词: 基于
    shared/agents/prompt_templates/review_base.md
    +
    modes/story.md
    组装提示词(遵循共享工作流"Step: Build Prompt"),替换其中的
    {story_ref}
    {task_refs}
    。将提示词保存到
    .agent-review/{identifier}_storyreview_prompt.md
  4. 启动两个Agent作为后台任务(遵循共享工作流"Step: Run Agents")
mode=context模式:
  1. 健康检查: 与上述规则相同
  2. 解析标识符: 若未提供,自动生成
    review_YYYYMMDD_HHMMSS
    格式的标识符
  3. 上下文持久化(若需要): 若上下文来自聊天记录 → 将其写入
    .agent-review/context/{identifier}_context.md
  4. 构建提示词: 基于
    shared/agents/prompt_templates/review_base.md
    +
    modes/context.md
    组装提示词(遵循共享工作流"Step: Build Prompt"),替换其中的
    {review_title}
    {context_refs}
    {focus_areas}
    。将提示词保存到
    .agent-review/{identifier}_contextreview_prompt.md
  5. 启动两个Agent作为后台任务
Agent将在后台运行,Claude同时执行前台工作。

Foreground: mode=context (skip Phases 2-4, run MCP Ref research instead)

前台工作:mode=context模式(跳过Phase2-4,执行MCP Ref研究)

MANDATORY READ: Load
references/context_review_pipeline.md
(weight table, stack detection, safety rules) and
shared/references/research_tool_fallback.md
While agents run in background, Claude performs foreground research:
a) Load Review Memory — per shared workflow "Step: Load Review Memory" b) Applicability Check — scan context_files for technology decision signals (infrastructure, API/protocol, security, library/framework choices). No signals → skip MCP Ref, proceed to Phase 5. c) Stack Detection — detect
query_prefix
from:
tech_stack
input >
docs/tools_config.md
> indicator files (*.csproj, package.json, etc.) d) Extract Topics (3-5) — parse context_files for technology decisions, score by weight, take top 3-5 e) MCP Ref Research — per
research_tool_fallback.md
chain (Ref → Context7 → WebSearch). Query:
"{query_prefix} {topic} RFC standard best practices {current_year}"
f) Compare & Correct — if MCP Ref contradicts plan statement (high confidence), apply surgical Edit with inline rationale
"(per {RFC/standard}: ...)"
. Max 5 corrections per run. In Plan Mode → output to chat, skip edits until approved. g) Save Findings — write to
.agent-review/context/{identifier}_mcp_ref_findings.md
(per
references/mcp_ref_findings_template.md
). Display:
"MCP Ref: {N} topics validated, {M} corrections, {K} confirmed"
Then proceed to Phase 5 (Merge).
必读要求: 加载
references/context_review_pipeline.md
(权重表、技术栈检测、安全规则)和
shared/references/research_tool_fallback.md
在Agent后台运行期间,Claude执行以下前台研究工作:
a) 加载评审历史 — 遵循共享工作流"Step: Load Review Memory" b) 适用性检查 — 扫描上下文文件,检测技术决策信号(基础设施、API/协议、安全、库/框架选择)。若无信号 → 跳过MCP Ref研究,直接进入Phase5。 c) 技术栈检测 — 按优先级确定
query_prefix
:输入的
tech_stack
>
docs/tools_config.md
配置 > 特征文件(*.csproj、package.json等) d) 提取主题(3-5个) — 解析上下文文件中的技术决策,按权重评分,选取前3-5个主题 e) MCP Ref研究 — 遵循
research_tool_fallback.md
中的工具链(Ref → Context7 → WebSearch)。查询语句:
"{query_prefix} {topic} RFC standard best practices {current_year}"
f) 对比与修正 — 若MCP Ref研究结果与计划声明存在高置信度矛盾,执行精准修改并添加内联说明
"(per {RFC/standard}: ...)"
。每次运行最多修正5处。若处于计划模式 → 仅输出到聊天窗口,等待批准后再执行修改。 g) 保存研究结果 — 将结果写入
.agent-review/context/{identifier}_mcp_ref_findings.md
(遵循
references/mcp_ref_findings_template.md
模板)。在终端展示:
"MCP Ref: 已验证{N}个主题,完成{M}处修正,确认{K}项内容"
完成后进入Phase5(合并结果)。

Phase 2: Research & Audit (mode=story only)

Phase 2: 研究与审计(仅mode=story模式)

PREREQUISITE: Phase 1b (Agent Launch) must have completed before Phase 2. If agents were not launched and health check was not run, go back to Phase 1b.
MANDATORY READ: Load
references/phase2_research_audit.md
for complete research and audit procedure:
  • Domain extraction from Story/Tasks
  • Documentation delegation to ln-002 (guides/manuals/ADRs)
  • MCP research (RFC/OWASP/library versions via Ref + Context7)
  • Anti-Hallucination verification (evidence-based claims)
  • Pre-mortem Analysis (Tigers → #20, Elephants → #24)
  • Penalty Points calculation (27 criteria, see Auto-Fix Actions Reference in same file)
Always execute for every Story - no exceptions.
前置条件: Phase1b(Agent启动)必须在Phase2之前完成。若未启动Agent或未执行健康检查,请返回Phase1b。
必读要求: 加载
references/phase2_research_audit.md
获取完整的研究与审计流程:
  • 从需求故事/任务中提取技术领域
  • 委托ln-002生成文档(指南/手册/ADRs)
  • MCP研究(通过Ref + Context7获取RFC/OWASP/库版本信息)
  • 防幻觉校验(验证技术声明是否有证据支持)
  • 事前分析(Tigers → #20,Elephants → #24)
  • 计算违规扣分(27项标准,详见同文件中的自动修复操作参考)
所有需求故事必须执行此阶段,无例外。

Phase 3: Audit Results & Fix Plan

Phase 3: 审计结果与修复方案

Display audit results:
  • Penalty Points table (criterion, severity, points, description)
  • Total: X penalty points
  • Fix Plan: list of fixes for each criterion
Mode handling:
  • IF Plan Mode: Show results + "After your approval, changes will be applied" -> WAIT
  • ELSE (Normal Mode): Proceed to Phase 4 immediately
展示审计结果:
  • 违规扣分表格(标准项、严重程度、扣分数值、描述)
  • 总扣分:X分
  • 修复方案:列出每项标准对应的修复措施
模式处理:
  • 计划模式: 展示结果并提示"获得批准后将应用修改" → 等待用户操作
  • 普通模式: 直接进入Phase4

Phase 4: Auto-Fix

Phase 4: 自动修复

Execute fixes for ALL 27 criteria on the spot.
  • Execution order (11 groups):
    1. Structural (#1-#4, #24) — Story/Tasks template compliance + AC completeness/specificity + Assumption Registry
    2. Standards (#5) — RFC/OWASP compliance FIRST (before YAGNI/KISS!)
    3. Solution (#6, #21) — Library versions, alternative solutions
    4. Workflow (#7-#13) — Test strategy, docs integration, size, cleanup, YAGNI, KISS, task order
    5. Quality (#14-#15) — Documentation complete, hardcoded values
    6. Dependencies (#18-#19/#19b) — Story/Task independence (no forward deps), parallel group validity
    7. Cross-Reference (#25-#26) — AC overlap with siblings, task duplication across Stories
    8. Risk (#20) — Implementation risk analysis (after dependencies resolved, before traceability)
    9. Pre-mortem (#27) — Tiger/Paper Tiger/Elephant classification (complex Stories)
    10. Verification (#22) — AC verify methods exist for all task ACs (test/command/inspect)
    11. Traceability (#16-#17) — Story-Task alignment, AC coverage quality (LAST, after all fixes)
  • Use Auto-Fix Actions table below as authoritative checklist
  • Zero out penalty points as fixes applied
  • Test Strategy section must exist but remain empty (testing handled separately)
立即针对全部27项标准执行修复。
  • 修复执行顺序(11类问题):
    1. 结构问题(#1-#4、#24) — 需求故事/任务模板合规性 + 验收标准完整性/明确性 + 假设登记
    2. 标准问题(#5) — 优先修复RFC/OWASP合规问题(优先级高于YAGNI/KISS原则!)
    3. 方案问题(#6、#21) — 库版本、替代方案
    4. 工作流问题(#7-#13) — 测试策略、文档集成、任务规模、清理工作、YAGNI/KISS原则、任务顺序
    5. 质量问题(#14-#15) — 文档完整性、硬编码值
    6. 依赖问题(#18-#19/#19b) — 需求故事/任务独立性(无前置依赖)、并行分组有效性
    7. 交叉引用问题(#25-#26) — 验收标准与兄弟任务重叠、需求故事间的任务重复
    8. 风险问题(#20) — 实现风险分析(依赖问题解决后、可追溯性校验前执行)
    9. 事前分析问题(#27) — 针对复杂需求故事的Tiger/Paper Tiger/Elephant分类
    10. 验证问题(#22) — 确认所有任务的验收标准都有对应的验证方法(测试/命令/检查)
    11. 可追溯性问题(#16-#17) — 需求故事与任务的一致性、验收标准覆盖质量(最后执行,所有修复完成后)
  • 以下方的自动修复操作表作为权威检查清单
  • 修复完成后将对应标准的扣分数值清零
  • 测试策略部分必须保留但需为空(测试工作由其他工具单独处理)

Phase 5: Merge + Critical Verification (MANDATORY — DO NOT SKIP)

Phase 5: 合并 + 严格校验(必填步骤 — 不可跳过)

MANDATORY STEP: This phase merges agent results (launched in Phase 1b) with Claude's own findings. Agents were already running in background during Phases 2-4 (mode=story) or during foreground research (mode=context).
MANDATORY READ: Load
shared/references/agent_review_workflow.md
(Critical Verification + Debate),
shared/references/agent_review_memory.md
  1. Wait for agent results — read result files as they arrive (process-as-arrive pattern)
  2. Parse agent suggestions from both agents' result files
  3. MERGE: Claude's own findings (Phase 2-4 violations for mode=story, MCP Ref findings for mode=context) + Agent suggestions
    • If agent suggestion targets lines modified in Phase 4 auto-fix, re-read affected lines before evaluation (agents saw pre-fix state, files are now post-fix)
  4. For EACH agent suggestion:
    • Dedup against Claude's own findings (skip if already covered)
    • Dedup against review history (skip if already addressed)
    • Claude Evaluation: is it real? Actionable? Applies to our context?
    • MCP Ref enhancement (mode=context): agent suggestion contradicts MCP Ref finding → DISAGREE with citation; aligns → AGREE; not covered → standard evaluation
    • AGREE → accept. DISAGREE → debate (Challenge + Follow-Up per shared workflow)
  5. Apply accepted suggestions:
    • mode=story → apply to Story/Tasks text
    • mode=context → output to chat as advisory
  6. Save review summary to
    .agent-review/review_history.md
  • If verdict =
    SKIPPED
    (no agents at health check) → proceed to Phase 6 unchanged
  • Display:
    "Agent Review: codex ({accepted}/{total}), gemini ({accepted}/{total}), {N} suggestions applied"
必填步骤: 此阶段将Phase1b启动的Agent结果与Claude自身的发现结果合并。Agent在Phase2-4(mode=story模式)或前台研究(mode=context模式)期间已在后台运行。
必读要求: 加载
shared/references/agent_review_workflow.md
(严格校验 + 辩论分析)、
shared/references/agent_review_memory.md
  1. 等待Agent结果 — 结果文件到达后立即读取并处理(到达即处理模式)
  2. 解析Agent建议 — 从两个Agent的结果文件中提取建议
  3. 合并结果: Claude自身的发现结果(mode=story模式下为Phase2-4的违规问题,mode=context模式下为MCP Ref研究结果) + Agent建议
    • 若Agent建议针对Phase4自动修复中修改的代码行,在评估前重新阅读受影响的代码行(Agent看到的是修复前的状态,当前文件已为修复后版本)
  4. 针对每一条Agent建议:
    • 与Claude自身的发现结果去重(已覆盖的建议跳过)
    • 与历史评审记录去重(已处理的建议跳过)
    • Claude评估:建议是否真实有效?是否可执行?是否适用于当前上下文?
    • MCP Ref增强校验(mode=context模式):若Agent建议与MCP Ref研究结果矛盾 → 引用依据并标记为DISAGREE;若一致 → 标记为AGREE;未覆盖的内容 → 按标准流程评估
    • AGREE → 接受建议。DISAGREE → 开展辩论(遵循共享工作流中的Challenge + Follow-Up规则)
  5. 应用已接受的建议:
    • mode=story模式 → 修改需求故事/任务文本
    • mode=context模式 → 在聊天窗口输出咨询建议
  6. 保存评审摘要
    .agent-review/review_history.md
  • 若结论为
    SKIPPED
    (健康检查时无可用Agent) → 直接进入Phase6,不做修改
  • 终端展示:
    "Agent Review: codex ({accepted}/{total}), gemini ({accepted}/{total}), {N}条建议已应用"

Phase 6: Approve & Notify (mode=story only)

Phase 6: 批准与通知(仅mode=story模式)

mode=context: Skip Phase 6. Return suggestions as advisory output. Done.
  • Set Story + all Tasks to Todo; update
    kanban_board.md
    with APPROVED marker
    • IF
      task_provider
      =
      linear
      :
      save_issue({id, state: "Todo"})
      for Story + each Task
    • IF
      task_provider
      =
      file
      :
      Edit
      **Status:**
      line to
      Todo
      in story.md + each task file
  • Add validation summary comment:
    • IF
      task_provider
      =
      linear
      :
      create_comment({issueId, body})
      on Story
    • IF
      task_provider
      =
      file
      :
      Write
      comment to
      docs/tasks/epics/.../comments/{ISO-timestamp}.md
    • Content: Penalty Points table (Before -> After = 0), Auto-Fixes Applied, Documentation Created (via ln-002), Standards Compliance Evidence
  • Display tabular output (Unicode box-drawing) to terminal with Before/After scores
  • Recommended next step:
    ln-400-story-executor
    to start Story execution
mode=context模式: 跳过Phase6。直接返回咨询建议,流程结束。
  • 将需求故事及其所有子任务状态设置为Todo;在
    kanban_board.md
    中添加APPROVED标记
    • task_provider
      =
      linear
      :对需求故事和每个子任务调用
      save_issue({id, state: "Todo"})
      接口
    • task_provider
      =
      file
      :修改
      story.md
      和每个子任务文件中的
      **Status:**
      行,更新为Todo
  • 添加验证摘要评论:
    • task_provider
      =
      linear
      :在需求故事下调用
      create_comment({issueId, body})
      接口添加评论
    • task_provider
      =
      file
      :将评论写入
      docs/tasks/epics/.../comments/{ISO-timestamp}.md
    • 评论内容:违规扣分表格(修复前→修复后=0)、已应用的自动修复、已生成的文档(通过ln-002)、标准合规证据
  • 在终端展示表格形式的输出结果(使用Unicode框线绘制),包含修复前/后的得分
  • 推荐下一步操作: 使用
    ln-400-story-executor
    启动需求故事的执行流程

Auto-Fix Actions Reference

自动修复操作参考

MANDATORY READ: Load
references/phase2_research_audit.md
for complete 27-criteria table with:
  • Structural (#1-#4, #24): Story/Task template compliance, Assumption Registry
  • Standards (#5): RFC/OWASP compliance
  • Solution (#6, #21): Library versions, alternatives
  • Workflow (#7-#13): Test strategy, docs, size, YAGNI/KISS, task order
  • Quality (#14-#15): Documentation, hardcoded values
  • Dependencies (#18-#19/#19b): No forward dependencies
  • Cross-Reference (#25-#26): AC overlap, task duplication across sibling Stories
  • Risk (#20): Implementation risk analysis
  • Pre-mortem (#27): Tiger/Paper Tiger/Elephant classification
  • Traceability (#16-#17): Story-Task alignment, AC coverage
Maximum Penalty: 110 points (sum of all 27 criteria; #20 capped at 15; #25 max 1 CRITICAL = 10)
必读要求: 加载
references/phase2_research_audit.md
获取完整的27项标准表格,包含:
  • 结构问题(#1-#4、#24):需求故事/任务模板合规性、假设登记
  • 标准问题(#5):RFC/OWASP合规性
  • 方案问题(#6、#21):库版本、替代方案
  • 工作流问题(#7-#13):测试策略、文档、任务规模、YAGNI/KISS原则、任务顺序
  • 质量问题(#14-#15):文档完整性、硬编码值
  • 依赖问题(#18-#19/#19b):无前置依赖
  • 交叉引用问题(#25-#26):验收标准重叠、兄弟需求故事间的任务重复
  • 风险问题(#20):实现风险分析
  • 事前分析问题(#27):Tiger/Paper Tiger/Elephant分类
  • 可追溯性问题(#16-#17):需求故事与任务的一致性、验收标准覆盖
最高扣分: 110分(所有27项标准的扣分总和;#20项最高扣15分;#25项最高扣10分(1个CRITICAL违规))

Final Assessment Model

最终评估模型

Two-stage assessment: Before (raw audit) and After (post auto-fix).
MetricBeforeAfterMeaning
Penalty PointsRaw audit totalRemaining after fixes0 = all fixed; >0 = unfixable items
Readiness Score
10 - (Before / 5)
10 - (After / 5)
Quality confidence (1-10)
Anti-HallucinationVERIFIED / FLAGGEDTechnical claims verified
AC CoverageN/N (target 100%)All ACs mapped to Tasks
GateGO / NO-GOFinal verdict
两阶段评估: 修复前(原始审计结果)和修复后(自动修复完成后)。
指标修复前修复后含义
违规扣分原始审计总分修复后剩余扣分0=全部问题已修复;>0=存在无法自动修复的问题
就绪度得分
10 - (修复前扣分 / 5)
10 - (修复后扣分 / 5)
质量置信度(1-10分)
防幻觉校验VERIFIED / FLAGGED技术声明是否已验证
验收标准覆盖N/N(目标100%)所有验收标准是否已映射到任务
准入判断GO / NO-GO最终结论

GO/NO-GO Decision

GO/NO-GO决策规则

GateCondition
GOAfter Penalty Points = 0 AND no FLAGGED criteria
NO-GOAfter Penalty Points > 0 OR any criterion FLAGGED as unfixable
FLAGGED criteria: If auto-fix is impossible (MCP Ref unavailable, external dependency), penalty stays — it is NOT zeroed out. User must resolve manually before re-validation.
准入状态条件
GO修复后违规扣分=0 且 无FLAGGED标记的标准项
NO-GO修复后违规扣分>0 或 存在标记为无法自动修复的FLAGGED标准项
FLAGGED标准项: 若无法自动修复(MCP Ref不可用、存在外部依赖),扣分将保留——不会清零。用户必须手动解决后才能重新验证。

Anti-Hallucination Verification

防幻觉校验

Verify technical claims have evidence:
Claim TypeVerification
RFC/Standard referenceMCP Ref search confirms existence
Library versionContext7 query confirms version
Security requirementOWASP/CWE reference exists
Performance claimBenchmark/doc reference
Status: VERIFIED (all claims sourced) or FLAGGED (unverified claims listed)
验证技术声明是否有证据支持:
声明类型验证方式
RFC/标准引用通过MCP Ref搜索确认其存在
库版本通过Context7查询确认版本有效性
安全要求确认存在OWASP/CWE引用
性能声明确认存在基准测试/文档引用
状态: VERIFIED(所有声明均有来源)或 FLAGGED(存在未验证的声明)

Task-AC Coverage Matrix

任务-验收标准覆盖矩阵

Output explicit mapping:
| AC | Task(s) | Coverage |
|----|---------|----------|
| AC1: Given/When/Then | T-001, T-002 | ✅ |
| AC2: Given/When/Then | T-003 | ✅ |
| AC3: Given/When/Then | — | ❌ UNCOVERED |
Coverage:
{covered}/{total} ACs
(target: 100%)
输出明确的映射关系:
| 验收标准 | 对应任务 | 覆盖状态 |
|----|---------|----------|
| AC1: Given/When/Then | T-001, T-002 | ✅ |
| AC2: Given/When/Then | T-003 | ✅ |
| AC3: Given/When/Then | — | ❌ 未覆盖 |
覆盖度:
{已覆盖数}/{总数}
个验收标准(目标:100%)

Self-Audit Protocol (Mandatory)

自审计协议(必填)

Verify all 27 criteria (#1-#27) from Auto-Fix Actions pass with concrete evidence (doc path, MCP result, Linear update) before proceeding to Phase 6.
在进入Phase6前,必须验证自动修复操作参考中的全部27项标准均已通过,并提供具体证据(文档路径、MCP结果、Linear更新记录)。

Critical Rules

核心规则

  • All 27 criteria MUST be verified with concrete evidence (doc path, MCP result, Linear update) before Phase 6 (Self-Audit Protocol)
  • Fix execution order is strict: Structural -> Standards -> Solution -> Workflow -> Quality -> Dependencies -> Cross-Reference -> Risk -> Pre-mortem -> Verification -> Traceability (standards before YAGNI/KISS)
  • If auto-fix succeeds, zero out that criterion's penalty. If auto-fix is impossible (e.g., MCP Ref unavailable, external dependency), mark as FLAGGED with reason — penalty stays, Gate = NO-GO, user must resolve manually
  • Test Strategy section must exist but remain empty (testing handled separately by other skills)
  • In Plan Mode, MUST stop after Phase 3 and wait for user approval before applying any fixes
  • 进入Phase6前,必须验证全部27项标准均已通过,并提供具体证据(文档路径、MCP结果、Linear更新记录)(遵循自审计协议)
  • 修复执行顺序严格遵循:结构问题 → 标准问题 → 方案问题 → 工作流问题 → 质量问题 → 依赖问题 → 交叉引用问题 → 风险问题 → 事前分析问题 → 验证问题 → 可追溯性问题(标准问题修复优先级高于YAGNI/KISS原则)
  • 若自动修复成功,将对应标准项的扣分清零。若无法自动修复(例如:MCP Ref不可用、存在外部依赖),标记为FLAGGED并说明原因——扣分保留,准入判断为NO-GO,需用户手动解决后重新验证
  • 测试策略部分必须保留但需为空(测试工作由其他工具单独处理)
  • 计划模式下,必须在Phase3结束后暂停,等待用户批准后再执行修复

Definition of Done

完成标准

  • Phases 1-6 completed: metadata loaded, research done, penalties calculated, fixes applied, agent review done, Story approved.
  • Penalty Points After = 0 (all 27 criteria fixed or none FLAGGED). Readiness Score After = 10.
  • Anti-Hallucination: VERIFIED (all claims sourced via MCP).
  • AC Coverage: 100% (each AC mapped to ≥1 Task).
  • Agent Review: agents launched in background before Phase 2, results merged in Phase 5, suggestions verified + debated, accepted applied (or SKIPPED if no agents).
  • Story/Tasks set to Todo; kanban updated; Linear comment with Final Assessment posted.
  • Phase1-6全部完成:元数据加载完成、研究已开展、违规扣分已计算、修复已应用、Agent评审已完成、需求故事已批准。
  • 修复后违规扣分=0(全部27项标准已修复或无FLAGGED标记项)。修复后就绪度得分=10。
  • 防幻觉校验状态:VERIFIED(所有声明均通过MCP验证)。
  • 验收标准覆盖度:100%(每个验收标准至少映射到1个任务)。
  • Agent评审:在Phase2前已在后台启动Agent,Phase5中已合并结果、验证并辩论建议、应用已接受的建议(或因无可用Agent标记为SKIPPED)。
  • 需求故事/任务状态已设置为Todo;看板已更新;Linear中已发布包含最终评估结果的评论。

Example Workflow

示例工作流程

Story: "Create user management API with rate limiting"
  1. Phase 1: Load metadata (5 Tasks, status Backlog) 1b. Phase 1b: Health check → launch codex-review + gemini-review in background
  2. Phase 2:
    • Domain extraction: REST API, Rate Limiting
    • Delegate ln-002: creates Guide-05 (REST patterns), Guide-06 (Rate Limiting)
    • MCP Ref: RFC 7231 compliance, OWASP API Security
    • Context7: Express v4.19 (current v4.17)
    • Penalty Points: 18 total (version=5, missing docs=5, structure=3, standards=5)
  3. Phase 3:
    • Show Penalty Points table
    • IF Plan Mode: "18 penalty points found. Fix plan ready. Approve?"
  4. Phase 4:
    • Fix #6: Update Express v4.17 -> v4.19
    • Fix #5: Add RFC 7231 compliance notes
    • Fix #13: Add Guide-05, Guide-06 references
    • Fix #17: Docs already created by ln-002
    • All fixes applied, Penalty Points = 0
  5. Phase 5: Merge agent results (launched in Phase 1b) + Claude's findings → verify, debate, apply
  6. Phase 6: Story -> Todo, tabular report
需求故事: "Create user management API with rate limiting"
  1. Phase1: 加载元数据(5个子任务,状态为Backlog) 1b. Phase1b: 健康检查 → 后台启动codex-review + gemini-review
  2. Phase2:
    • 技术领域提取:REST API、Rate Limiting
    • 委托ln-002:生成Guide-05(REST模式)、Guide-06(Rate Limiting)
    • MCP Ref:RFC 7231合规性、OWASP API安全标准
    • Context7:检测到Express v4.19(当前最新版本为v4.17)
    • 违规扣分:总计18分(版本问题扣5分、缺少文档扣5分、结构问题扣3分、标准问题扣5分)
  3. Phase3:
    • 展示违规扣分表格
    • 若为计划模式:"发现18分违规扣分。修复方案已准备就绪。是否批准?"
  4. Phase4:
    • 修复#6:将Express版本从v4.17升级到v4.19
    • 修复#5:添加RFC 7231合规性说明
    • 修复#13:添加Guide-05、Guide-06的引用
    • 修复#17:ln-002已生成对应文档
    • 所有修复完成,违规扣分=0
  5. Phase5: 合并Agent结果(Phase1b启动的Agent) + Claude的发现结果 → 验证、辩论、应用建议
  6. Phase6: 需求故事状态更新为Todo,展示表格形式的报告

Template Loading

模板加载

Templates:
story_template.md
,
task_template_implementation.md
Loading Logic:
  1. Check if
    docs/templates/{template}.md
    exists in target project
  2. IF NOT EXISTS: a. Create
    docs/templates/
    directory if missing b. Copy
    shared/templates/{template}.md
    docs/templates/{template}.md
    c. Replace placeholders in the LOCAL copy:
    • {{TEAM_ID}}
      → from
      docs/tasks/kanban_board.md
    • {{DOCS_PATH}}
      → "docs" (standard)
  3. Use LOCAL copy (
    docs/templates/{template}.md
    ) for all validation operations
Rationale: Templates are copied to target project on first use, ensuring:
  • Project independence (no dependency on skills repository)
  • Customization possible (project can modify local templates)
  • Placeholder replacement happens once at copy time
模板文件:
story_template.md
task_template_implementation.md
加载逻辑:
  1. 检查目标项目中是否存在
    docs/templates/{template}.md
  2. 若不存在: a. 若
    docs/templates/
    目录不存在则创建 b. 将
    shared/templates/{template}.md
    复制到
    docs/templates/{template}.md
    c. 替换本地副本中的占位符:
    • {{TEAM_ID}}
      → 从
      docs/tasks/kanban_board.md
      中提取
    • {{DOCS_PATH}}
      → "docs"(标准路径)
  3. 所有验证操作均使用本地副本(
    docs/templates/{template}.md
设计思路: 模板在首次使用时复制到目标项目,确保:
  • 项目独立性(不依赖技能仓库)
  • 支持自定义(项目可修改本地模板)
  • 占位符仅在复制时替换一次

Reference Files

参考文件

  • Tools config:
    shared/references/tools_config_guide.md
  • Storage mode operations:
    shared/references/storage_mode_detection.md
  • AC validation rules:
    shared/references/ac_validation_rules.md
  • Plan mode behavior:
    shared/references/plan_mode_pattern.md
  • Final Assessment:
    references/readiness_scoring.md
    (GO/NO-GO rules, Readiness Score calculation)
  • Templates (centralized):
    shared/templates/story_template.md
    ,
    shared/templates/task_template_implementation.md
  • Local copies:
    docs/templates/
    (in target project)
  • Validation Checklists (Progressive Disclosure):
    • references/structural_validation.md
      (criteria #1-#4)
    • references/standards_validation.md
      (criterion #5)
    • references/solution_validation.md
      (criterion #6)
    • references/workflow_validation.md
      (criteria #7-#13)
    • references/quality_validation.md
      (criteria #14-#15)
    • references/dependency_validation.md
      (criteria #18-#19/#19b)
    • references/risk_validation.md
      (criterion #20)
    • references/cross_reference_validation.md
      (criteria #25-#26)
    • references/premortem_validation.md
      (criterion #27)
    • references/traceability_validation.md
      (criteria #16-#17)
    • references/domain_patterns.md
      (pattern registry for ln-002 delegation)
    • references/penalty_points.md
      (penalty system details)
  • Prevention checklist:
    shared/references/creation_quality_checklist.md
    (creator-facing mapping of 27 criteria)
  • MANDATORY READ:
    shared/templates/linear_integration.md
    ,
    shared/references/research_tool_fallback.md
  • Agent review workflow:
    shared/references/agent_review_workflow.md
  • Agent delegation pattern:
    shared/references/agent_delegation_pattern.md
  • Agent review memory:
    shared/references/agent_review_memory.md
  • Review templates:
    shared/agents/prompt_templates/review_base.md
    +
    modes/story.md
    ,
    modes/context.md
  • Challenge template:
    shared/agents/prompt_templates/challenge_review.md
  • MCP Ref findings template:
    references/mcp_ref_findings_template.md
  • Context review pipeline:
    references/context_review_pipeline.md
    (weight table, stack detection, safety rules for mode=context)

Version: 7.0.0 Last Updated: 2026-02-03
  • 工具配置:
    shared/references/tools_config_guide.md
  • 存储模式操作:
    shared/references/storage_mode_detection.md
  • 验收标准验证规则:
    shared/references/ac_validation_rules.md
  • 计划模式行为:
    shared/references/plan_mode_pattern.md
  • 最终评估:
    references/readiness_scoring.md
    (GO/NO-GO规则、就绪度得分计算方法)
  • 集中式模板:
    shared/templates/story_template.md
    shared/templates/task_template_implementation.md
  • 本地副本: 目标项目中的
    docs/templates/
    目录
  • 验证检查清单(渐进式披露):
    • references/structural_validation.md
      (标准项#1-#4)
    • references/standards_validation.md
      (标准项#5)
    • references/solution_validation.md
      (标准项#6)
    • references/workflow_validation.md
      (标准项#7-#13)
    • references/quality_validation.md
      (标准项#14-#15)
    • references/dependency_validation.md
      (标准项#18-#19/#19b)
    • references/risk_validation.md
      (标准项#20)
    • references/cross_reference_validation.md
      (标准项#25-#26)
    • references/premortem_validation.md
      (标准项#27)
    • references/traceability_validation.md
      (标准项#16-#17)
    • references/domain_patterns.md
      (ln-002委托的模式注册表)
    • references/penalty_points.md
      (违规扣分系统详情)
  • 创建质量检查清单:
    shared/references/creation_quality_checklist.md
    (面向创建者的27项标准映射)
  • 必读文件:
    shared/templates/linear_integration.md
    shared/references/research_tool_fallback.md
  • Agent评审工作流:
    shared/references/agent_review_workflow.md
  • Agent委托模式:
    shared/references/agent_delegation_pattern.md
  • Agent评审历史:
    shared/references/agent_review_memory.md
  • 评审模板:
    shared/agents/prompt_templates/review_base.md
    +
    modes/story.md
    modes/context.md
  • 辩论模板:
    shared/agents/prompt_templates/challenge_review.md
  • MCP Ref研究结果模板:
    references/mcp_ref_findings_template.md
  • 上下文评审流程:
    references/context_review_pipeline.md
    (mode=context模式的权重表、技术栈检测、安全规则)

版本: 7.0.0 最后更新日期: 2026-02-03