rfc-workflow: Prompt Template: Generate a New Project Pack

Use this prompt with your harness model when you want it to scaffold a new projects/<name>/ pack for this repository's RFC workflow.

Replace every bracketed placeholder before use.

Create a new project pack under projects/[project-name]/ for the RFC workflow in this repository.

Goal

Scaffold the pack directory and draft the pack documents needed to support authoring this RFC project:

project name: [project-name]
intended RFC suite or documents: [list each target document or deliverable]
short project summary: [one paragraph describing what the suite/document set specifies]

The result should be a project-context pack only. Keep core/, repo-wide prompts, and top-level workflow semantics untouched.

Required outputs

Create projects/[project-name]/ with the following skeleton, adapting filenames under briefs/ and examples/ to the project:

projects/[project-name]/
├── README.md
├── suite-brief.md
├── corpus-brief.md
├── references.md
├── draft-metadata.md
├── briefs/
│   ├── [doc-brief-1].md
│   └── [doc-brief-2].md
├── examples/
│   └── [optional example seed file(s)]
├── references/
│   └── README.md
└── runs/
    └── README.md

If the project needs more or fewer per-document briefs, adjust briefs/ accordingly. If examples are not useful yet, still create examples/ only when the repo's conventions require it; otherwise explain that no example seed file was needed.

Project inputs

Use the following inputs to draft the pack docs.

1. Project name and suite shape

project directory name: [project-name]
project title: [human-readable title]
suite/documents: [document A, document B, ...]
intended deliverables: [for example: one RFC, a three-document suite, companion appendix, etc.]

2. Source corpus

Describe the material that governs the drafts.

authoritative source corpus: [implementation repos, standards corpus, datasets, traces, observed bytes, official docs, etc.]
informative/background material: [orientation docs, wiki pages, articles, design notes, prior drafts, etc.]
runtime or observed-evidence surfaces: [commands, logs, captures, repositories, fixtures, APIs, exported artifacts, etc.]
authority rule when sources disagree: [for example: implementation wins over lagging docs]

3. Scope boundaries

State what the pack covers and excludes.

in scope: [topics, protocol generation, artifact family, data model, interfaces, time window, versions, etc.]
out of scope: [legacy paths, old versions, deployment-specific behavior, UI, non-target protocols, etc.]
cross-document boundaries: [which document owns which topic]

4. Authoritative references

List the references the pack should treat as curated pack-level references.

normative references: [specs, standards, required external references]
informative references: [supporting docs, explanatory material, history]
internal dependencies: [document A depends on document B for terminology/format/etc.]

5. Terminology and dependency map

Provide the ownership model the harness should encode into references.md.

terminology owners: [term -> owning document or source]
dependency map: [document -> depends on ...]
citation hygiene notes: [what should be cited narrowly; what should not be duplicated]

6. Metadata and front-matter defaults

Provide shared draft defaults for draft-metadata.md.

submission/intended status defaults: [IETF/std/informational/etc.]
title defaults: [per document if needed]
abstract anchors: [one sentence or paragraph starter per document]
deliverable forms: [kramdown, txt, xml intermediate, etc.]
provenance/authorship rules: [human-only authors, where provenance text may appear, etc.]
any additional front-matter defaults: [keywords, category, stream, boilerplate constraints, etc.]

7. Planned briefs

List the files that should appear under briefs/ and what each brief must cover.

briefs/[name-1].md -> [scope, required sections, required capabilities, exclusions, edge cases]
briefs/[name-2].md -> [scope, required sections, required capabilities, exclusions, edge cases]
additional briefs: [repeat as needed]

8. Optional examples

If useful, specify example or anomaly seed material.

example seeds needed: [yes/no]
if yes, files to create under examples/: [filename -> purpose]
example policy: [observed-only, round-trip required, render traps to watch, anomalies to confirm, etc.]

9. Staged reference material to seed

Describe any local support-only material the harness should mention or prepare for under references/.

staged support material types: [copied excerpts, manifests, payloads, scrape outputs, fixture indexes, etc.]
whether to seed placeholder filenames or only the README: [choice]
ignore guidance: [tell future authors to keep copied/bulky staged files ignored rather than canonical]

10. Pack-local run-root placeholder

Describe the pack-local run-root note the harness should create under runs/README.md.

repo-local run-root rule: projects/[project-name]/runs/<run-id>/
required run layout: public/, evidence/, gates/, optional logs/
reminder: runs/README.md stays tracked; generated run contents belong under <run-id>/ and should remain ignorable by repo policy

Instructions for the harness

When generating the pack:

Create only files under projects/[project-name]/.
Do not modify core/, repo-level workflow rules, top-level prompts, or toolchain semantics.
Write pack docs that are source-agnostic in tone but explicit about this project's authorities, scope, and terminology ownership.
Keep a clear distinction between:
- authoritative pack docs such as corpus-brief.md and references.md,
- support-only staged material under references/, and
- run-owned output that will live later under runs/<run-id>/.
Draft references/README.md so it explains that copied source excerpts, manifests, exports, or other local support material belong there and should normally be kept ignored rather than treated as canonical checked-in content.
Put stable project conclusions in the canonical pack docs, not only in staged support files.
Make suite-brief.md describe the suite charter, deliverable boundaries, and cross-document rules.
Make corpus-brief.md identify the authoritative corpus, informative sources, evidence surfaces, and section-to-source routing.
Make references.md capture the normative/informative reference pools, terminology ownership, internal dependencies, and citation hygiene rules.
Make draft-metadata.md capture shared front-matter defaults without restating repo-wide workflow mechanics.
Make each file in briefs/ document one target RFC/deliverable with concrete scope, required capabilities, exclusions, and edge cases.
If examples/ is used, keep it focused on observed examples, anomaly seeds, or example-capture traps rather than normative prose.
Add a pack-local README.md that explains the suite, summarizes the pack contents, and tells a new contributor how to load the pack.
Add runs/README.md that explains repo-local executions for this pack belong under projects/[project-name]/runs/<run-id>/, preserving public/, evidence/, gates/, and optional logs/.
Do not create a shared projects/runs/ reference or tell the operator to place run artifacts outside the selected pack namespace.

Expected response shape

In your response:

create the files,
populate them with first-draft content based on the inputs above,
preserve the workflow's existing neutral architecture,
summarize any placeholders or assumptions that still need a human to refine.

If an input is missing, make the gap explicit in the generated file instead of inventing hidden project facts.

Suggested usage note for the operator:

After the harness generates the pack, review projects/README.md in this repo and confirm the new pack:

separates authoritative pack docs from staged support material,
identifies the real source corpus,
names the normative and informative reference pools,
maps terminology ownership and document dependencies,
includes runs/README.md so cloned packs inherit the per-project run-root shape,
leaves core/ and top-level workflow semantics untouched.