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.

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/<run-id>/ 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:

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.

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/<run-id>/.
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/<run-id>/, 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.