Octocode RFC Generator

Produce evidence-backed decisions that an implementer and reviewer can execute. Flow: UNDERSTAND → RESEARCH → PREREQUISITES → COMPARE → WRITE → CLOSE QUESTIONS → KPI → VALIDATE → DELIVER. For existing RFCs, run REASSESS (see references/workflow.md § Reassess existing RFCs) instead of WRITE — audit against live code, not prior checkboxes.

Lobby rules

• Skip RFC mode for trivial edits. Ask one focused question when uncertainty changes shape, owner, scope, or decision criteria.
• Compare at least two alternatives, including do-nothing, unless the user explicitly requests one implementation plan.
• Recommendations require verifiable facts; cite exact anchors and commands/checks that actually ran.
• RFC.md owns goals, scope, and decision. Other files link to its anchors rather than restating them.
• Resolve every open question with evidence or an explicit deferral; no recommendation may rest on an uncertain claim.
• Order implementation by dependency, not estimates; bind requirements to acceptance and verification.
• Reviewing, rating, or cleaning up .octocode/rfc/ (delete/implemented/fixed calls) always requires a dated ## Audit Reasoning block written into the RFC itself, backed by fresh reads of the live code.
• Never assert RFC status from memory or from another RFC's claims.
• Stop when: the change is a trivial one-file edit (route to octocode-research); a brainstorming handoff is marked Prototype First, Narrow, Park, or not ready; uncertainty changes artifact shape, owner, scope, or tradeoff priority; two research attempts fail (state what is known and ask for direction); scope needs splitting into separate RFCs or phases; an unresolved blocker would have to be assumed satisfied; or a save, delete, or archive under .octocode/rfc/ awaits explicit approval.