Noodle Release

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.

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 synchronization failed, the maintainer may manually run Release with its required tag. Recovery verifies published checksums and only repeats the website manifest synchronization. It does not rebuild or replace release binaries. Preparation itself still stops before any remote mutation.
• Manifest updates are serialized and reject version downgrades. Homebrew core maintains its formula independently; the release workflow no longer dispatches updates to the retired tap. After publication, check the official formula and existing Homebrew update PRs before preparing a manual version bump with brew bump-formula-pr.
• When OpenTUI changes, keep the formula's checksummed source resource and Zig dependency aligned with the released lockfile. Preserve Homebrew's bottle block and Linux runtime dependencies. See packaging/homebrew/README.md for source-build validation and tap migration instructions.