# Prompt Template: Generate a New Project Pack Use this prompt with your harness model when you want it to scaffold a new `projects//` pack for this repository's RFC workflow. If the suite shape, document boundaries, or non-goals are not already fixed, run `prompts/discover-rfc-suite-shape.md` first and use its final `Pack scaffold inputs` block to fill this template. Replace every bracketed placeholder before use. --- Create a new project pack under `projects/[project-name]/` for the RFC workflow in this repository. Start from the reusable defaults in `projects/template-ietf/` and inherit them unless I explicitly override them below. ## 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. ## Inherited IETF defaults unless overridden Assume all of the following without asking me to restate them: - draft source is kramdown-rfc Markdown `.md` - public rendered deliverable is `.txt` - RFCXML `.xml` is an intermediate artifact - `references.md` is the pack-level curated reference pool - per-document briefs use the common RFC section skeleton: - Introduction - Conventions and Terminology, including the BCP 14 note when requirement keywords are used - the document's normative heart, renamed to the real protocol / format / data-model section - Security Considerations - IANA Considerations, defaulting to explicit no-action unless the project needs registrations - normative versus informative references - repo-level kramdown-rfc and xml2rfc mechanics stay in `toolchains/kramdown-rfc-mechanics.md` - pack-local runs live under `projects/[project-name]/runs//` with `public/`, `evidence/`, `gates/`, and optional `logs/` Only record overrides when the project genuinely differs from those defaults. ## Required outputs Create `projects/[project-name]/` with the following skeleton, adapting filenames under `briefs/` to the project: ```text 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 ├── references/ │ └── README.md # placeholder boundary note; the default ignore glob matches it too, so explicitly add/promote it when scaffolding a new pack └── runs/ └── README.md ``` If the project needs more or fewer per-document briefs, adjust `briefs/` accordingly. Create `examples/` only if the project-specific inputs below actually justify example seeds. ## Project-specific inputs Use the following inputs to draft the pack docs. Prefer the output of `prompts/discover-rfc-suite-shape.md` when available so the scaffold inherits the decided suite boundaries instead of re-deriving them. ### 1. Project identity 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.]` - short charter: `[what the project standardizes, who needs it, and what a clean-room implementer or reviewer should be able to do]` ### 2. Normative scope and boundaries - in scope: `[topics, protocol generation, artifact family, data model, interfaces, time window, versions, etc.]` - out of scope: `[legacy paths, deployment-specific behavior, UI, non-target protocols, etc.]` - cross-document boundaries: `[which document owns which topic]` - required clean-room capabilities: `[what a competent reader must be able to parse, produce, validate, or understand]` ### 3. Authoritative corpus and evidence routing - 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]` - section-to-source routing notes: `[where Introduction, terminology, normative core, examples, security, etc. should look first]` ### 4. Project-specific references and dependencies - 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.]` - terminology owners: `[term or term family -> owning document or external source]` - citation hygiene exceptions, if any: `[only if this project differs from the template default]` ### 5. Front-matter inputs that remain project-specific - per-document titles: `[exact titles]` - authors/editors and affiliations: `[real human names and orgs]` - stream / submission type / intended status: `[IETF / IRTF / independent / etc. and status]` - abstract anchors: `[one sentence promise per document]` - provenance or special boilerplate rules: `[if any]` - metadata overrides to the inherited defaults: `[only if the project differs from md -> txt with xml intermediate]` ### 6. Planned briefs List the files that should appear under `briefs/` and what each brief must cover. - `briefs/[name-1].md` -> `[scope, normative heart, dependencies, exclusions, edge cases]` - `briefs/[name-2].md` -> `[scope, normative heart, dependencies, exclusions, edge cases]` - additional briefs: `[repeat as needed]` ### 7. Optional examples or staged support material Provide this only when the project actually needs it. - example seeds needed: `[yes/no]` - if yes, files to create under `examples/`: `[filename -> purpose]` - staged support material under `references/`: `[copied excerpts, manifests, payloads, scrape outputs, fixture indexes, etc., if any]` ## Instructions for the harness When generating the pack: 1. Create only files under `projects/[project-name]/`. 2. Do not modify `core/`, repo-level workflow rules, top-level prompts, or toolchain semantics. 3. Start from `projects/template-ietf/` and preserve its reusable IETF defaults unless the project-specific inputs above explicitly override them. 4. Write pack docs that are source-agnostic in tone but explicit about this project's authorities, scope, terminology ownership, and metadata decisions. 5. Keep a clear distinction between: - authoritative, versioned pack docs such as `corpus-brief.md` and `references.md`, - support-only staged material under `references/`, whose `README.md` explains the boundary once tracked; the default `projects/*/references/*` glob also matches that placeholder, so explicitly add/promote a new pack's `references/README.md` and any other files you want versioned, - and run-owned output that will live later under `runs//`. 6. Draft `references/README.md` so it explains that copied source excerpts, manifests, exports, or other local support material belong there, that authoritative versioned conclusions belong in `references.md` or other canonical pack docs, and that the default ignore rule covers the whole directory unless a file is deliberately promoted. 7. Put stable project conclusions in the canonical pack docs, not only in staged support files. 8. Make `suite-brief.md` describe the suite charter, deliverable boundaries, scope rules, and cross-document ownership without restating inherited IETF defaults unless overridden. 9. Make `corpus-brief.md` identify the authoritative corpus, informative sources, evidence surfaces, and section-to-source routing. 10. Make `references.md` capture the project-specific normative/informative reference pools, terminology ownership, internal dependencies, and any citation-rule exceptions. 11. Make `draft-metadata.md` keep the inherited `.md` -> `.txt` with `.xml` intermediate defaults unless overridden, while still forcing explicit project-specific titles, authors, stream, status, and abstract anchors. 12. Make each file in `briefs/` document one target RFC/deliverable with concrete scope, the default RFC section skeleton already specialized, required capabilities, exclusions, and edge cases. 13. Add a pack-local `README.md` that explains which IETF choices are reusable defaults and which inputs the project owner still must provide. 14. Add `runs/README.md` that explains repo-local executions for this pack belong under `projects/[project-name]/runs//`, preserving `public/`, `evidence/`, `gates/`, and optional `logs/`. 15. Create `examples/` only when the provided inputs justify example seeds; otherwise do not invent them. 16. 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 and the inherited template defaults, - preserve the workflow's existing neutral architecture, - summarize any remaining project-specific gaps or explicit overrides 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: - inherits the reusable IETF defaults unless the project says otherwise, - separates authoritative pack docs from staged support material, - identifies the real source corpus, - names the project-specific 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.