Menu
Socratic questioning protocol（苏格拉底式提问协议）与用户沟通准则。对于复杂请求、新功能或不明确的需求为 MANDATORY（强制要求）。包含进度汇报与错误处理。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
务实的编码标准—— 简洁、直接、不做过度设计、不写无用注释（Pragmatic coding standards）
性能分析原则。测量、分析与优化技术。
API design principles and decision-making（API 设计原则与决策逻辑）。REST vs GraphQL vs tRPC selection（选择）、response formats（响应格式）、versioning（版本控制）、pagination（分页）。
App Builder（应用构建编排器）主编排器。根据自然语言请求创建全栈应用，确定项目类型、选择技术栈并协调智能体。
Project scaffolding templates（项目脚手架模板）。用于从零创建新项目。包含 12 个技术栈模板。
Architectural decision-making framework（架构决策框架）。Requirements analysis（需求分析）、trade-off evaluation（权衡评估）、ADR documentation（架构决策记录）。Use when making architecture decisions or analyzing system design（用于架构决策与系统设计分析）。
| name | brainstorming |
| description | Socratic questioning protocol（苏格拉底式提问协议）与用户沟通准则。对于复杂请求、新功能或不明确的需求为 MANDATORY（强制要求）。包含进度汇报与错误处理。 |
| allowed-tools | Read, Glob, Grep |
MANDATORY（强制要求）： 适用于复杂/模糊的请求、新功能开发或系统更新。
| 模式 | 行动 |
|---|---|
| 在没有细节的情况下要求“构建/创建/制作 [某物]” | 提出 3 个问题 |
| 涉及复杂功能或架构设计 | 在交付方案前先进行澄清 |
| 针对现有系统的更新/变更请求 | 确认影响范围 |
| 需求描述过于模糊 | 询问目的、用户群体及约束条件 |
** 严禁使用静态模板。** 请查阅 dynamic-questioning.md 了解核心原则。
| 原则 | 含义 |
|---|---|
| 提问揭示后果 | 每个问题都应关联到一个架构决策 |
| 背景先于内容 | 首先理解是全新开发、功能增强、重构还是调试背景 |
| 最小可行问题 | 每个问题都必须能够排除掉某些特定的实现路径 |
| 生成数据而非假设 | 不要猜测 —— 带着 trade-offs（权衡）方案去询问 |
1. 解析请求 -> 提取领域、功能点、规模指标
2. 识别决策点 -> 区分阻塞性决策与可延后决策
3. 生成问题 -> 优先级：P0 (阻塞) > P1 (高杠杆) > P2 (可选)
4. 格式化权衡方案 -> 包含：内容、原因、选项、默认值
### [优先级] **[决策点]**
**问题：** [清晰简洁的问题描述]
**为什么要问：**
- [由此涉及的架构后果]
- [影响范围：成本/复杂度/工期/规模]
**备选方案：**
| 选项 | 优点 (+) | 缺点 (-) | 适用场景 |
|--------|------|------|----------|
| A | ... | ... | ... |
**若未指定：** [默认执行方案 + 理由]
关于特定领域的详细问题库与算法，请参阅：dynamic-questioning.md
原则： 透明度建立信任。状态必须是可见且可操作的。
| Agent（智能体） | 状态 | 当前任务 | 进度 |
|---|---|---|---|
| [代理名称] | [OK] [RUN] ⏳[FAIL] [WARN] | [任务描述] | [% 或 数量] |
| 图标 | 含义 | 使用场景 |
|---|---|---|
| [OK] | 已完成 | 任务已成功结束 |
| [RUN] | 运行中 | 正在执行相应指令 |
| ⏳ | 等待中 | 已阻塞，正在等待依赖项 |
| [FAIL] | 错误 | 任务失败，需要人工干预 |
| [WARN] | 警告 | 存在潜在问题，但不影响阻塞 |
原则： 错误是进行清晰沟通的契机。
1. 承认并确认错误
2. 解释发生了什么（对老板友好的中文化描述）
3. 提供带有权衡建议的特定解决方案
4. 请老板选择或提供其他替代路径
| 类别 | 响应策略 |
|---|---|
| 端口冲突 | 提供备选端口或询问是否关闭现有服务 |
| 缺少依赖项 | 自动安装或请求授权 |
| 构建失败 | 展示具体错误信息 + 建议的修复方案 |
| 不明原因错误 | 执行 /debug 或 /test 指令获取更多详情 |
原则： 庆祝成功，指引后续步骤。
1. 成功确认 (简短庆祝)
2. 工作总结 (具体内容)
3. 如何验证/测试 (可操作性)
4. 后续建议 (主动性)
| 原则 | 实施方式 |
|---|---|
| 简洁 | 无冗余细节，直奔主题 |
| 可视化 | 使用图标（[OK] [RUN] ⏳[FAIL] ）方便快速扫视 |
| 具体化 | 使用“大约 2 分钟”而非“请稍等一会儿” |
| 多选方案 | 陷入困境时提供多条备选路径 |
| 主动性 | 任务完成后立即建议后续步骤 |
| 反模式 | 后果 |
|---|---|
| 在理解需求前就急于给出方案 | 浪费时间在错误的路径上 |
| 在未询问的情况下擅自假设需求 | 产出结果偏离预期 |
| 在首个版本就进行过度设计 | 延误价值交付的进度 |
| 忽略既有的约束条件 | 产生无法落地的无效方案 |
| 使用“我觉得”之类的模糊措辞 | 造成不确定性 —— 应改为直接提问确认 |