# 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:
```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.
### 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.