Menu
当复杂问题需要系统性逐步推理时使用。适用于多阶段分析、设计规划、问题分解，或初始范围不明确且需要受控收敛的任务。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
当用户在 skills-only 环境中需要判断应该从哪个 anws 工作流开始，或需要在 forge / change / genesis / probe / blueprint / challenge / upgrade 之间路由时使用。它是 anws 工作流集合的导航入口。
纯静态「契约忠实度 / 实现侧证据」审查：对照 PRD、ADR、系统设计、05A_TASKS 与 05B_VERIFICATION_PLAN，围绕契约闭合、任务兑现、架构健康、安全边界、验证证据与回流一致性产出可追溯结论；供 /challenge（CODE/FULL）与 /forge（Step 3 §3.6 波末）共用。
当用户需求模糊、术语不清晰时使用。通过交互式追问澄清领域概念，提取实体、流程与暗物质（missing_components）。由 **`/genesis` Step 1** 在 Step 0 已确定 `TARGET_DIR = .anws/v{N}` 后调用；与 **同工作区 `/genesis`** 连用。
执行 /craft 时必读。提供 Workflow / Skill / Prompt 骨架与质量护栏。以判断准绳替代堆砌步骤。
当 `/challenge` 需要设计侧规范契约闭合证据（架构与系统设计文档三维审查）时加载；产出可锚点、按严重度分级的发现供纳入 07_CHALLENGE_REPORT，不作脱离 challenge 上下文的终局裁决。
规定面向真人的 E2E / 手动验证《测试指南》与《E2E Verification》报告骨架（PRD 可追溯、人机走查顺序、评测列仅能 PASS/PARTIAL_PASS/FAIL）；**不含实机浏览器编排**——先后顺序与回填义务由宿主 **`/forge` §3.7**（及 `/forge` 对应条文）统一写死。
| name | sequential-thinking |
| description | 当复杂问题需要系统性逐步推理时使用。适用于多阶段分析、设计规划、问题分解，或初始范围不明确且需要受控收敛的任务。 |
这个 skill 的核心不是“多写几段 thought”，而是让 AI 在复杂问题里持续推进、允许修正，并最终收敛成结论。CLI 只是执行载体；skill 本身负责定义什么时候该进入这种思考方式，以及如何避免把顺序思考退化成松散输出。
这个 skill 用来把复杂问题处理成一个有边界、可修正、可复核的推理过程：
它解决的不是“不会想”，而是“想得太散、太早下结论、太难复核”。
模型能力决定基线，任务复杂度决定是否升级。
| 模型能力 | 简单任务 | 复杂任务 |
|---|---|---|
| 有思维链（CoT） | 自然 CoT 即可 | 调用 ST CLI |
| 无思维链 | 必须调用 ST CLI | 必须调用 ST CLI |
"无 CoT → 必须用 ST 有 CoT → 复杂才用 ST"
| 场景 | 判断标准 | 为什么需要 CLI |
|---|---|---|
| 无 CoT 模型 | 当前模型不支持思维链输出 | 必须依赖外部工具组织推理 |
| 修正前提 | 推理过程中发现前面判断错了，需要回头修正 | CLI 会话保留历史，支持回看修正 |
| 多方案比较 | 需要在 2+ 个候选方案之间做权衡决策 | branch 模式专为分支比较设计 |
| 可回放轨迹 | 需要留下可审计、可复现的推理过程 | CLI 支持生成 replay 文档 |
| 复杂收敛 | 问题需要 > 5 步才能收敛到结论 | 强制步数限制防止无限发散 |
| 场景 | 判断标准 | 为什么不需要 CLI |
|---|---|---|
| 单向推理 | 不需要回头修正，线性推进 | 模型自然输出即可 |
| 简单分析 | 问题边界清晰、步骤 < 5 | 不需要复杂工具辅助 |
| 快速决策 | 只需结论，不需要可回放轨迹 | CoT 足够表达推理 |
| 探索性思考 | 还在发散阶段，不确定是否需要收敛 | 先用 CoT 探索，再决定是否用 CLI |
flowchart TD
A[需要多步推理?] -->|否| Z[直接回答]
A -->|是| B{模型有 CoT?}
B -->|否| CLI[必须调用 ST CLI]
B -->|是| C{任务复杂?}
C -->|简单: 步骤 < 5, 无修正| CoT[自然 CoT]
C -->|复杂: 修正/比较/回放| CLI
这个 skill 面向 agent 交付思考方式与调用约束；CLI 通过 npm 分发。
在使用前，应先确保本地已安装对应 CLI：
npm install -g sequential-thinking-cli
# 或
pnpm add -g sequential-thinking-cli
安装后，使用 sthink 作为命令入口。
本 skill 不再要求 AI 手写 thought JSON。执行层通过 CLI 主路径动作完成：
startstepreplaystart只接受四个输入：
namegoalmodetotalSteps约束：
mode 仅允许 explore、branch、audittotalSteps 仅允许 5 或 8如果你不确定该选哪种模式，默认用 explore。只有在任务明显是在比较候选路径时才用 branch；只有在任务明显是在审查既有判断时才用 audit。
step只接受：
content其余上下文应由 runtime 自动恢复并注入。
replay用于读取已完成会话并生成 replay 文档；如需要，可额外导出到当前目录。
1. 先判断问题是否真的需要 sequential-thinking，而不是默认套用。
2. 如需要，先安装或确认本地已有 npm CLI。
3. 用 `sthink start` 给出 `name`、`goal`、`mode`、`totalSteps`。
4. 用 `sthink step` 逐步推进，每一步只写当前推进内容。
5. 当出现新证据时，允许修正，而不是硬撑旧判断。
6. 到收敛阶段时，必须输出结论、风险与下一步建议。
7. 完成后按需使用 `sthink replay` 生成与导出回放文档。
以下示例不是为了让你回去手写 JSON，而是为了说明这种 skill 真正有价值的地方：如何推进、如何修正、如何收敛。
sthink start --name "query-diagnosis" --goal "定位查询性能下降的主因" --mode explore --totalSteps 5
sthink step --sessionPath "<session-path>" --content "先不要急着选优化手段。需要先把问题拆成几层：是单条 SQL 退化、接口级 N+1，还是更上层的调用放大。若根因没分清，后面的缓存、索引、重写都可能只是补丁。"
sthink step --sessionPath "<session-path>" --content "从查询日志看，用户详情接口在一次请求里触发了大量重复读取，已经出现明显的 N+1 信号。但还不能直接下结论，因为重复查询也可能只是症状；需要继续确认慢点究竟来自“查询次数过多”，还是“某条关键查询本身很慢”。因此总步数上调一档。"
sthink step --sessionPath "<session-path>" --content "结论可以收敛了：主因是列表页批量加载时触发的 N+1，次因是关联字段缺少索引放大了单次查询成本。优化顺序应该先消除 N+1，再补索引验证尾延迟；这样既先打掉主矛盾，也避免一上来引入缓存复杂度。"
sthink step --sessionPath "<session-path>" --content "回看 profiling 结果后，前面的判断需要修正：真正拖垮接口的不是 N+1 本身，而是关联列缺少索引，导致每次关联查询都在放大全表扫描成本。也就是说，N+1 仍然存在，但它不是第一性瓶颈，优先级应该后移。"
sthink start --name "change-impact-analysis" --goal "拆解复杂变更的影响与优先级" --mode explore --totalSteps 5
sthink step --sessionPath "<session-path>" --content "用户一次性提出了多项规则修改，不该把它们当成同一种改动处理。先拆开看：有的是机制原则调整，有的是数值平衡，有的是接口语义变化，还有的是文档与实现脱节。如果不先分型，后面会把“该改 ADR 的”“该改设计文档的”“该补代码契约的”混成一锅。"
sthink step --sessionPath "<session-path>" --content "先做影响矩阵。机制原则类改动通常会回流到 ADR 和 System Design；数值平衡会影响规则表、配置与测试基线；接口语义变化最危险，因为它会悄悄破坏调用方的假设。这里最该警惕的不是改动数量，而是有没有改到“被多个模块默认依赖、但文档里没写清楚”的隐性契约。"
sthink step --sessionPath "<session-path>" --content "可以收敛了：先处理那些会改变系统边界或调用语义的项，再处理数值与体验层面的项。顺序上应优先修正文档与契约，再讨论平衡性；否则后续所有实现和评审都会建立在漂移的前提上。结论不是“先改最显眼的”，而是“先修最容易污染系统认知的”。"
sthink start --name "performance-tradeoff" --goal "比较缓存止血与查询优化的优先级" --mode branch --totalSteps 5
sthink step --sessionPath "<session-path>" --content "方案 A：先引入缓存削峰。好处是见效快、对接口层侵入小，适合先止血；坏处是会把问题从“数据库慢”转成“缓存一致性与失效策略复杂”，如果根因其实是查询设计不合理，这条路容易把偶然复杂度永久留在系统里。与此同时，方案 B：直接做索引优化和查询重写。好处是从根上消除瓶颈，长期结构更干净；代价是需要更仔细验证写入放大、锁竞争和回归风险。这条路更慢，但如果业务模型稳定，通常比提前上缓存更符合简单优先的原则。"
replay 支持导出到当前目录，便于审阅与复用以下提醒是启发式问题，不是硬约束。真正重要的是：它们能帮助你减少空转，逼近结论。
explorestep 的 content 只表达当前推进内容，不要重复补全系统上下文replay