Critical review of design quality. Does not check format, only checks "should it be designed this way".
Core Question
Each critique answers one question:Can this design be simpler?
Anti-Accretion Rule: Net Reduction
After critique, the total number of lines must be ≤ before. This is a hard constraint, not a suggestion.
Critique allows only 4 operations:
| Operation | Description | Example |
|---|---|---|
| Delete | Remove a section or content | Delete the unused plugin system design |
| Merge | Combine multiple sections into one | Merge Error Handling into API Constraints |
| Split | Move to a separate intent | Split §13-§18 from ash into ash/agentic-patterns |
| Simplify | Express the same constraint with fewer lines | Compress a 5-line description into 2 lines |
Prohibited:
- ❌ Introducing new concepts or new sections
- ❌ Adding new analysis frameworks
- ❌ Expanding the scope of existing sections
If something is found to be missing, output a gap flag, do not fill it directly:
Gap: intent 没有说明 failure handling。建议在下一轮 interview 中讨论。
If new content really needs to be added, it must:
- First delete an equal or greater amount of old content
- Have explicit user agreement
- The final line count must still be ≤ the initial line count
Inspection Dimensions
| Dimension | Signal | Question |
|---|---|---|
| Over-engineering | Complex configuration systems, plugin architectures, multi-layer abstractions | "Is this complexity driven by current requirements?" |
| YAGNI | "May be needed in the future", "reserve extension points", "support multiple..." | "If this is deleted, will the MVP still work?" |
| Premature abstraction | An interface with only one implementation, a utility function used only once | "Is this layer of abstraction really needed now?" |
| Boundary issues | Large amounts of data passing between modules, circular dependencies, unclear responsibilities | "Is this boundary drawn naturally here?" |
| Hidden complexity | Descriptions that seem simple but are difficult to implement | "What is the implementation complexity behind this sentence?" |
Workflow
/intent-critique [path]
↓
┌───────────────────┐
│ 读取 Intent 文件 │
│ 理解设计意图 │
└─────────┬─────────┘
↓
┌───────────────────┐
│ 逐维度分析 │
│ 识别可疑设计 │
└─────────┬─────────┘
↓
┌───────────────────────────────────────┐
│ 对每个发现，与用户讨论： │
│ │
│ 展示问题 + 简化建议 │
│ AskUserQuestion: │
│ - 接受简化 │
│ - 保留原设计（说明理由） │
│ - 跳过此项 │
└─────────┬─────────────────────────────┘
↓
┌───────────────────┐
│ 汇总 critique │
│ 可选更新 Intent │
└───────────────────┘
Usage
# 审查指定 Intent
/intent-critique src/core/intent/INTENT.md
# 审查当前目录
/intent-critique
# 只分析不修改
/intent-critique --dry-run
Execution Steps
0. Record the initial line count
The first step must be counting. Before any analysis:
wc -l INTENT.md
# 记录为 before_lines
Record before_lines , to be used at the end of critique to verify net reduction.
0.5 Convergence Check (automatically triggered when modifications ≥ 3)
Check the number of commits to INTENT.md in git log. If ≥ 3, run convergence before the normal critique:
4-step convergence check:
-
Anchor trace — For each section ask: can it be traced back to an anchor?
- Cannot → mark as deletion candidate
-
Implementation match — For each section ask: is there a corresponding implementation?
- Has implementation → keep
- No implementation and not in the plan → mark as deletion candidate
-
Constraint vs Analysis — For each section ask: is this a constraint or analysis?
- "Three Dimensions of Chat Experience" = analyze → streamline or move to appendix
- "INV-1: LLM is a Pure Function" = constraint → keep
-
Dedup with sub-intents — is there overlap between a section and a sub-intent?
- Yes → delete it, leave a link
Convergence output format:
## Convergence Check (triggered: 5 commits since last convergence)
### Anchor trace failures
- § Agentic Pattern Zones — cannot trace to "ASH 是 shell 语言"
- § Echo Deprecation — migration plan, not core spec
### Unimplemented sections
- § Template Registry — no code, not in plan
### Analysis (not constraint)
- § AI Agent 适配性分析 — 40 lines of analysis, 0 constraints
### Duplicated in sub-intents
- § Boot Sequence — duplicates kernel/bootloader INTENT.md §2
→ Candidates for removal: 4 sections, ~280 lines
After convergence finishes, proceed to the normal critique flow.
0.7 Read the Records index
If records/INDEX.md exists, first read the index to understand the full decision context:
- Which interviews made which decisions
- What review opinions other AIs (ChatGPT, Gemini, etc.) have given
- Previous critique records
Read relevant record files in depth as needed. This solves context asymmetry — even if the original discussion happened on another AI, there is a complete record here.
0.8 Devil's Advocate (independent evaluation)
Start asubagent without the current discussion context, and give it only:
- The full text of INTENT.md
- The Anchor declaration
Have it independently answer 3 questions:
- What is the biggest design risk of this intent?
- Which sections look like analysis rather than constraints?
- If only 3 sections could be kept, which would you keep?
Use the devil's advocate output as additional input for the critique; do not adopt it directly, but use it to cross-validate your own judgment.
1. Read and understand the Intent
First read the Intent in full and understand:
- What problem is to be solved
- Core design decisions
- Main components and boundaries
2. Scan dimension by dimension
Over-engineering signals
检查是否存在：
- 可配置的部分 > 3 个
- 插件/扩展机制
- 多于 2 层的抽象
- "支持多种 X"的描述
- 复杂的状态机
YAGNI signals
检查是否存在：
- "未来可能..."
- "预留..."
- "方便以后..."
- 只在"高级场景"使用的功能
- 没有具体 use case 的抽象
Premature abstraction signals
检查是否存在：
- 只有一个实现的接口/协议
- 只用一次的公共函数
- 只有一个子类的基类
- 不必要的工厂/策略模式
Boundary problem signals
检查是否存在：
- 模块间传递 > 5 个参数
- A 依赖 B，B 也依赖 A
- 一个改动需要同时改多个模块
- 职责描述模糊或重叠
3. Generate the findings list
For each finding, prepare:
- Location: the specific section in the Intent
- Problem: a brief description of the problem
- Simplification suggestion: a specific alternative
- Risk: the cost that simplification may bring
4. Interactive discussion
Use AskUserQuestion for each finding:
发现 1/N: Over-engineering
Section: ## 插件系统
问题: 定义了完整的插件加载、生命周期、沙箱机制，但目前只有 2 个内置功能。
简化建议: 删除插件系统，直接硬编码这 2 个功能。
未来需要时再加。
风险: 如果很快需要第三方插件，要重新设计。
---
AskUserQuestion:
- question: "是否接受这个简化？"
- options:
- "接受简化" - 删除插件系统设计
- "保留原设计" - 请说明具体场景
- "跳过" - 暂不决定
5. Summary report
# Intent Critique Report
## 文件: src/core/intent/INTENT.md
## 统计
- 发现问题: 5
- 接受简化: 3
- 保留原设计: 1
- 跳过: 1
## 已接受的简化
### 1. 删除插件系统
- 原设计: 完整插件架构
- 简化为: 硬编码 2 个功能
- 影响 sections: ## 插件系统, ## 架构
### 2. 合并配置层
...
## 保留的设计
### 1. 多数据源支持
- 原因: 用户明确表示 v1.1 需要
- 建议: 在 Intent 中标注具体 timeline
## 跳过的项目
...
## 下一步
- [ ] 更新 Intent 文件（如果选择自动更新）
- [ ] 运行 /intent-validate 检查格式
- [ ] 运行 /intent-review 重新审批受影响的 sections
6. Optional: update the Intent
If the user agrees, automatically update the Intent:
- Delete the sections that were simplified away
- Add simplification notes to the change log
- Mark the affected sections back to
draft
7. Verify net reduction (required)
After updating the Intent, immediately verify:
wc -l INTENT.md
# 记录为 after_lines
Decision rule:
if after_lines > before_lines:
❌ 拒绝保存。回滚更改。
报告：
before: {before_lines} lines
after: {after_lines} lines
delta: +{after_lines - before_lines} lines
"Critique must net-reduce. Review changes and remove additions."
if after_lines <= before_lines:
✅ 保存成功。
报告：
before: {before_lines} lines
after: {after_lines} lines
reduced: {before_lines - after_lines} lines ({percentage}%)
8. Save the Critique record
Save the complete critique report to records/critique-{date}.md, update records/INDEX.md：
| 2026-02-06 | critique | — | Convergence + critique, removed §13-§15 (-180 lines), kept §2 |
The record includes: convergence results, devil's advocate output, the decision for each finding, and the net line count change.
Discussion techniques
Ways to ask questions
Good questions:
- "If X is deleted, can the system still work?"
- "Is there a specific scenario that needs X?"
- "Is X's complexity worth it?"
Avoid:
- Preset answers
- Overly theoretical discussion
- Ask multiple unrelated questions at the same time
When to accept "hold"
When the user provides:
- A specific usage scenario
- A clear timeline ("needed next month")
- External constraints ("required by the partner")
Record the reason; it is recommended to also note it in the Intent.
Working with other tools
intent-interview → intent-validate → intent-critique → intent-review
↑
可独立调用
任何时候想反思设计时
What not to do
- ❌ Do not check format (the responsibility of intent-validate)
- ❌ Do not check consistency (the responsibility of intent-sync)
- ❌ Do not mark approval status (the responsibility of intent-review)
- ❌ Do not make decisions automatically (must discuss with the user)