rpi-blueprint

name

rpi-blueprint

description

Go from a research note or a short problem statement straight to a phased plan in one pass, without a separate design to review. Use when user says 'just get me to a plan', 'skip the design, plan it', 'one-shot this from the research note', or 'I don't need a design, just plan this'. Do NOT invoke for genuine tradeoffs, multiple defensible approaches, or high-blast-radius changes — use rpi-propose instead; for a narrow scoped change to existing behavior use rpi-plan.

Fused Research-to-Plan Blueprint

Goal

Take a research note or a short problem statement to a phased implementation plan in a single pass: perform condensed design reasoning inline and emit the plan directly, without producing a separate reviewable design artifact. Always emit a minimal behavioral spec (the SDD floor) and record the design reasoning that would have lived in a design file as a ## Design Notes block inside the plan.

This is the fused shortcut — structurally omitting the design deliverable — as distinct from fast-forward mode, which runs the full pipeline fast but still produces a design.

Auto-detect the input:

• Research artifact (path to a research doc) → resolve its chain, reason inline, emit plan + minimal spec
• Short problem statement (plain text small enough to reason about in one pass) → condensed inline reasoning, then emit plan + minimal spec
• Nothing provided → ask for a research path or a short problem statement, with brief examples of each

On success, suggest → /rpi-implement <plan-path> (or, under --ff, the chain has already continued there).

Invariants

• See the project's RPI Skill Contract for --ff / --grill semantics; both flags apply here and are mutually exclusive
• Refuse-and-redirect hard gate (runs first, even under --ff): before writing anything, judge whether the work carries genuine tradeoffs, more than one approach a reasonable engineer would defend, or high blast radius. Apply the split-score signals — component count, directory spread, multi-spec — to the problem statement / research as one input; scaffold a throwaway design to score only when the call is genuinely ambiguous. If any hold, decline to produce a plan, explain in one or two sentences why the work needs a reviewable design, and suggest /rpi-propose <input>. This gate is an integrity check, not a review pause: it fires even under --ff and stops the chain — never silently chain into /rpi-propose --ff. If neither a research artifact nor a problem small enough to reason about in one pass is supplied, ask for a research pass or redirect to /rpi-propose
• If a research artifact is provided, read it fully and resolve its full artifact chain — warn if it is still draft or already complete
• Before drafting, search for prior plans, designs, and specs on this topic; if a prior plan covers the same scope, ask whether to extend it
• Check .rpi/specs/ for specs covering the affected area — the plan and the minimal spec must satisfy (and must not contradict) these behavioral contracts
• Condensed design reasoning inline: commit to the obvious approach and weigh it against the obvious alternative(s) in one pass — no parallel option-exploration fan-out. The fused path does less exploration than rpi-propose; if exploration surfaces a second defensible approach, that is the refuse signal, not a reason to keep exploring
• ## Design Notes block is mandatory near the top of the produced plan: the chosen approach, the alternative(s) considered and dropped, and the blast-radius judgment that justified blueprint over propose. The fused path omits the design deliverable, never the design reasoning
• Minimal spec floor: always write and link a behavioral spec describing user-observable behavior — 3-5 Given/When/Then scenarios (fewer than a full propose spec, reflecting the small scope that qualifies for this path), plus a Constraints section and an Out of Scope section. Scenarios must not reference internal structure (structs, file paths, function names). Name the spec file after its feature field. A plan with no linked spec is a contract violation
• Break the change into ordered phases — each leaves the codebase working and testable; each phase has tasks with file paths, success criteria (automated + manual), and a commit step; include tests in the same phase as the code they test. Map phases to spec scenarios where applicable
• When drafting each phase's Stage list, exclude paths matching .gitignore rules — gitignored artifacts (commonly the plan and spec files themselves under the default tracked-specs policy) must not appear in commit instructions
• Get buy-in on the condensed design reasoning and the proposed phases before writing the full plan
• Under --ff, skip the plan-outline approval pause — write the plan + minimal spec immediately, then invoke /rpi-implement --ff <plan-path> via the Skill tool and finally /rpi-verify <plan-path> once at the end, propagating --ff. The refuse gate above still stops the chain
• Under --grill (or matching natural-language phrasing) and when grill-me is available, invoke grill-me on the condensed design reasoning + phase outline in a single pass before writing the plan; apply revisions inline. If grill-me is unavailable, tell the user and ask whether to proceed with the standard approval gate
• Scaffold and save the plan artifact, linking the minimal spec in frontmatter (and the upstream research, when one was the input)
• Transition the research artifact to complete when it was the input and is fully addressed
• On success, suggest the next step (/rpi-implement <plan-path>), consistent with every other stage

Principles

• Commit to the obvious approach and record why — blueprint does condensed reasoning, not option fan-out; genuine ambiguity is a refuse signal, not a planning input
• Minimal is a floor, not a license — the spec is smaller than a propose spec, never absent
• Omit the deliverable, keep the reasoning — ## Design Notes makes the dropped design auditable so /rpi-verify has something to check against
• Blueprint is fused deliverables; --ff is suppressed pauses — they compose cleanly, but they are not the same axis
• Grilling is opt-in and single-pass — re-invoke if a second round is needed

Recommended model: premium tier, high effort — fused research → design → plan reasoning in one pass. Advisory; see docs/model-routing.md.