| name | methodology-picker |
| description | Use this skill when the user asks to "set up a new project", "start a new project", "scaffold a project", "pick a methodology", "choose an SDD framework", "configure Claude Code for this project", "what methodology should I use", or discusses agentic development methodology selection. Helps the user route to the right Spec-Driven Development approach based on Piskala's three-level rigor taxonomy and Wasowski's four decision contexts. Does NOT write files — conversational guidance only. For actual scaffolding, route to /mck-scaffold:init. |
| version | 0.1.0 |
Methodology Picker
Help the user pick the right Spec-Driven Development methodology for their project context. This is conversational guidance, not scaffolding. The user is making a decision; you are helping them frame it.
When this skill auto-triggers
The user mentions:
- Starting / setting up / scaffolding a new project
- Choosing / picking / selecting an SDD framework or methodology
- Configuring Claude Code for a specific project
- "What methodology should I use for …"
- Comparison of Superpowers vs Spec-Kit vs MUSUBI vs OpenSpec
- Piskala / Wasowski by name
What to NOT do
- Do not write files. If the user wants files written, route them to
/mck-scaffold:init.
- Do not install plugins. Same rule.
- Do not present all options as equivalent — the whole point is to choose.
Conceptual frame
Piskala's three-level rigor taxonomy
| Level | Promise | Cost | When to pick it |
|---|
| L1 Spec-First | Flexibility | Low | ~80% of projects. Spec lives in the feature branch and becomes historical after merge. |
| L2 Spec-Anchored | Auditability + traceability | Medium-high | Regulated work. Spec lives the whole lifecycle; every change requires an addendum. |
| L3 Spec-as-Source | Guarantee by construction | Aspirational in 2026 | Watch / not-yet. Tessl (closed beta) and CSDD (academic). |
Higher rigor is not better. It is more expensive, and only pays off when the project genuinely needs the promise.
Wasowski's four decision contexts
| Context | Profile | Default path |
|---|
| A | Solo / small team, greenfield | Spec-Kit lean ± Superpowers HARD-GATE |
| B | 10+ team, regulated, compliance | MUSUBI + CSDD security overlay |
| C | Brownfield / legacy | OpenSpec + Shotgun CLI |
| D | Security-critical (fintech, healthcare, embedded) | CSDD + MUSUBI + OWASP Skill |
How to talk the user through it
Ask questions one at a time. Don't batch. Reference the question tree in interview/questions.md but adapt the wording conversationally.
The single most-discriminating question is: "Will an auditor ever ask about REQ-to-Test traceability for this code?" Answer determines L1 vs L2 cleanly.
Second-most-discriminating: "Greenfield or brownfield?" Brownfield routes to OpenSpec almost regardless of other answers — once you've identified brownfield, do not ask Q3 or Q4 (they're pruned by interview/questions.md; the routing table's brownfield-any rule short-circuits everything else).
Third (greenfield only): "Solo / small team / 10+?" Solo + greenfield + no audit → L1-lean or L1-superpowers. Team 10+ + audit → L2.
Honest caveats to surface
When recommending Superpowers: note the HN consensus that "I stripped it back to ~30%" — it's opinionated; that's a feature for serious work, friction for a 20-minute fix.
When recommending Spec-Kit: note the measured ~10x agent-time overhead on the first cycle (33.5 min vs 8 min baseline). Worth it on real product work, painful on throwaways.
When recommending MUSUBI: note that 28 GitHub stars vs Superpowers' 166k is not a sign of MUSUBI being bad — it's a sign that most teams don't need its rigor. If an auditor will ask, the 28 stars are irrelevant.
When the user's context suggests L3 might matter in 18+ months (security-critical financial/healthcare): mention Tessl and CSDD as "watch, not deploy" — don't oversell them. Tessl is closed beta; CSDD is a paper with one empirical study.
Handoff to the scaffolder
When the user agrees to install (any of "okay, do it" / "set this up" / "scaffold it" / "let's go"):
-
Capture the answer letters from the conversation. You've been having a guided discussion — now condense it into the canonical interview tuple. Map your conversational understanding to interview/questions.md letter options (a/b/c/d). If you're unsure of any letter, ask the user one clarifying question before proceeding.
-
Run scripts/route.py with the captured tuple (see commands/init.md step 3 for the JSON shape) to get the methodologies + profile deterministically. Do not interpret the routing table yourself.
-
Produce a ready-to-paste handoff. Output a single fenced block the user can paste verbatim:
/mck-scaffold:init --decision={"version":1,"methodologies":[...],"profile":"...","stack":"...","project_name":"...","rationale":"<one paragraph>","interview_answers":{"q1":"...","q2":"...","q3":"...","q4":"...","q5":"...","q6":"...","q7":"..."}}
Required fields in the JSON: version (always 1), methodologies (from route.py), profile (from route.py). Strongly recommended fields: stack (from Q5 — without this the installer cannot drop stack strictness files), rationale (one paragraph for the audit log), interview_answers (the captured letters, for reproducibility).
This is JSON-on-one-line; the JSON content must match schema/scaffold-decision.schema.json. When the user pastes that command, commands/init.md step 1a recognizes the --decision= arg and skips the interview — your conversation is the interview.
If the rationale paragraph would contain quote characters that break one-line JSON encoding, keep the rationale short for the handoff and write the longer version into docs/decisions/METHODOLOGY.md post-install. Don't fight JSON escaping.
-
Tell the user what just happened. One short paragraph: "I'd recommend X + Y at profile Z because . Paste the command above to install. The installer is deterministic — same input always produces the same output."
The picker remains read-only — it does not write files. The handoff is text the user explicitly pastes. The slash command does the write.
Status
Phase 2 complete. Conceptual frame, conversational guidance flow, and routing references are all functional. The interview executor (/mck-scaffold:init) consumes the same interview/questions.md and interview/routing.md files this skill references — they are the single source of truth for both the conversational and the deterministic paths.
