agentleFS
Sign inStart free
rust-worksrust-works/succinctly/.agents/skills/release/SKILL.md

release

Skill52 starsChanged 25 days agoMITView on GitHub

Create a succinctly release when asked to release, publish, or prepare a new version.

  • Commits and pushes

We split this skill into the rules it gives an agent

12 rules. 0 are common, 9 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 183 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

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

    IMPORTANT: Do NOT run cargo publish manually.

    line 12
  2. Very specific:

    Run cargo check or cargo build to update Cargo.lock with the new version

    line 35
  3. Distinctive:

    If direct push to main is allowed, use that instead

    line 71
  4. Distinctive:

    Wait for PR to be merged before tagging

    line 72
  5. Distinctive:

    Check Actions tab for workflow status

    line 87
  6. Distinctive:

    Verify crates.io shows new version

    line 88
  7. Distinctive:

    Verify GitHub release has all artifacts

    line 89
  8. Distinctive:

    Never look at only recent commits: - always check ALL commits since last tag

    line 96
  9. Distinctive:

    If the "Publish to crates.io" job fails with "already exists":

    line 102
  10. Distinctive:

    Don't worry about it for this release

    line 105
  11. Very specific:

    Delete the tag: git tag -d vX.Y.Z && git push origin :refs/tags/vX.Y.Z

    line 108
  12. Distinctive:

    Create a new release

    line 110

“Common” is measured: kept by at least 6 in 10 of the 183 edited versions of this file we could read. “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

Release Skill

Creates releases for the succinctly crate. Triggered by terms like "release", "publish", "new version".

Release Process

IMPORTANT: Do NOT run cargo publish manually. The CI workflow handles crates.io publishing automatically after building binaries for all platforms.

Steps

  1. Gather ALL changes since last release
    git describe --tags --abbrev=0  # Get last tag (e.g., v0.4.0)
git log v0.4.0..HEAD --oneline --no-merges  # ALL commits, not just recent
    • Review the FULL list - there may be 50+ commits
    • Categorize by: CLI, Performance, Memory, SIMD, Compatibility, Fixes
  2. Run quality checks FIRST
    ./scripts/build.sh
cargo test --all-features
  3. Bump version in Cargo.toml
    • Follow semver: MAJOR.MINOR.PATCH
    • MAJOR: Breaking API changes
    • MINOR: New features (backward compatible)
    • PATCH: Bug fixes (backward compatible)
    • Run cargo check or cargo build to update Cargo.lock with the new version
  4. Update version snapshot (ALWAYS required)
    grep -r "0\.4\.0" tests/snapshots/  # Find version in snapshots
    • Update tests/snapshots/cli_golden_tests__version.snap
    • This test WILL fail if you skip this step
  5. Update CHANGELOG.md - entries are per-PR fragments in changelog.d/; never hand-edit [Unreleased]
    python3 scripts/changelog.py check                              # all fragments well-formed
python3 scripts/changelog.py collect --version X.Y.Z --dry-run  # preview, writes nothing
python3 scripts/changelog.py collect --version X.Y.Z            # write the section
    • collect creates ## [X.Y.Z] - DATE (fragments grouped Added, Changed, Deprecated, Removed, Performance, Fixed, Security), carries any text still under ## [Unreleased] into it verbatim (the pre-fragment legacy text goes out with the first release), updates the comparison links at the bottom, and deletes the consumed fragments
    • Review git diff CHANGELOG.md; regroup or reword by user impact only if the release needs it
    • Cross-check against git log vPREV..HEAD: a merged PR with no fragment (waived or forgotten) is a missing entry
  6. Commit the release
    git add Cargo.toml Cargo.lock CHANGELOG.md tests/snapshots/
git add -A changelog.d   # the consumed fragments are deleted
git commit -m "chore(release): prepare vX.Y.Z"
  7. Push via PR (branch protection may block direct push)
    git checkout -b release/vX.Y.Z
git push -u origin release/vX.Y.Z
gh pr create --title "chore(release): prepare vX.Y.Z" --body "..."
    • If direct push to main is allowed, use that instead
    • Wait for PR to be merged before tagging
  8. Create and push tag (after merge)
    git checkout main && git pull origin main
git tag -a vX.Y.Z -m "Release vX.Y.Z"
git push origin vX.Y.Z
  9. Wait for CI - The release workflow will:
    • Create GitHub release
    • Build binaries for linux-x64, linux-arm64, macos-arm64, windows
    • Publish to crates.io automatically
  10. Monitor the release
    • Check Actions tab for workflow status
    • Verify crates.io shows new version
    • Verify GitHub release has all artifacts

What NOT to Do

  • Never run cargo publish manually - CI handles this
  • Never push a tag before the commit is pushed - tag must reference pushed commit
  • Never skip updating CHANGELOG.md - it's part of the release; run collect, don't hand-assemble it
  • Never look at only recent commits - always check ALL commits since last tag
  • Never forget version snapshots - grep for old version across codebase
  • Never push directly to main without checking - branch protection may require PR

Troubleshooting

If the "Publish to crates.io" job fails with "already exists":

  • This is harmless if you accidentally published manually
  • The crate is published, just the CI step failed
  • Don't worry about it for this release

If build fails:

  1. Delete the tag: git tag -d vX.Y.Z && git push origin :refs/tags/vX.Y.Z
  2. Fix the issue
  3. Create a new release

Reference

See docs/guides/release.md for full documentation.

Download now (ZIP)

  • Other versions194 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 194

    1. paperclipai/paperclip★ 110ksame name
    2. modelcontextprotocol/servers★ 92ksame name
    3. remotion-dev/remotion★ 70ksame name
    4. traefik/traefik★ 65ksame name
    5. usememos/memos★ 64ksame name
    6. tw93/Pake★ 63ksame name
    7. Yeachan-Heo/oh-my-claudecode★ 40ksame name
    8. Yeachan-Heo/oh-my-claude-sisyphus★ 40ksame name
    9. tobi/qmd★ 30ksame name
    10. jlowin/fastmcp★ 28ksame name

    184 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use create-agent-adapter, changelog-style and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • MicrosoftSkill

      create-agent-adapter

      Technical guide for creating a new Paperclip agent adapter. Use when building a new adapter package, adding support for a new AI coding tool (e.g. a new CLI agent, API-based agent, or custom process), or when modifying the adapter system. Covers the required interfaces, module structure, registration points, and conventions derived from the existing claude-local and codex-local adapters.

      Also in 5 projects that use this

    • GrinvSkill

      changelog-style

      Turn a commit range into CHANGELOG.md entries following common-changelog style. Use when finishing a PR (adding to the [Unreleased] section) or cutting a release (moving [Unreleased] under a new version heading).

      Also in 4 projects that use this

    • GrinvSkill

      docs-consistency-check

      Check README/manifest.json/server.json/CHANGELOG.md/AGENTS.md and docs/*.md for drift against the actual registered tools and source. Use after adding, renaming, or removing a tool, or as part of a live-audit pass.

      Also in 4 projects that use this

    • MicrosoftSkill

      pr-report

      Review a pull request or contribution deeply, explain it tutorial-style for a maintainer, and produce a polished report artifact such as HTML or Markdown. Use when asked to analyze a PR, explain a contributor's design decisions, compare it with similar systems, or prepare a merge recommendation.

      Also in 5 projects that use this

    • Microsoft AzureSkill

      documentation-consistency

      Keeps GPT-RAG MCP service and umbrella documentation aligned with shipped behavior. Use for capabilities, configuration keys, deployment steps, endpoints, defaults, operations, or breaking changes.

      Also in 6 projects that use this

    • parcadeiSkill

      agent-context-isolation

      Agent Context Isolation

      Also in 3 projects that use this

    • +3 more from Grinv
  • In this repository27 other files it gives its agents.

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