review-code

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review Code

代码评审

Overview

概述

Perform adversarial AI-assisted code review on a pull request or branch changes using Builder/Critic separation with dual-contract validation (Spec + Constitution).

使用Builder/Critic分离模式结合双契约验证（Spec + Constitution），对拉取请求（Pull Request）或分支变更执行AI辅助的对抗式代码评审。

Definitions

定义

{PR_KEY}: Pull Request identifier (e.g.,
```
PR-12
```
,
```
#12
```
,
```
12
```
). Can be specified as:
- Full format:
```
PR-12
```
  or
```
#12
```
- Numeric only:
```
12
```
- The command should accept any format and normalize it for API calls (extract numeric ID)
{BRANCH_NAME}: Branch name to review (e.g.,
```
feat/FB-12
```
,
```
main
```
,
```
develop
```
)
- Can be local branch or remote branch
- Format:
```
{type}/{TASK_KEY}
```
  for feature branches (consistent with other commands)
{FEATURE_DOMAIN}: Kebab-case feature name for Spec lookup (e.g.,
```
user-authentication
```
,
```
skill-audit
```
)
- Determines which Spec to read from
```
specs/{FEATURE_DOMAIN}/spec.md
```
- May be extracted from branch name, PR title, or Jira issue context
PR (Pull Request): A GitHub pull request containing proposed changes to merge into a branch
- Referenced using {PR_KEY} format (e.g., PR-12, #12, or 12)
- Contains changes, metadata, comments, and review history
Branch: A Git branch containing changes to review
- Can be local (checked out in workspace) or remote (on GitHub)
- Referenced using {BRANCH_NAME} format
- For feature branches, follows
```
{type}/{TASK_KEY}
```
  naming convention
Diff: The difference between two versions of code showing additions, deletions, and modifications
- Shows line-by-line changes in files
- Indicates what was added (+), removed (-), or modified
- Essential for understanding the scope of changes
Builder Agent: The agent context that retrieves data, reads files, and packages context (no judgment)
Critic Agent: Fresh context session that performs validation, identifies violations, and judges quality
Spec: Living specification at
```
specs/{FEATURE_DOMAIN}/spec.md
```
containing:
- Blueprint: Context, Architecture, Anti-Patterns (architectural constraints)
- Contract: Definition of Done, Regression Guardrails, Scenarios (behavioral verification)
Constitution: AGENTS.md Operational Boundaries (3-tier system):
- Tier 1 (ALWAYS): Non-negotiable standards (must follow)
- Tier 2 (ASK): High-risk operations requiring human approval
- Tier 3 (NEVER): Safety limits (must not violate)
Dual-Contract Validation: Two-tier validation system:
- Functional Validation: Code meets Spec's Blueprint and Contract
- Architectural Validation: Code meets AGENTS.md Constitution (3-tier system)
Review Gate: Decisional output (PASS/FAIL/WARNING) based on violation severity
- PASS: No critical violations found
- FAIL: Spec CRITICAL violations OR Constitutional Tier 3 violations found
- WARNING: Spec warnings OR Constitutional Tier 2 violations found
Violation Report: Structured report containing:
- Description: What was violated
- Impact: Why it matters (performance, security, maintainability, scalability)
- Remediation: Ordered steps to fix the violation
- Location: File:Line reference
- Reference: Which Spec criterion or Constitutional boundary was violated

{PR_KEY}：拉取请求标识符（例如：
```
PR-12
```
,
```
#12
```
,
```
12
```
）。可通过以下格式指定：
- 完整格式：
```
PR-12
```
  或
```
#12
```
- 纯数字格式：
```
12
```
- 命令应支持任意格式，并将其标准化以适配API调用（提取数字ID）
{BRANCH_NAME}：待评审的分支名称（例如：
```
feat/FB-12
```
,
```
main
```
,
```
develop
```
）
- 可以是本地分支或远程分支
- 特性分支格式：
```
{type}/{TASK_KEY}
```
  （与其他命令保持一致）
{FEATURE_DOMAIN}：用于查找Spec的短横线命名法特性名称（例如：
```
user-authentication
```
,
```
skill-audit
```
）
- 决定从
```
specs/{FEATURE_DOMAIN}/spec.md
```
  读取哪个Spec
- 可从分支名称、PR标题或Jira工单上下文提取
PR (Pull Request)：GitHub上的拉取请求，包含拟合并到分支的变更
- 使用{PR_KEY}格式引用（例如：PR-12, #12, 或12）
- 包含变更内容、元数据、评论和评审历史
Branch：包含待评审变更的Git分支
- 可以是本地分支（已在工作区检出）或远程分支（托管在GitHub）
- 使用{BRANCH_NAME}格式引用
- 特性分支遵循
```
{type}/{TASK_KEY}
```
  命名规范
Diff：两个代码版本之间的差异，显示新增、删除和修改内容
- 逐行展示文件中的变更
- 用+表示新增，-表示删除，标识修改内容
- 是理解变更范围的关键
Builder Agent：负责检索数据、读取文件和打包上下文的代理（不做判断）
Critic Agent：全新上下文会话，负责执行验证、识别违规并评判代码质量
Spec：存储在
```
specs/{FEATURE_DOMAIN}/spec.md
```
的动态规范，包含：
- Blueprint：上下文、架构、反模式（架构约束）
- Contract：完成定义、回归防护规则、场景（行为验证）
Constitution：AGENTS.md中的操作边界（三级体系）：
- Tier 1 (ALWAYS)：不可协商的标准（必须遵守）
- Tier 2 (ASK)：高风险操作，需要人工批准
- Tier 3 (NEVER)：安全限制（绝对不能违反）
双契约验证：双层验证体系：
- 功能验证：代码符合Spec的Blueprint和Contract要求
- 架构验证：代码符合AGENTS.md Constitution的三级体系
评审门禁：基于违规严重程度的决策输出（PASS/FAIL/WARNING）
- PASS：未发现严重违规
- FAIL：发现Spec严重违规或 Constitution Tier 3违规
- WARNING：发现Spec警告或 Constitution Tier 2违规
违规报告：结构化报告，包含：
- 描述：违规内容
- 影响：违规的危害（性能、安全、可维护性、可扩展性）
- 修复方案：有序的修复步骤
- 位置：文件:行号引用
- 参考：违反了哪个Spec准则或Constitution边界

Prerequisites

前置条件

Before proceeding, verify:

MCP Status Validation: GitHub MCP connection required (see
```
mcp-status.md
```
for detailed steps)
- Use GitHub MCP tools to verify connection
- If GitHub MCP connection fails, STOP and report: "GitHub MCP connection failed. Please verify MCP configuration (see mcp-status.md)."
- MCP Tool Usage Standards: MCP tool usage should follow best practices (check schema files, validate parameters, handle errors gracefully). These standards are documented in AGENTS.md §3 Operational Boundaries if AGENTS.md exists, but apply universally regardless.
PR/Branch Existence: Verify {PR_KEY} or {BRANCH_NAME} is valid and accessible
- For PR ({PR_KEY}):
  - Normalize {PR_KEY} format (extract numeric ID from PR-12, #12, or 12)
  - Use GitHub MCP to verify PR exists
  - If PR not found or inaccessible, STOP and report: "Pull Request {PR_KEY} not found or inaccessible."
- For branch ({BRANCH_NAME}):
  - Use GitHub MCP or git commands to check if branch exists
  - If branch not found, STOP and report: "Branch {BRANCH_NAME} not found."
Access Verification: Verify user has access to PR/branch (read permissions)
- Attempt to retrieve PR details or branch information
- If access denied, STOP and report: "Access denied to {PR_KEY} or {BRANCH_NAME}. Please verify permissions."

开始前，请验证以下内容：

MCP状态验证：需要GitHub MCP连接（详细步骤见
```
mcp-status.md
```
）
- 使用GitHub MCP工具验证连接
- 如果GitHub MCP连接失败，请停止操作并报告："GitHub MCP连接失败。请验证MCP配置（详见mcp-status.md）。"
- MCP工具使用标准：MCP工具使用应遵循最佳实践（检查模式文件、验证参数、优雅处理错误）。这些标准记录在AGENTS.md第3节操作边界（如果AGENTS.md存在），但无论是否存在都普遍适用。
PR/分支存在性验证：验证{PR_KEY}或{BRANCH_NAME}有效且可访问
- 对于PR ({PR_KEY})：
  - 标准化{PR_KEY}格式：从PR-12、#12或12中提取数字ID
  - 使用GitHub MCP验证PR存在
  - 如果PR未找到或无法访问，请停止操作并报告："拉取请求{PR_KEY}未找到或无法访问。"
- 对于分支 ({BRANCH_NAME})：
  - 使用GitHub MCP或git命令检查分支是否存在
  - 如果分支未找到，请停止操作并报告："分支{BRANCH_NAME}未找到。"
访问权限验证：验证用户拥有PR/分支的读取权限
- 尝试获取PR详情或分支信息
- 如果访问被拒绝，请停止操作并报告："无法访问{PR_KEY}或{BRANCH_NAME}。请验证权限。"

Steps

步骤

[BUILDER AGENT CONTEXT]

[BUILDER AGENT 上下文]

Retrieve changes
- Determine if PR ({PR_KEY}) or branch ({BRANCH_NAME}):
  - Check if input is a PR format (PR-12, #12, 12) or branch name
  - Decision point: PR vs branch determines which tools to use
- If PR ({PR_KEY}):
  - Normalize {PR_KEY} format: Extract numeric ID from PR-12, #12, or 12
    - Example: PR-12 → 12, #12 → 12, 12 → 12
  - Use GitHub MCP to retrieve PR details, get list of changed files, and get full diff
  - STOP condition: If PR not found or inaccessible, report error and stop
- If branch ({BRANCH_NAME}):
  - Verify branch exists using GitHub MCP or git commands
  - Get diff using
```
run_terminal_cmd
```
    :
```
git diff main...{BRANCH_NAME}
```
  - Get list of changed files using
```
run_terminal_cmd
```
    :
```
git diff --name-only main...{BRANCH_NAME}
```
  - STOP condition: If branch not found, report error and stop
- Read all changed files:
  - Iterate through list of changed files
  - Use
```
read_file
```
    to read each changed file
  - STOP condition: If any file is unreadable or doesn't exist, report warning but continue with available files
- Understand scope of changes:
  - Review file paths to understand which parts of codebase are affected
  - Count lines changed, files changed
  - Identify change types: new files, modifications, deletions
  - Note related files that might need review (tests, documentation)
Determine feature domain and read Spec
- Determine feature domain:
  - Option 1: Extract from branch name format
```
{type}/{TASK_KEY}
```
    (e.g.,
```
feat/FB-39
```
    → fetch FB-39 from Jira to get feature context)
  - Option 2: Extract from PR title or description (look for feature keywords)
  - Option 3: Use
```
glob_file_search
```
    with pattern
```
**/specs/*/spec.md
```
    to list available specs, then prompt user if unclear
  - If unable to determine automatically: List available specs and ask user to specify feature domain
- Read Spec (if exists):
  - Check if
```
specs/{FEATURE_DOMAIN}/spec.md
```
    exists using
```
glob_file_search
```
  - If exists:
    - Use
      read_file
      to read spec file
    - Extract Blueprint section (Context, Architecture, Anti-Patterns)
    - Extract Contract section (Definition of Done, Regression Guardrails, Scenarios)
  - If no spec found:
    - Note: "No Spec available for {FEATURE_DOMAIN} - will validate against Constitution only"
    - Proceed with Constitution-only validation
Read Constitution (if available)
- Check if AGENTS.md exists:
  - Use
```
glob_file_search
```
    or
```
read_file
```
    to check for
```
AGENTS.md
```
    in repo root
  - If AGENTS.md exists:
    - Use
      read_file
      to read
      AGENTS.md
    - Extract Operational Boundaries section:
      - Tier 1 (ALWAYS): Non-negotiable standards
      - Tier 2 (ASK): High-risk operations requiring human approval
      - Tier 3 (NEVER): Safety limits
    - Extract Skill Structure Standards (if reviewing skill file changes)
    - Store for Critic Agent context
  - If AGENTS.md does NOT exist:
    - Log: "⚠️ AGENTS.md not found - Constitutional validation skipped"
    - Store status: "Constitutional Review: SKIPPED (AGENTS.md not found)"
    - Proceed with Spec-only validation (if Spec exists) or minimal validation

获取变更内容
- 判断是PR ({PR_KEY})还是分支 ({BRANCH_NAME})：
  - 检查输入是PR格式（PR-12、#12、12）还是分支名称
  - 决策点：PR或分支决定使用的工具
- 如果是PR ({PR_KEY})：
  - 标准化{PR_KEY}格式：从PR-12、#12或12中提取数字ID
    - 示例：PR-12 → 12, #12 → 12, 12 → 12
  - 使用GitHub MCP获取PR详情、变更文件列表和完整diff
  - 停止条件：如果PR未找到或无法访问，报告错误并停止
- 如果是分支 ({BRANCH_NAME})：
  - 使用GitHub MCP或git命令验证分支存在
  - 使用
```
run_terminal_cmd
```
    执行
```
git diff main...{BRANCH_NAME}
```
    获取diff
  - 使用
```
run_terminal_cmd
```
    执行
```
git diff --name-only main...{BRANCH_NAME}
```
    获取变更文件列表
  - 停止条件：如果分支未找到，报告错误并停止
- 读取所有变更文件：
  - 遍历变更文件列表
  - 使用
```
read_file
```
    读取每个变更文件
  - 停止条件：如果任何文件无法读取或不存在，报告警告但继续处理可用文件
- 理解变更范围：
  - 查看文件路径以了解代码库受影响的部分
  - 统计变更行数、变更文件数
  - 识别变更类型：新文件、修改、删除
  - 记录可能需要评审的相关文件（测试、文档）
确定特性域并读取Spec
- 确定特性域：
  - 选项1：从分支名称格式
```
{type}/{TASK_KEY}
```
    提取（例如：
```
feat/FB-39
```
    → 从Jira获取FB-39的特性上下文）
  - 选项2：从PR标题或描述中提取（查找特性关键词）
  - 选项3：使用
```
glob_file_search
```
    和模式
```
**/specs/*/spec.md
```
    列出可用的Spec，若不明确则提示用户
  - 如果无法自动确定：列出可用的Spec并请用户指定特性域
- 读取Spec（如果存在）：
  - 使用
```
glob_file_search
```
    检查
```
specs/{FEATURE_DOMAIN}/spec.md
```
    是否存在
  - 如果存在：
    - 使用
      read_file
      读取Spec文件
    - 提取Blueprint部分（上下文、架构、反模式）
    - 提取Contract部分（完成定义、回归防护规则、场景）
  - 如果未找到Spec：
    - 记录："{FEATURE_DOMAIN}无可用Spec - 将仅基于Constitution进行验证"
    - 继续执行仅Constitution验证
读取Constitution（如果可用）
- 检查AGENTS.md是否存在：
  - 使用
```
glob_file_search
```
    或
```
read_file
```
    检查仓库根目录是否存在
```
AGENTS.md
```
  - 如果AGENTS.md存在：
    - 使用
      read_file
      读取
      AGENTS.md
    - 提取操作边界部分：
      - Tier 1 (ALWAYS)：不可协商的标准
      - Tier 2 (ASK)：高风险操作，需要人工批准
      - Tier 3 (NEVER)：安全限制
    - 提取Skill结构标准（如果评审Skill文件变更）
    - 存储供Critic Agent使用
  - 如果AGENTS.md不存在：
    - 记录："⚠️ 未找到AGENTS.md - 跳过Constitution验证"
    - 存储状态："Constitution评审：跳过（未找到AGENTS.md）"
    - 继续执行仅Spec验证（如果Spec存在）或最小化验证

[CRITIC AGENT CONTEXT - FRESH SESSION]

[CRITIC AGENT 上下文 - 全新会话]

Invoke Critic Agent for Adversarial Review

Package context for Critic:
- Spec Blueprint + Contract (if exists)
- AGENTS.md Operational Boundaries (Tier 1, Tier 2, Tier 3) - if AGENTS.md exists
- Code diff from Step 1
- Note: If AGENTS.md missing but Spec exists, validate against Spec only. If both missing, perform minimal validation.
- Changed files list
Create fresh context session:
- CRITICAL: Critic Agent must have no bias from implementation
- Use separate conversation or explicit context boundary
- Critic Agent has not seen the implementation process, only the contracts and code

Critic Agent prompt structure:

You are a Critic Agent performing Adversarial Code Review with dual-contract validation.

**Your role**: Validate code against two contracts: Functional (Spec) and Architectural (Constitution). You have NOT been involved in building this code. Provide fresh, unbiased critique.

**Spec Contract** (functional validation):
[If spec exists at specs/{FEATURE_DOMAIN}/spec.md]
### Blueprint
[Paste Context, Architecture, Anti-Patterns sections]

### Contract
[Paste Definition of Done, Regression Guardrails, Scenarios sections]

[If no spec]
No Spec found for this feature - skip functional validation, proceed to Constitutional validation only.

**Constitution** (architectural validation):
[From AGENTS.md Operational Boundaries]
### Tier 1: ALWAYS (Must Follow)
[Paste Tier 1 rules with full descriptions]

### Tier 2: ASK (Require Human Approval)
[Paste Tier 2 rules with full descriptions]

### Tier 3: NEVER (Safety Limits)
[Paste Tier 3 rules with full descriptions]

**Code Changes** (git diff):
[Paste full diff output showing all additions, deletions, modifications]

**Files Changed**:
[List of changed files with paths]

**Task**: Perform dual-contract validation. For each violation found:
1. **Category**: SPEC | CONSTITUTIONAL
2. **Severity**: CRITICAL | WARNING | INFO
   - CRITICAL: Spec violations, Constitutional Tier 3 (NEVER) violations
   - WARNING: Spec warnings, Constitutional Tier 2 (ASK) violations
   - INFO: Spec suggestions, Constitutional Tier 1 (ALWAYS) violations
3. **Description**: What was violated? (specific and clear)
4. **Impact**: Why this matters (performance, security, maintainability, scalability)
5. **Remediation**: Ordered steps to fix the violation (actionable)
6. **Location**: File:Line reference where violation occurs
7. **Reference**: Which Spec Contract criterion or Constitutional Boundary rule was violated

**Output Format** (structured markdown):

## Code Review Report: [PASS | FAIL | WARNING]

### Summary
- Spec Violations: X (Critical: Y, Warning: Z, Info: W)
- Constitutional Violations: X (Critical: Y, Warning: Z, Info: W)
- Gate Decision: PASS | FAIL | WARNING

---

## Spec Contract Violations

### Critical Issues 🔴
[None] OR
1. **Violation**: [Description]
   - **Impact**: [Why this matters]
   - **Remediation**: [Ordered steps to fix]
   - **Location**: [File:Line]
   - **Contract Reference**: [Which DoD/Guardrail/Scenario violated]

### Warnings 🟡
[Similar format for WARNING severity violations]

### Info 🟢
[Similar format for INFO severity violations]

---

## Constitutional Violations

### Tier 3 Violations (CRITICAL - NEVER) 🔴
[None] OR
1. **Violation**: [Description]
   - **Impact**: [Security, safety, or anti-pattern concern]
   - **Remediation**: [Ordered steps to fix]
   - **Location**: [File:Line]
   - **Boundary Reference**: [Which NEVER rule violated]

### Tier 2 Violations (WARNING - ASK) 🟡
[Similar format for Tier 2 violations]

### Tier 1 Violations (INFO - ALWAYS) 🟢
[Similar format for Tier 1 violations]

---

## Recommendation

**[APPROVE | REQUEST CHANGES | COMMENT]**

Rationale: [Explanation based on violations found]

Model routing:
- Use reasoning-optimized model if available (e.g., o1, o3-mini for cost-effective reasoning)
- Fallback to standard model if reasoning model unavailable
- Note: Reasoning models excel at adversarial validation tasks

调用Critic Agent执行对抗式评审

为Critic打包上下文：
- Spec Blueprint + Contract（如果存在）
- AGENTS.md操作边界（Tier 1、Tier 2、Tier 3）- 如果AGENTS.md存在
- 步骤1中的代码diff
- 注意：如果AGENTS.md缺失但Spec存在，仅基于Spec验证。如果两者都缺失，执行最小化验证。
- 变更文件列表
创建全新上下文会话：
- 关键要求：Critic Agent必须不受实现过程的影响
- 使用独立对话或明确的上下文边界
- Critic Agent未参与实现过程，仅能看到契约和代码

Critic Agent提示结构：

你是执行对抗式代码评审的Critic Agent，采用双契约验证机制。

**你的角色**：验证代码是否符合两个契约：功能契约（Spec）和架构契约（Constitution）。你未参与此代码的实现工作，请提供客观、无偏见的评审意见。

**Spec契约**（功能验证）：
[如果specs/{FEATURE_DOMAIN}/spec.md存在]
### Blueprint
[粘贴上下文、架构、反模式部分]

### Contract
[粘贴完成定义、回归防护规则、场景部分]

[如果无spec]
未找到此特性的Spec - 跳过功能验证，仅执行Constitution验证。

**Constitution**（架构验证）：
[来自AGENTS.md操作边界]
### Tier 1: ALWAYS（必须遵守）
[粘贴Tier 1规则及完整描述]

### Tier 2: ASK（需要人工批准）
[粘贴Tier 2规则及完整描述]

### Tier 3: NEVER（安全限制）
[粘贴Tier 3规则及完整描述]

**代码变更**（git diff）：
[粘贴完整diff输出，显示所有新增、删除和修改内容]

**变更文件**：
[变更文件路径列表]

**任务**：执行双契约验证。对于每个发现的违规：
1. **类别**：SPEC | CONSTITUTIONAL
2. **严重程度**：CRITICAL | WARNING | INFO
   - CRITICAL：Spec严重违规、Constitution Tier 3（NEVER）违规
   - WARNING：Spec警告、Constitution Tier 2（ASK）违规
   - INFO：Spec建议、Constitution Tier 1（ALWAYS）违规
3. **描述**：违规内容（具体清晰）
4. **影响**：违规的危害（性能、安全、可维护性、可扩展性）
5. **修复方案**：有序的修复步骤（可执行）
6. **位置**：文件:行号引用
7. **参考**：违反了哪个Spec契约准则或Constitution边界规则

**输出格式**（结构化Markdown）：

## 代码评审报告：[PASS | FAIL | WARNING]

### 摘要
- Spec违规：X（严重：Y，警告：Z，提示：W）
- Constitution违规：X（严重：Y，警告：Z，提示：W）
- 门禁决策：PASS | FAIL | WARNING

---

## Spec契约违规

### 严重问题 🔴
[无] 或
1. **违规**：[描述]
   - **影响**：[危害说明]
   - **修复方案**：[有序修复步骤]
   - **位置**：[文件:行号]
   - **契约参考**：[违反的完成定义/防护规则/场景]

### 警告 🟡
[WARNING严重程度违规的类似格式]

### 提示 🟢
[INFO严重程度违规的类似格式]

---

## Constitution违规

### Tier 3违规（严重 - NEVER）🔴
[无] 或
1. **违规**：[描述]
   - **影响**：[安全、合规或反模式问题]
   - **修复方案**：[有序修复步骤]
   - **位置**：[文件:行号]
   - **边界参考**：[违反的NEVER规则]

### Tier 2违规（警告 - ASK）🟡
[Tier 2违规的类似格式]

### Tier 1违规（提示 - ALWAYS）🟢
[Tier 1违规的类似格式]

---

## 建议

**[批准 | 请求变更 | 评论]**

理由：[基于发现的违规的解释]

模型选择：
- 如果可用，使用推理优化模型（例如：o1、o3-mini，兼顾成本和推理能力）
- 如果推理模型不可用，回退到标准模型
- 注意：推理模型在对抗式验证任务中表现更优

[BUILDER AGENT CONTEXT]

[BUILDER AGENT 上下文]

Parse violations and make gate decision
- Parse Critic output:
  - Extract Spec violations (if Spec exists):
    - Categorize by severity: CRITICAL/WARNING/INFO
    - Extract description, impact, remediation, location, contract reference
    - Count violations by severity
  - Extract Constitutional violations:
    - Categorize by tier: Tier 3 (CRITICAL), Tier 2 (WARNING), Tier 1 (INFO)
    - Extract description, impact, remediation, location, boundary reference
    - Count violations by tier
- Count total violations:
  - Spec: Critical, Warning, Info counts
  - Constitutional: Tier 3, Tier 2, Tier 1 counts
- Gate Decision Logic:
  - FAIL if:
    - Spec CRITICAL violations found (functional contract broken) OR
    - Constitutional Tier 3 (NEVER) violations found (safety limits violated) - only if AGENTS.md exists
  - WARNING if:
    - Spec WARNING violations found (functional concerns) OR
    - Constitutional Tier 2 (ASK) violations found (human approval required) - only if AGENTS.md exists
  - PASS if:
    - Only Spec INFO violations OR
    - Only Constitutional Tier 1 (ALWAYS) violations OR
    - No violations found
    - Note: If AGENTS.md doesn't exist, validate against Spec only (if exists) or perform minimal validation
- Validation of Critic output:
  - If Critic output is unparseable or malformed:
    - WARN user about parsing failure
    - Ask to retry or provide emergency override option
    - Do not fail silently
Generate review report
- Use structured format from Critic Agent:
  - Report header: "Code Review Report: [PASS | FAIL | WARNING]"
  - Summary section:
    - Total violations by category (Spec + Constitutional)
    - Violation counts by severity
    - Gate decision with rationale
  - Spec Contract Violations section (if Spec exists):
    - Critical Issues 🔴 (Spec CRITICAL violations)
    - Warnings 🟡 (Spec WARNING violations)
    - Info 🟢 (Spec INFO violations)
  - Constitutional Violations section:
    - Tier 3 (CRITICAL - NEVER) 🔴
    - Tier 2 (WARNING - ASK) 🟡
    - Tier 1 (INFO - ALWAYS) 🟢
  - Recommendation section:
    - APPROVE (PASS) - No critical violations, ready to merge
    - REQUEST CHANGES (FAIL) - Critical violations must be fixed
    - COMMENT (WARNING) - Warnings flagged, human decision required
  - Each violation includes:
    - Description (what was violated)
    - Impact (why it matters)
    - Remediation steps (how to fix)
    - Location (File:Line)
    - Reference (Spec criterion or Constitutional boundary)
- Backward compatibility:
  - If no Spec exists and no Constitutional violations: Include general code quality observations
  - If parsing Critic output fails: Fall back to basic review with clear error message

解析违规并做出门禁决策
- 解析Critic输出：
  - 提取Spec违规（如果Spec存在）：
    - 按严重程度分类：CRITICAL/WARNING/INFO
    - 提取描述、影响、修复方案、位置、契约参考
    - 按严重程度统计违规数量
  - 提取Constitution违规：
    - 按层级分类：Tier 3（CRITICAL）、Tier 2（WARNING）、Tier 1（INFO）
    - 提取描述、影响、修复方案、位置、边界参考
    - 按层级统计违规数量
- 统计总违规数：
  - Spec：严重、警告、提示数量
  - Constitution：Tier 3、Tier 2、Tier 1数量
- 门禁决策逻辑：
  - FAIL 如果：
    - 发现Spec严重违规或
    - 发现Constitution Tier 3（NEVER）违规 - 仅当AGENTS.md存在时
  - WARNING 如果：
    - 发现Spec警告违规或
    - 发现Constitution Tier 2（ASK）违规 - 仅当AGENTS.md存在时
  - PASS 如果：
    - 仅存在Spec提示违规或
    - 仅存在Constitution Tier 1（ALWAYS）违规或
    - 未发现违规
    - 注意：如果AGENTS.md不存在，仅基于Spec验证（如果存在）或执行最小化验证
- 验证Critic输出：
  - 如果Critic输出无法解析或格式错误：
    - 向用户警告解析失败
    - 询问是否重试或提供紧急覆盖选项
    - 不得静默失败
生成评审报告
- 使用Critic Agent指定的结构化格式：
  - 报告标题："代码评审报告：[PASS | FAIL | WARNING]"
  - 摘要部分：
    - 按类别统计总违规数（Spec + Constitution）
    - 按严重程度统计违规数
    - 门禁决策及理由
  - Spec契约违规部分（如果Spec存在）：
    - 严重问题 🔴（Spec CRITICAL违规）
    - 警告 🟡（Spec WARNING违规）
    - 提示 🟢（Spec INFO违规）
  - Constitution违规部分：
    - Tier 3（严重 - NEVER）🔴
    - Tier 2（警告 - ASK）🟡
    - Tier 1（提示 - ALWAYS）🟢
  - 建议部分：
    - 批准（PASS）- 无严重违规，可合并
    - 请求变更（FAIL）- 必须修复严重违规
    - 评论（WARNING）- 已标记警告，需人工决策
  - 每个违规包含：
    - 描述（违规内容）
    - 影响（违规危害）
    - 修复步骤（修复方法）
    - 位置（文件:行号）
    - 参考（Spec准则或Constitution边界）
- 向后兼容性：
  - 如果无Spec且无Constitution违规：包含通用代码质量建议
  - 如果解析Critic输出失败：回退到基础评审并显示清晰的错误信息

Tools

工具

MCP Tools (GitHub)

MCP工具（GitHub）

GitHub MCP tools - Verify GitHub MCP connection and retrieve PR/branch information
- Use to validate GitHub MCP is configured and accessible
- Use to retrieve PR details, changed files, and diffs
- If connection fails, STOP workflow - GitHub MCP is required for PR operations

GitHub MCP工具 - 验证GitHub MCP连接并获取PR/分支信息
- 用于验证GitHub MCP已配置且可访问
- 用于获取PR详情、变更文件和diff
- 如果连接失败，停止工作流 - PR操作需要GitHub MCP

MCP Tools (Atlassian)

MCP工具（Atlassian）

```
getJiraIssue
```
- Fetch Jira issue details (if extracting feature domain from task key)
- Parameters:
```
cloudId
```
  ,
```
issueIdOrKey
```
  = {TASK_KEY}
- Use to extract feature context when branch name is
```
{type}/{TASK_KEY}
```

```
getJiraIssue
```
- 获取Jira工单详情（如果从任务键提取特性域）
- 参数：
```
cloudId
```
  ,
```
issueIdOrKey
```
  = {TASK_KEY}
- 当分支名称为
```
{type}/{TASK_KEY}
```
  格式时，用于提取特性上下文

Codebase Tools

代码库工具

```
codebase_search
```
- Find related code and understand context
- Query: "How is [similar feature] implemented?"
- Query: "Where is [component] used?"
- Query: "What are the patterns for [error handling/testing/API design] in this codebase?"
- Use to understand codebase patterns, find similar implementations, and ensure consistency

```
codebase_search
```
- 查找相关代码并理解上下文
- 查询："[类似特性]是如何实现的？"
- 查询："[组件]在哪里使用？"
- 查询："此代码库中[错误处理/测试/API设计]的模式是什么？"
- 用于理解代码库模式、查找类似实现并确保一致性

Filesystem Tools

文件系统工具

```
read_file
```
- Read changed files, Spec, and Constitution
- Read changed code files for full context
- Read
```
specs/{FEATURE_DOMAIN}/spec.md
```
  (if exists)
- Read
```
AGENTS.md
```
  for Operational Boundaries
```
glob_file_search
```
- Find available specs
- Pattern:
```
**/specs/*/spec.md
```
  - List all available specs
- Use to help determine feature domain or list options for user

```
read_file
```
- 读取变更文件、Spec和Constitution
- 读取变更代码文件以获取完整上下文
- 读取
```
specs/{FEATURE_DOMAIN}/spec.md
```
  （如果存在）
- 读取
```
AGENTS.md
```
  获取操作边界
```
glob_file_search
```
- 查找可用的Spec
- 模式：
```
**/specs/*/spec.md
```
  - 列出所有可用的Spec
- 用于帮助确定特性域或为用户列出选项

Terminal Tools

终端工具

```
run_terminal_cmd
```
- Execute git commands for branch operations
- ```
git branch -a
```
  - List all branches (local and remote)
- ```
git diff main...{BRANCH_NAME}
```
  - Get diff between main and branch
- ```
git diff --name-only main...{BRANCH_NAME}
```
  - List changed files between main and branch
- ```
git log {BRANCH_NAME} ^main
```
  - View commit history on branch

```
run_terminal_cmd
```
- 执行git命令进行分支操作
- ```
git branch -a
```
  - 列出所有分支（本地和远程）
- ```
git diff main...{BRANCH_NAME}
```
  - 获取main分支与目标分支的diff
- ```
git diff --name-only main...{BRANCH_NAME}
```
  - 列出main分支与目标分支的变更文件
- ```
git log {BRANCH_NAME} ^main
```
  - 查看目标分支的提交历史

Pre-flight Checklist

预检清单

MCP status validation performed (GitHub MCP connection verified, see
```
mcp-status.md
```
)
PR ({PR_KEY}) or branch ({BRANCH_NAME}) is accessible and exists
{PR_KEY} normalized to numeric ID if PR review (extract from PR-12, #12, or 12)
Changed files retrieved and readable
Scope of changes understood (file count, line count, change types)
Feature domain determined (for Spec lookup)
Spec read (if exists) - Blueprint and Contract sections extracted
Constitution read (AGENTS.md Operational Boundaries extracted)
Critic Agent context packaged (Spec + Constitution + Code diff)

已执行MCP状态验证（已验证GitHub MCP连接，详见
```
mcp-status.md
```
）
PR ({PR_KEY})或分支 ({BRANCH_NAME})可访问且存在
如果是PR评审，{PR_KEY}已标准化为数字ID（从PR-12、#12或12中提取）
已获取变更文件且可读取
已理解变更范围（文件数、行数、变更类型）
已确定特性域（用于查找Spec）
已读取Spec（如果存在）- 已提取Blueprint和Contract部分
已读取Constitution（已提取AGENTS.md操作边界）
已为Critic Agent打包上下文（Spec + Constitution + 代码diff）

Review Checklist

评审清单

Guidance

指南

Role

角色

Act as a Builder Agent responsible for orchestrating adversarial code review. You retrieve context, package information, and coordinate with the Critic Agent. You are systematic, thorough, and enforce the Review Gate pattern with dual-contract validation.

作为负责协调对抗式代码评审的Builder Agent。你需要检索上下文、打包信息并与Critic Agent协作。工作需系统、全面，并通过双契约验证执行评审门禁模式。

Instruction

指令

Execute the adversarial review-code workflow to perform comprehensive code review with dual-contract validation. This includes:

Retrieving PR/branch changes and understanding scope
Determining feature domain and reading Spec (if exists)
Reading Constitution (AGENTS.md Operational Boundaries)
Packaging context for Critic Agent (no judgment at this stage)
Invoking Critic Agent in fresh context session for validation
Parsing Critic output and categorizing violations
Making gate decision (PASS/FAIL/WARNING) based on violation severity
Generating structured review report with remediation paths

执行对抗式代码评审工作流，通过双契约验证完成全面代码评审。包括：

获取PR/分支变更并理解范围
确定特性域并读取Spec（如果存在）
读取Constitution（AGENTS.md操作边界）
为Critic Agent打包上下文（此阶段不做判断）
在全新上下文会话中调用Critic Agent执行验证
解析Critic输出并分类违规
基于违规严重程度做出门禁决策（PASS/FAIL/WARNING）
生成包含修复方案的结构化评审报告

Context

上下文

Adversarial Code Review: Builder/Critic separation prevents implementation bias
Fresh Context Session: Critic Agent has no knowledge of implementation, only contracts and code
Dual-Contract Validation: Functional (Spec) + Architectural (Constitution) validation
Review Gate: PASS/FAIL/WARNING decisions, not just suggestions
Spec (if exists): Permanent living specification at
```
specs/{FEATURE_DOMAIN}/spec.md
```
Constitution: AGENTS.md Operational Boundaries (3-tier system)
Backward Compatible: Works without Spec (Constitution-only validation)
Model Routing: Prefer reasoning models (o1, o3-mini) for Critic Agent if available
The review may be for a GitHub Pull Request ({PR_KEY}) or a local/remote branch ({BRANCH_NAME})
{PR_KEY} can be specified in multiple formats (PR-12, #12, or 12) and should be normalized to numeric ID
{BRANCH_NAME} follows
```
{type}/{TASK_KEY}
```
format for feature branches (consistent with other commands)
GitHub MCP integration provides access to PR data, diffs, and file lists
ASDLC patterns: Adversarial Code Review, Constitutional Review, The Spec
ASDLC pillars: Quality Control (Review Gate, dual-contract validation)

对抗式代码评审：Builder/Critic分离避免实现偏见
全新上下文会话：Critic Agent不了解实现过程，仅能看到契约和代码
双契约验证：功能（Spec）+ 架构（Constitution）验证
评审门禁：PASS/FAIL/WARNING决策，而非仅建议
Spec（如果存在）：存储在
```
specs/{FEATURE_DOMAIN}/spec.md
```
的动态规范
Constitution：AGENTS.md操作边界（三级体系）
向后兼容：无Spec时可正常工作（仅Constitution验证）
模型选择：如果可用，优先为Critic Agent使用推理模型（o1、o3-mini）
评审对象可以是GitHub拉取请求 ({PR_KEY}) 或本地/远程分支 ({BRANCH_NAME})
{PR_KEY}可通过多种格式指定（PR-12、#12或12），需标准化为数字ID
特性分支{BRANCH_NAME}遵循
```
{type}/{TASK_KEY}
```
格式（与其他命令一致）
GitHub MCP集成提供PR数据、diff和文件列表访问
ASDLC模式：对抗式代码评审、Constitution评审、The Spec
ASDLC支柱：质量控制（评审门禁、双契约验证）

Examples

示例

ASDLC: Adversarial Code Review and Constitutional Review — Critic Agent validates against Spec and Constitution in a fresh context.

Example 1: Review Pull Request with Spec Validation

Input: /review-code PR-12
Process:
1. Normalize PR-12 to numeric ID: 12
2. Use GitHub MCP to get PR details, changed files, and diff
3. Determine feature domain from PR title/branch (e.g., "user-authentication")
4. Read specs/user-authentication/spec.md (Blueprint + Contract)
5. Read AGENTS.md Operational Boundaries
6. Package context for Critic Agent
7. Invoke Critic Agent in fresh context (dual-contract validation)
8. Parse Critic output: Spec violations + Constitutional violations
9. Make gate decision: FAIL if CRITICAL violations or Tier 3 violations
10. Generate structured review report with remediation paths

Example 2: Review Branch without Spec (Constitution-only)

Input: /review-code feat/FB-12
Process:
1. Verify branch exists using git commands
2. Get diff using git diff main...feat/FB-12
3. Get changed files using git diff --name-only
4. Attempt to determine feature domain, no spec found
5. Read AGENTS.md Operational Boundaries
6. Package context for Critic Agent (Constitution only)
7. Invoke Critic Agent for Constitutional validation
8. Parse Critic output: Constitutional violations only
9. Make gate decision based on Constitutional violations
10. Generate review report noting "No Spec - validated against Constitution only"

Example 3: Adversarial Review Report Format (FAIL)

undefined

ASDLC：对抗式代码评审和Constitution评审 — Critic Agent在全新上下文中基于Spec和Constitution执行验证。

示例1：基于Spec验证的拉取请求评审

输入：/review-code PR-12
流程：
1. 将PR-12标准化为数字ID：12
2. 使用GitHub MCP获取PR详情、变更文件和diff
3. 从PR标题/分支确定特性域（例如："user-authentication"）
4. 读取specs/user-authentication/spec.md（Blueprint + Contract）
5. 读取AGENTS.md操作边界
6. 为Critic Agent打包上下文
7. 在全新上下文中调用Critic Agent（双契约验证）
8. 解析Critic输出：Spec违规 + Constitution违规
9. 做出门禁决策：如果存在严重违规或Tier 3违规则标记为FAIL
10. 生成包含修复方案的结构化评审报告

示例2：无Spec的分支评审（仅Constitution验证）

输入：/review-code feat/FB-12
流程：
1. 使用git命令验证分支存在
2. 使用git diff main...feat/FB-12获取diff
3. 使用git diff --name-only获取变更文件
4. 尝试确定特性域，未找到Spec
5. 读取AGENTS.md操作边界
6. 为Critic Agent打包上下文（仅Constitution）
7. 调用Critic Agent执行Constitution验证
8. 解析Critic输出：仅Constitution违规
9. 基于Constitution违规做出门禁决策
10. 生成评审报告并注明"无Spec - 仅基于Constitution验证"

示例3：对抗式评审报告格式（FAIL）

undefined

Code Review Report: FAIL

代码评审报告：FAIL

Summary

摘要

Spec Violations: 2 (Critical: 1, Warning: 1, Info: 0)
Constitutional Violations: 1 (Critical: 1, Warning: 0, Info: 0)
Gate Decision: FAIL

Spec违规：2（严重：1，警告：1，提示：0）
Constitution违规：1（严重：1，警告：0，提示：0）
门禁决策：FAIL

Spec Contract Violations

Spec契约违规

Critical Issues 🔴

严重问题 🔴

Violation: Missing input validation for user-provided OAuth callback URL
- Impact: Security vulnerability - allows open redirect attacks
- Remediation:
  1. Add URL validation in auth/service.ts
  2. Whitelist allowed callback domains
  3. Reject URLs not matching whitelist pattern
- Location: src/auth/service.ts:45
- Contract Reference: Definition of Done - "OAuth2 flow validates callback URLs"

违规：用户提供的OAuth回调URL缺少输入验证
- 影响：安全漏洞 - 允许开放重定向攻击
- 修复方案：
  1. 在auth/service.ts中添加URL验证
  2. 白名单允许的回调域名
  3. 拒绝不符合白名单模式的URL
- 位置：src/auth/service.ts:45
- 契约参考：完成定义 - "OAuth2流需验证回调URL"

Warnings 🟡

警告 🟡

Violation: Session timeout not configurable as specified
- Impact: Hardcoded 24-hour timeout doesn't match spec's "configurable timeout"
- Remediation:
  1. Extract timeout to configuration file
  2. Add environment variable SESSION_TIMEOUT_HOURS
  3. Update session creation to use config value
- Location: src/auth/session.ts:12
- Contract Reference: Blueprint Architecture - "Session management must be configurable"

违规：会话超时不可配置，不符合Spec要求
- 影响：硬编码的24小时超时不符合Spec的"可配置超时"要求
- 修复方案：
  1. 将超时配置提取到配置文件
  2. 添加环境变量SESSION_TIMEOUT_HOURS
  3. 更新会话创建逻辑以使用配置值
- 位置：src/auth/session.ts:12
- 契约参考：Blueprint架构 - "会话管理必须可配置"

Constitutional Violations

Constitution违规

Tier 3 Violations (CRITICAL - NEVER) 🔴

Tier 3违规（严重 - NEVER）🔴

Violation: Hardcoded API client secret in source code
- Impact: Security violation - credentials exposed in version control
- Remediation:
  1. Remove hardcoded secret from auth/config.ts
  2. Add OAUTH_CLIENT_SECRET to .env file
  3. Load secret from environment variable
  4. Add .env to .gitignore if not already present
- Location: src/auth/config.ts:8
- Boundary Reference: Tier 3 - "NEVER commit secrets, API keys, tokens, or .env files"

违规：源代码中硬编码API客户端密钥
- 影响：安全违规 - 凭据暴露在版本控制中
- 修复方案：
  1. 从auth/config.ts中移除硬编码密钥
  2. 将OAUTH_CLIENT_SECRET添加到.env文件
  3. 从环境变量加载密钥
  4. 如果.env未在.gitignore中，将其添加
- 位置：src/auth/config.ts:8
- 边界参考：Tier 3 - "绝对不能提交密钥、API密钥、令牌或.env文件"

Recommendation

建议

REQUEST CHANGES

Rationale: Code contains critical security violations (Spec: open redirect vulnerability, Constitution: hardcoded secret). These must be fixed before merging. The session timeout configuration issue should also be addressed to meet spec requirements.


**Example 4: Adversarial Review Report Format (PASS)**

请求变更

理由：代码包含严重安全违规（Spec：开放重定向漏洞，Constitution：硬编码密钥）。合并前必须修复这些问题。还应解决会话超时配置问题以满足Spec要求。


**示例4：对抗式评审报告格式（PASS）**

Code Review Report: PASS

代码评审报告：PASS

Summary

摘要

Spec Violations: 0 (Critical: 0, Warning: 0, Info: 1)
Constitutional Violations: 0 (Critical: 0, Warning: 0, Info: 1)
Gate Decision: PASS

Spec违规：0（严重：0，警告：0，提示：1）
Constitution违规：0（严重：0，警告：0，提示：1）
门禁决策：PASS

Spec Contract Violations

Spec契约违规

Info 🟢

提示 🟢

Violation: Test coverage could include edge case for expired tokens
- Impact: Minor - improves test robustness but not required by spec
- Remediation: Add test case for token expiration edge case in auth.test.ts
- Location: tests/auth.test.ts
- Contract Reference: Scenarios - Token expiration scenario could be more comprehensive

违规：测试覆盖率可包含过期令牌的边缘情况
- 影响：轻微 - 可提高测试健壮性，但非Spec强制要求
- 修复方案：在auth.test.ts中添加令牌过期边缘情况的测试用例
- 位置：tests/auth.test.ts
- 契约参考：场景 - 令牌过期场景可更全面

Constitutional Violations

Constitution违规

Tier 1 Violations (INFO - ALWAYS) 🟢

Tier 1违规（提示 - ALWAYS）🟢

Violation: Missing JSDoc comment on public validateToken function
- Impact: Documentation - reduces code clarity but not a blocker
- Remediation: Add JSDoc comment describing parameters, return value, and throws
- Location: auth/validator.ts:23
- Boundary Reference: Tier 1 - Documentation must use proper formatting

违规：公共validateToken函数缺少JSDoc注释
- 影响：文档问题 - 降低代码清晰度，但不阻塞合并
- 修复方案：添加描述参数、返回值和异常的JSDoc注释
- 位置：auth/validator.ts:23
- 边界参考：Tier 1 - 文档必须使用正确格式

Recommendation

建议

APPROVE

Rationale: No critical or warning-level violations found. Code meets Spec Contract requirements and respects Constitutional boundaries. Minor documentation improvements suggested but not blocking.


**Example 5: {PR_KEY} Normalization**

Input formats and normalization:

PR-12 → 12 (extract numeric ID)
#12 → 12 (remove # prefix)
12 → 12 (already numeric) All formats result in pullNumber=12 for API calls

undefined

批准

理由：未发现严重或警告级违规。代码符合Spec契约要求并遵守Constitution边界。仅建议轻微的文档改进，不阻塞合并。


**示例5：{PR_KEY}标准化**

输入格式及标准化结果：

PR-12 → 12（提取数字ID）
#12 → 12（移除#前缀）
12 → 12（已为数字格式）所有格式最终都使用pullNumber=12进行API调用

undefined

Constraints

约束

Rules (Must Follow):

Operational Standards Compliance: This command follows operational standards (documented in AGENTS.md if present, but apply universally):
- MCP Tool Usage: Check schema files, validate parameters, handle errors gracefully
- Safety Limits: Never commit secrets, API keys, or sensitive data in review reports
- AGENTS.md Optional: If AGENTS.md exists, Constitutional validation is performed. If missing, validate against Spec only or perform minimal validation.
- See AGENTS.md §3 Operational Boundaries (if present) for detailed standards
Fresh Context Requirement: Critic Agent MUST use separate context session with no implementation bias. Builder Agent packages context, Critic Agent validates.
Dual-Contract Validation: Validate against BOTH Spec (if exists) and AGENTS.md Constitution. Never validate against only one when both are available.
Gate Decision Logic:
- FAIL on Spec CRITICAL violations OR Constitutional Tier 3 violations
- WARNING on Spec WARNING violations OR Constitutional Tier 2 violations
- PASS on Spec INFO violations OR Constitutional Tier 1 violations OR no violations
Structured Violation Reports: Every violation MUST include: Description, Impact, Remediation, Location, Reference.
Backward Compatibility: Works without Spec (Constitution-only validation). Never fail if Spec doesn't exist.
MCP Validation: GitHub MCP connection is required. If validation fails, STOP and report the failure (see
```
mcp-status.md
```
).
{PR_KEY} Normalization: Always normalize {PR_KEY} to numeric ID (extract from PR-12, #12, or 12 format) before making API calls.
Reasoning Model Preference: Use reasoning-optimized model (o1, o3-mini) for Critic Agent if available. These models excel at adversarial validation.
No Implementation Bias: Critic Agent must NOT have access to implementation history, discussions, or rationale. Only contracts and code.
Actionable Remediation: Every violation must include specific, ordered steps to fix. No vague suggestions like "improve code quality."

Existing Standards (Reference):

MCP status validation: See
```
mcp-status.md
```
for detailed MCP server connection checks
Spec structure: See
```
specs/README.md
```
for Blueprint + Contract format
Constitution: See
```
AGENTS.md
```
Operational Boundaries for 3-tier system
Branch naming: Type prefix format (
```
{type}/{TASK_KEY}
```
) as shown in
```
start-task.md
```
ASDLC patterns: Adversarial Code Review, Constitutional Review, Context Gates, The Spec, Agent Constitution

必须遵守的规则：

操作标准合规：此命令遵循操作标准（如果AGENTS.md存在则记录在其中，但普遍适用）：
- MCP工具使用：检查模式文件、验证参数、优雅处理错误
- 安全限制：绝不在评审报告中提交密钥、API密钥或敏感数据
- AGENTS.md可选：如果AGENTS.md存在，执行Constitution验证。如果缺失，仅基于Spec验证或执行最小化验证。
- 详细标准见AGENTS.md第3节操作边界（如果存在）
全新上下文要求：Critic Agent必须使用独立上下文会话，不受实现偏见影响。Builder Agent负责打包上下文，Critic Agent负责验证。
双契约验证：当Spec和AGENTS.md Constitution都存在时，必须同时基于两者验证，不得仅验证其中一个。
门禁决策逻辑：
- 发现Spec严重违规或Constitution Tier 3违规时标记为FAIL
- 发现Spec警告违规或Constitution Tier 2违规时标记为WARNING
- 仅存在Spec提示违规、Constitution Tier 1违规或无违规时标记为PASS
结构化违规报告：每个违规必须包含：描述、影响、修复方案、位置、参考。
向后兼容性：无Spec时可正常工作（仅Constitution验证）。不得因Spec不存在而失败。
MCP验证：需要GitHub MCP连接。如果验证失败，停止操作并报告失败（详见
```
mcp-status.md
```
）。
{PR_KEY}标准化：在进行API调用前，必须将{PR_KEY}标准化为数字ID（从PR-12、#12或12格式中提取）。
推理模型优先：如果可用，为Critic Agent使用推理优化模型（o1、o3-mini）。这些模型在对抗式验证任务中表现更优。
无实现偏见：Critic Agent不得访问实现历史、讨论或理由。仅能看到契约和代码。
可执行修复方案：每个违规必须包含具体、有序的修复步骤。不得使用模糊建议如"提高代码质量"。

现有标准（参考）：

MCP状态验证：详见
```
mcp-status.md
```
中的MCP服务器连接检查步骤
Spec结构：详见
```
specs/README.md
```
中的Blueprint + Contract格式
Constitution：详见AGENTS.md操作边界的三级体系
分支命名：
```
start-task.md
```
中所示的类型前缀格式（
```
{type}/{TASK_KEY}
```
）
ASDLC模式：对抗式代码评审、Constitution评审、上下文门禁、The Spec、Agent Constitution

Output

输出

Review Report: Comprehensive report containing:
- Summary: Gate decision (PASS/FAIL/WARNING) with violation counts
- Spec Contract Violations section (if Spec exists):
  - Critical Issues 🔴 (Spec CRITICAL)
  - Warnings 🟡 (Spec WARNING)
  - Info 🟢 (Spec INFO)
- Constitutional Violations section:
  - Tier 3 (CRITICAL - NEVER) 🔴
  - Tier 2 (WARNING - ASK) 🟡
  - Tier 1 (INFO - ALWAYS) 🟢
- Each violation includes:
  - Description (what was violated)
  - Impact (why it matters)
  - Remediation (ordered steps to fix)
  - Location (File:Line)
  - Reference (Spec criterion or Constitutional boundary)
- Recommendation: APPROVE/REQUEST CHANGES/COMMENT with rationale
Gate Decision: Clear PASS/FAIL/WARNING decision based on violation severity
Actionable Remediation: Specific steps to fix all violations

评审报告：全面报告包含：
- 摘要：门禁决策（PASS/FAIL/WARNING）及违规统计
- Spec契约违规部分（如果Spec存在）：
  - 严重问题 🔴（Spec严重违规）
  - 警告 🟡（Spec警告违规）
  - 提示 🟢（Spec提示违规）
- Constitution违规部分：
  - Tier 3（严重 - NEVER）🔴
  - Tier 2（警告 - ASK）🟡
  - Tier 1（提示 - ALWAYS）🟢
- 每个违规包含：
  - 描述（违规内容）
  - 影响（违规危害）
  - 修复方案（修复步骤）
  - 位置（文件:行号）
  - 参考（Spec准则或Constitution边界）
- 建议：批准/请求变更/评论及理由
门禁决策：基于违规严重程度的清晰PASS/FAIL/WARNING决策
可执行修复方案：所有违规的具体修复步骤