Table of Contents generated with DocToc

• New project — TODO: replace with <Project Name>
  • What each file is for
    • Authoritative manifest (fill this in first)
    • Release state
    • Scope + product mapping
    • Security-model references
    • CVE-allocation mechanics
    • Remediation workflow
    • Editorial + reporter-facing
    • Contributor growth
    • Issue management
    • Repo-health audits
    • PR triage and review
    • External skill sources
  • Recommended setup order
  • Checklist after copying
  • Cross-references

New project — TODO: replace with <Project Name>

Skeleton directory for a new project under this framework. Do not edit the template in place; copy it to projects/<name>/ and fill in every TODO placeholder:

# From the repo root:
cp -R projects/_template projects/<name>
$EDITOR projects/<name>/project.md
grep -rn TODO projects/<name>     # work through the remaining TODOs

The _template prefix keeps this directory out of the way of the active-project resolver (the skills only load projects/<active>/, so a directory that starts with _ is never accidentally picked up).

What each file is for

Once you have copied the template into <project-config>/ in your tracker repo, update this README.md to be your project's file index. Delete the sections your project does not need and fill in the rest.

Authoritative manifest (fill this in first)

Release state

Scope + product mapping

Security-model references

CVE-allocation mechanics

Remediation workflow

Editorial + reporter-facing

Contributor growth

These files configure the contributor-nomination, committer-onboarding, and contributor-to-committer skill family. Adopters that do not use these skills can delete this group.

Issue management

These files configure the issue-* skill family — per-issue triage, pool-level reassessment, reproducer extraction, fix drafting, and read-only stats. Adopters that do not use a general-issue tracker (or only run the security skills) can delete this group.

Repo-health audits

These files configure the ci-runner-audit and workflow-security-audit skills and the planned dependency-audit, license-compliance-audit, and flaky-test-triage skills. Adopters who do not use repo-health audits can delete this group.

PR triage and review

These files configure the pr-management-triage, pr-management-stats, and pr-management-code-review skills. Adopters who only use the security skills can delete these four files; adopters running maintainer-side PR-queue management fill them in.

Each PR-skill reads its project-specific content exclusively from the files listed below. No defaults are baked into the framework — every adopter provides their own values in <project-config>/. See projects/_template/pr-management-*.md for concrete examples (filled in with the Apache Airflow project's values, which new adopters can use as a reference when drafting their own configuration).

External skill sources

Recommended setup order

After copying the template, fill in the core project files before the optional skill-family files:

1. Start with project.md, because every skill uses it to resolve project-scoped references.
2. Fill in security-model.md so security-facing workflows have an authoritative source.
3. Add current release details to release-trains.md.
4. Define tracker organization in scope-labels.md and milestones.md.
5. Prepare reporter-facing text in canned-responses.md.
6. Document the fix flow in fix-workflow.md.
7. If your project uses the issue or PR-management skill families, fill in the optional files they read, such as issue-tracker-config.md, runtime-invocation.md, pr-management-config.md, and pr-management-code-review-criteria.md.

Run grep -rn TODO projects/<name> after copying and again before opening a pull request so no template placeholders are left behind.

Checklist after copying

• [ ] cp -R projects/_template projects/<name> done.
• [ ] Every TODO in project.md resolved (grep: grep -n TODO projects/<name>/project.md).

Security workflow (delete this group if not using the security skills):

• [ ] scope-labels.md lists at least one scope label (exactly-one-of rule).
• [ ] security-model.md points at the project's authoritative Security-Model URL.
• [ ] release-trains.md has at least one current release branch + its RM.
• [ ] canned-responses.md has at least the “Confirmation of receiving the report” template filled in (the security-issue-import skill sends this verbatim).

PR triage and review (delete this group if not using the pr-* skills):

• [ ] pr-management-config.md — committers team handle and area-label prefix filled in.
• [ ] pr-management-triage-comment-templates.md — <quality_criteria_url>, <two_stage_triage_rationale_url>, and <project_display_name> filled in.
• [ ] pr-management-triage-ci-check-map.md — at least one CI-check pattern row filled in (or the catch-all row pointing at the project's static-checks doc).
• [ ] pr-management-code-review-criteria.md — at least one repo-wide review-criteria source file declared.

Common finishers:

• [ ] config/active-project.md updated to the new directory name if this working tree should target the new project.
• [ ] Root README.md “Current projects” table updated with a row for the new project + a link to this README.md.
• [ ] prek run --all-files passes.

Cross-references

• ../../README.md — framework-level “Adopting the framework” view + bootstrap walk-through.
• ../../AGENTS.md — the placeholder convention that lets skills resolve <project-config>/ to the adopter's path at agent runtime.