用途：该技能用于技术规格（tech spec）的生成与评审，触发关键词包括 tech spec、technical specification、spec review、review spec、feature design。不适用于创建请求文档（用 /create-request）、代码实现（用 feature-dev）和架构咨询（用 /codex-architect）。
主要能力与命令：/tech-spec 创建或更新技术规格，会根据文件系统状态自动判断创建还是更新；/deep-analyze 在初始概念之后深化规格与路线图；/review-spec 在规格确认阶段评审技术规格。
使用方式：技能支持上下文感知的 upsert 模式。未提供完整需求描述时，会通过 references/native-feature-resolution.md 中的级联逻辑自动识别目标功能，依赖 $ARGUMENTS、git branch --show-current、git diff --name-only HEAD 以及对 docs/features/* 的 Glob。规格发现按顺序匹配：docs/features/<key>/2-tech-spec.md（未拆分）、docs/features/<key>/2-tech-spec/2-tech-spec.md（拆分）、docs/features/<key>/2-tech-spec*.md（变体，排除 -fp-brief.md 与 -tech-brief.md）。命中两个及以上视为歧义，需人工介入。需求文档 1-requirements.md 同样三种解析方式但不做后缀排除。意图产物为 intent-<key>.md，需精确匹配。
文件系统状态决定动作：发现唯一规格则进入更新模式，读取该路径文件并增量更新受近期代码变更影响的章节；三个 Glob 均为空则进入创建模式，按模板生成 docs/features/<key>/2-tech-spec.md；Glob 3 返回多个则触发 Need Human 门禁；功能未解析同样触发门禁。创建模式下若 intent-<key>.md 缺失，先按 /req-analyze 的意图模板写入（仅约束，≤60 行）再写规格。更新模式聚焦受代码变更影响的章节，保留未变章节；若意图文件缺失则按创建模式创建。规格章节与 INV-* 或 Non-goal 冲突时应向用户暴露，不得改写意图。
工作流：需求澄清、代码研究、方案设计、风险评估、工作分解、输出文档。规格结构包含需求摘要、现有代码分析、技术方案（架构、数据模型、API、核心逻辑）、风险与依赖、工作分解、测试策略、开放问题。
写入预算：目标 ≤300 行；301–400 行可接受但应精简；超过 400 行需在文档中说明内聚例外，否则视为超预算，按 docs-numbering 规则先精简、再合并、最后拆分。应省略被否决的备选方案（各一行）、设计变更历史以及代码能更精确表达的内容。更新模式下被代码淘汰的章节应删除而非加注。
输出：带编号的技术规格文档，含 Overview、Requirements、Architecture、Implementation plan、Work breakdown、Testing strategy、Open questions。验证要点：方案覆盖所有需求点、架构图使用 Mermaid、风险有缓解策略、工作可拆分为可跟踪项、符合写入预算或已说明内聚例外。参考文件 references/template.md 提供模板与评审维度。文件位置为 docs/features/{feature}/，含 2-tech-spec.md、requests/ 与 README.md。示例：输入 /tech-spec "Implement user asset snapshot feature" 会依次执行需求澄清、代码研究、方案设计、输出文档；输入 /review-spec docs/features/xxx/2-tech-spec.md 会读取、研究、评审并输出报告与门禁。