From ralph-crispies
Ralph Crispies: deep interview for the QRDS-PI cycle. Understands the goal, explores the codebase tactically, then grills the design in small dependency-aware batches with recommended answers. Optimized for voice input. Triggers on: rc-questions, interview, start cycle, new epic, rc questions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ralph-crispies:rc-questionsopusThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Start a QRDS-PI cycle with a deep interview.
Start a QRDS-PI cycle with a deep interview.
Task input: $ARGUMENTS
qrds-pi formula to create the phase bead graph with gatesbd CLI installed (bd --version >= 1.0.0).beads/ workspace initialized in the current project (bd init if not)gate registered as custom type (bd config set types.custom "gate")qrds-pi formula available in ~/.beads/formulas/bd --version
bd formula list | grep qrds-pi
If .beads/ doesn't exist, ask the user if you should run bd init.
If the formula isn't found, tell the user to check ~/.beads/formulas/qrds-pi.formula.json.
Read $ARGUMENTS. Determine whether you have enough context to explore.
If the input is substantial (a paragraph or more with clear intent): Skip to step 3. You know what to look for.
If the input is short or vague (a sentence, a few words, or empty): Ask the user to describe what they're trying to accomplish before exploring. You need to know the goal to know where to look.
"Before I explore the codebase, tell me what you're trying to accomplish and why. I'll figure out the specifics from the code."
Do NOT explore blindly. Get the goal first.
Infer the work type from the task description:
Confirm with the user briefly, then pour:
bd mol pour qrds-pi --var name="<task title>" --var type="<work type>"
Capture the root epic ID. Read the full bead graph:
bd children <epic-id> --json
Parse the JSON to identify all bead IDs by title prefix:
Record ALL bead IDs — you'll need them in step 7.5 to enrich descriptions with concrete dependency references.
Now that you know the goal, explore the codebase to understand what exists. This is NOT the deep research phase — that comes later in its own context window. This exploration is tactical: learn enough to ask smart questions.
What to look for based on work type:
For features: Where does this fit? What patterns exist? What adjacent code would be affected? What test infrastructure is in place?
For bugfixes: Where is the affected code? Can you see the bug? What tests exist? What changed recently in that area?
For research: What are the current implementations? What dependencies or constraints are visible in the code?
Use sub-agents for parallel exploration when the task touches multiple areas. Each sub-agent explores one area and reports back. This keeps exploration fast.
Example: task touches API + database + tests
- Agent 1: explore the API layer (routes, middleware, handlers)
- Agent 2: explore the database layer (models, migrations)
- Agent 3: explore the test setup (framework, fixtures, patterns)
Default stance: grill the design relentlessly until there is shared understanding. Walk down each branch of the design tree, resolve dependencies between decisions one-by-one, and provide a recommended answer for every question.
Ask questions in small, coherent batches. A batch should contain only the minimum set of questions needed to unlock the next branch of decisions. Do NOT dump the whole interview at once.
What to ask about (the model decides based on context — no templates):
What NOT to ask about (you already know from exploration):
Presentation format:
Present your findings first (what you learned from exploration), then the current batch. This gives the user context for answering.
"Here's what I found in the codebase:
- [finding 1]
- [finding 2]
- [finding 3]
Questions — answer this batch in one go:
- [question about intent/constraint] Recommended answer: [best current recommendation]
- [question about scope boundary] Recommended answer: [best current recommendation]
- [question about edge case preference] Recommended answer: [best current recommendation] ... N. [question about priority/trade-off] Recommended answer: [best current recommendation]
Reply instructions:
- reply
acceptto accept all recommendations in this batch- reply with a number and your preferred answer to override a specific item
- reply with multiple numbered overrides if needed
- anything you do not mention will be treated as accepted as recommended"
Aim for 2-5 questions per batch, 7 max in unusually broad cases. If a batch is larger than that, it is probably not dependency-aware enough. If a single question is especially high-risk, ask only that question in the batch.
The user will likely answer via voice dictation — one long response covering multiple questions. Expect:
acceptParse the response gracefully. Map answers back to questions even if they're not numbered. Extract the signal from imperfect speech-to-text.
Treat accept as acceptance of the whole batch.
If the user overrides only specific numbered items, treat every unmentioned item in that batch as accepted as recommended.
If a reply is ambiguous, preserve any clear accepts/overrides you can parse, then ask a narrow cleanup batch only for unresolved items.
If the answers unlock the next branch of decisions but new uncertainty appears, ask the next focused batch. If critical questions went unanswered, ask a tighter follow-up batch. Repeat as many times as needed until the decision tree is resolved.
Do not stop just because a fixed number of rounds has passed. Stop when the important branches are resolved well enough for research to proceed.
Synthesize the full interview into a structured artifact. This is what the research phase reads — it must be self-contained.
bd update <questions-bead-id> --description "$(cat <<'EOF'
# Questions: <task title>
**Work type:** <type>
**Epic:** <epic-id>
## Codebase Context (from exploration)
- <what exists today — files, patterns, frameworks>
- <relevant adjacent code>
- <test infrastructure>
## Interview
### Q1: <question>
**Recommended:** <recommended answer>
**Decision:** <accepted as recommended | overridden by user to ...>
### Q2: <question>
**Recommended:** <recommended answer>
**Decision:** <accepted as recommended | overridden by user to ...>
...
## Key Findings
- <bullet summary of critical constraints or context>
- <bullet summary of scope boundaries>
- <bullet summary of risk areas identified>
## Research Directions
- <specific areas the research phase should explore deeply>
- <questions that need codebase-level answers>
- <patterns to verify or investigate>
## Open Items
- <anything the user flagged as uncertain>
- <questions the user deferred or didn't answer>
EOF
)"
The Research Directions section is critical — it tells the autonomous research phase what to focus on. Without it, research explores blindly.
This is critical for context firewalling. Each phase bead needs to know exactly which bead(s) to read.
Read .claude/templates/phase-enrichment.md for the enrichment template.
Replace all <*-bead-id> and <epic-id> placeholders with the
actual IDs from step 3.
bd close <questions-bead-id>
bd label add <epic-id> autonomous
The autonomous label signals the overseer that R-D-S phases are ready
to run. Without it, the overseer ignores the epic.
Output to the user:
ralph-loop <epic-id>Do NOT tell the user to resolve gates or close beads manually. The R-D-S chain has no intermediate gates — dependencies handle ordering. The only gate is after structured-outline (reviewed via rc-next).
bd list --parent <epic-id>
bd ready
accept
accepts the full batch, numbered replies override specific items,
and unmentioned items count as accepted as recommended.<<'EOF') for bead descriptions.npx claudepluginhub mwarger/ralph-crispies --plugin ralph-crispiesCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.