tonmoy007
User12-stage gated SDLC orchestrator for Claude Code — deterministic gates, REQ-ID traceability, cost-capped background agents, brownfield adoption
Categories
Indexed Skills (39)
forge-deploy
Run Stage 8 of the Forge pipeline — deployment. Use when the user says /forge:deploy, wants to ship to an environment, or needs a deployment plan and runbook. Requires Stage 7 eval to pass. Invokes the devops persona.
forge-arch-pro
Run Stage 3 of the Forge SDLC pipeline — Enterprise Architecture (Pro tier). Transforms approved requirements and product design artifacts into a deterministic, implementation-independent architecture specification. Produces the canonical architecture artifacts consumed by Stage 4 (Technical Specification). Invokes the System Architect Pro persona.
forge-build-pro
Run Stage 6 of the Forge pipeline -- Implementation -- via the Builder Pro Execution Orchestrator: scripts/build_executor.py handles context resolution, gate execution, commit, progress write, and traceability update; agents/builder-pro.md handles code and test generation. Use when the user says /forge:build-pro, wants "pro" or orchestrated implementation, or explicitly asks for the deterministic-engine builder pipeline. Requires Stage 1-5. Does not replace or modify /forge:build -- both coexist; use /forge:build for the original single-persona flow.
forge-arch
Run Stage 3 of the Forge pipeline — system architecture. Use when the user says /forge:architecture or /forge:arch, wants a C4 diagram, data model, API design, or tech stack decisions. Requires Stage 1–2 to exist. Invokes system-architect.
forge-autopilot
Drive the Forge pipeline hands-off — run stages back-to-back, checking each stage's gate and advancing only when it passes, stopping at the first blocker. Use when the user runs /forge:autopilot, says "autopilot", "run the pipeline for me", "take it from here", "build through to stage N", "run the next few stages automatically", or "drive the rest of the pipeline". Bounded and safe by default (stop-on-gate, never force). Stop anytime with /forge:autopilot-stop.
forge-build
Run Stage 6 of the Forge pipeline — implementation. Use when the user says /forge:build, wants to start coding, implement a feature, or work the task DAG. Requires Stage 1–5. Invokes the builder persona. Works one task at a time.
forge-doctor
Run the Forge diagnostic report to surface environment, plugin, project, and global-state issues. Use this skill whenever a user types `/forge:doctor`, reports that Forge isn't working, says hooks aren't firing, asks "is my Forge install OK?" or "what's wrong with Forge?", or wants a health check before reporting a bug. Make sure to use this skill BEFORE suggesting reinstallation or other heavy remediations — the doctor output frequently identifies the actual problem and the exact fix command to run.
forge-eval
Run Stage 7 of the Forge pipeline — evaluation and quality assurance. Use when the user says /forge:eval, wants to verify the implementation, check test coverage, or validate against requirements. Requires Stage 1–6. Invokes the evaluator.
forge-feedback
Run Stage 10 of the Forge pipeline — feedback triage. Use when the user says /forge:feedback, has user feedback to process, wants bugs classified, or needs a prioritized backlog. Requires Stage 9. Invokes the triage persona.
flow
Run a user-defined Forge workflow from `.forge/workflows/*.yaml` — a declarative DAG of agent steps with per-node prompts, `depends_on` edges, and `{{upstream}}` data passing. Use when the user runs /forge:flow, says "run my workflow", "run the <name> flow", "list my workflows", "show the flow plan", or references a `.forge/workflows/*.yaml` file. Lists available flows, shows the dependency-wave plan, and runs the chosen one through the bounded, deterministic workflow engine. Only active when `orchestration.flows_enabled` is true; otherwise it is a clean no-op that points the user at how to enable it.
forge-force-advance
Override a blocking gate and advance the pipeline stage, recording a lesson with the user's stated reason. Use this skill ONLY when a user explicitly asks to "force advance", "skip the gate", "override the blocker", "advance anyway", or otherwise expresses intent to proceed despite failing gate criteria. Make sure to require an explicit `--reason` justification from the user (≥ 10 characters) before invoking the script — the lesson recorded becomes part of the retrospective and protects future-them from forgetting why this happened. Do NOT use this skill proactively or as a workaround for fixable gate failures; if the user hasn't asked to override, ask whether they want to fix the blocker first.
graduate
Promote a project's proven lessons, skills, and workflows into the shared `~/.forge` global store so they're recalled into your other projects. Use when the user runs /forge:graduate, says "graduate my skills/workflows/lessons", "promote to ~/.forge", "promote my reusable workflows", "list global store", "what's graduated", or "dry-run graduation". Runs the same three-tier graduation driver the session-start hook uses, on demand — a `list` view of the global store, a `--dry-run` preview that writes nothing, and a real scan that promotes everything past its tier gate.
health-check
Run a full self-diagnostic of the Forge plugin — executes hook unit tests, checks lesson-store integrity, and reports overall status as healthy, degraded, or failing. Use when the user types `/forge:health-check`, asks "is forge healthy?", "check the plugin health", "run the health check", or "are the hooks working?". Never silently disables hooks — any auto-disable action requires explicit opt-in via the `health.auto_disable_hooks` config flag in .forge/config.yaml and is always surfaced to events.jsonl and health-surface.txt.
forge-init
Initialize the Forge SDLC pipeline in a project. Use whenever a user mentions setting up Forge, starting a new orchestrated project, scaffolding pipeline directories, or anything involving 'init', 'initialize', 'set up Forge', or 'start using Forge' in the context of starting work on a project. Also use when the user passes `--dry-run` to preview what would be created without writing any files. Make sure to use this skill before any other `/forge:*` command if `pipeline/` doesn't exist yet.
forge-monitor
Run Stage 9 of the Forge pipeline — observability and monitoring. Use when the user says /forge:monitor, wants SLOs defined, health checks, or a system health report. Requires Stage 8 deployment. Invokes the observer persona.
forge-orchestrate
OpenCode-only. Drive the full 12-stage Forge pipeline end-to-end by adopting the Orchestrator persona — runs each stage's own skill in turn, checks its gate, and explicitly advances and verifies pipeline/state.md before moving on. Use when the user runs /forge:orchestrate, says "orchestrate the pipeline", "run the whole pipeline", "drive this end-to-end", "take this from SRS to release", or "act as the pipeline orchestrator". Exists because OpenCode's Stop hook has no transcript-based auto-advance signal — state.md would otherwise stop tracking per-stage progress. For self-healing / background-dispatch / context-checkpointed runs, prefer /forge:autopilot instead (see Relationship note below).
forge-plan
Run Stage 5 of the Forge pipeline — implementation planning. Use when the user says /forge:plan, wants a task breakdown, task DAG, effort estimates, or a risk register. Requires Stage 1–4. Invokes the planner persona.
forge-product
Run Stage 2 of the Forge pipeline — product UX and PRD. Use when the user says /forge:ux, /forge:product, wants wireframes, user flows, a PRD, or a design system. Requires Stage 1 SRS to exist. Invokes the product-designer persona.
forge-release
Run Stage 12 of the Forge pipeline — release preparation. Use when the user says /forge:release, wants to cut a version, write a changelog, or prepare release notes. Requires Stage 11 or passing eval. Invokes the release-manager persona.
forge-resolve
Run Stage 11 of the Forge pipeline — issue resolution and hotfixes. Use when the user says /forge:resolve, wants to fix bugs from triage, or needs a hotfix. Requires Stage 10 triage report. Invokes the resolver persona.
forge-resume
Resume work on a Forge-managed project after a session restart. Reads pipeline state, injects the prioritized context for the current stage, shows the last reflection, and states the next concrete action. Use whenever the user runs /forge:resume, says "resume", "pick up where we left off", "continue from last session", or starts a new session and asks what to work on in a Forge project.
forge-retro
Run a cycle-completion retrospective after Stage 12 (Release). Synthesizes what went well, what didn't, lessons captured, and pending skill proposals into `pipeline/12-release/retro.md`. Use when the user runs /forge:retro, says "retrospective", "retro", "post-mortem", or asks to close out a release cycle in a Forge project.
forge-rules
Set up and manage user-authored Forge rules — project constraints that steer Forge's agents (like Cursor .cursor/rules). Use whenever the user runs /forge:rules, says "set up rules", "add a project rule", "create a coding rule", "make Forge always do X", "enforce a convention", or wants to list/validate existing rules. Rules live in .forge/rules/*.md with a scope (always/stage/glob/manual) and are injected at session start and on matching file writes. If no rules dir exists, the feature is a clean no-op.
skill-creator
Author a tested, installable Forge skill from a mined candidate proposal. Use whenever the user runs /forge:skill-creator, wants to turn a mined skill proposal into a real skill, says "author this skill", "write a skill from the proposal", "promote a mined candidate", "refine a proposed skill", or asks to test/optimize a skill's triggering description. Consumes a .forge/proposed-skills/<slug>/SKILL.md draft and runs the capture→write→test→grade→improve→optimize-description loop in-session, extending (never replacing) the /forge:skill-approval flow. Nothing installs without explicit user approval.
forge-spec
Run Stage 4 of the Forge pipeline — technical specification. Use when the user says /forge:spec, wants interface definitions, data schemas, API contracts, or a full technical spec. Requires Stage 1–3. Invokes the spec-writer persona.
forge-sprint
Group the project's task DAG into bounded sprints and review them. Use when the user runs /forge:sprint, says "plan a sprint", "start a sprint", "what's in this sprint", "sprint review", "sprint retro", or wants to batch the next ready tasks into a reviewable chunk. A deterministic VIEW over pipeline/05-plan/task-dag.md (T-IDs only) — the DAG and progress.md stay the source of truth. Fully opt-in; a project that never runs it sees no change.
forge-srs
Run Stage 1 of the Forge pipeline — requirements analysis. Use when the user says /forge:srs, wants to write requirements, define what to build, produce an SRS, or start a new project with Forge. Invokes the requirements-analyst persona.
forge-status
Show the current Forge pipeline status — stage, task, blockers, and progress. Use whenever the user asks what stage they are on, what is happening in the pipeline, what the current task is, what blockers exist, or says "status", "where are we", "what stage", "show progress", "forge status". Always use this skill before suggesting what to work on next in a Forge-managed project.
forge-trace-matrix
Generate the full ID x stage traceability matrix and a gap report, with each gap attributed to the stage agent responsible for resolving it. Use when the user runs /forge:trace-matrix, asks "generate a traceability matrix", "which requirements are missing", "show me ID coverage across the pipeline", "who owns this gap", or wants to see the whole pipeline's ID health at a glance. Writes .forge/traceability-gaps.jsonl, which session-start.py reads to advise the responsible agent when their stage becomes active.
forge-uninstall
Remove Forge filesystem state from the current project, and optionally global state, with a mandatory preview step before any deletion. Use this skill whenever a user types `/forge:uninstall`, says "remove Forge", "I want to uninstall this plugin", "clean up Forge files", "delete pipeline/", expresses frustration suggesting they may give up on Forge, or asks to start over from scratch. Make sure to ALWAYS run with `--dry-run` first and present the plan to the user; NEVER proceed to actual removal without an explicit user confirmation in the same turn. This skill does NOT unregister the plugin from Claude Code itself — always remind the user to run `/plugin uninstall forge@forge-plugins` as a separate step after filesystem removal.
forge-validate
Run a full pipeline gap analysis and confirm traceability end-to-end — malformed IDs (wrong case/separator/digit-padding), misplaced ID definitions (e.g. a REQ-* heading defined outside pipeline/01-srs/srs.md), duplicate ID definitions, and unimplemented/orphaned requirements (a REQ/NFR/FEAT/UF never referenced downstream) — plus a rollup of the existing traceability-check.py and gate-completeness scripts. Use when the user runs /forge:validate, asks "check traceability", "find gaps in the pipeline", "are any requirements unimplemented", "validate the IDs", or wants a gap analysis before a gate/release.
forge-why
Explain a Forge gate criterion, lesson tag, pipeline stage, or current blocker(s). Use this skill whenever a user types `/forge:why`, asks "why is G1-001 failing?", "what does this gate mean?", "what's blocking me?", "what is Stage 3?", or "show me lessons tagged X". Make sure to use this skill BEFORE suggesting `/forge:force-advance` — `/forge:why` often shows the user a fix they can apply in seconds, avoiding an unnecessary override and lesson. Also use proactively when a gate fails — a user asking "what does check-gate.py mean by G3-002?" deserves an explanation, not just the raw JSON.
forge-adopt
Onboard an EXISTING codebase into Forge (brownfield adoption). Use when the user runs /forge:adopt, wants to start using Forge on a project that already has code, says "adopt this repo", "set up Forge on my existing project", "reverse-engineer the requirements/architecture", or asks to bring a legacy/brownfield codebase into the pipeline. Pass --dry-run to preview without writing. Distinct from /forge:init, which scaffolds a greenfield pipeline.
forge-autopilot-stop
Stop a running Forge autopilot. Use when the user runs /forge:autopilot-stop, says "stop autopilot", "cancel the autopilot", "halt the pipeline run", or "stop running the pipeline". Sets a stop flag the autopilot loop checks between stages, so it halts cleanly at the next stage boundary (the in-progress stage finishes; nothing is forced).
dreamer-run
Run the Forge Dreamer — a nightly lesson consolidation daemon (/forge:dreamer-run) that applies confidence decay to dormant lessons, detects duplicate and contradicting lesson pairs (flag only — never auto-merges or auto-resolves), and writes a daily digest to pipeline/log/daily-<date>.md. When background agents are available, an optional cheap-model, session-reused consolidation summary is appended to the digest. Safe to run multiple times the same day — digest is idempotent (overwritten with identical content).
forge-review
Run a multi-dimensional parallel code review over the current change. Use when the user runs /forge:review, asks to review the diff / a file / the branch, wants a thorough review across correctness, security, performance, and conventions, or says "review my changes", "check this code", "find issues in the diff". Fans the review dimensions out in parallel and synthesizes one deduplicated, severity-sorted report.
forge-set-profile
Switch the project-type profile for a Forge-managed project. Use whenever the user runs /forge:set-profile, wants to change or correct the detected project type (e.g. "set the profile to monorepo", "this is actually a mobile app, fix the type", "change project_type to data-contract"), or when auto-detection picked the wrong profile. Pass the target type as the argument; pass --dry-run to preview without writing.
watch-stop
Stop the Forge Observer background daemon, preserving its last poll output and all recorded findings. Use when the user types `/forge:watch-stop`, says "stop watching", "stop the observer", "turn off monitoring", or "stop the background agent". Safe to run when nothing is watching (reports "not running").
watch
Start the Forge Observer — a background daemon (Stage 9) that periodically inspects recent project activity and records findings (risky changes, missing tests, drift) to .forge/observer-findings.jsonl, surfaced at session start and in /forge:status. Use when the user types `/forge:watch`, says "watch this project", "keep an eye on things", "start the observer", or "monitor in the background". The Observer reuses one cheap-model session per the cost cap; if background agents are unavailable it is a clean no-op.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.