Convert forge commands to skills (cross-platform)

README.md

@@ -5,7 +5,7 @@
 [![Stars](https://img.shields.io/github/stars/dasirra/cc-forge?style=flat-square&color=B0680F)](https://github.com/dasirra/cc-forge/stargazers)
 [![Last commit](https://img.shields.io/github/last-commit/dasirra/cc-forge?style=flat-square&color=3D5A9E)](https://github.com/dasirra/cc-forge/commits/main)
 
-An opinionated idea-to-PR workflow for [Claude Code](https://claude.com/claude-code), with a human gate at each seam. Three commands, run in order.
+An opinionated idea-to-PR workflow for [Claude Code](https://claude.com/claude-code), with a human gate at each seam. Three skills, run in order.
 
 ```
 PM   /forge:interview   vague idea         ->  docs/specs/YYYY-MM-DD-<slug>.md
@@ -49,17 +49,17 @@ The other two need:
 - **A way to run your project and observe it from outside.** `/forge:building` resolves an *evaluation surface* up front (`web`, `library`, `cli`, `service`, or `native`) and black-box tests the contract against it. Only `web` needs an extra dependency: a browser automation MCP server, Claude in Chrome or Playwright.
 - **`/code-review`**, invoked by `/forge:building` for the final review of the integrated diff.
 
-## Commands
+## Skills
 
-| Command | Altitude | Description |
+| Skill | Altitude | Description |
 |---------|----------|-------------|
 | `/forge:interview [idea \| path/to/brief.md]` | PM | Relentless one-question-at-a-time grilling until you and Claude share an understanding of the idea, then synthesis into a PM-level spec. No code, no issues. |
 | `/forge:planning [path/to/spec.md \| description]` | PM | A planner drafts an epic with user stories, a critic attacks it in a separate context, they iterate up to 3 rounds. Files the result as a GitHub epic with native sub-issues for async human review. No technical content: no files, no schemas, no architecture. |
 | `/forge:building <#issue ...> [--no-gate] [--max-rounds N] [--base <branch>] [--surface <name>]` | DEV | A generator and evaluator negotiate a granular contract of "done" against the live codebase, a team builds in an isolated worktree, then the evaluator black-box tests the running artifact against that contract until it passes: driving a browser for a web app, calling the public API for a library, running argv and reading exit codes for a CLI. Opens a PR. |
 
 ## Pipeline
 
-Adversarial pairs (⚔) never share context. They exchange files, relayed by the orchestrator. Every 👤 is a stop: the command hands you an artifact and prints the next step rather than running it.
+Adversarial pairs (⚔) never share context. They exchange files, relayed by the orchestrator. Every 👤 is a stop: the skill hands you an artifact and prints the next step rather than running it.
 
 ```mermaid
 flowchart TD
@@ -115,11 +115,11 @@ Every phase, agent, artifact, and loop is laid out in the [full pipeline referen
 
 ## Design
 
-Three ideas run through all three commands.
+Three ideas run through all three skills.
 
 **Separate contexts, artifacts only.** Every adversarial pair (planner/critic, generator/evaluator) communicates through files, never through summarized reasoning. A critic that sees the planner's rationale rubber-stamps it.
 
-**Altitude discipline.** PM commands describe behavior, the DEV command decides implementation, and the contract that binds them is negotiated against the codebase as it exists at build time, so it cannot go stale between planning and building. See [Two altitudes](#two-altitudes).
+**Altitude discipline.** PM skills describe behavior, the DEV skill decides implementation, and the contract that binds them is negotiated against the codebase as it exists at build time, so it cannot go stale between planning and building. See [Two altitudes](#two-altitudes).
 
 **Observed behavior beats claims.** `/forge:building` will not accept "mostly works". Each contract criterion passes or fails, judged by an evaluator driving the running artifact, not by reading the diff and not by running the builder's own tests. Those tests encode the builder's understanding, so a green suite certifies whatever misunderstanding produced the bug.
 
@@ -131,7 +131,7 @@ Forge is Claude Code specific, and not incidentally so. It depends on subagents
 
 Forge is an opinionated idea-to-PR workflow. It assembles ideas that are not mine, and the opinions and the mistakes in assembling them are.
 
-Mine are the three-command shape with a human gate at each seam, `/forge:planning` as an adversarial PM-level pass that files straight to GitHub and leaves contested items for a human to arbitrate, the altitude discipline that bans technical content until `/forge:building` negotiates it against the live codebase, the evaluation surfaces and the preflight that resolves one before anything expensive happens, and the rule that the evaluator never runs the builders' own tests.
+Mine are the three-skill shape with a human gate at each seam, `/forge:planning` as an adversarial PM-level pass that files straight to GitHub and leaves contested items for a human to arbitrate, the altitude discipline that bans technical content until `/forge:building` negotiates it against the live codebase, the evaluation surfaces and the preflight that resolves one before anything expensive happens, and the rule that the evaluator never runs the builders' own tests.
 
 **[Full Walkthrough: Workflow for AI Coding](https://www.youtube.com/watch?v=-QFHIoCo-Ko)**, Matt Pocock, at [AI Engineer](https://www.ai.engineer/). The grilling session that became `/forge:interview`, the smart zone and dumb zone, slicing work into vertical issues an agent can pick up independently, and the distinction between running an agent human-in-the-loop and running it AFK, unattended and away from the keyboard.
 

docs/harness-bindings/README.md

@@ -1,10 +1,10 @@
 # Harness bindings
 
-Forge's commands (`commands/*.md`) are written in harness-neutral prose: role
+Forge's skills (`skills/*/SKILL.md`) are written in harness-neutral prose: role
 tiers (`judgment-tier`, `labor-tier`) and generic verbs, instead of any one
 agent's tool and model names. Each supported harness has a binding doc in this
 directory that maps those neutral terms to its concrete tools and models. A
-command's **Harness binding** preamble points the running agent at the binding
+skill's **Harness binding** preamble points the running agent at the binding
 for its environment; the agent resolves every neutral term through it before
 acting.
 
@@ -14,10 +14,10 @@ compare harnesses, read this file.
 
 ## Available bindings
 
-- [`claude-code.md`](claude-code.md) — Claude Code. Judgment/labor tiers map to
+- [`claude-code.md`](claude-code.md): Claude Code. Judgment/labor tiers map to
   distinct models (opus / sonnet); binding is an exact-string substitution
-  (a round-trip check verifies it reconstructs the original command text).
-- [`pi.md`](pi.md) — Pi with open-weight models. Every tier maps to one model
+  (a round-trip check verifies it reconstructs the original skill text).
+- [`pi.md`](pi.md): Pi with open-weight models. Every tier maps to one model
   (GLM-5.2); binding is semantic (the agent interprets each phrase). Requires
   forked-context subagents (`pi-subagents`); the `native` evaluation surface is
   unavailable.

docs/harness-bindings/claude-code.md

@@ -1,13 +1,13 @@
 # Claude Code binding
 
-Forge's commands (`commands/interview.md`, `commands/planning.md`,
-`commands/building.md`) are written in harness-neutral prose: instead of
+Forge's skills (`skills/interview/SKILL.md`, `skills/planning/SKILL.md`,
+`skills/building/SKILL.md`) are written in harness-neutral prose: instead of
 naming a specific coding agent's tools or models, they use neutral verbs and
 tier markers that each harness binds to its own equivalents. This doc is
 the Claude Code binding: it maps every neutral phrase used in the prose to
 the concrete Claude Code tool or model tier that realizes it.
 
-| Neutral phrase (in commands/) | Claude Code binding |
+| Neutral phrase (in skills/) | Claude Code binding |
 | --- | --- |
 | judgment-tier | opus |
 | labor-tier | sonnet |
@@ -16,7 +16,7 @@ the concrete Claude Code tool or model tier that realizes it.
 | exploratory | Explore |
 | a working scratch location | the session scratchpad directory |
 
-Every left-hand phrase is the exact string as it appears in `commands/`;
+Every left-hand phrase is the exact string as it appears in the skills;
 binding is a literal substitution of that phrase by its right-hand value.
 The `exploratory` row is a single-word swap: it marks Claude Code's
 read-only **Explore** subagent, and substitution replaces only the word

docs/harness-bindings/pi.md

@@ -1,20 +1,20 @@
 # Pi binding
 
-Forge's commands (`commands/interview.md`, `commands/planning.md`,
-`commands/building.md`) are written in harness-neutral prose: instead of naming
+Forge's skills (`skills/interview/SKILL.md`, `skills/planning/SKILL.md`,
+`skills/building/SKILL.md`) are written in harness-neutral prose: instead of naming
 a specific coding agent's tools or models, they use neutral verbs and tier
 markers that each harness binds to its own equivalents. This doc is the Pi
 binding: it maps every neutral phrase used in the prose to the Pi coding
 agent's concrete tool or, for tiers, the open-weight model that realizes it.
 
-| Neutral phrase (in commands/) | Pi binding |
+| Neutral phrase (in skills/) | Pi binding |
 | --- | --- |
 | judgment-tier | GLM-5.2 |
 | labor-tier | GLM-5.2 |
 | an interactive question | a plain chat question to the user, options listed with the recommended one first |
 | the worktree helper | `git worktree add` |
 | exploratory | a read-only subagent (the `subagent` tool from `pi-subagents`, forked context) |
-| a working scratch location | a `harness/` directory inside the worktree, git-excluded (per the building command's `.git/info/exclude` step) |
+| a working scratch location | a `harness/` directory inside the worktree, git-excluded (per the building skill's `.git/info/exclude` step) |
 
 Read each neutral phrase in the prose as the Pi tool, model, or behaviour its
 right-hand value describes, and realise that behaviour: this is a semantic
@@ -28,7 +28,7 @@ the description into the sentence.
 
 Pi runs GLM-5.2 for every role; both `judgment-tier` and `labor-tier` map to
 it. The judgment/labor distinction stays legible in the prose but does not
-drive model selection here — there is no separate tier to select. What makes a
+drive model selection here; there is no separate tier to select. What makes a
 subagent an adversary is its separated context, not its weights, so a single
 model does not weaken the design on its own.
 
@@ -40,7 +40,7 @@ criterion on the first round.
 
 ## Required: forked-context subagents
 
-Forge's adversaries — planner vs critic, generator vs evaluator — only work
+Forge's adversaries (planner vs critic, generator vs evaluator) only work
 because each cannot see the other's reasoning. Pi core ships no subagent tool;
 the `pi-subagents` package provides one with forked contexts. **Do not run
 forge on a Pi without it.** Without forked contexts the pipeline collapses into
@@ -50,8 +50,8 @@ if the package is absent, stop and say so rather than faking the separation.
 
 ## Evaluation surfaces (not yet neutralized)
 
-The `web` / `native` / browser-MCP lines in `commands/building.md` were not
-neutralized (that was out of scope for the command neutralization), so they
+The `web` / `native` / browser-MCP lines in `skills/building/SKILL.md` were not
+neutralized (that was out of scope for the neutralization), so they
 still name tools that may not exist on Pi. Read them as follows until that
 follow-up lands: