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:

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.