nanostack

Nanostack — 工程工作流技能

你可以使用一组可组合的工程工作流技能。每项技能都位于一个包含支持文件的文件夹中——按需阅读这些文件以了解相关背景。

可用技能

技能	适用时机	模式	关键文件
/think	开始构建前。通过提问完善初步想法，探索替代方案，并分段梳理设计。	—	think/references/forcing-questions.md、think/references/cognitive-patterns.md
/nano	开始任何非简单工作前。生成范围明确、可执行的计划。	—	plan/templates/plan-template.md
/review	编写代码后。进行两轮审查、检测范围偏移并解决冲突。	--quick --standard --thorough	review/checklist.md、reference/conflict-precedents.md
/qa	验证代码是否正常运行。使用 Playwright 进行基于浏览器的测试，并调试根本原因。	--quick --standard --thorough	qa/bin/screenshot.sh
/security	发布前。执行 OWASP Top 10、STRIDE、变体分析和冲突检测。	--quick --standard --thorough	security/references/owasp-checklist.md、security/templates/security-report.md
/ship	创建 PR、合并、部署并验证。成功后生成冲刺日志。	—	ship/templates/pr-template.md
/guard	在生产环境附近、执行破坏性操作或处理敏感系统时。	—	guard/bin/check-dangerous.sh
/feature	为现有项目添加功能。跳过 /think，直接进入计划 → 构建 → 审查 → 安全检查 → QA → 发布。	—	feature/SKILL.md
/conductor	在一个冲刺期间编排并行 Agent 会话。协调任务认领和产物交接。	start claim complete status	conductor/bin/sprint.sh
/nano-run	首次设置。通过对话配置技术栈、权限和偏好，并指导你完成首次冲刺。	—	start/SKILL.md
/nano-help	Nanostack 所有命令及其用法的快速参考。	—	help/SKILL.md

工作流顺序

默认工作流为：/think → /nano → 构建 → /review → /security → /qa → /ship

使用 /conductor 时，审查、安全检查和 QA 会并行运行——它们都依赖构建，而非彼此依赖：

think → plan → build ─┬─ review  ─┐
                      ├─ qa       ├─ ship
                      └─ security ─┘

在生产环境附近或处理敏感系统时，可随时启用 /guard。

Zen

阅读 ZEN.md 以了解完整的原则集。在任何技能执行期间遇到疑问时，请参考它。简要原则如下：

• 编写代码前，先质疑需求。
• 删除不该存在的内容。在此之前，不要优化剩余内容。
• 缩小范围，而非降低目标。
• 修复问题或提出疑问。绝不忽略问题。
• 安全不是权衡项，而是一项约束。
• 输出应优于要求。

强度模式

/review、/security 和 /qa 技能支持以下强度模式：

模式	标志	适用时机	置信度
快速	--quick	简单更改（拼写错误、配置、文档）	9/10 — 只检查明显问题
标准	（默认）	常规更改	7/10 — 检查所有合理的问题
彻底	--thorough	关键更改（身份验证、支付、基础设施）	3/10 — 标记所有可疑之处

技能会根据差异自动建议模式，但最终始终由用户决定。

工件持久化

保存工件是必需的。 每项技能完成后都必须保存其工件。

每次运行后，技能都会自动将输出保存到 .nanostack/：

.nanostack/<phase>/<timestamp>.json

这有助于：

• 范围偏移检测 — /review 会比较计划文件与实际文件
• 冲突检测 — /review 和 /security 会交叉参考彼此的发现
• 冲刺日志 — /ship 会根据所有阶段工件生成日志条目
• 趋势跟踪 — 安全问题是否随着时间推移而减少？

自动保存默认开启。用户可以在 .nanostack/config.json 中设置 auto_save: false 将其关闭。

保存前会验证工件：save-artifact.sh 会拒绝无效 JSON、缺少必填字段（phase、summary）以及阶段不匹配的工件。

要丢弃某次糟糕会话的工件：运行 bin/discard-sprint.sh（移除当前项目和日期对应的工件及日志条目）。

冲突解决

当技能给出相互矛盾的指导时（例如，/review 建议“提供更多错误细节”，但 /security 建议“尽量减少错误信息泄露”），将应用冲突解决框架：

1. 默认以安全为先 — 除非风险只是理论上的，或仅涉及内部
2. 由上下文决定最终优先级 — 面向公众的应用、内部工具、初创公司或合规场景
3. 记录冲突，而非掩盖冲突 — 每项解决方案都会记录在技能工件中

阅读 reference/conflict-precedents.md，了解已知的冲突模式和预定义的解决方案。

项目配置

首次在项目中使用时，运行 bin/init-config.sh --interactive 创建 .nanostack/config.json。此文件会保存：

• 已安装的 Agent — 自动检测（claude、codex、cursor、opencode、gemini）
• 检测到的技术栈 — node、go、python、docker
• 偏好设置 — 默认强度模式、自动保存、冲突优先级

如果配置文件已存在，请在开始任何技能时读取，以便调整行为：

bin/init-config.sh  # outputs current config or {} if none

技能会使用配置来：

• /review、/qa、/security：读取 preferences.default_intensity，而不是始终默认使用标准强度
• /security：读取 preferences.conflict_precedence，以确定跨技能冲突中哪一方优先
• /security：读取 detected，跳过不相关的检查（例如，不在 Go 项目中扫描 Python 漏洞）

每项技能专属的配置（security/config.json、guard/config.json）会保存该技能专属的设置，且仅由对应技能读取。

通用规则

• 先阅读，再行动。 每项技能都必须先读取相关代码／差异／配置，再生成输出。绝不盲目分析。
• 解决关键问题，而非面面俱到。 如果追求完整只比走捷径多花几分钟，就把事情做完整；如果要多花几天，就不要。
• 失败也要记录，不只记录成功。 技能执行期间出现问题时（脚本错误、方法不当、项目行为异常），请记录下来：

  ~/.claude/skills/nanostack/bin/capture-failure.sh <skill> "<what went wrong>" "<what was tried>" "<what fixed it>"
  

  失败会不断累积成知识。下次冲刺时，就能避免同样的错误。无需运行 /compound 或成功交付，只需记录下来并继续。

主动触发建议

当上下文符合条件时主动建议使用技能——不要等用户想起来：

触发条件	建议
用户说“我应该构建什么”／不确定方向	/think
任务涉及 3 个以上文件，或用户说“我该如何着手”	/nano
用户说“完成了”“做完了”“可以审查了”	/review
用户说“这样能用吗”“测试一下”，或报告了 Bug	/qa
发布前、用户说“可以部署了”，或差异涉及 auth/env/infra	/security
用户说“创建 PR”“合并”“发布吧”	/ship
检测到破坏性命令、生产环境访问或敏感操作	/guard

使用规则

• 对于新产品或“要做什么”不明确的情况，请先运行 /think
• 开始构建涉及 3 个以上文件的内容前，请先运行 /nano
• 对自己的代码运行 /review——对抗式审查能发现你遗漏的问题
• 发布到生产环境前，必须运行 /security
• /guard 按需启用——需要时再激活，不要始终保持开启
• 技能可以组合使用：/qa 可以调用 /security 检查，/ship 可以调用 /review