| name | public-repo-operationalizer |
| description | Use when preparing a repository, project kit, plugin, skillpack, or developer tool for public release or maintainer-ready public operations. |
Public Repo Operationalizer
Turn a useful repo into a public repo operational status surface: understandable,
safe to contribute to, clear about proof, and maintainable without private
context.
Core Pattern
- Audit repo truth: purpose, license, setup path, tests, CI, release state,
security posture, private-data boundaries, and current claims.
- Define the public promise: what works, what is advisory, what is unproven,
and what the repo does not claim.
- Add or repair default surfaces:
README.md, LICENSE, SECURITY.md,
CONTRIBUTING.md, AGENTS.md, .github/ISSUE_TEMPLATE/*,
.github/PULL_REQUEST_TEMPLATE.md, and focused CI.
- Add claim/proof docs when claims could drift: claim audit, source authority,
proof boundary, release status, and setup path.
- Wire validation: docs safety scan, tests, link/image checks,
installer/package checks, and CI.
- Close with evidence: issue/PR, commands, CI URL, risks, and next action.
Public Safety Rules
- Do not publish raw transcripts, credentials, tokens, private paths, customer
data, local stores, browser/session data, or screenshots with secrets.
- Say "patterns that worked for us" for practice-based guidance.
- Cite official sources near factual pricing, cache, API, legal, or security
claims.
- Keep optional tools optional unless the repo truly depends on them.
Default Template Bar
Contributor-facing templates should force safe evidence:
- issue templates: public-safe reproduction and redacted logs
- docs bug templates: wrong public claim or setup step
- pull request template: linked issue, changed files, validation, safety
boundary, claim impact, rollback notes, and agent-authored disclosure
Scorecard
Score each category 0-2. Pass at 14/18 or higher.
| Category | 2 means |
|---|
| Public promise | README says who it helps, what it does, and what it does not prove |
| First-run path | clone/install/setup/run commands work from a fresh checkout |
| Template completeness | README, license, security, contributing, AGENTS, issue templates, and pull request template fit the repo |
| Claim safety | allowed and forbidden claims are explicit and sourced where needed |
| Source/proof authority | authoritative vs advisory sources and proof boundary are clear |
| Contributor safety | redaction, no raw transcripts, no secrets, and no private paths are enforced |
| Validation automation | CI, docs safety scan, tests, and link/image checks cover the public surface |
| Release readiness | release tags, package channels, notes, or "not released yet" are clear |
| Maintainer handoff | issue/PR/evidence paths let a future agent resume |
Automatic blockers: secret, private path, raw transcript, missing license,
broken required setup command, missing install path, unbounded claim, official
endorsement claim, universal safety/savings claim, broken required local link,
or failing docs safety scan.
Common Mistakes
- Treating README polish as operational readiness.
- Copying mature-repo machinery into a small v1 kit.
- Saying "ready" without setup-path and CI evidence.
