# 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:
```yaml
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.