# Auto Using Skills

> Use at the start of every task to select applicable skills. Routes bugs to debug and unclear changes to scope; never auto-selects manual-only review-spec or review-code.

- Skill: `swm8023/auto-using-skills` (Agent Skill)
- Install (CLI): `npx skillmds@latest add swm8023/auto-using-skills`
- Raw SKILL.md: https://api.skillmd.com/api/skills/swm8023/auto-using-skills/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: swm8023 (https://skillmd.com/u/swm8023)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/swm8023/auto-using-skills

---


<SUBAGENT-STOP>
如果你是作为 subagent 被派遣来执行某个特定任务，请跳过这个 skill。
</SUBAGENT-STOP>

# auto-using-skills

## 核心规则

在任何回复、澄清、读文件、写代码或运行命令之前，先检查 skill。只要某个 skill 有 1% 的可能适用，就必须调用 Skill 工具读取它。

用户指令始终最高优先级；skill 决定的是**怎么做**，不覆盖用户明确说的**做什么**。如果调用后发现某个 skill 不适用，说明原因并继续检查其他 skill。

## 路由

按顺序判断：

1. **用户点名 skill**：先调用被点名的 skill。
2. **仅限手动触发**：遵守 skill 的显式限制，包括 `disable-model-invocation: true`、`agents/openai.yaml` 中的 `allow_implicit_invocation: false` 或仅限手动触发的说明。`$skill-name`、`/skill-name` 或明确要求使用该 skill 才算点名；普通的“review”“审查”“audit”不算。没有点名时继续执行后续路由，不要因意图或 description 相似而自动选择它们。
3. **WheelMaker session 默认交接**：用户提供 session ID 并要求继续、总结、交接或未说明导出目的时，调用 `handoff`。只有用户明确点名 `export-session`/`$export-session` 并要求导出诊断 JSON 时才调用 `export-session`；session ID 本身永远不触发导出。
4. **执行已确认范围或修复**：用户已批准 spec、scope 已取得对话内实施契约确认，或 debug 已提交证据充分的修复契约且用户明确批准时，调用 `implement`。bug 使用 `source_kind: approved-fix`；此项优先于通用 bug 路由，即使确认消息再次提到“bug”“失败”或“修复”。
5. **新的 bug / failure**：用户报告坏了、报错、测试失败、build 失败、flaky、变慢、性能退化或行为不符合预期，且还没有获批修复契约时，调用 `debug`。不要先走 `scope`。
6. **项目知识 / wiki**：用户要沉淀、查找、整理或迁移项目长期知识，维护 `docs/wiki` 时调用 `wiki`；固定 WheelMaker Vault 的检索用 `pubwiki-search`，写入和发布用 `pubwiki-markdown`。按用户目标和已有路径确定知识库，不同时启动两套写入流程。
7. **未定需求**：用户要加 feature、设计行为、改交互、新建系统、重构、规划或 review，且范围还没钉清，调用 `scope`。
8. **Git 工作流**：纯只读调查、对话内需求澄清和不落盘的计划不调用 `git-workflow`。首次持久化写入前必须已有 `prepare`；已验证的独立工作单元按需调用 `checkpoint`；任务结束或外部 handoff 前必须调用 `finalize`。同一任务在 Skill 间转交时，`git_state: prepared` 继承现有 Git 生命周期，`git_state: unprepared` 才执行 `prepare`。调用时必须写明阶段，不能只说“参考 Git 偏好”。
9. **即将写生产代码**：如果下一步会实现新行为、重构或改现有行为，统一由 `implement` 按内置测试先行契约执行。bug 修复必须先由 debug 形成并获批 `approved-fix`，再交给 implement；不要从 debug 或“确认”消息直接开始修改生产代码。
10. **其他匹配 skill**：任何 skill 的 description 命中当前任务，就调用它，但不得绕过第 2 条的手动触发限制。

## 调用后

调用 skill 后：

1. 告诉用户：`Using [skill] to [purpose]`。
2. 如果 skill 有 checklist，把每项登记为 todo。
3. 严格按 skill 内容执行，再回复用户。

## 警示信号

出现这些想法时，停下来重新检查 skill：

- "先问个澄清问题再说"：澄清前也要检查 skill。
- "先看文件 / 跑命令"：行动前也要检查 skill。
- "这很简单"：简单任务也可能有适用 skill。
- "我记得这个 skill"：读取当前版本，不凭记忆执行。
- "用户说了修 bug，所以直接修"：用户说的是目标，不是允许跳过 debug。
- "已经 scoped / debug 过了，可以直接写代码"：先把已确认契约交给 implement，由它建立 Git 所有权并执行测试先行流程。
- "用户确认了 bug 方案，直接开始修"：先把 `approved-fix` 交给 implement，不在 debug 内实施。
- "开始时已经调用过 Git skill，结束时不用再调"：prepare 不能替代 finalize。
- "写一句未提交就可以结束"：如果偏好要求自动提交或推送，必须完成动作或给出明确 blocker。