revision-adversarial

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Adversarial Design Review

对抗性设计审查

Goal

目标

Challenge an existing Technical Design Document (

TECH-DESIGN.md

) and its ADRs, actively hunting for gaps, unjustified decisions, and unconsidered risks. This skill never validates by default — its job is to disagree first and only concede a decision is sound after failing to find a real problem with it.

挑战现有的Technical Design Document（

TECH-DESIGN.md

）及其ADRs，主动寻找漏洞、不合理的决策和未考虑到的风险。此技能默认从不进行验证——它的职责是先提出异议，只有在确实找不到问题后，才认可决策是合理的。

Why this matters

重要性

Asking the same conversation that produced a design "are you sure about this?" tends to return a defense, not a critique — models exhibit sycophancy (RLHF training rewards agreement) and self-preference bias (a model rates its own prior output more favorably). Run this skill from a fresh conversation, without the history of how the design was produced, whenever possible. If run in the same conversation that generated the TDD, say so explicitly to the user before starting, since the review is weaker under that condition.

向产出该设计的对话询问“你确定这样没问题吗？”往往得到的是辩解而非批评——模型会表现出奉承性（RLHF训练会奖励认同行为）和自我偏好偏见（模型会更青睐自己之前的输出）。尽可能在全新对话中运行此技能，不要带上设计产出过程的历史记录。如果在生成TDD（技术设计文档）的同一对话中运行，需在开始前明确告知用户，因为这种情况下审查效果会打折扣。

Required Input

必要输入

```
TECH-DESIGN.md
```
and its
```
adrs/*.md
```
files — required.
```
PRD.md
```
and
```
Design.md
```
, if present — used to cross-check that no decision contradicts stated scope or UI requirements. Not required to run the review, but skipping them narrows it — say so.

```
TECH-DESIGN.md
```
及其
```
adrs/*.md
```
文件——必填。
```
PRD.md
```
和
```
Design.md
```
（若存在）——用于交叉检查是否有决策与既定范围或UI要求相矛盾。非运行审查的必填项，但跳过会缩小审查范围——需告知用户这一点。

Workflow

工作流程

Read
```
TECH-DESIGN.md
```
and every ADR in full.
For each ADR, check against this bar — it fails if any of these is missing or weak:
- Context actually justifies the decision (not generic boilerplate).
- Alternatives considered are genuinely viable options, not a false choice (two names for the same thing does not count).
- Consequences include at least one real cost or trade-off, not only benefits.
- The decision is proportional to the project's actual scale — flag both over-engineering and under-engineering.
Check across documents:
- Does any decision contradict the PRD's scope or explicit "No alcance"? (if PRD.md available)
- Does every data-implying element in
```
Design.md
```
  have coverage in the data model? (if Design.md available)
- Are there missing decision areas entirely — components, data model, API contracts, stack, state management, resilience — that the project clearly needs but no ADR addresses?
Actively look for what isn't there: unhandled failure modes, missing non-functional requirements the PRD implies (performance, concurrency, offline use), and second-order consequences of a decision that its own ADR didn't mention.
Produce a findings report — do not edit
```
TECH-DESIGN.md
```
or any ADR directly. This skill reports; the human decides what to change.

完整阅读
```
TECH-DESIGN.md
```
和每一份ADR。
针对每份ADR，对照以下标准检查——若存在任意一项缺失或薄弱则判定不合格：
- 上下文确实能支撑决策（而非通用模板内容）。
- 考虑的替代方案是真正可行的选项，而非虚假选择（同一事物的两个名称不算）。
- 后果部分至少包含一个真实的成本或权衡，而非仅提及收益。
- 决策与项目实际规模相匹配——同时标记过度设计和设计不足的情况。
跨文档检查：
- 若
```
PRD.md
```
  可用，是否有决策与PRD的范围或明确的“非范围”相矛盾？
- 若
```
Design.md
```
  可用，
```
Design.md
```
  中所有涉及数据的元素是否都在数据模型中有对应覆盖？
- 是否存在项目明确需要但没有ADR涉及的决策领域——组件、数据模型、API契约、技术栈、状态管理、弹性等？
主动寻找缺失的内容：未处理的故障模式、PRD隐含但未明确的非功能性需求（性能、并发、离线使用），以及ADR自身未提及的决策带来的二阶后果。
生成发现报告——不得直接编辑
```
TECH-DESIGN.md
```
或任何ADR。此技能仅负责报告；由人类决定需要修改的内容。

Output

输出

A findings report, ranked most severe first:

Crítico — the design will likely fail or contradict a stated requirement if unaddressed.
Advertencia — a real gap or weak justification, worth fixing before implementation.
Sugerencia — a smaller improvement, not blocking.

Each finding: which ADR or section it targets, the concrete problem, and why it matters — not a vague "consider reviewing this." If, after genuinely trying, no real issue is found in an area, say so plainly instead of inventing a minor one to appear thorough.

一份发现报告，按严重程度从高到低排序：

严重（Crítico）——若不解决，设计可能失败或与既定要求相矛盾。
警告（Advertencia）——存在真实漏洞或薄弱的决策依据，值得在实施前修复。
建议（Sugerencia）——较小的改进点，不阻碍实施。

每项发现需明确：针对的ADR或章节、具体问题及其影响——不得模糊表述“建议审查此处”。若经过认真排查后，某一领域未发现真实问题，需直接说明，而非为了显得全面而编造小问题。

Quality Gate

质量关卡

Before returning, silently check:

Every ADR was actually challenged — none were skipped or rubber-stamped.
At least one finding names a real trade-off the original ADR missed, or the report explicitly states the design held up under scrutiny — never a generic "looks solid" with no specifics.
No finding is invented just to pad the report.

返回报告前，需静默检查：

每份ADR都已被挑战——无遗漏或草率通过的情况。
至少有一项发现指出了原ADR遗漏的真实权衡，或报告明确说明设计经审查后无问题——不得仅用通用表述“看起来没问题”却无具体依据。
不得为了凑报告内容而编造发现。