absolute

Absolute — 开发工作流引擎

一个技能，十一个命令，通过 /absolute <command> [target] 调度。其中一个命令负责初始化， 其余命令分为两组：

初始化（每个仓库运行一次）：init — 访谈 + 技术栈检测 → 生成供其他命令读取的 JSON 配置。

构建循环（日常流程）： 思考 → 规划 → 构建（work） → 仅编写规格（spec） → 设计（ui） → 润色（simplify） → 编写文档（docs）

工程健康（在绿色的 main 上持续维护）： upgrade（依赖项） · audit（安全性） · prune（死代码） · debt（lint/类型） · deflake（不稳定测试）

每个命令的正文都位于 references/<command>.md。此文件充当路由器：判断用户需要哪个命令， 加载对应的参考文件并按其指示执行。各命令的参考文件篇幅较长且观点鲜明——只加载当前要用的那一个。五个 健康维护命令共用 references/health-engine.md 中的一个循环（由各命令分别加载）。

---

命令

命令	阶段	功能说明	参考
init	设置	一次性设置：询问你希望 absolute 如何运行（输出风格、自主性／门控、TDD 严格程度、规格目录、系列）+ 一次性检测技术栈，然后写入 .absolute.config.json（项目级，提交到仓库）以及可选的 ~/.absolute/config.json（用户默认值 + 按项目覆盖项）。其他所有命令都会读取配置，而不是重新检测；不会造成破坏，也不会提交更改。	references/init.md
work [target]	思考 · 规划 · 构建	端到端、按阶段门控的软件开发生命周期：深入的设计访谈 → 经审核的规格 → 带依赖关系图的任务看板 → 安全波次的 TDD 执行 → 验证 → 收敛。支持功能、缺陷、重构、从零构建、规划拆解和迁移。	references/work.md
spec [target]	规划	轻量级独立设计规格——适合想要一份用于讨论或交接的文档，而非立即构建的场景。扫描代码库 → 有限的澄清环节（几个问题，不会盘问）→ 将经审核的规格写入 docs/plans/ → 独立评分审核 → 结束。复用 work 的规格模板和评估标准。	references/spec.md
ui [target]	设计	使用具体的 CSS/Tailwind 值构建精致、考究的 UI：排版、颜色、布局、间距、深色模式、无障碍性、动画、组件。最全面的 UI 知识库，不提供含糊的建议。	references/ui.md
simplify [target]	润色	自主简化已暂存／未暂存的 git 更改或目标路径——降低复杂度、扁平化嵌套、移除冗余和无用代码——然后运行测试，确认没有破坏任何内容。	references/simplify.md
docs [target]	文档	以 Diátaxis 为指导的文档工作：编写、改进或审查教程、操作指南、参考资料、说明文档和开发者文档（README、CONTRIBUTING、ADR）。检测文档技术栈；根据代码核实每项说明。	references/docs.md
upgrade [target]	健康维护	依赖升级：列出过时／有漏洞的依赖，将升级安排到语义化版本波次中（批量处理补丁／次要版本，主要版本需经门控并阅读变更日志），逐步应用、重新生成锁文件，并在每次升级后确保测试通过。	references/upgrade.md
audit [target]	健康维护	漏洞与安全扫描（仅限防御用途，针对你自己的代码库）：检查依赖项 CVE 和高风险代码模式（机密信息、注入、脆弱的授权），按严重程度 × 可达性进行分级处理，并修复问题，不予抑制。可与内置的 /security-review 互补。	references/audit.md
prune [target]	健康维护	清理整个代码库中的无用代码和依赖：未使用的依赖、未引用的导出、不可达代码、孤立文件——仅在工具证据支持时才移除，并分可回退的波次进行。（针对差异范围的清理使用 simplify。）	references/prune.md
debt [target]	健康维护	清理 lint 和类型检查欠账：逐波处理每条规则，消除代码库中已有的 lint／类型违规和抑制项（@ts-ignore、# type: ignore），修复根因而非表象。（针对差异范围的质量改进使用 simplify。）	references/debt.md
deflake [target]	健康维护	修复不稳定测试：通过经验性检测（重复／打乱顺序／并行运行）找出非确定性测试，诊断根因并修复——绝不重试、跳过或休眠——并通过多次随机运行进行验证。	references/deflake.md

---

路由规则

每次调用时解析命令，然后转到对应的参考文档。

1. 首个词与某个命令匹配（init、work、spec、ui、simplify、docs、 upgrade、audit、prune、debt、deflake）→ 阅读 references/<command>.md 并严格遵循其中的说明。命令名称之后的所有内容均为目标／参数。

2. 首个词不匹配，但意图明显对应某个命令 → 加载该命令的参考文档，并按用户明确调用了该命令的方式继续：

   • “设置／初始化／配置 absolute”、“首次设置”、“记住我在这个仓库中的 约定／偏好” → init
   • “端到端构建 X”、“规划并构建”、“把这件事拆分成任务”、“就这个计划 详细问我”、“着手处理这个工单”、“运行这项迁移” → work
   • “编写规格说明”、“为这个功能编写规格”、“为 X 起草设计文档”、“我想 要一份供交接／评审的规格说明，暂时不要构建” → spec （与 work 的区别：spec 编写一份经过评审的设计文档后即停止；work 则编写文档并构建。如果不确定用户是否要立即构建，优先选择 spec——之后可以接着执行 work。）
   • “设计定价页面”、“调整这个组件的样式”、“让它看起来不那么像 AI 垃圾”、“修复间距／排版／颜色”、“深色模式” → ui
   • “简化这个”、“清理我的更改”、“重构这个”、“降低复杂度”、“删除 死代码”、“整理一下” → simplify
   • “编写文档／教程／README”、“记录这个内容”、“改进这份文档”、 “审查我们的文档”、“重构文档结构” → docs
   • “升级我们的依赖项”、“更新依赖版本”、“更新软件包”、“弃用 X， 改用其他方案”、“清理 Dependabot 积压项” → upgrade
   • “安全审计”、“我们是否存在漏洞”、“扫描 CVE”、“检查密钥／注入 问题”、“加固这个项目” → audit（防御性地审查整个仓库；对于待处理的差异，可配合内置的 /security-review 使用）
   • “删除死代码”、“查找未使用的依赖项／导出项”、“哪些内容可以删除”、“清理 孤立文件”（整个仓库范围） → prune
   • “修复 lint 警告”、“清除类型错误”、“切换到严格模式”、“清理 @ts-ignore／抑制项” → debt
   • “修复不稳定的测试”、“CI 不稳定”、“这个测试随机／间歇性失败” → deflake

   消歧：prune／debt 针对绿色状态的 main 分支，在整个仓库范围内执行；simplify 针对你的工作差异——根据范围选择命令。audit（该命令）会扫描整个仓库的安全问题；“审查我们的文档”仍应选择 docs。

   如果两个命令确实都适用，只询问一次用户想使用哪个。否则，选择明显匹配的命令，并说明加载了哪个命令。

3. 没有参数（单独输入 /absolute）→ 不要自动运行任何操作。展示上面的命令表，然后根据上下文推荐价值最高的 1～2 个后续命令（例如：有未提交的更改 → simplify；新工单或目标模糊 → work；若用户只想要一份供交接的设计文档，则选 spec；差异中有 UI 文件 → ui；文档缺失或过时 → docs；清单中的依赖过时／存在漏洞 → upgrade／audit；CI 失败或不稳定 → deflake；尚无配置 → 建议先运行 init）。推荐仅供参考，由用户确认。

4. 完全没有明确匹配的命令 → 将完整输入视为开发任务，并加载 work（默认生命周期），将输入作为任务说明。

配置解析（在移交给除 init 以外的任何命令之前）

按优先级由高到低叠加配置，以此解析有效配置：./.absolute.config.json（项目）→ ~/.absolute/config.json 中的 projects["<cwd>"] → ~/.absolute/config.json 中的 defaults。 对 conventions 和 preferences 执行浅合并。将解析后的偏好应用于命令 （输出样式、自主性/门控、TDD 严格程度、spec 目录）。

如果项目级和全局配置都不存在，输出一行，然后继续动态检测——不要阻塞：

未找到 Absolute 配置 — /absolute init 会缓存你的技术栈和偏好，让命令跳过重新检测。继续动态检测。

这是一条软性建议，每次调用最多显示一次。有关配置架构和优先级，请参阅 references/init.md。

加载命令参考后，遵循其自身的激活横幅、门控和流程。子命令参考不会重新调用此路由器。

---

所有命令共用的原则

• 先看代码库，再提问。 提问前先阅读现有内容；只询问代码无法解答的问题。
• 昂贵工作前先设门控。 work 在各阶段之间设置门控；docs 在大纲处设置门控；simplify 仅限于限定范围内的更改；spec 在审阅后的文档处停止，绝不开始构建；健康检查命令（upgrade/audit/prune/debt/deflake）会按风险等级呈现发现，并在应用任何修复前设置门控。绝不悄然扩大范围。
• 验证，不要假设。 用测试、实际输出和经代码核实的事实证明行为——绝不作空泛承诺。
• 绝不自动提交。 每个命令都会写入文件并报告；由用户提交。