using-agent-skills
Use when starting a new session, switching tasks, or unsure which arthurpower skill applies. Routes incoming work to the matching skill via flowchart before invoking. Activates on phrases like "which skill should I use", "skill check", "pre-task skill check", "how to start", "router", "skill routing", or when multiple competing skills could apply. Does not auto-invoke user-invoked authoring skills (skill-authoring, self-evolving-rules).
- License 许可
- MIT
- 最近更新
- 2026-10-28
- Stars
- ★ 2
- Forks
- 0
01 前言 Front Matter
- name
- using-agent-skills
- type
- discipline
- bucket
- engineering
- description
- Use when starting a new session, switching tasks, or unsure which arthurpower skill applies. Routes incoming work to the matching skill via flowchart before invoking. Activates on phrases like "which skill should I use", "skill check", "pre-task skill check", "how to start", "router", "skill routing", or when multiple competing skills could apply. Does not auto-invoke user-invoked authoring skills (skill-authoring, self-evolving-rules).
02 资源文件 6
- 参考文档references/behaviors.md1.5 KB
- 参考文档references/flowchart.md3.1 KB
- 参考文档references/git-workflow.md7.4 KB
- 参考文档references/landing.md867 B
- 参考文档references/quick-reference.md3.0 KB
- 参考文档references/router-maintenance.md795 B
03 SKILL.md 正文
Using Agent Skills
Skill router for the arthurpower collection. It names the task class and the current slot in any documented sequence, then invokes that one skill. It does not do the downstream work.
User-invoked only (disable-model-invocation: true on the target): skill-authoring, self-evolving-rules. The operator must name them. Other skills, including dispatching-parallel-agents, are model-invoked playbooks the current agent may run when their triggers match.
When to use
- A new session whose first task is unclassified
- The user asks which skill / how to start / skill check / routing
- Several skills could match (ambiguous routing)
- Switching task class mid-session (planning → implementing → verifying)
Skip when the task already maps to one skill, the user already named a skill, the edit is trivial, or the work is outside this graph.
Procedure
-
Classify. Match the task to one branch in
references/flowchart.md(Defining / Planning / Implementing / Verifying / Reviewing / Committing / Meta). Scale (single vs multi-session) selects a sequence, not a pile of skills in one turn. Completion: one branch label, and if scale applies, the sequence named. -
User-invoked gate. If the match is
skill-authoringorself-evolving-rulesand the user did not name it, stop and ask. Completion: either a different skill, or the user named that skill. -
Current slot. Documented sequences (SPECIFY →
architecture-change-reviewer→ persist →writing-plans;code-review→review-report-repairwhenGATE: BLOCKED) are ordered gates. Invoke this slot only; do not stack the whole sequence. Competing skills for the same slot (e.g. ACR andcode-reviewas "the review") are not a sequence — pick one. Completion: the slot's skill name. -
Invoke. State the routing decision in one sentence, then invoke that skill. CONTEXT / ADR writes go through
domain-modelingwhen a persist list exists. Completion: the chosen skill started.
Promoted skill add / rename / remove / flow-placement updates this file and references/quick-reference.md in the same change. Default landing sequence: references/landing.md. Details: references/router-maintenance.md.
Registered skills (hook mirror)
hooks/pre-release-validate.ts greps this SKILL.md for each sibling directory basename. Keep every promoted skill named below. Phase / trigger tables live in references/quick-reference.md, not here.
- architecture-change-reviewer
- boundary-testing
- bounded-context-guardian
- code-review
- review-report-repair
- complexity-anti-drift
- input-contract-tests
- dispatching-parallel-agents
- domain-modeling
- error-handling-enforcer
- logicsync
- minimal-change-verifier
- self-evolving-rules
- session-handoff
- setup-arthurpower
- skill-authoring
- spec-driven-development
- systematic-debugging
- test-driven-development
- verification-before-completion
- wayfinder
- writing-plans
Acceptance
- [ ] Flowchart branch chosen before any skill invoke
- [ ] One task class; if a sequence, only the current slot invoked
- [ ] User-invoked authoring skills not auto-started
- [ ] Routing stated in one sentence
- [ ] No catch-all meta skill when a focused skill matches
References
references/flowchart.md— branches including scale sequencesreferences/quick-reference.md— phase / trigger / user-invoked vs model-invokedreferences/router-maintenance.md— add / rename / remove / flow-placementreferences/behaviors.md— optional operating habits (not routing)
04 同仓库更多 Skills
writing-plans
Use when turning a buildable spec into ordered tracer bullets after architecture-change-reviewer. Covers vertical slicing, dependency order, and headroom for the implementer. Triggers on 写计划, 拆任务, 任务分解, 制定方案, 跨文件改动, 计划.
wayfinder
Use when a chunk of work is more than one agent session can hold — plan it as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
verification-before-completion
This skill should be used when claiming "完成" / "done" / "fixed" / "passing" / "ready to ship", before trusting a subagent success report, or when checking "对照计划" / "对照 spec" — whether this run's delivery matches its basis.
test-driven-development
Use when implementing logic, fixing a bug, or changing behavior — write the failing test first (RED), then minimal code (GREEN), then refactor. Triggers on "write the failing test first", "Prove-It", or a bug that needs a reproduction test before the fix.
systematic-debugging
Use when debugging a test failure, build break, unexpected runtime error, flaky test, or hanging process. Triggers on phrases like "fix this bug", "getting an error", "failing test", "flaky", "hanging", "halfway through debugging", "this used to work", "intermittent failure", "stack trace shows X", or any case where behavior does not match expectations. Prevents shotgun debugging.
spec-driven-development
Use when the work isn't a spec yet — a one-line ask, multi-file change, ambiguous scope, or architectural decision on the table. Spec-driven-development captures what to build, why, and how to know it's done before any plan or commit. Skip for single-line fixes or bounded bug fixes.