| name | activation |
| description | Forge's front door — invoke FIRST when starting work in a project that has Forge available but you are not yet oriented: no `.forge/` yet, a fresh session, or the user says "/activation", "set up Forge", "start Forge", "is Forge active here?". Orients on the actual repo (detects project type, states findings) BEFORE offering anything, then offers the bare-minimum gates-disabled setup WITHOUT forcing it. Do NOT use this to run a specific stage (use /plan, /dev, /status, /ship directly) or once `.forge/` is already initialized and you know the workflow.
|
| allowed-tools | Bash, Read, Grep, Glob |
Forge activation (front door)
You are orienting a project where Forge is available (installed as a global plugin
or an npm dev-dep) but not yet engaged. Your job is to orient first, then offer —
never force. This skill creates nothing by itself; a mutating forge verb is what
lazily initializes .forge/.
Orient first (state findings BEFORE offering)
Run read-only checks, then STATE what you found in one short paragraph before you
offer any setup. Do not opine or prescribe before you have looked.
- Is Forge initialized?
test -d .forge && echo present || echo absent
- What kind of project is this?
package.json present → JS/TS project (note the package manager: bun/npm/pnpm/yarn lockfile).- Markdown-heavy, no
package.json → docs / planning repo.
- Otherwise → describe what you see (language, build files).
- Is it a git repo?
git rev-parse --is-inside-work-tree 2>/dev/null
Then say, in your own words: "Here's what this project looks like today: …" —
project type, whether .forge/ exists, git status. Only after stating this do you
offer anything.
Then offer the bare minimum (never forced)
Present setup as a conversational choice, not a mandate:
- If
.forge/ is absent: explain that Forge needs no setup step to be useful —
read-only verbs (forge status, forge ready, forge show <id>) work immediately
and write nothing. The first mutating verb (forge claim, forge create,
forge remember) lazily creates a bare-minimum, gates-disabled .forge/
skeleton. Nothing heavier (git hooks, lefthook, protected paths, .mcp.json,
scripts tree) is installed unless the user later runs forge setup.
- If
.forge/ is present: say so and route to the right stage instead — this
skill's work is done.
Offer, then stop and let the user choose. Do not run forge setup or install hooks
on their behalf unless they ask.
Terminal state → next step
This is a front-door primitive, not the full workflow. After orienting and offering:
- New / unscoped work ("let's build X") → the one next step is
/plan.
- A known task to implement →
/dev.
- "Where am I / what's ready?" →
/status or forge ready.
- A bug or failure →
systematic-debugging, then the matching stage.
Name the single next step explicitly and hand off. Do not implement here.
