Getting Started
This section provides the entry point for adopting the methodology. The full onboarding process is documented in the setup guide; this section provides orientation.
Setup Guide: setup/SETUP-GUIDE.md in the s4u-methodology repository (link omitted from synced docs since the file 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 ≤5K-token rule surface; 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 (e.g., Trust Relay's RLS and 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. The 2026-06-11 assessment (TA-06) found this classified as personal preference while another product's compliance architecture was "non-negotiable" — inverted priorities for a hospital-grade 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.