IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. You cannot rationalize your way out of it.
The rule
Invoke the relevant or requested Forge skill BEFORE any response or action — including clarifying questions, exploring the codebase, or checking files. If it turns out wrong for the situation, you don't have to follow it — but you check first.
Then announce Using [skill] to [purpose] and follow the skill exactly. If it has a
checklist or HARD-GATE, create one todo per item.
When unsure WHICH skill fits, either consult the routing table below or run
forge skill for "<what you are about to do>" for a deterministic best-fit answer.
Intent → skill routing table
Process skills set the approach first; then the stage/implementation skill carries it out.
| When the situation is… | Start with |
|---|---|
| "Add / build / scope a new feature", "let's build X" | plan |
| Implement a task that a plan already defined | dev |
| "Fix this bug" / a failing test / unexpected behavior | dev (if superpowers:systematic-debugging is installed, apply its technique first, then implement via dev) |
| Run type-check, lint, security, or tests | validate |
| Push the branch and open a PR | ship |
| Address PR / review-agent feedback (CodeRabbit, Greptile, CI) | review |
| Post-merge health check, close issues | verify |
| "What should I work on?" — rank the ready queue | triage-ready |
| "Where am I?" / current stage / stale or active work | status |
| Create / update / close / search / comment on ONE issue | issue-basics |
| Claim an issue and PROVE the lease before mutating | claim-safety |
| Drive one issue plan→merged-PR under human gates | smith |
| Monitor / shepherd a PR's CI + checks (never merges) | shepherd |
| Deep, multi-source web research | research / parallel-deep-research |
| "How does Forge fit together?" / which verb for X | kernel |
| Safe revert / undo a merged change | rollback |
If two skills seem to apply, run the process skill first (plan, systematic-debugging), then
the doing skill. kernel is the umbrella index — use it to orient, not to do the work.
Red flags — these thoughts mean STOP, you are rationalizing
| Thought | Reality |
|---|---|
| "This is just a simple question" | Questions are tasks. Check for a skill. |
| "I need more context first" | The skill check comes BEFORE clarifying questions. |
| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
| "I can check git/files quickly" | Files lack conversation context. Check for a skill. |
| "This doesn't need a formal stage" | If a skill exists, use it. |
| "I remember what that skill says" | Skills evolve. Read the current version. |
| "The skill is overkill here" | Simple things become complex. Use it. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "It's obviously a plan/dev/ship" | Then invoking it costs nothing. Invoke it. |
Subagent escape hatch
You do NOT have to hold every skill in your own context. When a task is independent and
bounded, dispatch a subagent with the specific skill and a self-contained brief, and keep only
its conclusion. Parallelize independent tasks (see superpowers:dispatching-parallel-agents).
Reviewers/verifiers that find nothing must say so and name what they inspected.
Agent-agnostic
This skill syncs to every harness mirror (.agents/, .claude/, .codex/, .cursor/,
.hermes/), and the same routing guidance is reachable via forge skill for "<situation>" on
any harness — never branch on harness identity. On Claude the SessionStart hook injects this
text automatically; elsewhere, AGENTS.md points here and the CLI router is the fallback.
User instructions win
CLAUDE.md / AGENTS.md and direct user requests take precedence over skills, which in turn override default behavior. Skip a skill only when your human partner explicitly tells you to.