# Activation

> 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.

- Skill: `harshanandak/activation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add harshanandak/activation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/harshanandak/activation/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/activation

---


# 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.

1. **Is Forge initialized?** `test -d .forge && echo present || echo absent`
2. **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).
3. **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.