adapt

Adapt to Superpowers + GStack

You are adapting an existing project to the Superpowers + GStack combined workflow. Unlike setup-routing (which is for new/empty projects), this skill preserves everything that already exists and makes only the changes needed for a smooth transition.

Invoke this skill with: /superpowers-gstack:adapt

<!-- Keep in sync with skills/setup-routing/SKILL.md dependency + directory checks --> 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-official then /plugin install superpowers

Missing: GStack — git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

Only mention the framework(s) that are actually missing. Restart Claude Code after installing, then run /superpowers-gstack:adapt again.

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 && claude

```

Then run /superpowers-gstack:adapt again.

Version check: This skill is version 1.11.2. If the project's CLAUDE.md contains a version marker (<!-- superpowers-gstack: X.Y.Z -->) with an older version, inform the user that routing and session rules will be updated to the current version as part of this adaptation. Projects on version 1.10.0 or earlier will gain a ### Model Routing section in their CLAUDE.md unless they opt out — surface this clearly so it's not a silent addition. Projects on 1.11.1 or earlier will gain three new gstack skill rows (/sync-gbrain, /scrape, /skillify) in the evaluation tables.

Process

Follow these steps in order. Do NOT skip steps.

Step 1: Analyze the project

Read and analyze the following (skip any that don't exist):

1. CLAUDE.md — existing instructions, conventions, routing rules
2. Package files — package.json, Package.swift, Cargo.toml, pyproject.toml, go.mod, Gemfile, plugin.json, etc.
3. Test configuration — jest.config., vitest.config., pytest.ini, .swiftpm/, Makefile test targets, etc.
4. CI/CD — .github/workflows/, .gitlab-ci.yml, Jenkinsfile, etc.
5. Git state — current branch, remotes, branching strategy (check recent branch names)
6. Project structure — ls the root and key directories to understand the layout
7. docs/ — existing documentation structure

Summarize what you found to the user. Be concise — focus on what matters for the transition.

Step 2: Identify the project type and stack

Based on Step 1, determine:

• Project type (web app, API, mobile, plugin, library, monorepo, etc.)
• Language(s) and frameworks
• Test framework and how to run tests
• Deploy target (if any)
• QA URL (if browser-testable)
• Whether it's a team or solo project

Present this to the user for confirmation, and ask one additional question about harnesses (needed for model routing in Step 5):

Based on my analysis, this is a [type] using [stack]. Tests run with [command]. [Deployed to X / Local-only]. [Has browser UI at X / No browser UI].

Is this correct? Anything to add?

Also: which harnesses do you run this project under? Pick all that apply: Claude Code, Pi (local-only — no network), Pi (hybrid — local + cloud fallback), or None — skip model routing entirely. Determines which model-routing columns the CLAUDE.md gets. Pick "None" to opt out of the v1.11.0 Model Routing feature for this project (existing CLAUDE.md content stays untouched; only routing updates happen).

STOP HERE. Do not continue to the next step until the user responds. Do not add "Next steps", suggestions, or any other content after the question. End your message with the question.

Step 3: Evaluate relevant skills

Use the same evaluation tables as setup-routing to determine which Superpowers and GStack skills are relevant. The tables are reproduced here for reference:

Superpowers skills:

| 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 |

GStack skills — 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 |

GStack skills — 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) |

GStack skills — 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) | | `/set