By gyuha
Orchestrator plugin that auto-chains GSD -> Superpowers -> sg-retro so planning, implementation, and retrospection stay connected as a single learning loop.
Use this to archive accumulated phase directories from completed milestones — delegates to gsd-cleanup, then displays a table of what was archived.
Complete a phase (bare number → delegates to sg-phase) or close a milestone (vX.Y, or the current milestone when no argument) via gsd-complete-milestone.
Use this when the phase plan is ready and implementation should begin — packages PLAN/REQ/SC and hands off to Superpowers via superpowers:executing-plans.
Use this when you need a map of the current codebase structure — invokes gsd-map-codebase to analyse and document the project layout.
Use this when something feels broken or before onboarding — diagnoses GSD, Superpowers, hooks, HANDOFF.md, and STATE.md installation line by line.
Matches all tools
Hooks run on every tool call, not just specific ones
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
![]()
Orchestrator plugin that auto-chains GSD → Superpowers → sg-retro so planning, implementation, and retrospection stay connected as a single learning loop.
super-gsd is a Claude Code plugin whose only job is to keep GSD, Superpowers, and the built-in sg-retro skill talking to each other. Strategy lives in GSD. Implementation lives in Superpowers. Retrospection lives in sg-retro. When one of them finishes a stage, super-gsd is responsible for handing the context to the next one — so the user does not have to remember which command comes next, and so lessons learned in one cycle actually reach the next plan.
The problem this solves is that manual handoff between these three tools is fragile. People forget to run the review, skip the retro, lose context between sessions, or re-run a planning command that overwrites half-finished work. By separating roles and then orchestrating the seams between them, the same mistakes stop showing up.
All twenty-two slash commands covering the full GSD → Superpowers → sg-retro cycle are available — from starting a new milestone to closing it out and beginning the next. Use sg-next at any point to auto-detect the current stage and invoke the next command without having to remember it. See the Commands section below for the quick-reference table, and docs/COMMANDS.md for the full per-command reference.
The workflow splits into a manual entry (you run sg-start/sg-new, sg-explore, then the first sg-plan) and an auto-chain that sg-next drives from sg-execute onward. The sg-tdd, sg-review, and sg-learn stages are optional — toggle them with sg-toggle-* (which set tdd_mode / skip_review / skip_learn in .planning/config.json), and sg-next, sg-status, and the stop hook all chain-skip any disabled stage straight to the next non-skipped one. sg-start can also configure all three at once via multi-select when starting a new project or milestone. Each shipped phase loops back to sg-plan (with lessons fed forward); closing the milestone runs sg-complete → sg-new.
Manual entry Auto-chain (sg-next drives from sg-execute)
sg-start / sg-new ┌── [sg-tdd] ─ [sg-review] ─ [sg-learn] ──┐
→ sg-explore → sg-plan ── sg-execute ───┤ (optional, skippable via sg-toggle-*) ├── sg-ship
▲ └─────────────────────────────────────────┘ │
└── next phase / lessons fed forward ───────────────────────────┘ │
milestone done ── sg-complete ─→ sg-new
[ … ] = optional stage — skip with sg-toggle-tdd / sg-toggle-review / sg-toggle-learn
flowchart LR
S(["sg-start / sg-new"]) --> EX["sg-explore"] --> PL["sg-plan"]
PL --> EXE["sg-execute"]
EXE --> TDD["sg-tdd"]
TDD --> REV["sg-review"]
REV --> LRN["sg-learn"]
LRN --> SHIP["sg-ship"]
EXE -.->|"tdd_mode off (default)"| REV
EXE -.->|"skip_review"| LRN
REV -.->|"skip_learn"| SHIP
SHIP -->|"next phase"| PL
SHIP -->|"milestone done"| CMP["sg-complete"]
CMP --> NEW["sg-new"]
NEW -.->|"next milestone"| PL
LRN -.->|"lessons → next plan"| PL
classDef manual fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
classDef auto fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
classDef opt fill:#fff8e1,stroke:#ef6c00,color:#e65100,stroke-dasharray:5 3;
classDef done fill:#f3e5f5,stroke:#7b1fa2,color:#4a148c;
class S,EX,PL manual;
class EXE,SHIP auto;
class TDD,REV,LRN opt;
class CMP,NEW done;
Solid arrows are the default path; dashed arrows are skip routes that activate when a stage is toggled off (
tdd_modeis off by default, sosg-tddonly runs once enabled). Yellow dashed nodes are the optional, toggleable stages.
sg-next reads HANDOFF.md/STATE.md and auto-invokes the next command in the chain (gsd-plan → sg-execute, parallel/execute → sg-tdd (tdd_mode=true) → sg-review, review → sg-learn, sg-retro → sg-ship, ship → sg-plan {next phase} or sg-complete, complete → sg-new via AskUserQuestion). The entry-point commands (sg-start, sg-explore, and the initial sg-plan) are invoked manually before the auto-chain begins.
sg-status can be run at any point to check current position. sg-quick handles one-off tasks outside the main flow.
Quick reference for all /super-gsd:sg-* slash commands.
npx claudepluginhub gyuha/super-gsd --plugin super-gsdA stage-by-stage workflow skill set (fg-*). A development loop that takes one task through a single cycle of ask·plan → execute → retro → done. Consists of fg-ask (inquiry/triage + grill-with-docs-style conversational grilling), fg-run (backlog selection menu · Run all, Dynamic Workflow execution), fg-learn (retro · doc promotion), and fg-done (done · seal · re-run guard), plus fg-map — an on-demand utility outside the loop that maps the codebase into .forge/codebase/ with parallel subagents so grilling reads a map instead of re-exploring the code (cuts context rot), and fg-quick — a lightweight lane outside the loop for trivial tasks that still grills lightly but skips formal artifacts (no ADR/plan/retro), records one line to .forge/quick/LOG.md, runs directly, and bails to fg-ask if the task turns out non-trivial, fg-status — a read-only reporter that surveys .forge/ and prints where every task stands plus the single next step you need (writes nothing, never auto-runs), fg-next — derives that same next step and runs it, announcing the step then invoking the skill rather than only reporting it (one-shot; fg-status reports, fg-next acts), with an 'all' mode (fg-next all) that drives backlog tasks to completion until empty, auto-progressing mechanical steps and halting at conversational walls, and fg-tdd — toggles persistent TDD mode in .forge/config.json (fg-ask then defaults to asking, fg-run runs test-first), and fg-eco — toggles eco mode in .forge/config.json (when on, fg-run caps its delegated workflow subagents at sonnet; lower only, the session model is untouched — ADR-0014), and fg-loop — a goal-driven momentum loop with bounded replan: an initial conversational inquiry pins a machine-verifiable stop condition, an authorized fix-forward replan scope, and a replan cap (default 3 rounds) into .forge/loop.md, then it drives tasks unattended (run → UAT → auto-skip retro → seal, auto-selecting recommended defaults at every soft decision and asking the user nothing) until the checks pass, generating in-scope fix-forward tasks within the cap and halting only at the walls (unverifiable UAT, genuine fork, cap exhausted, no progress — ADR-0016). On a non-default git branch the whole forge state moves under .forge/branch/<branch>/ (git-tracked, namespaced so parallel branches never collide on .forge state — ADR-0011), and fg-merge — an outside-the-loop utility that, after you git merge a branch, integrates that branch's .forge/branch/<branch>/ into .forge/ (renumbering ADRs and rewriting cross-references, merging CONTEXT terms, folding done history, removing the branch folder; halts on genuine conflicts), and fg-cleanup — an outside-the-loop utility that retires stale or superseded ADRs to .forge/adr/retired/ on your approval, keeping the active decision set current without deleting the why (ADR-0012), and fg-statusline — an outside-the-loop setup utility that installs a bash fragment script reading .forge/ and wires it into settings.json so your terminal statusline shows the current loop progress (active task·stage, goal-loop indicator, or backlog count); since Claude Code allows only one statusLine it auto-wraps your existing one as an extra row rather than replacing it (ADR-0017), and fg-adversarial-review — an outside-the-loop utility that runs an optional adversarial review between fg-run and fg-learn: it assumes the result is wrong and fans out six lenses (failure points, hidden assumptions, misread requirements, security/performance/data-loss, unexpected misuse, weak decisions) as parallel workflow subagents, records findings to .forge/review.md, and on your approval turns fix-needed findings into a fix-forward plan to run again — optional, never a seal gate, always auto-skipped in unattended drives (ADR-0018), and fg-doctor — a read-only integrity health check (outside the loop) that surveys the .forge/ state contract and the docs/manifests and reports inconsistencies with a severity and an actionable fix hint each (orphaned run.md, broken/missing STATUS fields, slug-pairing mismatches, half-sealed done/, manifest version drift across the 3 places, README bilingual drift, skills missing from CLAUDE.md); it writes nothing and never auto-fixes — fg-status reports where you are, fg-doctor reports whether the state is healthy (ADR-0019), and fg-drop — an outside-the-loop utility that discards incomplete work you no longer want (a backlog plan, the active slot, an awaiting-retro task in executed/, or a halted goal loop): it lists the items with a per-item risk level (a checkbox dialog for ≤4, a numbered text list for ≥5), then a separate question to hard-delete (default, no trace) or archive to .forge/dropped/, behind a confirmation gate that warns already-run code is not reverted; it removes forge state only — never git, never your code — and a halted goal loop is dropped whole with its member tasks excluded from individual drop (ADR-0021). Use in contexts like 'start a new task', 'start with forge', 'let's work on this', 'refine the plan', 'map the codebase', 'forge quick', 'forge status', 'forge next', 'forge loop', 'forge tdd', 'forge eco', 'forge merge', 'forge cleanup', 'forge statusline', 'adversarial review', '적대적 리뷰', 'forge doctor', '무결성 검사', '상태 점검', 'forge drop', '작업 버리기', '계획 지워'.
Claude harness - A harness for solo developers (Vibecoders) to handle full-cycle contract development.
Core skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques
Harness-native ECC operator layer - 67 agents, 271 skills, 92 legacy command shims, reusable hooks, rules, selective install profiles, and production-ready workflows for Claude Code, Codex, OpenCode, Cursor, and related agent harnesses
Persistent file-based planning for AI coding agents. Crash-proof markdown plans (task_plan.md, findings.md, progress.md) that survive context loss and /clear, with an opt-in completion gate and multi-agent shared state. Manus-style. Works with Claude Code, Codex CLI, Cursor, Kiro, OpenCode and 60+ agents via the SKILL.md standard. Includes Arabic, German, Spanish, and Chinese (Simplified and Traditional).
Superpowers Plus core skills library for Claude Code: planning, execution routing, TDD, debugging, and collaboration workflows
Intelligent prompt optimization: injects the right context at the right moment so Claude lands a better first output. Clarifies vague prompts with research-based questions, plus targeted nudges for approach selection, plan readability, workflow routing, background execution, subagent routing, output readability, user-decision questions, and plan-mode assessment