fongzhizhi

openspec-apply-change

Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.

openspec-archive-change

Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.

openspec-explore

Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.

Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.

openspec-sync-specs

Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.

openspec-update-change

Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Never edits code.

Data & Documents Listed

ones-parser

解析 ONES 项目管理平台（ones.com、ones.yourcompany.com 等）复制出来的工单内容——识别工单 ID（PRO-/WIKI-/TASK-/BUG- 等前缀）、标题与链接，输出结构化结果供对话使用或 commit 引用。当对话中出现 ONES 链接、ONES 工单粘贴内容、"PRO-xxx"、"WIKI-xxx" 等 ONES 单号标识时使用。

comment-keeper

按 TS 注释规范指南统一调整代码注释——核对、增删改注释，补录错误和不合适的注释，必要时调整代码结构使其自解释。默认处理 git diff 变更的 TS/TSX 文件，支持手动指定函数、文件或目录。当用户要求整理/统一/修复代码注释、执行注释规范、清理过期注释时使用。

Testing & QA Listed

test-keeper

按 TS 测试规范补充与修复单元测试——根据 git diff 判定当前业务模块，无测试时启动 openspec-propose 编写测试方案，有测试时按规范审查质量（注水、漏洞、覆盖率、断言质量），问题多输出报告并建议方案、问题少直接优化。当用户要求补充/修复/审查单元测试、执行测试规范、清理注水测试、分析测试质量时使用。

error-handling-keeper

按 TS 错误处理规范修复存量代码——语义等价改动直接做（catch 变量 unknown 化、补错误日志、throw 裸值改 Error 实例、保留 cause），控制流改动列清单（补 try/catch、新增边界校验、catch 后中断或跳过）。当用户要求修复错误处理、消除静默 catch、执行错误处理规范、补充异常日志时使用。

Code & Development Listed

live-debugger

埋点数据驱动的前端 bug 排查技能：快速定位数据流转关键节点 → console.log 埋点（埋点明细对用户透明、可人工确认位置）→ 浏览器复现（默认人工复现，AI 自动复现按需启用）→ 读 console 数据 → 收��闭环。核心哲学：埋点数据是主要信息来源，代码分析只服务于选埋点位置；复现是每轮必做的验证动作，人工复现是默认方式（最快最稳），AI 自动复现是可选加速。当用户描述前端 bug、要求定位/调试/排查/修复问题时使用。

quick-start

快速测试功能或新改动：理解诉求后自动注入测试代码（便捷入口、硬编码、mock 数据、console.log 埋点），减少用户操作步骤，验证功能与数据是否符合预期，验证完成后清除全部注入代码恢复原状。依赖浏览器控制 MCP（chrome-devtools / playwright 等）。当用户想快速验证某个功能、测试新改动、入口太深或没有入口、需要 mock 数据时使用。

style-keeper

按 TS 编码风格规范统一存量代码——命名规约（camelCase/PascalCase/UPPER_SNAKE_CASE、布尔 is/has 前缀）、文件名 kebab-case、魔法数字提取、单文件职责。优先用 ESLint/Prettier 自动兜底，工具修不了的再手工改，改名遵循安全分级。当用户要求统一/修复代码风格、执行编码风格规范、整理命名、清理魔法数字时使用。

type-keeper

按 TS 类型安全规范修复存量代码——清除 any、替换 @ts-ignore、消除非空断言、import type、type/interface 场景校正、泛型约束、外部数据运行时校验。改动按风险分级：编译期语义直接做、行为等价验证后做、运行时校验列清单，tsc --noEmit 全绿为交付门禁。当用户要求修复类型安全、清理 any、执行类型规范、消除 @ts-ignore 时使用。

prompt-crafter

把粗略的需求描述优化成高质量、可直接使用的 AI prompt。用户说"帮我优化/改进/写个 prompt、提示词、提示语"，或描述一个需求并希望得到更严谨的提示词时使用。会结合当前会话上下文分析需求与预期，按"诊断 → 选技术 → 重写 → 自检 → 输出"流水线生成，输出为 markdown 文档（含可直接复制的 prompt 代码块 + 主要改动说明），方便直接复制使用。触发词：优化 prompt、改进提示词、帮我写个 prompt、prompt engineering。

month-log-summary

为 month-log 月工作日志生成/覆盖「AI月总结」章节：阅读月总结数据、月计划与任务记录，生成先数据后结论的主观叙述总结，写回文档末尾（已存在则整体覆盖，不询问）。支持三种目标指定方式：显式文件路径 / 只给月份（当月、上个月、2026-07 等）/ 什么都不给（默认今天所在周的归属月，与 month-log init 一致）。用户要求生成或更新月总结汇报、述职月报、AI 月总结时触发。