agentleFS
Sign inStart free
tumftumf/skills/oss-publish/SKILL.md

oss-publish

Skill4 starsChanged 7 months agoMITView on GitHub

Open source publication and release hygiene for repositories and CLIs (language-agnostic): choose and add LICENSE, prepare README/CONTRIBUTING/SECURITY/CODE_OF_CONDUCT, standardize versioning/tags/releases and release notes, set up CI matrices, quality gates (pre-commit/pre-push), and safe-by-default automation/bootstrapping. Use when preparing a project to be published publicly (GitHub/GitLab), cutting a release, or standardizing repo tooling across languages.

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈13

    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. Distinctive:

    Prefer safe-by-default, non-interactive, repeatable steps.

    line 14
  2. Distinctive:

    Add these at repo root (or confirm they exist and are correct):

    line 18
  3. Distinctive:

    If the project is a CLI/tool, also ensure:

    line 27
  4. Distinctive:

    Use semantic versioning (SemVer) unless the ecosystem dictates otherwise.

    line 34
  5. Distinctive:

    Treat releases as immutable:

    line 35
  6. Distinctive:

    Prefer a split between fast and slow checks:

    line 56
  7. Very specific:

    Use pre-commit or prek (compatible alternative) depending on repo conventions.

    line 61
  8. Distinctive:

    If the project is intended to be cross-platform, include a CI matrix:

    line 65
  9. Distinctive:

    Prefer a single, predictable setup command usable by humans and automation:

    line 75
  10. Distinctive:

    Keep it idempotent and non-interactive

    line 78
  11. Distinctive:

    Avoid collisions with common system commands and common package names.

    line 83
  12. Distinctive:

    If the name is generic, add an org/team prefix.

    line 84
  13. Distinctive:

    If the project stores user config/data:

    line 88
  14. Distinctive:

    Avoid OS-specific special cases unless the ecosystem requires it.

    line 93

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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

oss-publish - OSS Publication And Release Hygiene

Focus: make a repository publishable and releasable with minimal ambiguity. Prefer safe-by-default, non-interactive, repeatable steps.

Baseline Repo Artifacts

Add these at repo root (or confirm they exist and are correct):

  • LICENSE (pick one; do not invent a custom license)
  • README.md (project intent, quick start, examples)
  • CONTRIBUTING.md (how to contribute; local dev workflow)
  • CODE_OF_CONDUCT.md (community expectations; adopt a standard template)
  • SECURITY.md (vulnerability reporting process)
  • Optional: SUPPORT.md (where to ask questions)

If the project is a CLI/tool, also ensure:

  • --help is stable and in English
  • docs include examples for both humans and automation

Release Discipline (Language-Agnostic)

  • Use semantic versioning (SemVer) unless the ecosystem dictates otherwise.
  • Treat releases as immutable:
    • tag the release commit
    • generate release notes from commits/CHANGELOG
    • attach artifacts (if you distribute binaries)

Pre-release checklist (minimum):

  1. working tree clean
  2. tests + lint/format pass
  3. documentation updated (README, examples)
  4. version bumped + tagged
  5. release notes produced

For a concrete checklist and file templates, see:

  • oss-publish/references/checklist.md
  • oss-publish/references/templates.md
  • oss-publish/references/readme.md

Quality Gates (Local + CI)

Prefer a split between fast and slow checks:

  • pre-commit: format + lint (fast)
  • pre-push (or CI only): full test suite (slower)

Use pre-commit or prek (compatible alternative) depending on repo conventions.

CI Policy (Cross-Platform)

If the project is intended to be cross-platform, include a CI matrix:

  • ubuntu-latest
  • macos-latest
  • windows-latest

Set fail-fast: false so one platform failure does not hide others.

Stable Bootstrap Entry Point

Prefer a single, predictable setup command usable by humans and automation:

  • Provide an executable .wt/setup that runs make setup (or equivalent)
  • Keep it idempotent and non-interactive

Naming And Collisions

  • Pick a unique repo and command/binary name.
  • Avoid collisions with common system commands and common package names.
  • If the name is generic, add an org/team prefix.

Filesystem Layout (XDG)

If the project stores user config/data:

  • Config: $XDG_CONFIG_HOME/{app} (fallback ~/.config/{app})
  • Data/state/artifacts (non-git-managed): $XDG_DATA_HOME/{app} (fallback ~/.local/share/{app})

Avoid OS-specific special cases unless the ecosystem requires it.

Related Skills

  • agentic-cli-design: deep guidance for agent/automation-friendly CLIs (JSON mode, exit codes, non-interactive)
  • rust-cli: Rust-specific CLI implementation patterns (clap/anyhow/tracing/serde_json, cargo-release)

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.

Reviews can't be read right now.

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