メニュー
Create, update, or review user-facing stable release notes and publication readiness. Use when deriving stable notes from a canonical changelog or checking release readiness; not for canonical changelog authoring or publishing.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Create, align, or review production-quality Python Flet applications across package and module architecture, presentation state, Flet controls, async lifecycle, persistence and I/O boundaries, uv dependency management, Ruff, strict mypy, pytest, 100% branch and statement coverage, GitHub Actions, Flet packaging, security, and developer documentation. Use for new Flet projects, large UI refactors, quality-baseline adoption, CI setup, release readiness, or reviews of pyproject.toml, uv.lock, src/tests layout, and Flet application code. Pair with software-documentation-maintenance for document ownership and with security-check for dependencies, secrets, and CI supply chain decisions.
Select a reviewed APM CLI version, then set up, pin, deploy, audit, and update APM-managed agent dependencies safely. Use when creating or editing apm.yml or apm.lock.yaml, choosing or installing APM, adding an Agent Skill, plugin, or MCP dependency, validating a pinned deployment, or preparing a cooldown-aware update proposal.
Review or create a BepInEx Mono mod for C# project and module structure, plugin identity, game compatibility, dependency boundaries, GitHub CI and release automation, packaging, release metadata, and verification. Use when implementing, reviewing, preparing a release for, or diagnosing quality gaps in a BepInEx 5 Mono plugin or its build and release workflow.
Maintain a canonical developer changelog and versioned release history. Use when adding or correcting Keep a Changelog entries, prerelease history, compatibility context, or release-source material; not for user-facing release notes or publishing.
Review or draft repository commit messages for Conventional Commits format, accurate change summaries, breaking-change footers, and required attribution trailers. Use before creating, amending, or validating a commit.
Set up and use an isolated Git worktree for repository implementation tasks. Use unless the user explicitly requests another workspace arrangement.
| name | release-note-workflow |
| description | Create, update, or review user-facing stable release notes and publication readiness. Use when deriving stable notes from a canonical changelog or checking release readiness; not for canonical changelog authoring or publishing. |
Derive user-facing stable notes from the canonical developer changelog; do not create a competing source of truth.
Changed, while Fixed requires a publicly exposed incorrect label. Keep internal correction history in the changelog.Notes, after change categories, for compatibility and limitation metadata unless the channel requires another layout. Source claims, preserve confidence levels, and group paired tools or dependencies with their tested product/version. Exclude test dependencies, diagnostics, and issue/PR IDs unless users need them.prose-quality-check for nuanced prose and security-check for security- or supply-chain-sensitive content.Before publication, confirm the version and documented tag convention, local and remote tag availability, required note format, release-workflow inclusion, and documented verification result. Treat missing stable metadata, tag convention or remote-tag verification, publication format/destination, prerelease-policy evidence, workflow inclusion, or failed verification as blockers. Do not publish, create tags or releases, or expose private paths, transcripts, or credentials.
For review-only requests, make no edits and return a compact status matrix for the source section, notes destination, version and tags, channel and format, workflow inclusion, verification, required updates, and blockers.