메뉴
Roll out a validated canonical change from a designated primary repository to compatible peers with only necessary local differences. Use for shared Agent Skills, repository rules, workflows, or documentation conventions.
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 | rollout-workflow |
| description | Roll out a validated canonical change from a designated primary repository to compatible peers with only necessary local differences. Use for shared Agent Skills, repository rules, workflows, or documentation conventions. |
Treat the primary repository as the canonical source. Propagate only a change that is already validated there; do not use rollout work to redesign it.
