agentleFS
Sign inStart free
wasabeefwasabeef/AgentNote/.cursor/skills/agentnote-release/SKILL.md

agentnote-release

Skill15 starsChanged 6 months agoMITView on GitHub

Prepare and publish Agent Note releases with the repo-local Markdown workflow, including version bump validation, release note preview, tag creation, workflow monitoring, and npm/GitHub verification.

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. About 0 are common, 8 are distinctive, and 8 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 8

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the task asks to release Agent Note, bump a version, cut a tag, publish npm packages, or verify a release.

    line 8
  2. Distinctive:

    Check the working tree. Do not release with unrelated dirty files.

    line 14
  3. Very specific:

    If the user only wants a rehearsal or passes --dry-run, do not edit files, commit, tag, or push.

    line 15
  4. Distinctive:

    Follow these steps instead of relying on a release script:

    line 19
  5. Very specific:

    Update packages/cli/package.json to x.y.z.

    line 21
  6. Very specific:

    Run npm install from the repository root so npm updates package-lock.json and synchronizes packages["packages/cli"].version to x.y.z.

    line 22
  7. Very specific:

    Commit only those release files as chore: bump version to x.y.z with Release note: skip.

    line 29
  8. Distinctive:

    Create the annotated tag with git tag -a vx.y.z -m vx.y.z.

    line 30
  9. Distinctive:

    Do not manually push a release tag before the package version bump commit is on main.

    line 35
  10. Very specific:

    If release notes look like an implementation log, fix commit subjects or Release note: bodies before tagging.

    line 36
  11. Distinctive:

    If any step fails after a local commit or tag, inspect the repository state before retrying.

    line 37
  12. Very specific:

    Keep release plumbing commits hidden with Release note: skip.

    line 38
  13. Distinctive:

    After pushing a release tag:

    line 42
  14. Very specific:

    Verify the GitHub Release exists for v<version>.

    line 45
  15. Very specific:

    Verify npm publishes both agent-note@<version> and @wasabeef/agentnote@<version>.

    line 46
  16. Distinctive:

    If release notes need copy edits after publication, update the GitHub Release body directly and keep the source commit guidance for future …

    line 47

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

Agent Note Release Workflow

Use this skill when the task asks to release Agent Note, bump a version, cut a tag, publish npm packages, or verify a release.

Prepare

  1. Confirm the target version from the user request, accepting either x.y.z or vx.y.z. Use x.y.z for package metadata and vx.y.z for the git tag.
  2. Switch to main and pull the latest changes before an actual release.
  3. Check the working tree. Do not release with unrelated dirty files.
  4. If the user only wants a rehearsal or passes --dry-run, do not edit files, commit, tag, or push; only inspect state, run safe checks when useful, and preview the release notes.

Release

Follow these steps instead of relying on a release script:

  1. Update packages/cli/package.json to x.y.z.
  2. Run npm install from the repository root so npm updates package-lock.json and synchronizes packages["packages/cli"].version to x.y.z.
  3. Run npm -w packages/cli run build.
  4. Run npm -w packages/cli run typecheck.
  5. Run npm -w packages/cli run lint.
  6. Run npm -w packages/cli test.
  7. Preview release notes with git-cliff --config .github/cliff.toml --unreleased --tag vx.y.z --strip header.
  8. Stage packages/cli/package.json, package-lock.json, and the rebuilt packages/cli/dist/cli.js.
  9. Commit only those release files as chore: bump version to x.y.z with Release note: skip.
  10. Create the annotated tag with git tag -a vx.y.z -m vx.y.z.
  11. Push main and vx.y.z only when ready to publish.

Guardrails

  • Do not manually push a release tag before the package version bump commit is on main.
  • If release notes look like an implementation log, fix commit subjects or Release note: bodies before tagging.
  • If any step fails after a local commit or tag, inspect the repository state before retrying; do not create duplicate tags.
  • Keep release plumbing commits hidden with Release note: skip.

Verify

After pushing a release tag:

  1. Watch the release workflow until completion.
  2. Verify the GitHub Release exists for v<version>.
  3. Verify npm publishes both agent-note@<version> and @wasabeef/agentnote@<version>.
  4. If release notes need copy edits after publication, update the GitHub Release body directly and keep the source commit guidance for future releases.

Report

End with:

  • Version released or prepared
  • Commands run
  • Workflow status
  • GitHub Release URL
  • npm package versions confirmed

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