Getting Started
In one line: Install Superpowers, run setup/bootstrap.sh, read the operating card — then adopt Core gates first, Recommended as value shows, Project-specific only with an ADR.
This section is the entry point for adopting the methodology. The full onboarding is in the setup guide; this is orientation.
Installer: setup/bootstrap.sh <project-root> in the s4u-methodology repository — reads your existing config, shows a diff, and installs non-destructively. (Link omitted from synced docs since the kit lives outside the consuming repo's tree.)
The setup guide is a 10-step interactive onboarding process. Each step reads the developer's existing configuration before proposing changes, shows a diff of what would change, and waits for approval before applying. Nothing is overwritten — all changes are additive, and the process can be reversed by restoring from the recommended backup.
Quick Start (3 Steps):
For developers who want to evaluate the methodology before committing to full setup:
- Install the Superpowers plugin:
claude plugins install superpowers@superpowers-marketplace - Run
setup/bootstrap.sh <your-project-root>from this repo — it installs the corrected hooks (diff-aware Stop verification, lint-on-edit, pre-push gate, memory budget), the reviewer agents, the s4u skills, and the operating card. - Read the operating card (
docs/operating-card.md) — it is the byte-budgeted rule surface (enforced cap in bytes viascripts/context-budgets.tsv, measured bywc -c; roughly 5K tokens); this document is rationale and reference.
Adoption Tiers:
| Tier | Components | Value Provided |
|---|---|---|
| Core (non-negotiable) | Required CI status checks on the default branch: full test suite (never -x first-failure abort), full lint (ruff check + ruff format --check, not rule subsets); CODEOWNERS-backed human review on safety paths; where the product has a user-facing safety surface, a deterministic safety-floor eval subset as a required check; the Brainstorm Gate including the safety-policy trigger (Section 3.1); the single-source rule (Section 4.5); silent-failure discipline R1-R3; worktree isolation for agent work; the testing standard (no-mocking default, migrated-schema oracle, live contract smoke) | These are the gates with documented incident saves — code produced under them is trustworthy without relying on any individual's discipline |
| Recommended (strongly advised) | Reviewer agent definitions, memory discipline (Section 6), the kit hook templates, generated STATE.md, the consolidation census cadence (Section 2.8) | Development velocity and quality — proven valuable but divergence does not break integration |
| Project-specific (adopt with an ADR) | Domain compliance architectures (row-level security, regulatory patterns — see the case studies in docs/showcase.md), a Docusaurus living-doc site, MCP server integrations | Powerful where the domain demands them; cargo-culting them into a project that doesn't is pure process weight |
Permission mode is a security control, not a preference. Promptless agent action (dontAsk and equivalents) against anything that can reach production is a team-level decision with a stated default: plan mode or ask-permission for production-touching commands. Treating this as personal preference while treating a compliance architecture as "non-negotiable" inverts the priorities for any safety-critical system.
The tier classification allows incremental adoption: start with Core (it is mostly one-time configuration — branch protection, CI flags, CODEOWNERS), add Recommended as value becomes apparent, and adopt Project-specific components only with a deviation ADR explaining why the domain needs them.