noodle: Skill for Claude Code

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 with the evidence-backed reason or unchanged with a concise reason. 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.