Agent skill

Release Candidate

by shortcuts in shortcuts/locationjoystick

Go/no-go audit of main before tagging a release: build pipeline, tests, doc consistency, code quality.

MITAuto-check passedDevelopment

Install Release Candidate

skills CLI
$ npx skills add shortcuts/locationjoystick --skill release-candidate -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install shortcuts/locationjoystick release-candidate --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/shortcuts/locationjoystick.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/release-candidate .claude/skills/release-candidate && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
release-candidate
GitHub stars
104
Token cost
~1.3k tokens
SKILL.md length
672 words
Files
2
Skills in repo
2
Repo updated
First seen
Licence
MIT

At a glance

Go/no-go audit of main before tagging a release: build pipeline, tests, doc consistency, code quality.

  • Works in 8 steps: Baseline → Build pipeline → Tests → …
  • Pre-release audit
  • SKILL.md covers Step 0: Baseline, Step 1: Build pipeline, Step 2: Tests and Step 3: Documentation…, plus 5 more sections
  • Calls make, git and bash

What it does

Release Candidate is an agent skill from shortcuts/locationjoystick. Go/no-go audit of main before tagging a release: build pipeline, tests, doc consistency, code quality. Logs every failure to radin's backlog. Use for "release checks", "pre-release audit", "is this ready to ship?".

Its SKILL.md is about 1.3k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `CHANGELOG-PROCEDURE.md`).

It sits in Development, covering Code quality, App store release and Feature launches and release readiness. The repository describes itself as: 🕹️ android app for GPS spoofing and mock locations. The licence is MIT.

When your agent uses it

  • Pre-release audit
  • Is this ready to ship?

Example prompts

  • “s backlog. Use for”
  • “pre-release audit”
  • “is this ready to ship?”
  • “/release-candidate”

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Baseline
  2. Build pipeline
  3. Tests
  4. Documentation consistency
  5. Intermediate verdict
  6. Thermo-nuclear code quality review
  7. Verdict
  8. Changelog (✅ verdict only)

What it can do on your machine

Read from SKILL.md and the folder at commit 53285b4. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • make
    • git
    • bash
    • adb

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Release Candidate loads about 1.3k tokens when it runs. Until then it costs about 58 tokens; SKILL.md has 672 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~58
When it runs · the whole SKILL.md, loaded when a task matches
~1.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from shortcuts/locationjoystick at commit 53285b4, republished under its MIT licence (© shortcuts). 672 words, ~1,333 tokens.

Download SKILL.mdSave it as .claude/skills/release-candidate/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
release-candidate
description
Go/no-go audit of main before tagging a release: build pipeline, tests, doc consistency, code quality. Logs every failure to radin's backlog. Use for "release checks", "pre-release audit", "is this ready to ship?".

Release Candidate Auditor

Every failure becomes a backlog entry detailed enough to act on without re-running the audit. Route every finding through the radin-record skill — it is the only writer to BACKLOG.md.

Done when every step below has run and every failure it found is logged.

Step 0: Baseline

Resolve radin's per-project namespace to locate BACKLOG_FILE. Read-only here — the count detects net-new entries at the end:

bash
bash "$HOME/.claude/radin-lib/radin-namespace.sh"
grep -c '^### ' "$BACKLOG_FILE" 2>/dev/null || echo "0"

Identify the last release tag, which bounds "since last release" everywhere below:

bash
git describe --tags --abbrev=0 2>/dev/null || git log --oneline | tail -1 | awk '{print $1}'

Step 1: Build pipeline

Each step is a hard gate. A non-zero exit stops the pipeline there.

bash
make format 2>&1
make lint   2>&1
make build  2>&1

Per failure, invoke radin-record:

Log a fix: build pipeline failure in make <step>. Exit code <N>. Output: <last 30 lines>

Step 2: Tests

bash
make test 2>&1

On failure, invoke radin-record:

Log a fix: make test failed. Failures: <failing test names / error summary>

Smoke tests. Check for a connected Android device:

bash
adb devices 2>/dev/null | grep -v "List of devices" | grep -v "^$"

A device appears: ask whether to run make smoke-test — it covers all navigation paths and takes a few minutes. On a yes and a failure, invoke radin-record:

Log a fix: make smoke-test failed. Failing tests: <failing test names>

Step 3: Documentation consistency

The codebase is the source of truth. Every user-facing change since the last release appears in at least one of: README.md, AGENTS.md, docs/, docs/wiki/.

Done when every feature area with source changes since the tag is accounted for — documented, stale-doc logged, or marked not user-facing.

bash
git diff --name-only <last-release-tag> HEAD

Keep feature/, core/, app/ sources plus already-changed docs. Group them by feature area (map, routes, favorites, settings, joystick, widget, location engine). Per area, read the docs and compare against the changed sources:

  1. A doc exists in docs/features/.
  2. The docs/wiki/ section matches current behavior.
  3. README.md names the feature when it is user-visible.
  4. AGENTS.md reflects new services, modules, or domain models.

Also verify: the Key Services table matches the real services, docs/domain-models.md matches :core:model classes, and the module table covers every module added or removed since the tag.

Per gap, invoke radin-record:

Log a fix: documentation gap in <feature area>. Changed sources: <paths>. Gap: <what is missing or stale, specific enough that the writer knows what to write>. Doc file: <path>.

A doc that exists and covers the change passes. A user-visible feature with no doc is a gap. Skip cosmetic nits.

Step 4: Intermediate verdict

Count entries again and compare to the Step 0 baseline. New entries: report the ❌ verdict below and stop. No new entries: continue to Step 5.

Show full SKILL.md (270 more words)Show less

Step 5: Thermo-nuclear code quality review

Invoke radin-review — it runs the review and logs each finding itself:

Review all commits since <last-release-tag> (git diff <last-release-tag> HEAD). Apply the full thermo-nuclear standards and log findings to the backlog.

Log only findings that meet the thermo-nuclear bar: structural regressions, missed code-judo, spaghetti growth, bad abstractions, file-size explosions.

Step 6: Verdict

Count entries and compare to the Step 0 baseline.

No new entries across Steps 1–5:

✅ Release is ready. All checks passed: format, lint, build, tests, documentation consistency, and thermo-nuclear code quality review.

Then do Step 7.

New entries:

❌ Release is NOT ready. N issue(s) were logged to the backlog during this audit. Resolve them before tagging a release.

Issues logged:

  • [headings of the items added during this run]

Step 7: Changelog (✅ verdict only)

Tell the user, verbatim in substance:

Recommend generating the website changelog now (docs/wiki/changelog.html) for the upcoming version, before tagging. Also watch for the release-please PR — it opens automatically (title chore(main): release <version>) once these commits land on main, and its body is the authoritative source list for the changelog entry.

Then invoke radin-record to log it as a chore, not a fix — an action item, not a defect. It does not flip the verdict:

Log a chore: generate changelog for <version>. Release checks passed. Generate the docs/wiki/changelog.html entry for <version> before tagging. See CHANGELOG-PROCEDURE.md in this skill for the procedure.

The procedure lives in CHANGELOG-PROCEDURE.md — read it when you generate the changelog in this session rather than logging it for later.

Notes

  • Keep lint errors visible. A suppression that hides a real issue is itself a finding — log it.

© shortcuts, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in .claude/skills/release-candidate of shortcuts/locationjoystick.

  • SKILL.md
  • CHANGELOG-PROCEDURE.md

Open the folder on GitHubat commit 53285b4

Compare with similar skills

Release Candidate next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Release Candidate compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Release Candidate this skillshortcuts/locationjoystick104—~1.3kAutomated safety check: PassMIT
Beta Testinggustavscirulis/snapgrid1171 repos~4.7kAutomated safety check: PassCustom licence
Herdr Pre-Release Auditherdrdev/herdr43k—~289Automated safety check: PassApache-2.0
Happier Reviewhappier-dev/happier1.9k—~4.5kAutomated safety check: PassMIT
Megaphone ReleaseKuberwastaken/megaphone170—~1.3kAutomated safety check: PassMIT
Create Release Checklistsoftware-mansion/smelter734—~1.9kAutomated safety check: NotesCustom licence

Similar skills

  • Beta Testing

    gustavscirulis/snapgrid

    Beta testing strategy for iOS/macOS apps. An agent skill from gustavscirulis/snapgrid.

    117 GitHub starsUsed in 1 repo~4.7k tokens
    MobileAuto-check passed
  • Audit herdr release readiness by comparing commits since the base release against next-release changelog and docs. Use when asked to run or apply the repo's…

    43k GitHub stars~289 tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Happier Review

    happier-dev/happier

    Conduct evidence-backed Happier code, plan-completeness, session, worktree, feature, commit, branch, PR, codebase, and release-readiness reviews with affected-corridor analysis, high-confidence…

    1.9k GitHub stars~4.5k tokensUpdated today
    DevelopmentAuto-check passed
  • Megaphone Release

    Kuberwastaken/megaphone

    Prepare, validate, publish, and verify Megaphone releases. An agent skill from Kuberwastaken/megaphone.

    170 GitHub stars~1.3k tokensUpdated 2 mo ago
    DevelopmentAuto-check passed
  • Create Release Checklist

    software-mansion/smelter

    Generate a GitHub release-checklist issue for a full (non-RC) release of the Smelter server and/or the TypeScript SDK.

    734 GitHub stars~1.9k tokensUpdated yesterday
    DevelopmentAuto-check: notes
  • Releasing

    OdradekAI/bundles-forge

    A skill your agent uses when releasing a bundle-plugin, bumping versions, fixing version drift across manifests, setting up version sync infrastructure, updating CHANGELOG, publishing to…

    229 GitHub stars~3.3k tokensUpdated 5 mo ago
    DevelopmentAuto-check passed

More from shortcuts/locationjoystick

  • Screenshots

    shortcuts/locationjoystick

    Refresh all wiki/Play Store gallery screenshots from a connected Android device.

    104 GitHub stars~3.1k tokensUpdated yesterday
    Auto-check passed

Questions about Release Candidate

What does Release Candidate do?

Go/no-go audit of main before tagging a release: build pipeline, tests, doc consistency, code quality. Release Candidate is an agent skill from shortcuts/locationjoystick. Go/no-go audit of main before tagging a release: build pipeline, tests, doc consistency, code quality.

When should I use Release Candidate?

Release Candidate fits situations like: pre-release audit; is this ready to ship?.

How do I install Release Candidate in Claude Code?

Run `npx skills add shortcuts/locationjoystick --skill release-candidate -a claude-code`. Or copy the skill folder (.claude/skills/release-candidate in shortcuts/locationjoystick) into .claude/skills/release-candidate in your project. Claude Code loads it when a task matches its description.

How do I install Release Candidate in Codex?

Run `npx skills add shortcuts/locationjoystick --skill release-candidate -a codex`. Or copy the skill folder (.claude/skills/release-candidate in shortcuts/locationjoystick) into .agents/skills/release-candidate in your project. Codex loads it when a task matches its description.

Can I use Release Candidate in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add shortcuts/locationjoystick --skill release-candidate -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/release-candidate, .gemini/skills/release-candidate, .github/skills/release-candidate and .opencode/skills/release-candidate in your project.

What does Release Candidate need to run?

Going by SKILL.md and its folder, Release Candidate needs the command-line tools its instructions call (make, git, bash and adb).

Does Release Candidate access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Release Candidate safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Release Candidate use?

Release Candidate is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Release Candidate use?

About 1.3k tokens (SKILL.md is roughly 5.3k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Release Candidate?

Skills that share tags, products or a category with Release Candidate: Beta Testing (gustavscirulis/snapgrid, 117 stars), Herdr Pre-Release Audit (herdrdev/herdr, 43k stars), Happier Review (happier-dev/happier, 1.9k stars) and Megaphone Release (Kuberwastaken/megaphone, 170 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Release Candidate?

shortcuts (a GitHub user) maintains it in shortcuts/locationjoystick, which has 104 GitHub stars. The repository holds 2 skills in this directory. The repository was last updated on October 8, 2026.

Source: shortcuts/locationjoystick on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.