Cross-Agent Usage

Feature Forge’s skills are vendor-neutral canon; Claude Code is the first-class surface, but the same pipeline runs on other coding agents via generated adapter bundles. For first-time install steps see install.

Claude Code (preferred)

Install via the plugin marketplace:

/plugin marketplace add garygentry/feature-forge
/plugin install feature-forge@feature-forge

Skills are invoked as slash commands like /feature-forge:forge-init. Claude installs under ~/.claude.

Other agents (Codex, Copilot, Cursor, Gemini)

Install with the universal one-liner, which copies the generated adapter bundle into each detected agent’s config directory:

npx @garygentry/feature-forge install            # all detected agents
npx @garygentry/feature-forge install -a codex   # one agent (codex|copilot|cursor|gemini|claude)
npx @garygentry/feature-forge install --dry-run --json   # preview the plan, change nothing

The --dry-run --json plan reports the resolved install destination per agent. Claude’s ~/.claude is the only hard-coded well-known destination; for the others the destination comes from the dry-run plan.

Checking what’s installed

Run npx @garygentry/feature-forge list (optionally -a <agent>) to show per-agent installed / up-to-date status.

Self-contained bundles

Every installed adapter bundle is self-contained: it ships the neutral .feature-forge-bundle.json sentinel plus byte-identical copies of every runtime helper a skill can invoke (forge-root.sh, forge-init.sh, epic-manifest.py, validate-traceability.py, forge-bootstrap.py). The portable resolver scripts/forge-root.sh self-locates from the installed location via the neutral sentinel (and honors FEATURE_FORGE_ROOT), so helper-backed skills run after install on any agent — no dependency on Claude-only files.

For agents whose install spans a second root, the installer also places the bundle where that agent actually loads it: Codex custom agents are mirrored into .codex/agents/*.toml, and Copilot’s native SKILL.md skills and .agent.md custom agents are mirrored into .github/skills/ and .github/agents/ (personal scope: ~/.copilot/skills/ and ~/.copilot/agents/) next to one complete runtime at .github/feature-forge/ (~/.copilot/feature-forge/). Each mirrored file is recorded in the install manifest, so uninstall removes exactly what the installer wrote.

GitHub Copilot

Copilot loads feature-forge natively; nothing is written into .github/copilot-instructions.md. The skill name depends on how the bundle was installed: a direct install (the npm installer) exposes /<name>, a Copilot plugin install exposes /feature-forge:<name>. Skill text therefore says invoke-skill: <name>, and each skill’s Copilot host notes map it to your form. Install the Copilot plugin with copilot plugin marketplace add garygentry/feature-forge and then copilot plugin install feature-forge@feature-forge: the repository’s Copilot marketplace (.github/plugin/marketplace.json) serves the Copilot bundle, while Claude Code keeps reading .claude-plugin/marketplace.json. The npm installer (npx @garygentry/feature-forge install -a copilot) remains the compatibility path, for project-scoped installs or when Copilot plugins are unavailable.

Installs from installer 0.3.9 or earlier (which wrote an instructions-file block) migrate with npx @garygentry/feature-forge update -a copilot (-g for personal). The full guide covers runtime roots and FEATURE_FORGE_ROOT, migration conflicts, list / doctor diagnostics and uninstall: feature-forge on Copilot.

The loop runner across agents

At Stage 5 the coding agent that runs the loop is chosen by precedence: item.provider > --agent (run-level) > project defaultAgent > the runner’s default (claude-cli). The agent (who runs each item) is selected separately from the model (which model that agent uses) — an item’s model alias never decides the agent. If you select a non-Claude agent but your backlog items carry Claude model aliases, the loop warns and offers to strip them or proceed.