# 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:
```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
├── 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:
1. Create only files under `projects/[project-name]/`.
2. Do not modify `core/`, repo-level workflow rules, top-level prompts, or toolchain semantics.
3. Write pack docs that are source-agnostic in tone but explicit about this project's authorities, scope, and terminology ownership.
4. 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>/`.
5. 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.
6. Put stable project conclusions in the canonical pack docs, not only in staged support files.
7. Make `suite-brief.md` describe the suite charter, deliverable boundaries, and cross-document rules.
8. Make `corpus-brief.md` identify the authoritative corpus, informative sources, evidence surfaces, and section-to-source routing.
9. Make `references.md` capture the normative/informative reference pools, terminology ownership, internal dependencies, and citation hygiene rules.
10. Make `draft-metadata.md` capture shared front-matter defaults without restating repo-wide workflow mechanics.
11. Make each file in `briefs/` document one target RFC/deliverable with concrete scope, required capabilities, exclusions, and edge cases.
12. If `examples/` is used, keep it focused on observed examples, anomaly seeds, or example-capture traps rather than normative prose.
13. Add a pack-local `README.md` that explains the suite, summarizes the pack contents, and tells a new contributor how to load the pack.
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. 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.