How do I install the Activation skill?

Run npx skillmds@latest add harshanandak/activation in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Activation safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Activation?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Activation free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Activation?

harshanandak (@harshanandak) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Activation by harshanandak — Agent Skill

Name: Activation
Author: harshanandak

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.

harshanandak 14e8646 2.9 KB Updated Sep 17, 2026

File contents

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.

---name: activationdescription: 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.---# Forge activation (front door)You are orienting a project where Forge is available (installed as a global pluginor 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 whatlazily initializes `.forge/`.## Orient first (state findings BEFORE offering)Run read-only checks, then STATE what you found in one short paragraph before youoffer 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 youoffer 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 hookson their behalf unless they ask.## Terminal state → next stepThis 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.

Frequently asked questions