Setup Routing — CLAUDE.md Generator
You are setting up the Superpowers + GStack combined workflow for a new project. Your job is to generate a CLAUDE.md file with routing rules tailored to this specific project.
Invoke this skill with: /superpowers-gstack:setup-routing
Dependency check: Before anything else, verify both upstream frameworks are installed. Run:
ls -d ~/.claude/plugins/cache/claude-plugins-official/superpowers/*/ 2>/dev/null | head -1
ls -d ~/.claude/skills/gstack/ 2>/dev/null
If either path is missing, STOP and tell the user:
This plugin is glue for two upstream frameworks. Install them first:
Missing: Superpowers —
/plugin marketplace add claude-plugins-officialthen/plugin install superpowersMissing: GStack —
git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setupOnly mention the framework(s) that are actually missing. Restart Claude Code after installing, then run
/superpowers-gstack:setup-routingagain.
Do NOT proceed until both frameworks are present.
Directory check: Verify that Claude Code's working directory is the target project. If the current directory appears to be a different project (e.g., the superpowers-gstack repo itself rather than the user's project), STOP and tell the user:
You're currently in
[cwd]. This skill needs to run from your target project directory. Start a new Claude Code session:cd /path/to/your-project && claudeThen run
/superpowers-gstack:setup-routingagain.
Important: If the project already has a CLAUDE.md file with existing content, STOP and suggest the user runs /superpowers-gstack:adapt instead — it preserves existing content while adding routing.
Version: This skill writes version 1.11.0 into the CLAUDE.md version marker.
Process
Follow these steps in order. Do NOT skip steps.
Step 1: Ask about the project
Ask the user ONE question:
What kind of project is this? (e.g., Swift iOS app, React/Next.js web app, Python API, Node.js backend, Flutter mobile app, Claude Code plugin/skill, data pipeline, infrastructure/Terraform, monorepo, static site, or describe it)
STOP HERE. Do not continue to the next step until the user responds. End your message with the question.
Step 2: Ask follow-up questions
Based on the project type, ask 3-5 focused follow-up questions. Always include questions 1-3 and 10. Add 4-9 based on relevance:
- What test framework will you use? (or "no tests yet")
- Will this be deployed? Where? (or local-only)
- Any security concerns? (auth, user data, payments, external APIs — helps evaluate
/cso) - Will this have a UI testable in a browser? What URL? (skip for CLI tools, libraries, pipelines)
- Is there a design component? (UI mockups, design system — skip for backend-only)
- Is this a team project with a regular cadence? (helps evaluate
/retro) - Is this a long-running project or a one-off? (helps evaluate
/learn) - Do you have existing linting, type checking, or test suites? (helps evaluate
/health) - Is this a monorepo? Which directory will you work in? (helps evaluate
/freeze) - Which harnesses will you run this project under? Pick all that apply: Claude Code, Pi (local-only — no network calls), Pi (hybrid — local + cloud fallback), or None — skip model routing entirely. Determines which model-routing columns get emitted in CLAUDE.md. Pick "None" to opt out of the new v1.11.0 Model Routing section completely; setup-routing falls back to its v1.10.0 behavior for this project.
Ask all follow-up questions in a single message. STOP HERE. Do not continue to the next step until the user responds. Do not add suggestions or any other content after the questions. End your message with the questions.
Step 3: Evaluate relevant Superpowers skills
Based on the project type and answers, evaluate which Superpowers skills are relevant. Think through each one:
| Skill | Consider relevant when... |
|---|---|
/superpowers:brainstorming | Almost always — skip only for trivial projects |
/superpowers:writing-plans | Almost always — skip only for single-file changes |
/superpowers:subagent-driven-development | Projects with 5+ tasks, benefits from parallel TDD |
/superpowers:executing-plans | Smaller projects (< 5 tasks), or when user wants more control |
/superpowers:systematic-debugging | Any project with code that can have bugs |
/superpowers:dispatching-parallel-agents | Projects with clearly independent modules |
/superpowers:using-git-worktrees | Projects where feature isolation matters |
/superpowers:finishing-a-development-branch | Projects using feature branches and PRs |
/superpowers:test-driven-development | Projects with testable code (most projects) |
/superpowers:verification-before-completion | Complex projects where correctness is critical |
/superpowers:requesting-code-review | Multi-file changes (runs automatically during SDD, but can be invoked manually) |
/superpowers:receiving-code-review | After /review or PR feedback requires code changes — structures the response with TDD |
/superpowers:writing-skills | Only for Claude Code plugin/skill projects |
Step 4: Evaluate relevant GStack skills
Think through each GStack skill, organized by phase:
Phase 1 — Planning:
| Skill | Consider relevant when... |
|---|---|
/office-hours | New product ideas, features with unclear scope |
/plan-ceo-review | Projects with strategic decisions or significant scope |
/plan-eng-review | Projects needing architecture decisions |
/plan-design-review | Projects with UI/UX components |
/design-consultation | New projects defining a design system from scratch (creates DESIGN.md) |
/design-shotgun | When you want multiple design variants to compare before committing |
/plan-devex-review | Projects with developer-facing surfaces (APIs, CLIs, SDKs, libraries) |
/plan-tune | Tune plan-skill question preferences (one-time, per-project) |
/autoplan | When all three plan reviews are relevant — chains them automatically |
Phase 3 — Review & QA:
| Skill | Consider relevant when... |
|---|---|
/review | Almost always — pre-merge code review |
/qa <url> | Projects with a browser-accessible UI (include the URL) |
/qa-only <url> | Same, but report-only (no auto-fixes) |
/cso | Projects handling auth, user data, payments, or external APIs. For security-critical features, run BEFORE /review |
/design-review | Projects with visual UI — catches spacing, alignment, inconsistencies |
/design-html | When you have an approved design and need production HTML/CSS |
/devex-review | Developer-facing projects — live audit of onboarding flow, docs, CLI help |
/investigate | Bugs discovered AFTER Phase 2 — in QA, staging, or production. Do NOT use during Phase 2 implementation (use /superpowers:systematic-debugging instead) |
Phase 4 — Ship & Monitor:
| Skill | Consider relevant when... |
|---|---|
/ship | Projects using git with feature branches and PRs |
/land-and-deploy | Projects with CI/CD deployment pipelines |
/canary | Projects with production monitoring needs |
/landing-report | Read-only PR queue + sibling-workspace dashboard (workspace-aware ship) |
/setup-deploy | One-time: configure deploy platform (Fly.io, Vercel, Render, etc.) for /land-and-deploy |
/document-release | Projects with documentation to maintain |
/retro | Team projects with regular sprint cadence |
/learn | Long-running projects (> 2 weeks) — saves cross-session learnings |
/setup-gbrain | Long-running projects wanting cross-session memory (PGLite local or Supabase) |
/sync-gbrain | Long-running projects with gbrain — keeps the brain current with |