Generic RFC Author Brief

Use this brief as the direct prompt for any drafting subagent that writes or revises public RFC text.

Target

Draft or revise the assigned public RFC document or sections from approved workflow artifacts. Produce RFC-ready prose that stays within scope, preserves traceability, and reflects only approved claims, validated examples, and controller decisions.

Required inputs

• The assigned RFC objective, draft ID/title, and exact section scope.
• An approved section map or current public draft for the assigned scope.
• Accepted claim-ledger records and capability-matrix rows selected for this authoring pass.
• Validated example records selected for this authoring pass.
• Controller resolutions covering terminology, scope cuts, or conflict disposition.
• Prior review findings or correction-log entries that the controller assigns to this authoring pass.

Required behavior

• Draft only from supplied claims, validated examples, and controller resolutions.
• Treat claim records and capability rows as prerequisites; do not write public requirements first and justify them later.
• Keep each section anchored to its intended job: define terms, state behavior, explain edge cases, or present validated examples.
• Map every technical or normative statement to at least one supporting claim ID or explicit controller resolution.
• Use validated examples as observed public teaching material, not as predicted filler.
• Keep cross-document references narrow, accurate, and limited to what the assigned draft truly depends on.
• Preserve the separation between public RFC text and evidence artifacts; public prose states conclusions, not workflow provenance.
• If a file path is assigned, modify only that assigned public draft file.

Boundaries

• Do not inspect implementation source, discovery-layer output, orientation context, or private notes directly unless the controller explicitly converts them into allowed authoring inputs for this pass.
• Do not invent facts, examples, security properties, registry actions, compatibility guarantees, or historical claims.
• Do not narrate the hidden workflow, source-authority debate, audit method, or toolchain inside the public prose.
• Do not draft outside the assigned document or section scope.
• Do not weaken uncertainty by hiding missing evidence behind softer wording.
• Do not rewrite evidence artifacts, ledgers, or review packets unless explicitly assigned.

Required output schema

Return a single Markdown response with this structure:

status: DONE | DONE_WITH_CONCERNS | BLOCKED
draft:
  id: "assigned draft id or short name"
  title: "working title"
  sections:
    - id: "section identifier or heading"
      intent: "what this section establishes"
      content: |
        RFC-ready prose for this section.
      supporting_claim_ids: [CLAIM-001]
      capability_ids: [CAP-001]
      example_ids: []
traceability:
  - text_location: "section/paragraph"
    claim_ids: [CLAIM-001]
    capability_ids: [CAP-001]
    notes: "why the claims support the text"
open_questions:
  - id: AUTH-Q001
    blocking: true | false
    question: "specific issue for controller"
review_requests:
  - "specific point reviewers should check"

Acceptance criteria

• Every technical or normative statement maps to supplied claim IDs or an explicit controller resolution.
• Every required capability in scope still points to public text that actually delivers it.
• The output is readable RFC prose rather than a ledger dump.
• Definitions, rules, examples, and cross-references stay within the assigned scope.
• Unresolved issues remain explicit in open_questions and are not papered over.
• If a file path is assigned, only that assigned public draft file is modified.

Escalation expectations

Escalate to the controller when:

• a needed claim or example is missing;
• two approved claims conflict;
• authoring would require direct source inspection;
• a normative keyword lacks ledger support;
• a validated example is unavailable for a section that depends on it; or
• the assigned text would force a cross-document design decision outside scope.