AgentSkillsCN

intent-critique

通过结构化访谈，将模糊的想法转化为可实施的规范。当用户描述一项新功能或产品创意，或有亟待解决的问题，又或是需要记录需求时，可使用此功能。产出 intent.md（面向代码代理的技术规范）与 overview.md（便于人类理解的摘要）。

SKILL.md
--- frontmatter
name: intent-critique
description: Critical review of Intent design quality. Checks for over-engineering, YAGNI violations, premature abstraction, and simplification opportunities. Uses interactive discussion to refine design decisions.

Intent Critique

设计质量的批判性审查。不检查格式，只检查"是否该这么设计"。

核心问题

每次 critique 回答一个问题：这个设计能更简单吗？

检查维度

维度信号问题
Over-engineering复杂的配置系统、插件架构、多层抽象"这个复杂度是当前需求驱动的吗？"
YAGNI"未来可能需要"、"预留扩展点"、"支持多种...""删掉这个，MVP 还能工作吗？"
过早抽象只有一个实现的接口、只用一次的工具函数"现在真的需要这层抽象吗？"
边界问题模块间大量数据传递、循环依赖、职责模糊"这个边界切在这里自然吗？"
隐藏复杂度看似简单但实现困难的描述"这句话背后的实现复杂度是什么？"

工作流程

code
/intent-critique [path]
        ↓
┌───────────────────┐
│  读取 Intent 文件  │
│  理解设计意图      │
└─────────┬─────────┘
          ↓
┌───────────────────┐
│  逐维度分析        │
│  识别可疑设计      │
└─────────┬─────────┘
          ↓
┌───────────────────────────────────────┐
│  对每个发现，与用户讨论：              │
│                                       │
│  展示问题 + 简化建议                   │
│  AskUserQuestion:                     │
│  - 接受简化                           │
│  - 保留原设计（说明理由）              │
│  - 跳过此项                           │
└─────────┬─────────────────────────────┘
          ↓
┌───────────────────┐
│  汇总 critique     │
│  可选更新 Intent   │
└───────────────────┘

使用方法

bash
# 审查指定 Intent
/intent-critique src/core/intent/INTENT.md

# 审查当前目录
/intent-critique

# 只分析不修改
/intent-critique --dry-run

执行步骤

1. 读取并理解 Intent

先完整阅读 Intent，理解：

  • •要解决什么问题
  • •核心设计决策
  • •主要组件和边界

2. 逐维度扫描

Over-engineering 信号

markdown
检查是否存在：
- 可配置的部分 > 3 个
- 插件/扩展机制
- 多于 2 层的抽象
- "支持多种 X"的描述
- 复杂的状态机

YAGNI 信号

markdown
检查是否存在：
- "未来可能..."
- "预留..."
- "方便以后..."
- 只在"高级场景"使用的功能
- 没有具体 use case 的抽象

过早抽象信号

markdown
检查是否存在：
- 只有一个实现的接口/协议
- 只用一次的公共函数
- 只有一个子类的基类
- 不必要的工厂/策略模式

边界问题信号

markdown
检查是否存在：
- 模块间传递 > 5 个参数
- A 依赖 B，B 也依赖 A
- 一个改动需要同时改多个模块
- 职责描述模糊或重叠

3. 生成发现列表

对每个发现，准备：

  • •位置：Intent 中的具体 section
  • •问题：简短描述问题
  • •简化建议：具体的替代方案
  • •风险：简化可能带来的代价

4. 交互式讨论

对每个发现使用 AskUserQuestion：

code
发现 1/N: Over-engineering

Section: ## 插件系统
问题: 定义了完整的插件加载、生命周期、沙箱机制，但目前只有 2 个内置功能。

简化建议: 删除插件系统，直接硬编码这 2 个功能。
未来需要时再加。

风险: 如果很快需要第三方插件，要重新设计。

---
AskUserQuestion:
- question: "是否接受这个简化？"
- options:
  - "接受简化" - 删除插件系统设计
  - "保留原设计" - 请说明具体场景
  - "跳过" - 暂不决定

5. 汇总报告

markdown
# 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. 可选：更新 Intent

如果用户同意，自动更新 Intent：

  • •删除被简化掉的 sections
  • •添加简化说明到变更记录
  • •将受影响的 sections 标记回 draft

讨论技巧

提问方式

好的提问:

  • •"删掉 X，系统还能工作吗？"
  • •"有没有具体场景需要 X？"
  • •"X 的复杂度值得吗？"

避免:

  • •预设答案
  • •过于理论化的讨论
  • •同时问多个不相关的问题

接受"保留"的时机

当用户提供：

  • •具体的使用场景
  • •明确的时间线（"下月就要"）
  • •外部约束（"合作方要求"）

记录理由，建议在 Intent 中也注明。

与其他工具配合

code
intent-interview → intent-validate → intent-critique → intent-review
                                          ↑
                                     可独立调用
                                     任何时候想反思设计时

不做什么

  • •❌ 不检查格式（intent-validate 的职责）
  • •❌ 不检查一致性（intent-sync 的职责）
  • •❌ 不标记审批状态（intent-review 的职责）
  • •❌ 不自动做决定（必须与用户讨论）