mirumee/nimara-ecommerce/rfc-modeling

RFC modeling

Follow these stages in order. The technical grilling, and the self-lint are mandatory.

Altitude: a proposal, not an implementation plan

An RFC proposes a solution. It is not an implementation plan.

Describe the shape of the solution:

• the architectural principles that hold the design up: what layers over what, which boundaries are swappable, and the dependency direction.
• the key decisions.
• the implementation gotchas and the risks that can sink the design.

Do not specify exact package or folder paths, file or function names, type signatures, or line-level structure. Those belong in implementation tickets and pull requests. Package placement can appear once, as a one-line suggestion that does not bind the implementer.

If a detail is doubtful, ask one question: does a reviewer need this detail to judge the approach? If the answer is no, the detail sits too low. It constrains the implementer and it earns nothing.

Stage 1 - Resolve the PRD and pull context

An RFC is always anchored to one PRD. Resolve it first.

• If the user named a PRD, load it.
• If the user named no PRD, list the PRDs under llm-wiki/prd/ and ask the user to pick one. Do not invent a PRD. Do not design against a loose feature idea, because an RFC without a PRD has nothing to be falsified against.

Then read the following, before you question the user:

• the PRD, and especially its business bet, its deferred technical decisions, and its open questions.
• the relevant personas, strategy notes, and market notes.
• the existing ADRs and RFCs that overlap or constrain this design.
• the code and the infrastructure the design touches: packages, layers, services, schema, and config.

Use repository and source exploration to answer factual questions. Facts belong to exploration. Decisions belong to the user. Never invent a constraint, a current behavior, or a capability.

Completion criterion: the PRD is fixed, the deferred technical branches are collected, and you understand the affected code and infrastructure before research begins.

Stage 2 - Run technical grilling - use proper languages

Run a /llm-wiki:grilling session that which does not go beyond the scope of the RFC definition.

If a problem is complex use /llm-wiki:show-me skill so that the questions are easy for the user to understand. A diagram with a description settles a structural question faster than a paragraph.

Read references/technical-protocol.md and follow it completely.

Adjust your language so that it is as easy to understand as possible for the person you're grilling.

Stage 3 — Draft the RFC

Read references/rfc-template.md. Follow the wiki's local schema and link convention.

Stage 4 - Self-lint

Run every check in references/quality-checklist.md. Fix the issues that need no new decision. Put the genuine unknowns in the deferred items. Report every failed check instead of hiding it.

Completion criterion: every checklist item passes, or it is reported as an explicit gap with an owner.

Stage 5 - Gate

A new RFC starts as status: draft. A rewritten RFC changes status only when the user approves the transition explicitly: draft to in_review to final.

References

• references/technical-protocol.md - the mandatory sequential design interview and its completion gate.
• references/quality-checklist.md - the Definition of Ready for an RFC.
• references/rfc-template.md the canonical RFC template structure.