# RFC Workflow
This repository exists to make **source-grounded RFC authoring** repeatable, reviewable, and portable.
It began when Dan Shearer reached out with a real task and an unusually well-crafted project pack for Fossil and libfossil: generate RFCs that writers and reviewers could examine as serious, evidence-backed specifications rather than as vague summaries or hand-wavy design notes. The deeper hope behind that effort was not only to clarify Fossil as it stands today, but to make future ports in new languages easier to build, easier to review, and easier to trust—and, in turn, to help Fossil flourish in new domains and alongside other forges.
That origin matters here. This workflow was first exercised in the orbit of Fossil and libfossil, and it is offered with gratitude to Richard Hipp, Stephan Beal, and Dan Shearer, whose work, clarity, and trust made the exercise worth doing.
At the same time, this is **not** a Fossil-only repository. It gathers practical lessons from LLM harness techniques, context engineering, loop engineering, and agentic workflows, then recasts those lessons into a harness-agnostic method meant to be reused, adapted, and passed on.
## What this repository is
`rfc-workflow` is a reusable way to turn source material into RFC drafts without losing contact with the underlying evidence.
It is deliberately harness-neutral. The repo does not ask you to adopt one runner, agent framework, or plugin stack. Instead, it gives you:
1. a workflow for serious RFC production,
2. project packs for source-specific material, and
3. run-local output for each execution.
That separation is the point: the method can travel, the project knowledge can stay local to one pack, and the generated drafts can stay local to one run.
## Start here
If you are new, use this order:
1. Read `AGENTS.md` for load order, operating assumptions, and runtime expectations.
2. Read `GENERATING-RFCS-FROM-SOURCE.md` for the full end-to-end walkthrough.
3. Read `projects/README.md` to understand what a project pack contains and how packs are organized.
4. Then decide whether you need to discover a suite, scaffold a pack, translate the workflow into a harness, or run an existing pack.
## The workflow order
The repo is organized around one real sequence:
1. **Discovery** — decide the RFC suite shape when the boundaries are still open.
2. **Pack scaffolding** — create or refine the project pack that holds the source-specific material.
3. **Harness translation** — adapt the neutral workflow into the execution model of your chosen harness.
4. **Execution** — run one selected project, one selected scope, and one run-local workspace.
If you already have a good project pack, you may skip discovery and pack creation in practice. The conceptual order still stays the same: discovery before pack scaffolding before translation before execution.
## Where to go next
### For operating guidance
- `AGENTS.md` — how to load and operate the workflow correctly in an agent runtime.
- `GENERATING-RFCS-FROM-SOURCE.md` — the reader-friendly walkthrough from corpus to rendered draft.
### For project-pack work
- `projects/README.md` — how packs are shaped, what belongs in them, and where runs live.
- `projects/PROMPT-GENERATE-PROJECT-PACK.md` — the pack-generation prompt when you need to create or repair a pack.
- `projects/template-ietf/` — the checked-in starter/reference pack shape.
### For workflow contracts and prompts
- `suite-discovery.contract.yaml` and `schemas/` — the authoritative shape for suite discovery.
- `workflow.contract.yaml` and `schemas/` — the authoritative shape for execution after a pack exists.
- `prompts/discover-rfc-suite-shape.md` — use during discovery.
- `prompts/translate-workflow-for-harness.md` — use when adapting the workflow to a harness.
- `prompts/run-selected-project.md` — use when executing one chosen pack and scope.
### For supporting materials
- `core/` — reusable workflow semantics and guardrails.
- `briefs/`, `templates/`, and `toolchains/` — shared support material for discovery, drafting, and rendering.
## Repository map in one sentence
Think of a run as:
> neutral workflow + selected project pack + harness translation + one run-local workspace
That is the design center of this repository.
## A few orienting notes
- Project-specific source knowledge belongs under `projects/<name>/`.
- Generated drafts, evidence, and gate records belong under `projects/<name>/runs/<run-id>/`.
- If prose and contracts ever disagree about required order or deliverables, follow the relevant contract.