forge

Plugin forge from marketplace forge in travelhawk/forgeshift. Commands read from the repo's manifest — 2 days ago.

Skills (16)

• adopt

  Bring an EXISTING codebase under the harness - maps the code, reverse-engineers an as-built spec, seeds PROGRESS.md and a project AGENTS.md so the full lifecycle (/forge:feature, /forge:harden, /forge:ship) works on it. Use when the user points at a repo they already have instead of starting fresh.

• debug-hard

  Escalate a stubborn bug to the hard-bug debugging specialist with a structured handoff - it runs on the session model, so put the session on your host's strongest model for the hardest ones when you have the quota. Use when a bug survived two fix attempts, reproduces intermittently, or looks impossi

• deep-review

  Multi-dimension code review with adversarial verification of every finding - before merging or shipping non-trivial work. Reviews the current diff by default; pass args to scope it. /forge:build and /forge:ship fire this automatically; use it directly for a standalone review.

• design-panel

  Generate N independent design approaches, score them with a judge panel, synthesize the winner - for architecture or design decisions where the solution space is wide and a wrong pick is expensive (system design, data model, API shape, major refactor strategy). Pass the design brief as args.

• feature-pipeline

  Implement independent features in parallel - plan, implement in an isolated git worktree, verify per risk tier. The engine /forge:build drives; use it directly for a raw batch of independent features without the PR ceremony. Needs a git repo with at least one commit.

• feature

  Build one feature through the full quality loop - plan, failing test, implement, fresh-context verify. Use for any feature or task from the spec/PROGRESS.md, or an ad-hoc feature request during a build.

• fix

  Bugfix lane - reproduce, regression test, fix, review, optional patch release. Lighter than /forge:feature (no spec ceremony), earlier than /forge:debug-hard (which needs two failed attempts). Use for reported bugs, production issues, and broken behavior.

• harden

  Security and robustness pass - full audit by the security specialist plus a robustness sweep (boundary validation, failure modes, secrets hygiene, rate limiting), then fixes with approval. Use before first public exposure and after auth, payment, or data-model changes.

• kickoff

  Take a product idea to a scaffolded, spec'd, buildable project - structured interview, spec, stack choice from a playbook, scaffold with git and tests wired up. Use when the user wants to start a new product, app, tool, or project of any kind. For an EXISTING codebase, use /forge:adopt instead.

• next

  Hand the next version of an existing product to forge in one command - clarify new feature ideas into right-sized, risk-tiered features, append them to the spec, then build the whole slice hands-off through the forge flow (waves of PRs, merge, deep-review finish). Use after a product is already kick

• release-gate

  Run the six ship gates (static, security, docs, tests, build, runtime smoke) across three agents, aggregated fail-closed into a SHIP/NO-SHIP verdict. /forge:ship fires this automatically; use it directly for a standalone pre-release check.

• resume

  Resume a stalled /forge:build or /forge:next run - read .forge/run.json, reconcile it against git and open PRs, and state the exact next action (which wave, which merge, which fix). Use after a run died mid-way (rate limit, crash, closed session) or when unsure where a batch left off.

• retro

  Harness retrospective - blockers and observed defects only, each traced to a citation and verified against the harness text before it becomes a change. Use after a run that broke, stalled, or produced a wrong result.

• ship

  Release gate and deploy - prepares the release commit (CHANGELOG, version bump), runs the automated release-gate workflow, walks the manual checklist, then tags and deploys per the project playbook.

• status

  Project state report and session handoff - audits PROGRESS.md against reality (git, tests), reports what is done/in-flight/next with evidence, and writes the handoff so the next session starts clean. Use at session end, after milestones, or when resuming after a break.

• understand

  Map an unfamiliar or large codebase with parallel read-only subagents, then synthesize one architecture brief. Use at the start of work on a foreign/large codebase, or when a change spans subsystems you have not read. Optional focus question narrows the maps.

Subagents (8)

• forge-blueprint

  The Blueprint (planner) — architecture and spec specialist on the session model. Use for system design, product specs, technology decisions with real trade-offs, and decomposing large work into feature lists. Use proactively before any multi-file build starts without a written plan.

• forge-etcher

  The Etcher (docs scribe) — documentation specialist on Sonnet. Use for READMEs, CHANGELOGs, setup guides, and keeping docs in sync with shipped reality. Verifies every command it documents by running it.

• forge-hammer

  The Hammer (implementer) — feature implementation specialist on Opus. Use to build a planned feature end-to-end with tests-first discipline, or execute a written plan/spec section. Give it the plan, the done-criteria, and the paths involved.

• forge-proof

  The Proof (tester) — test engineering specialist on Opus. Use to build test coverage for existing code, design an E2E test strategy, verify a feature end-to-end the way a real user would, or produce visual walkthroughs (Playwright flow videos + a screen-overview image, e.g. the /forge:build finish).

• forge-prospector

  The Prospector (research scout) — research specialist on Sonnet. Use for web research — library evaluation, API documentation, current versions and best practices, error-message hunting, prior art. Returns verified facts with sources, not summaries of guesses.

• forge-quench

  The Quench (reviewer) — adversarial code reviewer on the session model, always fresh-context. Use after any non-trivial implementation, before merge. Give it the diff scope and the plan/criteria it was built against. Use proactively after completing significant code changes.

• forge-temper

  The Temper (debugger) — hard-bug specialist on the session model (raise the session to the top tier only when the bug already beat a default-session attempt). Use when a bug survived two fix attempts, reproduces intermittently, or involves concurrency, caching, state corruption, or "impossible" beha

• forge-warden

  The Warden (security) — security audit specialist on Opus. Use before first public exposure, after auth/payment/data-model changes, and inside /forge:harden. Reports only real, reachable vulnerabilities with attack paths — not checklist theater.

Similar plugins