ai-sdlc-code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

ai-sdlc-code-review: Code Review

ai-sdlc-code-review：代码审查

Internal AI SDLC skill, not client-facing by default. Every rule below is important to follow. None of it can be skipped. Before producing the final artifact, confirm required inputs, target audience, missing facts, output format, and constraints when they are unclear. Do not invent missing information. Ask concise clarification questions when required inputs are absent.

内部AI SDLC技能，默认不面向客户。以下每条规则都必须遵守，不可跳过任何一条。在生成最终成果前，若对必填输入项、目标受众、缺失信息、输出格式或约束条件存在疑问，需先确认清楚。不得编造缺失信息。当必填输入项缺失时，需提出简洁的澄清问题。

0. Skill Card

0. 技能卡片

Skill name:
```
ai-sdlc-code-review
```
Primary audience: Dev
Supporting audience: QA, BA, Security
Audience tags: Dev, QA, BA
SDLC stage: Code review quality gate
Purpose: Review AI SDLC code, diffs, branches, commits, or completed implementations for correctness, regressions, contract drift, missing tests, SDD drift, and material maintainability risks.
Output: Findings-first review with severity, path, impact, fix, validation gaps, and residual risk

技能名称：
```
ai-sdlc-code-review
```
主要受众：开发人员（Dev）
支持受众：测试人员（QA）、业务分析师（BA）、安全人员
受众标签：Dev、QA、BA
SDLC阶段：代码审查质量关卡
目的：审查AI SDLC代码、代码差异（diff）、分支、提交或已完成的实现，检查其正确性、回归问题、契约漂移、测试缺失、SDD偏离以及重大可维护性风险。
输出：以问题为核心的审查报告，包含严重程度、路径、影响、修复方案、验证缺口和剩余风险

0.1 Required Inputs

0.1 必填输入项

Review target: diff, commit, branch, PR, staged changes, or subsystem.
Relevant spec files for medium or large work.
Validation evidence or explicit note that it is absent.

审查目标：diff、提交、分支、PR、暂存变更或子系统。
中大型任务的相关规范文件。
验证证据，或明确说明证据缺失。

0.2 Clarification Rules

0.2 澄清规则

Ask concise questions before finalizing when role, artifact, requirements, scope, audience, or constraints are unclear.
If optional information is missing, mark it as
```
TBD
```
,
```
Not provided
```
, or
```
Assumption
```
instead of inventing it.
Separate confirmed facts from assumptions and open questions.
Do not proceed to downstream synthesis when a required upstream artifact or decision is missing.

当角色、成果物、需求、范围、受众或约束条件不明确时，需先提出简洁的问题再完成工作。
若可选信息缺失，标记为
```
TBD
```
、
```
未提供
```
或
```
假设
```
，不得编造。
将已确认事实与假设、待澄清问题分开。
当上游必填成果物或决策缺失时，不得进行下游合成工作。

0.2.1 Flow Mode Flags

0.2.1 流程模式标记

Support two explicit execution flags:
```
--quick-flow
```
and
```
--full-flow
```
.
If both flags are supplied,
```
--full-flow
```
takes precedence because it is the stricter mode.
```
--quick-flow
```
: move fast, make high-quality progress with available context, avoid clarification questions unless continuing would create material product, security, compliance, data-loss, or irreversible implementation risk.
In
```
--quick-flow
```
, use documented assumptions, recommended defaults, existing repository patterns, and the nearest available artifact evidence; record important assumptions and decisions in
```
decision-log.md
```
.
In
```
--quick-flow
```
, run only focused checks that are directly relevant, cheap, and likely to catch regressions for the requested work; report any skipped broader checks as residual risk.
```
--full-flow
```
: ask concise clarification questions when inputs, scope, ownership, acceptance criteria, or decisions are unclear; do not silently assume material requirements.
In
```
--full-flow
```
, verify upstream and downstream artifacts, decision-log entries, traceability links, acceptance criteria, and validation evidence before finalizing.
In
```
--full-flow
```
, run or recommend the skill-appropriate gates, reviews, scripts, and validation commands needed for end-to-end confidence; document any blocked verification explicitly.
When neither flag is supplied, follow the skill default rules and choose the least risky behavior for the request size and domain.

支持两种明确的执行标记：
```
--quick-flow
```
和
```
--full-flow
```
。
若同时提供两种标记，
```
--full-flow
```
优先级更高，因为它是更严格的模式。
```
--quick-flow
```
：快速推进，利用现有上下文高效开展工作；除非继续执行会导致重大产品、安全、合规、数据丢失或不可逆实现风险，否则避免提出澄清问题。
在
```
--quick-flow
```
模式下，使用文档化假设、推荐默认值、现有仓库模式和最接近的可用成果物证据；将重要假设和决策记录在
```
decision-log.md
```
中。
在
```
--quick-flow
```
模式下，仅运行与请求工作直接相关、成本低且可能发现回归问题的针对性检查；将任何跳过的更广泛检查作为剩余风险报告。
```
--full-flow
```
：当输入项、范围、所有权、验收标准或决策不明确时，提出简洁的澄清问题；不得默认重大需求。
在
```
--full-flow
```
模式下，在完成工作前需验证上下游成果物、决策日志条目、可追溯链接、验收标准和验证证据。
在
```
--full-flow
```
模式下，运行或推荐技能对应的关卡、审查、脚本和验证命令，以实现端到端的可信度；明确记录任何受阻的验证工作。
当未提供任何标记时，遵循技能默认规则，并根据请求规模和领域选择风险最低的行为。

0.3 Output Rules

0.3 输出规则

Keep output structured with headings and bullets.
Make findings, gaps, risks, and blockers explicit.
Tie recommendations to evidence from the provided artifact, repository,
```
specs-refiniment/<feature-name>/<file.md>
```
workspace, or user context.
Include role ownership when the output creates follow-up work for BA, QA, Dev, PM, or Delivery.
Return progress, completion, validation, and handoff summaries directly in the Codex response.

Before the final response, emit the

ai-sdlc-handoff/v1

contract with

result

blockers

next_required

, and

next_optional

; every action includes

reason

command

, and

expected_artifact

Do not create
```
summary.txt
```
,
```
*-summary.txt
```
, or another standalone summary file unless the user explicitly requests one.
Keep durable writes limited to the canonical lifecycle artifacts, decision log, human-readable index, and
```
_ai_sdlc
```
machine files.
Let shared helpers migrate legacy paths on the next write; never overwrite or manually merge divergent legacy and canonical files.

输出需保持结构化，使用标题和项目符号。
明确列出发现的问题、缺口、风险和阻塞点。
建议需与提供的成果物、仓库、
```
specs-refiniment/<feature-name>/<file.md>
```
工作区或用户上下文的证据相关联。
当输出为BA、QA、Dev、PM或交付团队产生后续工作时，需明确角色归属。
直接在Codex响应中返回进度、完成情况、验证和交接摘要。

在最终响应前，输出

ai-sdlc-handoff/v1

契约，包含

result

、

blockers

、

next_required

和

next_optional

；每个操作需包含

reason

、

command

和

expected_artifact

。

除非用户明确要求，否则不得创建
```
summary.txt
```
、
```
*-summary.txt
```
或其他独立摘要文件。
仅将持久化写入限制在规范生命周期成果物、决策日志、人类可读索引和
```
_ai_sdlc
```
机器文件中。
让共享助手在下次写入时迁移旧路径；切勿覆盖或手动合并不一致的旧文件和规范文件。

0.4 Artifact Routing

0.4 成果物路由

Maintain a feature decision log whenever this skill records, resolves, changes, or depends on a product, delivery, QA, security, validation, branching, implementation, or rollout decision.
For PM, BA, QA, Delivery, discovery, planning, refinement, and readiness work, write decisions to
```
specs-refiniment/<feature-name>/decision-log.md
```
.
For developer implementation SDD work, write decisions to
```
specs/<feature-name>/decision-log.md
```
.
Each decision-log entry must include date, decision, context or evidence, options considered when relevant, owner, status, and links to affected artifacts, tasks, tests, or validation evidence.

Use this exact decision-log structure:

markdown

# Decision Log

| ID | Date | Status | Owner | Decision | Context/Evidence | Options Considered | Affected Artifacts | Validation/Trace Links |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| DEC-001 | YYYY-MM-DD | proposed / accepted / superseded / rejected | role or name | concise decision | source facts, artifact links, or evidence | option A; option B; recommended default | affected docs, tasks, code, tests, or rollout notes | requirement IDs, test IDs, validation commands, PRs, commits, or tickets |

Use
```
specs/
```
only for developer implementation SDD packages and repo-governance artifacts.
Do not place PM, BA, QA, Delivery, discovery, planning, refinement, or readiness outputs in
```
specs/
```
; those belong at
```
specs-refiniment/<feature-name>/<file.md>
```
.
When consuming
```
specs-refiniment/<feature-name>/<file.md>
```
, treat it as upstream refinement context and create or update
```
specs/
```
only when implementation work is explicitly in scope.

当本技能记录、解决、更改或依赖产品、交付、QA、安全、验证、分支、实现或发布决策时，需维护功能决策日志。
对于PM、BA、QA、交付、探索、规划、细化和准备工作，将决策写入
```
specs-refiniment/<feature-name>/decision-log.md
```
。
对于开发人员实现SDD的工作，将决策写入
```
specs/<feature-name>/decision-log.md
```
。
每个决策日志条目必须包含日期、决策内容、上下文或证据、相关备选方案（如有）、负责人、状态以及关联成果物、任务、测试或验证证据的链接。

使用以下精确的决策日志结构：

markdown

# 决策日志

| ID | 日期 | 状态 | 负责人 | 决策内容 | 上下文/证据 | 备选方案 | 关联成果物 | 验证/追溯链接 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| DEC-001 | YYYY-MM-DD | 提议/已接受/已取代/已拒绝 | 角色或姓名 | 简洁的决策内容 | 源事实、成果物链接或证据 | 选项A；选项B；推荐默认值 | 受影响的文档、任务、代码、测试或发布说明 | 需求ID、测试ID、验证命令、PR、提交或工单 |

```
specs/
```
仅用于开发人员实现SDD的包和仓库治理成果物。
不得将PM、BA、QA、交付、探索、规划、细化或准备工作的输出放入
```
specs/
```
；这些内容应放在
```
specs-refiniment/<feature-name>/<file.md>
```
。
当使用
```
specs-refiniment/<feature-name>/<file.md>
```
时，将其视为上游细化上下文；仅当实现工作明确在范围内时，才创建或更新
```
specs/
```
中的内容。

0.5 Feature State Machine

0.5 功能状态机

Maintain feature lifecycle state in TOON at

specs-refiniment/<feature-name>/_ai_sdlc/state.toon

for refinement work and

specs/<feature-name>/_ai_sdlc/state.toon

for implementation work.

Before executing this skill for a feature, check the state machine with

python3 skills/_shared/state_machine.py check --feature <feature-name> --skill <this-skill-name> --workspace <refinement|implementation> --quick-flow|--full-flow

When this skill starts durable work, mark it in progress with
```
begin
```
; when the skill's required artifact or review is complete, mark it done with
```
complete
```
and include
```
--artifacts <path>
```
plus
```
--decision-ref DEC-###
```
when a decision was involved.
In
```
--full-flow
```
, do not proceed when predecessor stages are incomplete, another lifecycle skill is active, or the state file reports a blocker.
In
```
--quick-flow
```
, a predecessor skip is allowed only when continuing is low risk and the command includes
```
--assumption "..."
```
or
```
--decision-ref DEC-###
```
; record the same assumption or decision in
```
decision-log.md
```
.

Use

python3 skills/_shared/state_machine.py status --feature <feature-name> --workspace <refinement|implementation> --format toon

to emit compact LLM-readable state before choosing the next skill.

The state machine is feature-scoped: do not reuse a
```
state.toon
```
across unrelated feature folders.

在TOON中维护功能生命周期状态：细化工作的状态存于
```
specs-refiniment/<feature-name>/_ai_sdlc/state.toon
```
，实现工作的状态存于
```
specs/<feature-name>/_ai_sdlc/state.toon
```
。

在为某个功能执行本技能前，使用

python3 skills/_shared/state_machine.py check --feature <feature-name> --skill <this-skill-name> --workspace <refinement|implementation> --quick-flow|--full-flow

检查状态机。

当本技能开始持久化工作时，用
```
begin
```
标记为进行中；当技能的必填成果物或审查完成时，用
```
complete
```
标记为已完成，若涉及决策需添加
```
--artifacts <path>
```
和
```
--decision-ref DEC-###
```
。
在
```
--full-flow
```
模式下，当前置阶段未完成、另一个生命周期技能处于活跃状态或状态文件报告阻塞时，不得继续执行。
在
```
--quick-flow
```
模式下，仅当继续执行风险低且命令包含
```
--assumption "..."
```
或
```
--decision-ref DEC-###
```
时，才允许跳过前置阶段；需在
```
decision-log.md
```
中记录相同的假设或决策。

使用

python3 skills/_shared/state_machine.py status --feature <feature-name> --workspace <refinement|implementation> --format toon

在选择下一个技能前输出紧凑的LLM可读状态。

状态机以功能为范围：不得在不相关的功能文件夹间复用
```
state.toon
```
。

0.6 Artifact Metadata And Metatags

0.6 成果物元数据与元标签

Every Markdown artifact generated or updated by this skill must start with an
```
artifact_metadata
```
YAML frontmatter block before the first visible heading.

Use schema

ai-sdlc-artifact-metadata/v1

and keep these fields current:

feature

artifact

path

workspace

skill

flow_mode

state_file

decision_log

status

owner

created_at

updated_at

trace_ids

related_artifacts

validation

, and

metatags

```
metatags
```
must include at minimum
```
ai-sdlc
```
, the workspace (
```
refinement
```
or
```
implementation
```
), this skill name, the artifact type or filename stem, and a lifecycle/status tag such as
```
draft
```
,
```
review
```
,
```
approved
```
, or
```
validated
```
.
When
```
--quick-flow
```
is active, set
```
flow_mode: quick
```
, keep assumptions visible in the body, and add tags for major defaults or unresolved risk only when they help retrieval.
When
```
--full-flow
```
is active, set
```
flow_mode: full
```
, keep blockers and validation evidence reflected in
```
status
```
,
```
validation
```
,
```
trace_ids
```
, and
```
related_artifacts
```
.
Update metadata whenever the artifact path, status, owner, trace links, validation evidence, related artifacts, or decision references change.
Metadata is an index for routing, retrieval, and traceability; it does not replace the artifact body,
```
decision-log.md
```
, or
```
state.toon
```
.

本技能生成或更新的每个Markdown成果物，必须在第一个可见标题前包含
```
artifact_metadata
```
YAML前置块。

使用

ai-sdlc-artifact-metadata/v1

schema，并保持以下字段最新：

feature

、

artifact

、

path

、

workspace

、

skill

、

flow_mode

、

state_file

、

decision_log

、

status

、

owner

、

created_at

、

updated_at

、

trace_ids

、

related_artifacts

、

validation

和

metatags

。

```
metatags
```
至少需包含
```
ai-sdlc
```
、工作区（
```
refinement
```
或
```
implementation
```
）、本技能名称、成果物类型或文件名主干，以及生命周期/状态标签（如
```
draft
```
、
```
review
```
、
```
approved
```
或
```
validated
```
）。
当
```
--quick-flow
```
模式激活时，设置
```
flow_mode: quick
```
，在正文中保留假设，仅当有助于检索时才添加重大默认值或未解决风险的标签。
当
```
--full-flow
```
模式激活时，设置
```
flow_mode: full
```
，在
```
status
```
、
```
validation
```
、
```
trace_ids
```
和
```
related_artifacts
```
中反映阻塞点和验证证据。
当成果物路径、状态、负责人、追溯链接、验证证据、关联成果物或决策引用发生变化时，需更新元数据。
元数据用于路由、检索和可追溯性；它不能替代成果物正文、
```
decision-log.md
```
或
```
state.toon
```
。

0.7 Specs Index

0.7 规范索引

Before searching across feature folders, inspect the compact LLM index first:
```
specs-refiniment/_ai_sdlc/specs-index.toon
```
for refinement work or
```
specs/_ai_sdlc/specs-index.toon
```
for implementation work.
Use the human-readable index at
```
specs-refiniment/specs-index.md
```
or
```
specs/specs-index.md
```
when reporting feature coverage, artifact inventory, or handoff status to people.

After this skill creates or materially updates an artifact, refresh the matching workspace index with

python3 skills/_shared/ai_sdlc_specs_index.py --workspace <refinement|implementation> --quick-flow|--full-flow

In
```
--quick-flow
```
, rely on
```
specs-index.toon
```
to choose the smallest relevant artifact set before opening files.
In
```
--full-flow
```
, verify the updated artifact appears in both
```
specs-index.toon
```
and
```
specs-index.md
```
before final handoff.
The specs index summarizes artifact metadata and state; it does not replace reading the selected source artifacts when details, approvals, or validation evidence matter.

在跨功能文件夹搜索前，先查看紧凑的LLM索引：细化工作查看
```
specs-refiniment/_ai_sdlc/specs-index.toon
```
，实现工作查看
```
specs/_ai_sdlc/specs-index.toon
```
。
当向人员报告功能覆盖范围、成果物清单或交接状态时，使用人类可读索引
```
specs-refiniment/specs-index.md
```
或
```
specs/specs-index.md
```
。

当本技能创建或大幅更新成果物后，使用

python3 skills/_shared/ai_sdlc_specs_index.py --workspace <refinement|implementation> --quick-flow|--full-flow

刷新对应工作区的索引。

在
```
--quick-flow
```
模式下，依赖
```
specs-index.toon
```
选择最小的相关成果物集，再打开文件。
在
```
--full-flow
```
模式下，在最终交接前需验证更新后的成果物是否同时出现在
```
specs-index.toon
```
和
```
specs-index.md
```
中。
规范索引汇总成果物元数据和状态；当细节、审批或验证证据很重要时，它不能替代阅读选定的源成果物。

References

参考资料

Read
```
references/review-checklist.md
```
when the task needs the detailed structure, checklist, or examples for this skill.
Use
```
scripts/review_readiness.py
```
when deterministic validation, planning, or formatting is required by the workflow; pass the same
```
--quick-flow
```
or
```
--full-flow
```
flag that was supplied to the skill when supported.

当任务需要本技能的详细结构、检查清单或示例时，阅读
```
references/review-checklist.md
```
。
当工作流需要确定性验证、规划或格式化时，使用
```
scripts/review_readiness.py
```
；若支持，需传入与技能相同的
```
--quick-flow
```
或
```
--full-flow
```
标记。

Script Usage

脚本使用

Run review readiness before producing findings when reviewing diffs, branches, staged changes, or full-repo surfaces.

Quick flow:

python3 skills/ai-sdlc-code-review/scripts/review_readiness.py --quick-flow

Full flow with spec:

python3 skills/ai-sdlc-code-review/scripts/review_readiness.py --full-flow --spec specs/<feature-name>

Branch review: add
```
--base <branch-or-commit>
```
; broad audit: use
```
--full-repo
```
instead of
```
--base
```
.
Treat errors as blockers; treat warnings as review focus areas unless the user explicitly narrowed scope.

在审查diff、分支、暂存变更或全仓库内容时，需先运行审查就绪检查，再生成问题报告。

快速模式：

python3 skills/ai-sdlc-code-review/scripts/review_readiness.py --quick-flow

带规范文件的完整模式：

python3 skills/ai-sdlc-code-review/scripts/review_readiness.py --full-flow --spec specs/<feature-name>

分支审查：添加
```
--base <branch-or-commit>
```
；全面审计：使用
```
--full-repo
```
替代
```
--base
```
。
将错误视为阻塞点；将警告视为审查重点，除非用户明确缩小范围。

Purpose

目的

Review AI SDLC code, diffs, branches, commits, or completed implementations for correctness, regressions, contract drift, missing tests, SDD drift, and material maintainability risks.

审查AI SDLC代码、diff、分支、提交或已完成的实现，检查其正确性、回归问题、契约漂移、测试缺失、SDD偏离以及重大可维护性风险。

Inputs

输入项

Collect the review target: staged diff, unstaged diff, branch, commit, PR, package, or subsystem.
Run
```
git status --short
```
and
```
git diff --stat
```
for local diffs.

Read the relevant diff:

staged:
```
git diff --cached
```
unstaged:
```
git diff
```
branch:
```
git diff <base>...HEAD
```

Read relevant

requirements.md

design.md

test-cases.md

qa.md

tasks.md

_ai_sdlc/plan.toon

, and

plan.md

for medium or large work.

Read validation output or record that it is absent.
Read
```
references/review-checklist.md
```
for deep-audit mode or complex surfaces.

收集审查目标：暂存diff、未暂存diff、分支、提交、PR、包或子系统。
针对本地diff，运行
```
git status --short
```
和
```
git diff --stat
```
。
读取相关diff：
- 暂存：
```
git diff --cached
```
- 未暂存：
```
git diff
```
- 分支：
```
git diff <base>...HEAD
```

针对中大型任务，读取相关的

requirements.md

、

design.md

、

test-cases.md

、

qa.md

、

tasks.md

、

_ai_sdlc/plan.toon

和

plan.md

。

读取验证输出，或记录输出缺失。
针对深度审计模式或复杂场景，读取
```
references/review-checklist.md
```
。

Steps

步骤

Identify review mode: normal review or deep-audit review.
Define the exact review boundary before judging code.
Use the
```
review
```
subagent only when the user requested review work and the active runtime policy permits delegation; otherwise perform the review locally.
Inspect high-risk files first: handlers, services, workflows, providers, config, schema, migrations, generated contracts, tests, and repo-local automation runtime files.
Compare implementation against spec requirements, design contracts, task scope, and validation evidence.
Check authorization, data integrity, state transitions, decimal math, asset identifiers, provider routing, errors, observability, and exported Go doc comments when touched.
Escalate to
```
$ai-sdlc-security-testing
```
when exploitability, auth boundaries, secrets, or abuse paths are the primary concern.
Report findings first, ordered by severity.
Report no findings explicitly when none are found.
Report validation gaps and residual risks after findings.

确定审查模式：常规审查或深度审计审查。
在评判代码前，明确定义精确的审查边界。
仅当用户请求审查工作且当前运行时政策允许委托时，才使用
```
review
```
子代理；否则需本地执行审查。
先检查高风险文件：处理器、服务、工作流、提供者、配置、schema、迁移文件、生成的契约、测试以及仓库本地自动化运行时文件。
将实现与规范需求、设计契约、任务范围和验证证据进行对比。
当涉及授权、数据完整性、状态转换、十进制运算、资产标识符、提供者路由、错误处理、可观测性和导出的Go文档注释时，进行检查。
当主要关注点为可利用性、授权边界、密钥或滥用路径时，升级至
```
$ai-sdlc-security-testing
```
。
先报告发现的问题，按严重程度排序。
当未发现问题时，需明确报告。
在问题报告后，报告验证缺口和剩余风险。

Output Spec

输出规范

Use this format:

text

Findings:
- [CRITICAL|HIGH|MEDIUM|LOW] path:line - concise issue statement.
  Why it matters: concrete failure, regression, or maintenance risk.
  What should change: specific fix or test.

Open questions:
- Only blockers or assumptions that affect correctness, scope, or severity.

Validation gaps:
- Missing, failed, skipped, or stale checks.

Secondary observations:
- Deep-audit mode only; material non-blocking observations.

Summary:
- Brief change summary after findings.

Quality gate:

Pass when every finding has a path, severity, impact, and fix; no-finding reports still include validation gaps.
Fail when the review starts with a summary, lists style nits as findings, omits spec comparison for medium/large work, or hides missing validation.

使用以下格式：

text

问题发现:
- [CRITICAL|HIGH|MEDIUM|LOW] 路径:行号 - 简洁的问题说明。
  影响原因: 具体的故障、回归问题或维护风险。
  整改建议: 具体的修复方案或测试建议。

待澄清问题:
- 仅包含影响正确性、范围或严重程度的阻塞点或假设。

验证缺口:
- 缺失、失败、跳过或过期的检查项。

次要观察:
- 仅适用于深度审计模式；重大非阻塞性观察结果。

摘要:
- 问题报告后的简要变更总结。

质量关卡:

通过：每个问题都包含路径、严重程度、影响和修复方案；无问题报告仍需包含验证缺口。
不通过：审查以摘要开头、将风格问题列为发现的问题、中大型工作未对比规范、隐藏缺失的验证。

Examples

示例

Finding example:

text

Findings:
- [HIGH] internal/service/orders.go:218 - Accepted orders can be repriced after execution because the status guard excludes only cancelled orders.
  Why it matters: A borrower could see a different rate after the lender accepted the order, violating the order contract.
  What should change: Reject repricing unless the order is still in draft or requested state, and add a service test for accepted orders.

No-finding example:

text

Findings:
- None found.

Validation gaps:
- `go test ./internal/service` was not run, so service-level regressions remain unverified.

Summary:
- Reviewed the staged service diff against `specs/NNN-feature-name`; no material defects found.

Invalid counter-example:

text

Looks good. Nice cleanup.

Reject this because it is not findings-first and does not mention validation.

问题发现示例:

text

问题发现:
- [HIGH] internal/service/orders.go:218 - 已接受的订单在执行后可重新定价，因为状态防护仅排除已取消的订单。
  影响原因: 借款人可能在贷款人接受订单后看到不同的利率，违反订单契约。
  整改建议: 除非订单仍处于草稿或请求状态，否则拒绝重新定价，并为已接受的订单添加服务测试。

无问题示例:

text

问题发现:
- 未发现任何问题。

验证缺口:
- 未运行`go test ./internal/service`，因此服务级回归问题仍未验证。

摘要:
- 已对照`specs/NNN-feature-name`审查暂存的服务代码差异；未发现重大缺陷。

无效反例:

text

看起来不错。清理得很干净。

拒绝此类输出，因为它未以问题为核心，且未提及验证情况。

Edge Cases

边缘情况

State
```
target unclear
```
and ask for the review boundary when no diff, commit, branch, or subsystem is available.
Keep docs-only review lightweight unless docs change SDD policy, API contracts, setup, security, or validation behavior.
Use deep-audit mode only when the user asks for a broad pass or the surface spans multiple high-risk areas.
Do not spawn subagents when the active runtime requires explicit permission and the user did not request delegation.
Report stale validation when files changed after tests ran.
Treat hook-driven review as advisory-first; warnings do not replace human-readable findings.

当无diff、提交、分支或子系统可用时，标记
```
目标不明确
```
并请求明确审查边界。
除非文档变更了SDD策略、API契约、设置、安全或验证行为，否则仅对纯文档审查保持轻量级。
仅当用户要求全面检查或场景涉及多个高风险领域时，使用深度审计模式。
当当前运行时要求明确权限且用户未请求委托时，不得生成子代理。
当文件在测试运行后发生变更时，报告验证过期。
将钩子驱动的审查视为建议优先；警告不能替代人类可读的问题发现报告。

Scope Boundary

范围边界

Do not edit code during review unless the user explicitly asks for fixes.
Do not perform security-focused exploitability review as a side effect; use
```
$ai-sdlc-security-testing
```
.
Do not choose final validation commands except to identify gaps; use
```
$ai-sdlc-validation
```
.
Do not approve scope changes that are missing from
```
tasks.md
```
; require a spec update first.

除非用户明确要求修复，否则审查期间不得编辑代码。
不得附带进行以安全为重点的可利用性审查；需使用
```
$ai-sdlc-security-testing
```
。
不得选择最终验证命令，仅可识别验证缺口；需使用
```
$ai-sdlc-validation
```
。
不得批准
```
tasks.md
```
中未提及的范围变更；需先更新规范。

Hook Policy

钩子策略

Skip automatic review for docs-only or metadata-only changes with no code, config, hook, spec-runtime, or test behavior impact.
Require review for non-trivial production code, repo-local automation logic, config, hook, workflow, provider, transport, schema, or test changes.
Recommend deep audit for high-churn surfaces, multiple risk categories, or changes spanning handlers, services, providers, and config.
Keep hook enforcement advisory-first; emit warnings before hard blocks.

对于仅涉及文档或元数据变更、未影响代码、配置、钩子、规范运行时或测试行为的情况，跳过自动审查。
对于非trivial的生产代码、仓库本地自动化逻辑、配置、钩子、工作流、提供者、传输、schema或测试变更，要求进行审查。
对于高变动场景、多个风险类别或涉及处理器、服务、提供者和配置的变更，建议进行深度审计。
钩子执行以建议优先；在强制阻塞前先发出警告。