ln-310-multi-agent-validator
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChinesePaths: File paths (,shared/,references/) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root.../ln-*
路径说明: 文件路径(、shared/、references/)是相对于技能仓库根目录的。如果在当前工作目录(CWD)中未找到,请定位到本SKILL.md所在目录,然后向上一级即可到达仓库根目录。../ln-*
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
输入参数
| Input | Required | Source | Description |
|---|---|---|---|
| mode=story | args, git branch, kanban, user | Story to process |
| mode=context | args | File paths to review |
| No | args or auto | Short label for file naming (default: |
| No | args | Areas to focus on (default: all) |
| No | args | Human-readable title (default: |
| No | args or auto-detect | Technology stack override (e.g., |
Mode detection: → mode=context. Anything else → mode=story.
Resolution (mode=story): Story Resolution Chain. Status filter: Backlog
"context {file1} {file2}..."| 输入项 | 是否必填 | 来源 | 描述 |
|---|---|---|---|
| mode=story模式下必填 | 参数、Git分支、看板、用户输入 | 待处理的需求故事ID |
| mode=context模式下必填 | 参数 | 待评审的文件路径 |
| 否 | 参数或自动生成 | 用于文件命名的短标签(默认值: |
| 否 | 参数 | 评审重点领域(默认:全部领域) |
| 否 | 参数 | 易读的评审标题(默认: |
| 否 | 参数或自动检测 | 技术栈覆盖配置(例如: |
模式检测规则: 输入为时自动切换为mode=context模式;其他输入则默认使用mode=story模式。
需求故事解析(mode=story模式): 遵循需求故事解析链。状态过滤: 仅处理Backlog状态的需求
"context {file1} {file2}..."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.
| Severity | Points | Description |
|---|---|---|
| CRITICAL | 10 | RFC/OWASP/security violations |
| HIGH | 5 | Outdated libraries, architecture issues |
| MEDIUM | 3 | Best practices violations |
| LOW | 1 | Structural/cosmetic issues |
Workflow:
- Audit: Calculate penalty points for all 27 criteria (Before)
- Fix: Auto-fix fixable violations; FLAGGED items keep their penalty
- Report: Before → After (0 if all fixed; >0 if FLAGGED remain)
目标: 对需求故事/任务的质量进行量化评估。修复前分数=原始质量得分;修复后分数=修复完成后的质量得分。
| 严重程度 | 扣分数值 | 描述 |
|---|---|---|
| CRITICAL(严重) | 10 | 违反RFC/OWASP/安全规范 |
| HIGH(高) | 5 | 使用过时库、架构设计问题 |
| MEDIUM(中) | 3 | 违反最佳实践 |
| LOW(低) | 1 | 结构/格式问题 |
工作流程:
- 审计:针对全部27项评审标准计算违规扣分(修复前)
- 修复:自动修复可修正的违规问题;标记为FLAGGED的问题将保留扣分
- 报告:展示修复前→修复后的扣分变化(全部修复则为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:
- Create todos IMMEDIATELY before Phase 1
- Each phase step = separate todo item
- Mark before starting step,
in_progressafter finishingcompleted
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开始前立即创建待办事项
- 每个阶段的每个步骤对应单独的待办项
- 开始步骤前标记为,完成后标记为
in_progresscompleted
待办事项模板(约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 , , and
shared/references/tools_config_guide.mdshared/references/storage_mode_detection.mdshared/references/input_resolution_pattern.mdExtract: = Task Management → Provider ( | ).
task_providerlinearfileAll subsequent phases use to select operations per storage_mode_detection.md.
task_provider必读要求: 加载、和
shared/references/tools_config_guide.mdshared/references/storage_mode_detection.mdshared/references/input_resolution_pattern.md提取配置: = 任务管理工具提供商( | )。
task_providerlinearfile后续所有阶段将根据,按照storage_mode_detection.md中的规则选择对应操作。
task_providerPhase 1: Discovery & Loading
Phase 1: 发现与加载
Step 1: Resolve storyId (per input_resolution_pattern.md):
- IF args provided → use args
- ELSE IF git branch matches → extract id
feature/{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 (), project docs (
docs/tasks/kanban_board.md), epic from Story.projectCLAUDE.md - 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.mdGlob("docs/tasks/epics/*/stories/*/tasks/*.md")
- IF
- 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分支匹配格式 → 提取其中的id
feature/{id}-* - 若看板中Backlog状态的需求故事恰好有1个 → 自动选择该需求
- 其他情况 → 向用户提问:展示看板中Backlog状态的所有需求故事供选择
Step 2: 配置与元数据加载
- 自动发现配置信息:团队ID()、项目文档(
docs/tasks/kanban_board.md)、需求故事所属的epicCLAUDE.md - 仅加载元数据:需求故事的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.mdshared/references/agent_delegation_pattern.mdmode=story:
- Health Check (per shared workflow "Step: Health Check"):
- Read → exclude agents with
docs/environment_state.jsondisabled: true - Run for remaining agents
python shared/agents/agent_runner.py --health-check - If 0 agents available → skip agent review, proceed with Claude-only validation
- Read
- Get references:
- IF =
task_provider:linear→ Story URL,get_issue(storyId)→ Task URLslist_issues(parent=storyId) - IF =
task_provider: Read story.md, Glob tasks → pathsfile
- IF
- Build prompt: Assemble from +
shared/agents/prompt_templates/review_base.md(per shared workflow "Step: Build Prompt"), replacemodes/story.md,{story_ref}. Save to{task_refs}.agent-review/{identifier}_storyreview_prompt.md - Launch BOTH agents as background tasks (per shared workflow "Step: Run Agents")
mode=context:
- Health Check: same as above
- Resolve identifier: If not provided, generate
review_YYYYMMDD_HHMMSS - Materialize context (if needed): If context is from chat → write to
.agent-review/context/{identifier}_context.md - Build prompt: Assemble from +
shared/agents/prompt_templates/review_base.md(per shared workflow "Step: Build Prompt"), replacemodes/context.md,{review_title},{context_refs}. Save to{focus_areas}.agent-review/{identifier}_contextreview_prompt.md - Launch BOTH agents as background tasks
Agents now run in background. Claude proceeds to foreground work.
必读要求: 加载、
shared/references/agent_review_workflow.mdshared/references/agent_delegation_pattern.mdmode=story模式:
- 健康检查(遵循共享工作流"Step: Health Check"):
- 读取→ 排除标记为
docs/environment_state.json的Agentdisabled: true - 对剩余Agent执行命令
python shared/agents/agent_runner.py --health-check - 若没有可用Agent → 跳过Agent评审,仅使用Claude进行验证
- 读取
- 获取参考信息:
- 若=
task_provider:调用linear获取需求故事URL,调用get_issue(storyId)获取子任务URLlist_issues(parent=storyId) - 若=
task_provider:读取story.md文件,匹配子任务路径file
- 若
- 构建提示词: 基于+
shared/agents/prompt_templates/review_base.md组装提示词(遵循共享工作流"Step: Build Prompt"),替换其中的modes/story.md和{story_ref}。将提示词保存到{task_refs}.agent-review/{identifier}_storyreview_prompt.md - 启动两个Agent作为后台任务(遵循共享工作流"Step: Run Agents")
mode=context模式:
- 健康检查: 与上述规则相同
- 解析标识符: 若未提供,自动生成格式的标识符
review_YYYYMMDD_HHMMSS - 上下文持久化(若需要): 若上下文来自聊天记录 → 将其写入
.agent-review/context/{identifier}_context.md - 构建提示词: 基于+
shared/agents/prompt_templates/review_base.md组装提示词(遵循共享工作流"Step: Build Prompt"),替换其中的modes/context.md、{review_title}和{context_refs}。将提示词保存到{focus_areas}.agent-review/{identifier}_contextreview_prompt.md - 启动两个Agent作为后台任务
Agent将在后台运行,Claude同时执行前台工作。
Foreground: mode=context (skip Phases 2-4, run MCP Ref research instead)
前台工作:mode=context模式(跳过Phase2-4,执行MCP Ref研究)
MANDATORY READ: Load (weight table, stack detection, safety rules) and
references/context_review_pipeline.mdshared/references/research_tool_fallback.mdWhile 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 from: input > > 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 chain (Ref → Context7 → WebSearch). Query:
f) Compare & Correct — if MCP Ref contradicts plan statement (high confidence), apply surgical Edit with inline rationale . Max 5 corrections per run. In Plan Mode → output to chat, skip edits until approved.
g) Save Findings — write to (per ). Display:
query_prefixtech_stackdocs/tools_config.mdresearch_tool_fallback.md"{query_prefix} {topic} RFC standard best practices {current_year}""(per {RFC/standard}: ...)".agent-review/context/{identifier}_mcp_ref_findings.mdreferences/mcp_ref_findings_template.md"MCP Ref: {N} topics validated, {M} corrections, {K} confirmed"Then proceed to Phase 5 (Merge).
必读要求: 加载(权重表、技术栈检测、安全规则)和
references/context_review_pipeline.mdshared/references/research_tool_fallback.md在Agent后台运行期间,Claude执行以下前台研究工作:
a) 加载评审历史 — 遵循共享工作流"Step: Load Review Memory"
b) 适用性检查 — 扫描上下文文件,检测技术决策信号(基础设施、API/协议、安全、库/框架选择)。若无信号 → 跳过MCP Ref研究,直接进入Phase5。
c) 技术栈检测 — 按优先级确定:输入的 > 配置 > 特征文件(*.csproj、package.json等)
d) 提取主题(3-5个) — 解析上下文文件中的技术决策,按权重评分,选取前3-5个主题
e) MCP Ref研究 — 遵循中的工具链(Ref → Context7 → WebSearch)。查询语句:
f) 对比与修正 — 若MCP Ref研究结果与计划声明存在高置信度矛盾,执行精准修改并添加内联说明。每次运行最多修正5处。若处于计划模式 → 仅输出到聊天窗口,等待批准后再执行修改。
g) 保存研究结果 — 将结果写入(遵循模板)。在终端展示:
query_prefixtech_stackdocs/tools_config.mdresearch_tool_fallback.md"{query_prefix} {topic} RFC standard best practices {current_year}""(per {RFC/standard}: ...)".agent-review/context/{identifier}_mcp_ref_findings.mdreferences/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 for complete research and audit procedure:
references/phase2_research_audit.md- 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):
- Structural (#1-#4, #24) — Story/Tasks template compliance + AC completeness/specificity + Assumption Registry
- Standards (#5) — RFC/OWASP compliance FIRST (before YAGNI/KISS!)
- Solution (#6, #21) — Library versions, alternative solutions
- Workflow (#7-#13) — Test strategy, docs integration, size, cleanup, YAGNI, KISS, task order
- Quality (#14-#15) — Documentation complete, hardcoded values
- Dependencies (#18-#19/#19b) — Story/Task independence (no forward deps), parallel group validity
- Cross-Reference (#25-#26) — AC overlap with siblings, task duplication across Stories
- Risk (#20) — Implementation risk analysis (after dependencies resolved, before traceability)
- Pre-mortem (#27) — Tiger/Paper Tiger/Elephant classification (complex Stories)
- Verification (#22) — AC verify methods exist for all task ACs (test/command/inspect)
- 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-#4、#24) — 需求故事/任务模板合规性 + 验收标准完整性/明确性 + 假设登记
- 标准问题(#5) — 优先修复RFC/OWASP合规问题(优先级高于YAGNI/KISS原则!)
- 方案问题(#6、#21) — 库版本、替代方案
- 工作流问题(#7-#13) — 测试策略、文档集成、任务规模、清理工作、YAGNI/KISS原则、任务顺序
- 质量问题(#14-#15) — 文档完整性、硬编码值
- 依赖问题(#18-#19/#19b) — 需求故事/任务独立性(无前置依赖)、并行分组有效性
- 交叉引用问题(#25-#26) — 验收标准与兄弟任务重叠、需求故事间的任务重复
- 风险问题(#20) — 实现风险分析(依赖问题解决后、可追溯性校验前执行)
- 事前分析问题(#27) — 针对复杂需求故事的Tiger/Paper Tiger/Elephant分类
- 验证问题(#22) — 确认所有任务的验收标准都有对应的验证方法(测试/命令/检查)
- 可追溯性问题(#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 (Critical Verification + Debate),
shared/references/agent_review_workflow.mdshared/references/agent_review_memory.md- Wait for agent results — read result files as they arrive (process-as-arrive pattern)
- Parse agent suggestions from both agents' result files
- 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)
- 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)
- Apply accepted suggestions:
- mode=story → apply to Story/Tasks text
- mode=context → output to chat as advisory
- Save review summary to
.agent-review/review_history.md
- If verdict = (no agents at health check) → proceed to Phase 6 unchanged
SKIPPED - 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.mdshared/references/agent_review_memory.md- 等待Agent结果 — 结果文件到达后立即读取并处理(到达即处理模式)
- 解析Agent建议 — 从两个Agent的结果文件中提取建议
- 合并结果: Claude自身的发现结果(mode=story模式下为Phase2-4的违规问题,mode=context模式下为MCP Ref研究结果) + Agent建议
- 若Agent建议针对Phase4自动修复中修改的代码行,在评估前重新阅读受影响的代码行(Agent看到的是修复前的状态,当前文件已为修复后版本)
- 针对每一条Agent建议:
- 与Claude自身的发现结果去重(已覆盖的建议跳过)
- 与历史评审记录去重(已处理的建议跳过)
- Claude评估:建议是否真实有效?是否可执行?是否适用于当前上下文?
- MCP Ref增强校验(mode=context模式):若Agent建议与MCP Ref研究结果矛盾 → 引用依据并标记为DISAGREE;若一致 → 标记为AGREE;未覆盖的内容 → 按标准流程评估
- AGREE → 接受建议。DISAGREE → 开展辩论(遵循共享工作流中的Challenge + Follow-Up规则)
- 应用已接受的建议:
- mode=story模式 → 修改需求故事/任务文本
- mode=context模式 → 在聊天窗口输出咨询建议
- 保存评审摘要 到
.agent-review/review_history.md
- 若结论为(健康检查时无可用Agent) → 直接进入Phase6,不做修改
SKIPPED - 终端展示:
"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 with APPROVED marker
kanban_board.md- IF =
task_provider:linearfor Story + each Tasksave_issue({id, state: "Todo"}) - IF =
task_provider:fileEditline to**Status:**in story.md + each task fileTodo
- IF
- Add validation summary comment:
- IF =
task_provider:linearon Storycreate_comment({issueId, body}) - IF =
task_provider:filecomment toWritedocs/tasks/epics/.../comments/{ISO-timestamp}.md - Content: Penalty Points table (Before -> After = 0), Auto-Fixes Applied, Documentation Created (via ln-002), Standards Compliance Evidence
- IF
- Display tabular output (Unicode box-drawing) to terminal with Before/After scores
- Recommended next step: to start Story execution
ln-400-story-executor
mode=context模式: 跳过Phase6。直接返回咨询建议,流程结束。
- 将需求故事及其所有子任务状态设置为Todo;在中添加APPROVED标记
kanban_board.md- 若=
task_provider:对需求故事和每个子任务调用linear接口save_issue({id, state: "Todo"}) - 若=
task_provider:修改file和每个子任务文件中的story.md行,更新为Todo**Status:**
- 若
- 添加验证摘要评论:
- 若=
task_provider:在需求故事下调用linear接口添加评论create_comment({issueId, body}) - 若=
task_provider:将评论写入filedocs/tasks/epics/.../comments/{ISO-timestamp}.md - 评论内容:违规扣分表格(修复前→修复后=0)、已应用的自动修复、已生成的文档(通过ln-002)、标准合规证据
- 若
- 在终端展示表格形式的输出结果(使用Unicode框线绘制),包含修复前/后的得分
- 推荐下一步操作: 使用启动需求故事的执行流程
ln-400-story-executor
Auto-Fix Actions Reference
自动修复操作参考
MANDATORY READ: Load for complete 27-criteria table with:
references/phase2_research_audit.md- 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)
必读要求: 加载获取完整的27项标准表格,包含:
references/phase2_research_audit.md- 结构问题(#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).
| Metric | Before | After | Meaning |
|---|---|---|---|
| Penalty Points | Raw audit total | Remaining after fixes | 0 = all fixed; >0 = unfixable items |
| Readiness Score | | | Quality confidence (1-10) |
| Anti-Hallucination | — | VERIFIED / FLAGGED | Technical claims verified |
| AC Coverage | — | N/N (target 100%) | All ACs mapped to Tasks |
| Gate | — | GO / NO-GO | Final verdict |
两阶段评估: 修复前(原始审计结果)和修复后(自动修复完成后)。
| 指标 | 修复前 | 修复后 | 含义 |
|---|---|---|---|
| 违规扣分 | 原始审计总分 | 修复后剩余扣分 | 0=全部问题已修复;>0=存在无法自动修复的问题 |
| 就绪度得分 | | | 质量置信度(1-10分) |
| 防幻觉校验 | — | VERIFIED / FLAGGED | 技术声明是否已验证 |
| 验收标准覆盖 | — | N/N(目标100%) | 所有验收标准是否已映射到任务 |
| 准入判断 | — | GO / NO-GO | 最终结论 |
GO/NO-GO Decision
GO/NO-GO决策规则
| Gate | Condition |
|---|---|
| GO | After Penalty Points = 0 AND no FLAGGED criteria |
| NO-GO | After 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 Type | Verification |
|---|---|
| RFC/Standard reference | MCP Ref search confirms existence |
| Library version | Context7 query confirms version |
| Security requirement | OWASP/CWE reference exists |
| Performance claim | Benchmark/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: (target: 100%)
{covered}/{total} ACs输出明确的映射关系:
| 验收标准 | 对应任务 | 覆盖状态 |
|----|---------|----------|
| 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"
- Phase 1: Load metadata (5 Tasks, status Backlog) 1b. Phase 1b: Health check → launch codex-review + gemini-review in background
- 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)
- Phase 3:
- Show Penalty Points table
- IF Plan Mode: "18 penalty points found. Fix plan ready. Approve?"
- 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
- Phase 5: Merge agent results (launched in Phase 1b) + Claude's findings → verify, debate, apply
- Phase 6: Story -> Todo, tabular report
需求故事: "Create user management API with rate limiting"
- Phase1: 加载元数据(5个子任务,状态为Backlog) 1b. Phase1b: 健康检查 → 后台启动codex-review + gemini-review
- 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分)
- Phase3:
- 展示违规扣分表格
- 若为计划模式:"发现18分违规扣分。修复方案已准备就绪。是否批准?"
- Phase4:
- 修复#6:将Express版本从v4.17升级到v4.19
- 修复#5:添加RFC 7231合规性说明
- 修复#13:添加Guide-05、Guide-06的引用
- 修复#17:ln-002已生成对应文档
- 所有修复完成,违规扣分=0
- Phase5: 合并Agent结果(Phase1b启动的Agent) + Claude的发现结果 → 验证、辩论、应用建议
- Phase6: 需求故事状态更新为Todo,展示表格形式的报告
Template Loading
模板加载
Templates: ,
story_template.mdtask_template_implementation.mdLoading Logic:
- Check if exists in target project
docs/templates/{template}.md - IF NOT EXISTS:
a. Create directory if missing b. Copy
docs/templates/→shared/templates/{template}.mdc. Replace placeholders in the LOCAL copy:docs/templates/{template}.md- → from
{{TEAM_ID}}docs/tasks/kanban_board.md - → "docs" (standard)
{{DOCS_PATH}}
- Use LOCAL copy () for all validation operations
docs/templates/{template}.md
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.mdtask_template_implementation.md加载逻辑:
- 检查目标项目中是否存在
docs/templates/{template}.md - 若不存在:
a. 若目录不存在则创建 b. 将
docs/templates/复制到shared/templates/{template}.mdc. 替换本地副本中的占位符:docs/templates/{template}.md- → 从
{{TEAM_ID}}中提取docs/tasks/kanban_board.md - → "docs"(标准路径)
{{DOCS_PATH}}
- 所有验证操作均使用本地副本()
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: (GO/NO-GO rules, Readiness Score calculation)
references/readiness_scoring.md - Templates (centralized): ,
shared/templates/story_template.mdshared/templates/task_template_implementation.md - Local copies: (in target project)
docs/templates/ - Validation Checklists (Progressive Disclosure):
- (criteria #1-#4)
references/structural_validation.md - (criterion #5)
references/standards_validation.md - (criterion #6)
references/solution_validation.md - (criteria #7-#13)
references/workflow_validation.md - (criteria #14-#15)
references/quality_validation.md - (criteria #18-#19/#19b)
references/dependency_validation.md - (criterion #20)
references/risk_validation.md - (criteria #25-#26)
references/cross_reference_validation.md - (criterion #27)
references/premortem_validation.md - (criteria #16-#17)
references/traceability_validation.md - (pattern registry for ln-002 delegation)
references/domain_patterns.md - (penalty system details)
references/penalty_points.md
- Prevention checklist: (creator-facing mapping of 27 criteria)
shared/references/creation_quality_checklist.md - MANDATORY READ: ,
shared/templates/linear_integration.mdshared/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.mdmodes/context.md - Challenge template:
shared/agents/prompt_templates/challenge_review.md - MCP Ref findings template:
references/mcp_ref_findings_template.md - Context review pipeline: (weight table, stack detection, safety rules for mode=context)
references/context_review_pipeline.md
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 - 最终评估: (GO/NO-GO规则、就绪度得分计算方法)
references/readiness_scoring.md - 集中式模板: 、
shared/templates/story_template.mdshared/templates/task_template_implementation.md - 本地副本: 目标项目中的目录
docs/templates/ - 验证检查清单(渐进式披露):
- (标准项#1-#4)
references/structural_validation.md - (标准项#5)
references/standards_validation.md - (标准项#6)
references/solution_validation.md - (标准项#7-#13)
references/workflow_validation.md - (标准项#14-#15)
references/quality_validation.md - (标准项#18-#19/#19b)
references/dependency_validation.md - (标准项#20)
references/risk_validation.md - (标准项#25-#26)
references/cross_reference_validation.md - (标准项#27)
references/premortem_validation.md - (标准项#16-#17)
references/traceability_validation.md - (ln-002委托的模式注册表)
references/domain_patterns.md - (违规扣分系统详情)
references/penalty_points.md
- 创建质量检查清单: (面向创建者的27项标准映射)
shared/references/creation_quality_checklist.md - 必读文件: 、
shared/templates/linear_integration.mdshared/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.mdmodes/context.md - 辩论模板:
shared/agents/prompt_templates/challenge_review.md - MCP Ref研究结果模板:
references/mcp_ref_findings_template.md - 上下文评审流程: (mode=context模式的权重表、技术栈检测、安全规则)
references/context_review_pipeline.md
版本: 7.0.0
最后更新日期: 2026-02-03