agentleFS
Sign inStart free
gocronx-teamgocronx-team/gocron/.agents/skills/release/SKILL.md

release

Skill808 starsChanged 3 months agoMITView on GitHub

Prepare or publish a safe gocron release by choosing a SemVer bump, updating AppVersion and migrations, invoking the complete verification gate, committing, checking CI, and creating an annotated tag. Use when asked to release, 发版, bump the version, cut a release, 打 tag, or assess release readiness.

  • Commits and pushes

We split this skill into the rules it gives an agent

13 rules. 0 are common, 7 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 185 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep preparation separate from publication.

    line 8
  2. Distinctive:

    Before tagging, record evidence for every affected case:

    line 14
  3. Distinctive:

    Use automated compatibility tests, previous-version fixtures, or a documented reproducible check.

    line 22
  4. Distinctive:

    If a case cannot remain compatible, stop before tagging: obtain explicit approval, use a major version, and document migration, deployment …

    line 24
  5. Distinctive:

    Never develop or commit directly on master.

    line 44
  6. Very specific:

    Check that the target version and vX.Y.Z tag do not already exist.

    line 48
  7. Very specific:

    Update AppVersion in cmd/gocron/gocron.go.

    line 52
  8. Very specific:

    Update helm/gocron/Chart.yaml appVersion to the same application version.

    line 53
  9. Very specific:

    If the release changes the schema, add the model to the Install tables slice where applicable, append a unique migration version id and …

    line 56
  10. Distinctive:

    If there is no schema change, do not add an empty migration.

    line 62
  11. Very specific:

    Commit with chore(release): bump version to X.Y.Z.

    line 77
  12. Very specific:

    Create and push an annotated tag: git tag -a vX.Y.Z -m "vX.Y.Z" followed by git push origin vX.Y.Z.

    line 84
  13. Distinctive:

    Never move or replace an existing release tag, and never tag an unverified commit.

    line 89

“Common” is measured: kept by at least 6 in 10 of the 185 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 gocron

Keep preparation separate from publication. A version-bump request authorizes the local version edit and verification, but not a push, merge, or tag unless the user also asks to publish the release.

Compatibility evidence (required)

Before tagging, record evidence for every affected case:

  • N frontend/client with N-1 and N backend;
  • N backend with N-1 and N frontend/client;
  • N gocron with N-1 and N gocron-node, in both directions;
  • N upgrading an existing SQLite, MySQL, and PostgreSQL database;
  • rolling upgrade with temporary N/N-1 HA members when HA is affected.

Use automated compatibility tests, previous-version fixtures, or a documented reproducible check. Current/current tests and a fresh install are not enough. If a case cannot remain compatible, stop before tagging: obtain explicit approval, use a major version, and document migration, deployment order, rollback limits, and recovery.

Performance evidence (required when affected)

  • Identify affected hot paths and record the workload, data size, environment, command, baseline, and release-candidate result.
  • Compare latency, throughput, memory/allocations, goroutines, query count, database writes, and migration duration as applicable.
  • Include SQLite concurrent read/write and lock behavior when database write frequency, logging, polling, migrations, or scheduler state changed.
  • Require a benchmark or regression test for a material fix or risk. Do not publish a material unexplained regression; an accepted tradeoff needs the user's explicit approval and release-note disclosure.

1. Establish the release

  • Inspect the current branch, working tree, latest v* tag, AppVersion, and changes since the latest release.
  • Never develop or commit directly on master; create or use a release branch.
  • Choose the SemVer bump from user-facing changes: features bump minor and fixes or chores bump patch. Ask when the intended version cannot be inferred safely. Honor an explicit version supplied by the user.
  • Check that the target version and vX.Y.Z tag do not already exist.

2. Update version and migrations

  • Update AppVersion in cmd/gocron/gocron.go.
  • Update helm/gocron/Chart.yaml appVersion to the same application version. Increment the Chart version whenever the packaged Chart changes; the chart release workflow skips versions that have already been published.
  • If the release changes the schema, add the model to the Install tables slice where applicable, append a unique migration version id and matching upgradeForNNN function in internal/models/migration.go, add it to the upgrade chain, and add a migration test.
  • Derive the migration id using the repository's existing version conversion convention. Confirm it with ToNumberVersion; do not guess or reuse an id.
  • If there is no schema change, do not add an empty migration.
  • For migrations that rewrite existing data, tell the user to back up the database and include the impact in release notes.

3. Pass the mandatory gate

Invoke $verify and require every backend, frontend, lint, test, and Docker check to pass. Do not commit, merge, push, or tag while any check is failed, skipped, or unavailable.

Review the final diff and confirm AppVersion, Helm appVersion and Chart version, migration id, tests, and user-facing release notes agree.

4. Publish only when requested

  • Commit with chore(release): bump version to X.Y.Z; keep the subject under 100 characters and omit Co-Authored-By.
  • Push the branch and merge it into master according to the repository's normal review process.
  • Confirm the GitHub Actions CI run for the exact release commit is green.
  • Confirm local master, remote master, and the green CI SHA all identify the same commit.
  • Create and push an annotated tag: git tag -a vX.Y.Z -m "vX.Y.Z" followed by git push origin vX.Y.Z.
  • Confirm the tag-triggered release workflow starts successfully.

Never move or replace an existing release tag, and never tag an unverified commit.

Download now (ZIP)

  • Other versions195 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 195

    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-claude-sisyphus★ 40ksame name
    8. Yeachan-Heo/oh-my-claudecode★ 40ksame name
    9. tobi/qmd★ 30ksame name
    10. jlowin/fastmcp★ 28ksame name

    185 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 repository9 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.

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