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
└── 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 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>/.
6. 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.
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.