Agent skill

Noodle Release

by wilfredinni in wilfredinni/noodle

Prepare a versioned Noodle release by updating package.json, inspecting changes since the latest tag, auditing every repository-maintained skill, synchronizing affected README, AGENTS.md, tests…

Apache-2.0Auto-check passedDevelopment

Install Noodle Release

skills CLI
$ npx skills add wilfredinni/noodle --skill noodle-release -a claude-code

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

GitHub CLI
$ gh skill install wilfredinni/noodle noodle-release --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/wilfredinni/noodle.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/noodle-release .claude/skills/noodle-release && 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
noodle-release
GitHub stars
367
Token cost
~2k tokens
SKILL.md length
1,034 words
Files
2 (incl. references)
Skills in repo
4
Repo updated
First seen
Licence
Apache-2.0

At a glance

Prepare a versioned Noodle release by updating package.json, inspecting changes since the latest tag, auditing every repository-maintained skill, synchronizing affected README, AGENTS.md, tests…

  • Works in 12 steps: Normalize the requested release as… → Run bun run release:context before… → Read the generated report before… → …
  • Release preparation
  • SKILL.md covers Workflow, Evidence rules and CI artifacts and publication…
  • Calls bun

What it does

Noodle Release is an agent skill from wilfredinni/noodle. Prepare a versioned Noodle release by updating package.json, inspecting changes since the latest tag, auditing every repository-maintained skill, synchronizing affected README, AGENTS.md, tests, CHANGELOG.md, noodle-site documentation, and a release blog post, then running the release validation. Use for release preparation, documentation synchronization, skill updates, and public-surface review; never commit, tag, push, publish, or modify GitHub releases.

Its SKILL.md is about 2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/public-surface-map.md`).

It sits in Development, covering Blog and article writing and Changelog and release notes. It works with npm and GitHub. The repository describes itself as: A REST Client where the Repository is the Workspace. The licence is Apache-2.0.

When your agent uses it

  • Release preparation
  • Documentation synchronization
  • Public-surface review
  • Modify GitHub releases

Example prompts

  • “/noodle-release”

Workflow steps

12 steps, taken from the first numbered list in SKILL.md.

  1. Normalize the requested release as package version X.Y.Z and tag vX.Y.Z. Reject missing, prerelease, or malformed versions instead of…
  2. Run bun run release:context before editing. If the documentation checkout is not at ../noodle-site, set NOODLE_SITE_DIR to its path.
  3. Read the generated report before editing. Treat changed files, tests, and CLI help as evidence; do not infer unsupported behavior.
  4. Read the public-surface map and inspect the current target documents in both repositories.
  5. Set package.json to package version X.Y.Z. Search tracked source, tests, scripts, and public documentation for the previous product…
  6. Identify version-sensitive tests and fixtures from the implementation and the version search. Update those that intentionally assert the…
  7. Audit every repository-maintained skill under .agents/skills/, including noodle-dev, noodle-use, noodle-release, and opentui. For each…
  8. Audit src/ui/Tips.tsx against current keybindings, commands, CLI behavior, and UI modes. Replace stale tips, remove duplicates, and add…
  9. If the update mechanism changed (update manifest, cache format, release asset structure), verify noodle-site/public/update.json schema…
  10. Update only the affected README, AGENTS.md, skills, site pages, src/ui/Tips.tsx, tests, and CHANGELOG.md. Preserve each repository's…
  11. Update CHANGELOG.md for the target version. Immediately below the version/date heading, add a concise two- to three-sentence release…
  12. Create a new article under noodle-site/src/content/blog/ for the target release. Turn the matching CHANGELOG.md section into a cohesive…

What it can do on your machine

Read from SKILL.md and the folder at commit 60b83bb. 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:

    • bun

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

  • Network

    No URLs in SKILL.md.

    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

Noodle Release loads about 2k tokens when it runs, and up to ~2.4k if it reads all its reference files. Until then it costs about 119 tokens; SKILL.md has 1,034 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~119
When it runs · the whole SKILL.md, loaded when a task matches
~2k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~2.4k

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 wilfredinni/noodle at commit 60b83bb, republished under its Apache-2.0 licence (© wilfredinni). 1,034 words, ~2,003 tokens.

Download SKILL.mdSave it as .claude/skills/noodle-release/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
noodle-release
description
Prepare a versioned Noodle release by updating package.json, inspecting changes since the latest tag, auditing every repository-maintained skill, synchronizing affected README, AGENTS.md, tests, CHANGELOG.md, noodle-site documentation, and a release blog post, then running the release validation. Use for release preparation, documentation synchronization, skill updates, and public-surface review; never commit, tag, push, publish, or modify GitHub releases.

Noodle release preparation

Use this skill when the maintainer asks to prepare a Noodle release or synchronize public documentation after a set of changes.

Workflow

  1. Normalize the requested release as package version X.Y.Z and tag vX.Y.Z. Reject missing, prerelease, or malformed versions instead of guessing.
  2. Run bun run release:context before editing. If the documentation checkout is not at ../noodle-site, set NOODLE_SITE_DIR to its path.
  3. Read the generated report before editing. Treat changed files, tests, and CLI help as evidence; do not infer unsupported behavior.
  4. Read the public-surface map and inspect the current target documents in both repositories.
  5. Set package.json to package version X.Y.Z. Search tracked source, tests, scripts, and public documentation for the previous product version; update only references that intentionally track the Noodle release. Do not rewrite unrelated protocol versions or semver fixtures.
  6. Identify version-sensitive tests and fixtures from the implementation and the version search. Update those that intentionally assert the current Noodle version, then rely on the full release check to catch additional required changes.
  7. Audit every repository-maintained skill under .agents/skills/, including noodle-dev, noodle-use, noodle-release, and opentui. For each skill, record either changed since the base tag with the evidence-backed reason or unchanged with a concise reason. Distinguish skill updates already committed in the release range from additional release-preparation edits, and fix any remaining documented-behavior gap now. Do not edit a skill merely to make the audit show a change.
  8. Audit src/ui/Tips.tsx against current keybindings, commands, CLI behavior, and UI modes. Replace stale tips, remove duplicates, and add concise tips for evidence-backed user-facing behavior introduced since the prior release.
  9. If the update mechanism changed (update manifest, cache format, release asset structure), verify noodle-site/public/update.json schema, noodle-site/netlify.toml cache headers (target: Cache-Control: s-maxage=300, stale-while-revalidate=600 for /update.json), release workflow ordering, and site installation docs are consistent.
  10. Update only the affected README, AGENTS.md, skills, site pages, src/ui/Tips.tsx, tests, and CHANGELOG.md. Preserve each repository's existing voice and examples.
  11. Update CHANGELOG.md for the target version. Immediately below the version/date heading, add a concise two- to three-sentence release summary that synthesizes the most important evidence-backed user-facing changes. Then group the detailed changes under these exact headings when applicable: ### ✨ Features, ### 🐞 Fixes, and ### 🔧 Refactors. Use ### 📚 Documentation for documentation-only changes when applicable. Keep Unreleased at the top, include only changes since the previous release tag, and do not invent behavior.
  12. Create a new article under noodle-site/src/content/blog/ for the target release. Turn the matching CHANGELOG.md section into a cohesive, release-reader-oriented article rather than copying its bullets. Follow the existing blog frontmatter and voice, include release in tags so the site renders #release, and do not introduce claims that the changelog does not support.
  13. For uncertain behavior, leave a review note instead of guessing.
  14. Run bun run release:check -- --tag vX.Y.Z and report failures with their command output. Fix only failures within release-preparation scope, rerun the affected check, and finish with the complete release check passing.
  15. Stop after the verified diff and review summary. Report the target package version and tag, validation commands and results, remaining review notes, and the explicit changed/unchanged decision for every audited skill. Do not commit, tag, push, publish, or modify GitHub releases.
Show full SKILL.md (504 more words)Show less

Evidence rules

  • Verify CLI syntax and options against the current CLI help and implementation.
  • Verify examples against tests or a local smoke run when they are deterministic and do not require credentials or network access.
  • Verify shortcut labels in src/ui/Tips.tsx against src/ui/keybind.ts; preserve {key} markup and identify any required focus or browse/edit mode.
  • Keep tips concise, actionable, and limited to supported current behavior. Do not add a tip solely because an implementation detail changed.
  • Describe export formats from their serializers and tests; do not promise support for fields the serializer drops.
  • Treat overlays, focus, and event-propagation fixes as release-note candidates unless users must learn a new interaction.
  • Do not update every skill by default. Update only skills whose workflows or supported behavior changed.
  • The GitHub release body is generated from the matching CHANGELOG.md version section. Write it for release readers, not as a raw commit list.
  • The release summary belongs between the version/date heading and the first detailed section. It should be concise, release-reader oriented, and must not introduce claims absent from the detailed entries.
  • Keep each CHANGELOG.md prose paragraph and list item on one physical line. Never insert manual line breaks to satisfy a column width, terminal readability, or diff preference; the code formatter's printWidth does not apply to changelog prose. Preserve headings, blank lines, and intentional code blocks. The release-notes generator rejects manually wrapped prose.
  • Use a separate release-note bullet for each unrelated change within a section. Keep a single bullet when multiple details form one cohesive user-facing capability; do not split merely to mirror individual commits.
  • When an agent skill changes, add a separate ### 📚 Documentation bullet for each changed skill; do not combine multiple skill updates into one entry.
  • Preserve the exact emoji headings in the release body; GitHub supports the Unicode emojis from CHANGELOG.md.

CI artifacts and publication recovery

  • Release reuses all five validated binaries from a successful ci.yml push to main at the exact release commit. CI artifacts contain the binary plus format version, commit, Noodle version, native target, asset name, Bun version, run ID, and SHA-256 metadata, and expire after seven days.
  • Pending CI is allowed fifteen minutes to finish. Failed or cancelled CI and API failures block Release. Only absent CI or missing/expired artifacts run the reusable workflow once; invalid metadata or hashes block publication.
  • Ubuntu and Windows each run the full applicable suite once in their own job. Windows native platform checks still cover the shipped addon, diagnostics, Credential Manager, compiled executable, and independent Zig rebuild. Tests remain sequential within every job.
  • For a published release whose site or Homebrew synchronization failed, the maintainer may manually run Release with its required tag. Recovery verifies published checksums and only repeats the manifest synchronization and Homebrew notification. It does not rebuild or replace release binaries. Preparation itself still stops before any remote mutation.
  • Manifest updates and Homebrew formula updates are serialized and reject version downgrades. Homebrew receives the exact requested version; a successful notification means dispatch accepted, while formula completion is reported by the tap's Update Formula workflow.

© wilfredinni, Apache-2.0. 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 (references) in .agents/skills/noodle-release of wilfredinni/noodle.

  • SKILL.md
  • references/public-surface-map.md

Open the folder on GitHubat commit 60b83bb

Compare with similar skills

Noodle Release 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.

Noodle Release compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Noodle Release this skillwilfredinni/noodle367—~2kAutomated safety check: PassApache-2.0
Cutting A ReleaseTriliumNext/Trilium38k—~3.2kAutomated safety check: PassAGPL-3.0
Verdaccio Pull Request Workflowverdaccio/verdaccio18k—~1.9kAutomated safety check: PassMIT
Hunk Release Workflowmodem-dev/hunk9.6k—~3.8kAutomated safety check: PassMIT
Version ReleaseNG-ZORRO/ng-zorro-antd9.2k—~3.1kAutomated safety check: PassMIT
Release Roundethereumjs/ethereumjs-monorepo2.8k—~2kAutomated safety check: PassNone

Similar skills

  • Cutting A Release

    TriliumNext/Trilium

    A skill your agent uses when cutting, preparing, or debugging a Trilium release — bumping the monorepo version, tagging, or diagnosing a failed "Release" workflow run.

    38k GitHub stars~3.2k tokensUpdated today
    DevelopmentAuto-check passed
  • Takes a change through a verdaccio pull request: branch, local checks, changeset, title and body, labels, CI and review rounds, and ports to other release lines.

    18k GitHub stars~1.9k tokensUpdated 2 days ago
    DevelopmentAuto-check passed
  • Hunk Release Workflow

    modem-dev/hunk

    Maintainer workflow for preparing, publishing, verifying and curating Hunk releases, with confirmation gates before tags, publishes and public edits.

    9.6k GitHub stars~3.8k tokensUpdated 3 days ago
    DevelopmentAuto-check passed
  • Version Release

    NG-ZORRO/ng-zorro-antd

    NG-ZORRO/ng-zorro-antd repository release workflow. An agent skill from NG-ZORRO/ng-zorro-antd.

    9.2k GitHub stars~3.1k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Release Round

    ethereumjs/ethereumjs-monorepo

    Runs a coordinated EthereumJS npm release round in six human-gated phases — intent and readiness, CHANGELOG, version bump, publish (human executes), post-publish verification, and announcements.

    2.8k GitHub stars~2k tokensUpdated 22 days ago
    DevelopmentAuto-check passed
  • Ccb GitHub

    SeemSeam/claude_codex_bridge

    Maintain this CCB project's GitHub-facing release and npm publication surface.

    3.6k GitHub stars~4.9k tokensUpdated today
    DevelopmentAuto-check passed

More from wilfredinni/noodle

  • Noodle Dev

    wilfredinni/noodle

    A skill your agent uses when developing features for the noodle terminal REST client — adding panes, keybindings, hooks, overlays, auth types, body types, I/O operations, environment features…

    367 GitHub stars~8.7k tokensUpdated yesterday
    Auto-check: notes
  • Noodle Use

    wilfredinni/noodle

    Teach agents to create, organize, maintain, evaluate, import, convert, and automate noodle terminal REST client collections using supported CLI commands plus YAML and dotenv files.

    367 GitHub stars~8.5k tokensUpdated yesterday
    Auto-check: notes
  • Opentui

    wilfredinni/noodle

    Build terminal UIs with OpenTUI. An agent skill from wilfredinni/noodle.

    367 GitHub stars~2.9k tokensUpdated yesterday
    Auto-check passed

Works with

Questions about Noodle Release

What does Noodle Release do?

Prepare a versioned Noodle release by updating package.json, inspecting changes since the latest tag, auditing every repository-maintained skill, synchronizing affected README, AGENTS.md, tests…. Noodle Release is an agent skill from wilfredinni/noodle.md, noodle-site documentation, and a release blog post, then running the release validation.

When should I use Noodle Release?

Noodle Release fits situations like: release preparation; documentation synchronization; public-surface review; modify GitHub releases.

How do I install Noodle Release in Claude Code?

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

How do I install Noodle Release in Codex?

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

Can I use Noodle Release 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 wilfredinni/noodle --skill noodle-release -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/noodle-release, .gemini/skills/noodle-release, .github/skills/noodle-release and .opencode/skills/noodle-release in your project.

What does Noodle Release need to run?

Going by SKILL.md and its folder, Noodle Release needs the command-line tools its instructions call (bun).

Does Noodle Release access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Noodle Release 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 Noodle Release use?

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

How many tokens does Noodle Release use?

About 2k tokens (SKILL.md is roughly 8k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 400 tokens, read only when the agent opens those files.

What are the alternatives to Noodle Release?

Skills that share tags, products or a category with Noodle Release: Cutting A Release (TriliumNext/Trilium, 38k stars), Verdaccio Pull Request Workflow (verdaccio/verdaccio, 18k stars), Hunk Release Workflow (modem-dev/hunk, 9.6k stars) and Version Release (NG-ZORRO/ng-zorro-antd, 9.2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Noodle Release?

wilfredinni (a GitHub user) maintains it in wilfredinni/noodle, which has 367 GitHub stars. The repository holds 4 skills in this directory. The repository was last updated on October 9, 2026.

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