bayes-platform: Skill for Claude Code

Wrap up a feature by running its final steps. Present a checklist form, then execute only the checked steps, in the fixed order below.

Step 0 — Show the checklist form

Before doing anything, call AskUserQuestion with a single multi-select question so the user can check/uncheck the steps (list them as the options; the user unchecks any they want to skip):

• Update changelog — add an entry under ## [Unreleased] in CHANGELOG.md
• Create a branch — move current work onto a feature branch
• Review the frontend conventions — a subagent reviews the diff of an ADR 0031 app against docs/frontend/conventions.md
• Run tests-parallel — make tests-parallel
• Create a PR — open a pull request with gh

All steps are pre-selected by default EXCEPT the changelog, which is optional: pre-select it only when the change is visible to end users or security-relevant. Leave it unchecked for internal work — refactors, CI/tooling, docs, tests. Mention in the question why you left it unchecked; the user can still check it. Pre-select the frontend review only when the diff touches apps/desk, packages/desk-contracts or docs/frontend/.

Use header: "Steps", multiSelect: true. Whatever the user leaves checked is the set to run.

Then run the checked steps strictly in this order (skip unchecked ones):

1. Update changelog

Only if checked. Edit CHANGELOG.md, adding a line under ## [Unreleased]:

• New capability → ### Added; modified behavior → ### Changed; bug fix → ### Fixed; security hardening or vulnerability fix → ### Security.
• Write for end users, not developers — describe the visible outcome, not entities/services/migrations.
• Prefix with (beta) if the feature is behind a flag or not yet exposed in the UI.
• Write in STE (Simplified Technical English): short sentences (max 20 words), one fact per sentence, active voice.
• One sentence per entry. Even a large feature gets one headline sentence naming the capability or the new status (e.g. "Agents now have a draft and a published version of their settings."), not the mechanics. No sub-bullets. Never chain clauses with ";", "—", or "so".
• Name the capability, not the UI: no button placement, labels, colors, or click behavior. Keep dates and required user actions.
• Merge entries that belong to the same change into one. Delete an entry whose information is already carried by another.
• Verify before writing: check the actual commits/code for how a change works (runtime vs data migration, full vs partial scope). Scope claims exactly — write "New CSV extraction runs are personal." when existing data is unaffected.
• Do not add an entry for a bug that was never in a released version. Check that the bug's cause was in the last release tag before listing a fix.