Steer Tech 是一个用于生成或完善团队技术指南文档的技能，目标文件为 docs/steering/TECH.md。该文档是技术栈、架构模式以及每位实现者都必须遵守的约束的权威参考。
用途 当团队希望创建或完善技术指南文档时使用本技能，例如要求创建技术 steering 文档或记录团队技术规范。
工作流程 本技能遵循共享的 steering-doc 流程：存在性检查 → 调研 → 访谈 → 起草 → 评审 → 写入 → wiki 同步 → 继续。该共享流程位于 ../references/steering-doc-process.md，本技能在其基础上提供特定输入：文档路径为 docs/steering/TECH.md，模板为 references/tech-template.md，显示名称与 wiki 页面为 WTF-Tech.md，提交信息为 "docs: add technical guidelines steering document"。
调研环节 在调研步骤中，使用 Agent 工具提取技术事实，而不是向用户询问本可读取到的内容。调研清单包括：技术栈（从 package.json、pyproject.toml、go.mod、Cargo.toml、*.csproj 或同类文件读取语言、框架与版本）；架构（模块结构、目录布局、分层模式）；测试框架（现有测试文件、package.json 中的测试脚本）；命令（package.json scripts、Makefile、justfile、CI 配置）；ADR（docs/adr/、docs/decisions/ 或内联决策记录）；约定（命名模式、导入路径、测试文件位置）；以及 CLAUDE.md 和任何现有的架构文档。调研完成后应仅凭调研结果就能产出一份具体的 Stack、Commands 和 Code Conventions 草稿，这些部分不应需要用户输入。
访谈环节 仅询问调研无法确定的缺口话题。对每个未回答项，按照 ../references/questioning-style.md 调用 AskUserQuestion。具体问题包括：关键约束——问题为“是否存在每位实现者都必须遵守的不可让步项？”，标题为 Key constraints，选项可从 CLAUDE.md 或现有文档中预填约束；架构决策——问题为“是否存在塑造了架构但尚未记录的决策？”，标题为 Architecture decisions，选项可从代码库结构中推断的模式预填；已知痛点——问题为“是否存在需要特别留意的代码区域？”，标题为 Known pain points，选项可从 README 或注释中标记的内容预填。
写作规则 在撰写任何持久正文之前，按照 ../references/ste-writing.md 应用严格的 STE 文风（共享流程的步骤 4 也要求如此）。命令必须准确且经过测试，过时的命令比没有命令更糟。架构描述应反映代码库的实际行为，而不是陈述愿景。约束以祈使句形式书写（例如“请求路径上不允许同步 I/O”）。ADR 在存在源文件时链接到源文件，仅内联决策与理由。
后续选项 完成技术文档后，本技能提供继续选项：创建 DESIGN.md（运行 wtf.steer-design 以记录设计指南）、创建 QA.md（运行 wtf.steer-qa 以记录 QA 标准）、创建 VISION.md（运行 wtf.steer-vision 以记录产品愿景），或就此停止（退出，不做进一步操作）。
限制 该技能的具体效果、支持的平台、收费方式与价格等事实在所提供的资料中暂未提供。