agentleFS
Sign inStart free
100yenadmin100yenadmin/fable-token-saving-skills-orchestrator/skills/public-repo-operationalizer/SKILL.md

public-repo-operationalizer

Skill100 starsChanged 4 months agoMITView on GitHub

Use when preparing a repository, project kit, plugin, skillpack, or developer tool for public release or maintainer-ready public operations.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Add or repair default surfaces: README.md, LICENSE, SECURITY.md, CONTRIBUTING.md, AGENTS.md, .github/ISSUE_TEMPLATE/*, …

    line 18
  2. Distinctive:

    Add claim/proof docs when claims could drift: claim audit, source authority, proof boundary, release status, and setup path.

    line 21
  3. Distinctive:

    Do not publish raw transcripts, credentials, tokens, private paths, customer data, local stores, browser/session data, or screenshots with …

    line 29
  4. Distinctive:

    Keep optional tools optional unless the repo truly depends on them.

    line 34

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

Category2 means
Public promiseREADME says who it helps, what it does, and what it does not prove
First-run pathclone/install/setup/run commands work from a fresh checkout
Template completenessREADME, license, security, contributing, AGENTS, issue templates, and pull request template fit the repo
Claim safetyallowed and forbidden claims are explicit and sourced where needed
Source/proof authorityauthoritative vs advisory sources and proof boundary are clear
Contributor safetyredaction, no raw transcripts, no secrets, and no private paths are enforced
Validation automationCI, docs safety scan, tests, and link/image checks cover the public surface
Release readinessrelease tags, package channels, notes, or "not released yet" are clear
Maintainer handoffissue/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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free