---
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

1. Audit repo truth: purpose, license, setup path, tests, CI, release state,
   security posture, private-data boundaries, and current claims.
2. Define the public promise: what works, what is advisory, what is unproven,
   and what the repo does not claim.
3. 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.
4. Add claim/proof docs when claims could drift: claim audit, source authority,
   proof boundary, release status, and setup path.
5. Wire validation: docs safety scan, tests, link/image checks,
   installer/package checks, and CI.
6. 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.