# Prompt: Discover RFC Suite Shape
Use this prompt before `projects/PROMPT-GENERATE-PROJECT-PACK.md` when a source corpus exists but the RFC suite boundaries have not been fixed yet.
Load these reusable repo assets first:
- `suite-discovery.contract.yaml`
- `schemas/suite-discovery-contract.schema.json`
- `templates/NORMATIVE-SURFACE-INVENTORY.md`
- `templates/SUITE-BOUNDARY-DECISION.md`
- `templates/PACK-SCAFFOLD-INPUTS.md`
- `templates/SUITE-DISCOVERY-BRIEF.md`
This is the repository's pre-pack discovery workflow. Follow the contract stage order:
1. `discovery-scope`
2. `corpus-map`
3. `surface-inventory`
4. `suite-shaping`
5. `handoff-packaging`
Before sending this prompt, prepare:
- a concrete system or project name
- the authoritative source corpus to analyze: implementation repos, standards text, official docs, schemas, traces, captures, fixtures, or exported artifacts
- any informative/background material that helps orientation but does not outrank the authoritative corpus
- any observed runtime or interoperability surfaces that reveal the system's real structure
- the authority rule to apply when sources disagree, or an explicit `unknown` if the workflow must infer and justify one
Required substitutions and context:
- replace `<system-name>` with the real project or system name
- attach or preload the authoritative and informative materials named below
- do not ask this prompt to scaffold files; its job is discovery and suite design only
Expected result and next step:
- this prompt must return the final `suite-discovery-brief` artifact, not a pack scaffold
- the final section must embed the `pack-scaffold-inputs` artifact using the exact headings from `templates/PACK-SCAFFOLD-INPUTS.md`
- after reviewing the suite decision, copy that final block into `projects/PROMPT-GENERATE-PROJECT-PACK.md` to scaffold the project pack
```text
You are running the RFC suite discovery workflow defined by `suite-discovery.contract.yaml`.
System under analysis: `<system-name>`
Load these project inputs before deciding document boundaries:
- authoritative source corpus: `<implementation repos, standards text, official docs, observed bytes, traces, schemas, datasets, exported artifacts, or equivalent>`
- informative/background material: `<orientation notes, explainer docs, wiki pages, prior drafts, blog posts, issue threads, or equivalent>`
- observed system structure: `<runtime surfaces, captures, APIs, wire traces, command behavior, exported files, interoperability evidence, or equivalent>`
- authority rule when sources disagree: `<implementation wins over docs | standards text wins | observed output breaks ties | unknown, infer and justify>`
This run is discovery only. Do not scaffold repository files, draft RFC prose, or redesign the downstream pack prompt.
## Stage contract
Advance in this order and do not skip a gate.
### Stage 1 — discovery-scope
Gate:
- confirm the system name, corpus boundary, observed surfaces, and authority rule
- state any unknown or operator-supplied inputs explicitly
- lock the run to discovery-only output
### Stage 2 — corpus-map
Gate:
- separate authoritative, informative, and observed sources
- note contradictions, stale docs, or gaps instead of smoothing them over
- identify which materials actually carry normative weight
### Stage 3 — surface-inventory
Gate:
- inventory the real normative surfaces from the loaded materials
- tie each surface to source anchors or observed evidence
- distinguish core surfaces from subordinate or non-normative material
### Stage 4 — suite-shaping
Gate:
- cluster the surviving surfaces into the smallest clean RFC suite
- merge, reject, or demote weak candidate documents with reasons
- assign terminology ownership, document dependencies, clean-room capabilities, and explicit non-goals
### Stage 5 — handoff-packaging
Gate:
- package the result into a final `suite-discovery-brief`
- embed scaffold-ready `pack-scaffold-inputs` that downstream pack generation can consume directly
- leave unresolved metadata questions explicit instead of guessed
## Decision standard
Identify the system's core:
- algorithms that define interoperable behavior
- processes or state transitions that implementations must reproduce
- formats, schemas, or artifacts that must be parsed or produced
- protocols or message exchanges that cross a system boundary
- roles or actors whose responsibilities change the normative behavior
- terminology that needs one clear owning document
Then cluster those findings into the smallest clean RFC suite that lets a competent reader understand, implement, validate, and review the system without duplicated ownership.
Prefer fewer documents unless a split clearly improves one or more of these:
- clean ownership of a normative subject
- separable clean-room implementability
- reduced cross-document duplication
- clearer review and validation boundaries
- reuse of one format/protocol/algorithm by another document
Do not create standalone RFCs for material that should remain subordinate, such as:
- deployment guidance
- operator runbooks
- UI behavior
- implementation-local helper code
- examples or fixtures that exist only to illustrate another document
- performance tuning, product positioning, history, or narrative background
- security or IANA text that belongs inside another document unless there is a real independent registries/security surface that demands its own specification
## Required output shape
Return the final `suite-discovery-brief` artifact using the section order from `templates/SUITE-DISCOVERY-BRIEF.md`.
### 1. System core summary
- short charter: what the system fundamentally does
- authoritative surfaces actually used
- observed/runtime surfaces actually used
- authority rule applied
- one-paragraph explanation of what makes this system worth specifying
### 2. Normative surface inventory
Use the column order from `templates/NORMATIVE-SURFACE-INVENTORY.md` and include one row per important surface:
- surface
- type: algorithm | process | format | protocol | role | terminology domain
- why it matters normatively
- likely owning document
- source anchors/evidence used to identify it
### 3. RFC suite recommendation
State:
- recommended suite size
- recommended deliverables list
- why this is the smallest clean suite
- rejected candidate documents and why they should stay dependent, merged, or out of scope
### 4. Document boundary table
Use the column order from `templates/SUITE-BOUNDARY-DECISION.md` and provide, for each recommended document:
- working short name
- proposed title
- normative heart section name
- owns
- explicitly does not own
- depends on
- depended on by
- required clean-room capabilities
- key edge cases or review traps
### 5. Cross-document rules
State:
- terminology owners
- cross-document dependency rules
- section-to-source routing notes
- suite-wide in-scope topics
- suite-wide out-of-scope topics
- open metadata questions that pack generation cannot infer safely
### 6. Pack scaffold inputs
Return the final section using the exact headings and field names from `templates/PACK-SCAFFOLD-INPUTS.md`.
## Guardrails
- Do not scaffold files or emit a repository tree.
- Do not propose extra documents just to mirror implementation modules.
- Do not hide uncertainty; mark unresolved metadata or naming questions explicitly.
- Do not invent authorities that were not present in the loaded materials.
- Do not let project-pack defaults drive the suite split; discovery owns boundaries first, pack scaffolding inherits them second.
- If one document can cleanly own a topic, prefer that over splitting it into a second RFC.
- If a topic only exists to support another document's implementability, keep it dependent unless separation is clearly justified.
```