メニュー
Set up and use an isolated Git worktree for repository implementation tasks. Use unless the user explicitly requests another workspace arrangement.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | git-worktree-workflow |
| description | Set up and use an isolated Git worktree for repository implementation tasks. Use unless the user explicitly requests another workspace arrangement. |
Inspect the repository state; treat uncommitted and untracked files in the original checkout as user work.
Fetch the requested base branch. Use main when no base is specified.
Create a short descriptive branch and worktree under .agents/worktrees/, for example:
git fetch origin main
git worktree add -b <branch-name> .agents/worktrees/<branch-name> origin/main
Inspect an existing branch or path before reuse; choose a new name if it is not clearly the task workspace.
Make all implementation changes in the new worktree. Do not remove another worktree unless the user explicitly requests it.
commit-message-quality-check.github-workflow when requested.<pull request title> (#<pull request number>); do not rely on a CLI default or omit the number.
Pass that exact subject through the merge command's --subject option; constructing it only in a candidate file or
reading the PR title is insufficient. After merging, inspect the stored commit subject and confirm it still contains
that exact number suffix.Use documented builds, tests, linters, formatters, or structural validators appropriate to the change. State skipped verification and its reason in the PR body. After a branch is pushed or attached to a PR, add follow-up commits rather than rewriting history unless the user explicitly requests a rewrite.
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, repository-family alignment, GitHub CI and release automation, package readiness, release metadata, and verification. Use when implementing, reviewing, preparing a release for, diagnosing quality gaps in, or applying a minimal-difference peer rollout to a BepInEx 5 Mono plugin or its build and release workflow.
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.
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.
Create or review channel-specific release notes from a canonical changelog. Use when checking destination history or publication readiness.
Investigate version-specific Lethal Company mechanics using verified Unity-build evidence, seeded RNG, exhaustive or sampled computation, and runtime observation; produce reproducible, bounded gameplay reports. Use for mechanics questions, full-seed enumeration, sealed-result reuse, Terminal or HUD endpoint interpretation, version comparisons, statistical prediction, or playable-strategy evaluation. Use unity-game-analyze for the underlying decompiled-code and serialized-asset trace.