메뉴
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.