g-forge

Plugin g-forge from marketplace g-forge in onlygian/G-Forge. Commands read from the repo's manifest — 13 days ago.

Skills (38)

• g-adr

  Capture an architectural decision record. First triages whether the decision merits an ADR or just a one-line entry in the brief's tech-decisions table (keeping the corpus rare and high-signal). Captures pre-deliberated reasoning or interviews from scratch, offloads the high-branching weighing to a

• g-afk

  Autonomous milestone executor. Requires an approved plan. Runs all pending waves and auto-review with no between-step check-ins. Uses an Opus-class or newer top-tier model for orchestration. Ends with a structured handoff telling the user what to test and review.

• g-align

  Brief-deviation check. Compares the project's actual trajectory (ROADMAP progress, recent commits, the observer journal) against the original g-docs/project_brief.md — goals, non-goals, MVP, tech decisions — and reports whether the work is still serving the brief. Advisory, never blocks. Auto-runs a

• g-audit

  Full-codebase or targeted code quality audit. Detects SOLID violations, code smells, architectural drift, dead code, and test coverage gaps. Targeted scope produces an inline report. Whole-codebase scope produces a prioritised roadmap milestone.

• g-blast-radius

  Analyse the blast radius of a planned change. Inputs a file path, feature name, or list of paths from a plan. Outputs the set of dependent files (forward and reverse references), a per-file volatility score (commit frequency proxy), and a total blast-radius rating (low / moderate / wide). Read-only.

• g-brief

  Refresh g-docs/project_brief.md as the project evolves — reads current state, asks targeted questions, and updates the brief without a full re-onboard.

• g-doc-review

  Documentation review gate. Dispatches the doc-reviewer agent on the changed file set to check documentation currency against the code it describes, then issues a standalone DOCS READY or DOCS HOLD verdict. On DOCS READY it writes the doc-approval sentinel that the commit gate checks for doc/mixed co

• g-docs

  Documentation audit and generation. Scans for missing or stale code docs, missing README sections, undocumented env vars, CHANGELOG gaps, and architectural decisions without ADRs. Targeted scope fixes gaps immediately via doc-writer. Whole-codebase scope produces a prioritised documentation debt rep

• g-doctor

  Read-only health diagnostics for G-Forge projects — 25 checks including hook registration, installed-copy drift, Check 23 plugin-version-lag, Check 24 CLAUDE.md injection-rule compliance, and Check 25 integration-tier guard. Recommends `/plugins` or `/g-update` by direction. Never writes.

• g-execute

  Execute an approved wave plan by dispatching parallel subagents per wave. Use after /g-plan is approved, or to resume a plan that was interrupted. Argument: optional wave number to start from (default: Wave 1).

• g-forecast

  Run scope-realism analysis and premortem on an approved-or-pending plan. Outputs a complexity score, a quantified likelihood that ≥1 premortem scenario fires, and a ranked list of likely failure scenarios seeded by /g-patterns history. Plan-time gate, never blocks — surfaces risk for human judgment.

• g-help

  Context-aware help. With no argument, reads current project state and tells you where you are and what to do next, plus a map of every archive. With a topic or question argument (`/g-forge help <topic>`), answers it and points you at the right command or archive.

• g-identity

  Synthesise the project's operational identity from accumulated history — recurring risks, architectural personality, delivery cadence, characteristic strengths and friction points. Output is a narrative summary written to g-docs/identity.md plus a printed snapshot. Read-only.

• g-init

  The single G-Forge front door — run once after installing the plugin. Detects what's here and routes to /g-onboard (existing codebase) or /g-kickoff (new project) for the brief, scaffolds CLAUDE.md (compact G-rules), g-docs/ROADMAP.md (with the Active Session handoff), g-docs/milestones/, g-docs/tod

• g-intake

  Proactive feature-drop triage. When the developer drops a feature idea mid-stream, classify it against the brief (on-brief / scope-creep / out-of-scope), propose where it belongs (existing milestone, new milestone, or backlog) with a version impact and a one-line risk hint — then ask before writing

• g-kickoff

  Interview the developer about their project goals, constraints, and stack. Challenges scope and every tech choice honestly. Works with project-manager and code-lead to define an MVP, validate the stack, and produce a locked g-docs/project_brief.md with a tech decisions table.

• g-listen

  Enter listen mode — collect user reports and information without acting, then synthesize and triage when the user signals done

• g-onboard

  Onboard G-Forge onto an existing codebase. Reads deeply before asking anything — treats existing CLAUDE.md, rules, agents, and task ledgers as first-class inputs. Only interviews for what it genuinely doesn't know yet. Produces or updates g-docs/project_brief.md.

• g-optimize

  Full-codebase or targeted performance audit. Detects algorithmic complexity problems, N+1 queries, re-render waste, resource leaks, and caching opportunities. Targeted scope produces an inline report. Whole-codebase scope produces a prioritised roadmap milestone.

• g-patterns

  Two-phase pattern lifecycle. MINE — read g-docs/retros/ and g-docs/todo-done.md for recurring failure patterns, print a detailed chat report, and save an abstracted, externally-shareable report to g-docs/patterns/ for any pattern observed ≥2 times. RESOLVE — in a later, fresh session, check g-docs/i

• g-plan

  Decompose the current request into atomic tasks and produce a parallel wave schedule. Runs task-decomposer then wave-planner. Use at the start of any multi-step implementation.

• g-refactor

  Guided refactor workflow — identify target, pre-analyse, spec, approve, execute, review. Accepts a scope path, an audit milestone file, or runs interactively. Safe-by-default: checks test coverage before execution and runs the full review gate after.

• g-resume

  Re-hydrate a fresh session with the right slice of the durable record. The read-side counterpart to /g-retro — selectively retrieves the relevant retro, ADRs, journal, and handoff keyed by the current branch/milestone/first-task, and assembles a focused re-entry briefing. Loads distilled context int

• g-retro

  Synthesize a session retrospective from the silent-observer journal — no interview. Reads the passive activity log (.claude/journal/), git history, and g-docs/todo.md, and writes g-docs/retros/YYYY-MM-DD-topic.md with what happened, decisions inferred, patterns, and cold-start context.

• g-review

  Run the review gate on the current branch diff. Runs the test suite, captures the diff, and dispatches code-lead, which verifies done conditions and reviews the diff itself. Issues MERGE READY or HOLD.

• g-roadmap

  Project-manager-driven milestone planner. Gated phases — feature dump → cluster → sequence → premortem & re-prioritize → approve → write. Narrates reasoning at every step, and runs a premortem + re-prioritization of the whole roadmap whenever a milestone is added or modified. Auto-triggers when no g

• g-roundtable

  Bind the session to "the Roundtable" — a shared live Doc that is the human-facing communication layer between you, non-programmers (PMs, collaborators), and the session. start binds a Doc (create-from-template or attach-by-URL); sync reads the Roundtable at a boundary and writes only salient deltas;

• g-skill-design

  Design a new G-Forge skill from scratch. Gathers requirements, drafts SKILL.md with correct structure, and registers the new skill's bare token on all three router surfaces.

• g-skill-validate

  Validate a skill or agent file against G-Forge structural rules. Checks SKILL.md format, retired-shim absence, router registration, and agent frontmatter. Issues VALID or NEEDS FIXES verdict.

• g-specialize

  Determine which stack profiles to apply by reading the project brief and dependency files. Handles multi-stack projects. Detects known stack combos and installs combo architecture rules covering emergent cross-stack patterns. Consults code-lead when the picture is ambiguous or risky. Installs archit

• g-status

  Quick one-shot snapshot of current workflow state: active plan, wave progress, review gate, current milestone.

• g-telemetry

  Compute the 8 reliability metrics defined in g-docs/telemetry-metrics.md, derive a health profile (stable / cautious / defensive / recovery), and write it to .claude/telemetry-profile for adaptive orchestration in /g-execute and /g-review. Read-only on history; never modifies retros, forecasts, or g

• g-tier

  Switch the G-Forge integration tier between `full` (default — all hooks fire, all workflows auto-trigger), `balanced` (state hooks only, no auto-triggers, commit gate still on), and `light` (workflow-checkpoint only, commit gate off — opt-out mode). Writes `.claude/integration-tier`.

• g-train

  Activates training mode. Establishes the learner profile, confirms or generates a project idea, and writes .claude/training-mode. PM then takes the session from there — in training mode, PM is the mentor: explains why each step exists, assigns tasks alongside waves, and runs post-wave check-ins. The

• g-trim

  Use proactively once a week. Read-only audit of CLAUDE.md, its @-import targets, and agent memory for bloat, orphaned references, duplicate rules, and stale content. Reports issues for human review — never modifies any file. Writes .claude/last-trim on completion.

• g-update

  Fix G-Forge-managed files via Step 0 staleness preflight (stops with zero writes if cache lags GitHub, directs to `/plugins` first), then realigns CLAUDE.md Rules, agents, architecture rules, hooks, and native pre-commit gate. Safe — G-Forge markers only.

• g-voice

  Set how G-Forge communicates with you. With no argument, runs a short 2-question intake and sets the right profile automatically — you never need to know the tier names. With `dev`, `mid`, or `eli5` as an argument, applies that profile directly. Writes `.claude/voice-profile`. Every G-Forge skill re

• g-wiki

  Build and maintain a human-facing project wiki in g-wiki/ — narrative documentation of what the project is, how it's architected, how each major area works, and how to use it. Synthesizes from the codebase, ROADMAP, ADRs, and brief via the doc-writer agent. Run anytime; queued as a task at the end o

Slash commands (1)

• /g-forge:g-forge

  G-Forge workflow commands. Subcommands — help, status, resume, doctor, audit, init, kickoff, onboard, brief, roadmap, intake, plan, forecast, blast-radius, execute, review, doc-review, align, afk, specialize, update, skill-design, skill-validate, adr, docs, wiki, patterns, telemetry, identity, retro

Subagents (19)

• architecture-enforcer

  Use proactively when files in layer-boundary directories change. Validates import direction, circular deps, and separation of concerns. Reports violations with file:line refs. Does not fix.

• code-lead

  Use before any merge and when project-manager needs technical risk assessment. Guards milestone feasibility, checks done conditions, and reviews diffs directly. Does not implement.

• code-reviewer

  Use proactively after any code change and before every merge. Reviews for logic errors, code smells, DRY violations, and edge cases. Reports with file:line refs and severity. Does not fix.

• debugger

  Use proactively when a bug resists a first fix attempt. Reproduces the failure, traces root cause, and proposes a fix strategy. Does not implement.

• dependency-auditor

  Use proactively before any release and whenever the dependency manifest changes. Audits for security advisories, deprecated packages, license conflicts, and unused declarations. Does not fix or upgrade.

• doc-reviewer

  Use proactively when documentation changes, when public exports change, or at milestone close. Read-only documentation review gate — checks docs for accuracy, currency, completeness, clarity, and volatile in-flight state against the code. Reports with file:line refs and severity, then issues DOCS RE

• doc-writer

  Use proactively after implementation is complete or when exports lack documentation. Writes inline docs and README sections explaining WHY, not WHAT.

• error-detective

  Use proactively when facing cryptic errors or production incidents before attempting a fix. Parses logs and stack traces to identify patterns and root causes. Does not fix.

• feature-implementer

  The generic, stack-agnostic wave implementer — the default executor for any implementation task that has no matching stack implementer installed by /g-specialize, and the fallback for projects that have not been specialized. Implements one wave task to its done condition. Single-use — one approach,

• performance-auditor

  Use proactively on performance-sensitive changes. Flags O(n²) paths, N+1 queries, unnecessary re-renders, and hot-path waste. Reports with file:line refs and estimated impact. Does not fix.

• pr-writer

  Use proactively before opening a pull request. Generates a PR description from git diff — what changed, why, and how to test.

• project-manager

  The user-facing interface for every session. The user talks to the PM — not to a neutral assistant. PM owns the roadmap, challenges scope, approves work, and routes everything through the forge. Does not write code or touch implementation files.

• refactor-executor

  Use when a refactor spec from spec-writer is ready to execute. Executes exactly as written — no scope creep, no judgment calls.

• review-orchestrator

  Coordinates the full review pipeline — code review, architecture, security, and performance in parallel. Aggregates findings into one report. Does not review itself. Directly invocable (`--agent review-orchestrator`) or from a skill; nested subagent dispatch works on the current platform (probe 2026

• security-auditor

  Use proactively before any merge, especially those touching auth or external integrations. Audits for OWASP Top 10 vulnerabilities, injection vectors, and secrets exposure. Does not fix.

• spec-writer

  Use when a task needs to be specced before handoff to an executor. Produces an implementation spec precise enough for a Haiku agent to execute without judgment calls.

• task-decomposer

  Use at the start of any multi-step implementation before touching code. Breaks the request into atomic, verifiable tasks with done conditions.

• test-writer

  Use proactively after implementing code that needs coverage or when spec-writer produces a spec. Writes unit, integration, or e2e tests. Fixed data only, no Date.now() or random values.

• wave-planner

  Use immediately after task-decomposer. Takes a task list and produces a parallel wave execution schedule by mapping dependencies, and tags each task with the executor agent that should run it.

Similar plugins