v2.0.0 — cross-platform (Claude Code + Pi)

Forge is now a harness-agnostic skills package that runs on both Claude Code and the Pi coding agent with open-weight models, from one source.

Highlights

• Commands are now skills. The three workflows moved from commands/*.md to skills/{interview,planning,building}/SKILL.md. Skills are the unit both harnesses understand. On Claude Code, invocation is unchanged: /forge:interview, /forge:planning, /forge:building still work exactly as before, explicit-only via disable-model-invocation.
• Pi / open-model support. A new package.json declares the skills as a Pi package. Install with pi install git:github.com/dasirra/cc-forge. Requires pi-subagents for the adversarial subagent pairs (planner/critic, generator/evaluator).
• Harness-neutral workflow bodies. The prose no longer names any specific agent's tools or models. It uses role tiers (judgment-tier / labor-tier) and generic verbs, resolved per harness by a binding doc.
• Binding layer. docs/harness-bindings/claude-code.md and pi.md map every neutral term to each harness (Claude Code: opus/sonnet, AskUserQuestion, EnterWorktree, computer use, a browser MCP; Pi: GLM-5.2, git worktree, pi-subagents, direct-UI-control unavailable, Playwright).

Install

• Claude Code: /plugin marketplace add dasirra/cc-forge then /plugin install forge@cc-forge. Invocation is unchanged.
• Pi: pi install git:github.com/dasirra/cc-forge (plus pi-subagents).

Breaking

• Internal structure changed from commands/ to skills/. Claude Code invocation names are unchanged, but anything referencing commands/*.md paths directly should update to skills/*/SKILL.md.

Status

Claude Code is fully supported. The Pi path is packaged and reviewed; end-to-end validation from the installed skill form (does Pi pass $ARGUMENTS, does it tolerate disable-model-invocation) is the remaining live check.

v1.1.1

First published release. Covers everything since the v1.0.0 tag, which was never released, so the evaluation-surface work from 1.1.0 lands here too.

Evaluation surfaces

/forge:building no longer assumes every project is a web app.

It now resolves an evaluation surface up front (web, library, cli, service, native), inferred from the repo and confirmed with you. A new --surface flag skips the question. The surface flows into the contract, into the generator's verify_how vocabulary, and into the evaluator's tools and role prompt.

Only web needs a browser automation MCP server, and it is checked in the new Phase 0.5 preflight, before a worktree, a contract, or an issue comment exists. Previously a missing browser surfaced in Phase 6, after two opus negotiations and a full build. Preflight also adds the gh auth and remote check that /forge:planning had and /forge:building lacked.

The evaluator never runs the builders' tests

A guardrail the browser-only design never exposed. Builder-written tests encode the builder's understanding, so a green suite certifies whatever misunderstanding produced the bug. Those tests still run in Phase 5 as static verification. They do not count as evaluation. The evaluator writes its own scripts in harness/eval/, from the contract alone, having never read the implementation.

Documentation

• The PM/DEV altitude split is now explained in its own README section: what each altitude may say, and why planning is forbidden technical content.
• A banner, a Mermaid pipeline diagram that renders inline on GitHub, and a full pipeline reference.
• Credits for the two AI Engineer talks and the superpowers repo the workflow builds on.
• /forge:interview Phase 1 renamed from "Grill" to "Interview".

Known limitation

Only the web evaluation surface has actually been exercised end to end. library, cli, service, and native are untested prose.