# Using Forge > Forge dispatch skill: the session bootstrap that makes Forge's skills auto-trigger as a reasoning-driven SYSTEM. Reach for this FIRST, before ANY response (including clarifying questions, codebase exploration, or file reads), whenever there is even a 1% chance a Forge skill applies. Carries the 1%-rule, the announce-before-acting rule, an anti-rationalization red-flags table, a subagent escape hatch, and an intent-to-skill routing table: add/build/scope a feature to plan; implement an existing task to dev; fix a failing test or bug to dev (debug first); type-check/lint/tests to validate; push and open a PR to ship; address PR/review feedback to review; post-merge health to verify; what to work on to triage-ready; where am I / current stage to status; create/close/search an issue to issue-basics; drive one issue end-to-end to smith; monitor a PR to shepherd. Run `forge skill for ""` for a deterministic fallback. NOT itself a stage; the kernel skill is the fuller umbrella index once oriented. - Skill: `harshanandak/using-forge` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add harshanandak/using-forge` - Raw SKILL.md: https://api.skillmd.com/api/skills/harshanandak/using-forge/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: harshanandak (https://skillmd.com/u/harshanandak) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/harshanandak/using-forge --- If you were dispatched as a subagent to execute one specific task, ignore this skill and do the task you were given. This dispatch rule is for the top-level session, not for a scoped subagent — otherwise every subagent would re-enter routing instead of working. If you think there is even a 1% chance a Forge skill applies to what you are doing, you MUST invoke that skill BEFORE any response or action. 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 ""` 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 ""` 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.