菜单
PRのライフサイクル全体をゲート付きで管理する。PR作成、レビュー対応、マージ、ポストマージまでの一連のワークフローを強制する。PRを作りたい、レビュー対応したい、マージしたい、といった場面で使用する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
WHEN: the user wants a critical review by the `code-critic` agent. The skill gathers the agent's required Invocation Contract inputs (review target, intent, layer), dispatches the agent via the Agent tool, and drives the **address-then-resubmit** loop until the agent returns an `Approved` verdict or the user explicitly defers what is left.
WHEN: PROACTIVELY when the change introduces or modifies design (new abstraction, new boundary, new module, contract change, security-sensitive interaction, refactor that reshapes responsibility). INPUT: File paths/directory + intent of the change. OUTPUT: Design-level critical issues — contract gaps, architectural misalignment, over-/under-engineered abstractions, security-designed-in failures, systemic problems hidden behind local fixes — with root causes and structural fixes. Implementation defects (logic bugs, races, resource leaks) are out of scope; route those to critic-implementation-review.
WHEN: PROACTIVELY when reviewing code that implements an already-settled design (bug fixes, feature implementation against an agreed shape, optimizations inside an existing module). INPUT: File paths/directory + the design contract being implemented. OUTPUT: Implementation-level critical defects — logic errors, race conditions, resource leaks, concrete security bugs, error-handling gaps, performance problems on real-sized inputs, contract drift between signature and behavior — with concrete fixes. Design-level concerns (abstraction quality, contract shape, architectural fit) are out of scope; route those to critic-design-review.
OrbStack がホストの Docker runtime として常に利用可能である前提で、Docker Compose 開発環境にアクセスする方法。OrbStack 特有の自動 DNS・自動 port forwarding を活用し、dnsmasq や ports: 公開の手間を省く。Docker Compose 上の Rails/Node 等のサーバーにローカルからアクセスする場面、マルチテナントアプリのサブドメインルーティングを検証する場面で使用する。
Five Whys分析で問題の根本原因を特定し、本質的な解決策を導出する。問題の原因分析、根本原因の特定、なぜなぜ分析、トラブルシューティング、障害分析、インシデント振り返り、ポストモーテムなど、「なぜこの問題が起きたのか」を深掘りして解決策を考えたい場面で使用する。ユーザーが問題の原因について悩んでいたり、表面的な対処ではなく根本的な解決を求めている場合にも発動する。
WHEN: PROACTIVELY after completing a substantial task (PR merge, feature implementation, bug fix, investigation)—invoke WITHOUT waiting for user request. SKIP for trivial/instant tasks (typo fix, single-line change, quick question answer, config tweak). Also invokable manually via /slack-notify. Sends a completion notification to Slack via Incoming Webhook. Does nothing if CLAUDE_SLACK_NOTIFY_WEBHOOK_URL is not set.
| name | pr |
| description | PRのライフサイクル全体をゲート付きで管理する。PR作成、レビュー対応、マージ、ポストマージまでの一連のワークフローを強制する。PRを作りたい、レビュー対応したい、マージしたい、といった場面で使用する。 |
| user-invocable | true |
| allowed-tools | Bash(git:*), Bash(gh:*), Bash(glab:*) |
PRのライフサイクルをゲート付きで管理する。各ステップにはゲート条件がある。ゲートを通過しないまま次に進むな。
$ARGUMENTS でフェーズを指定できる: create, review, merge。省略時は現在のPR状態を判定して適切なフェーズから開始する。
git status
git rev-parse --abbrev-ref HEAD
git diff HEAD
mainブランチ上に未コミットの変更がある場合、新しいブランチを作成する。差分の内容から適切なブランチ名を提案する（例: feature/add-user-auth, fix/handle-null-errors）。
git checkout -b <branch-name>
feat, fix, docs, refactor, test, chore, style, perftype(scope): descriptiongit add .
git commit -m "<commit-message>"
glab を使用する.github/PULL_REQUEST_TEMPLATE.md等）、そのテンプレートに従ってPR本文を作成するgit push origin <branch-name>
PR TEMPLATEの確認（.github/PULL_REQUEST_TEMPLATE.md、.github/pull_request_template.md、docs/pull_request_template.md等）。存在すればテンプレートに従ってPR本文を作成する。
PR本文を.pr-body.md（workspace内一時ファイル）に書き出し、--body-fileで入力する。使用後に削除する。
Write toolで.pr-body.mdにPR本文を書き出す。
gh pr create --base main --title "<title>" --body-file .pr-body.md
rm .pr-body.md
gh pr view でPRの状態を確認する/address-pr-review を実行する制約:
gh pr checks で確認--squash / --merge / --rebase）を特定する。リポジトリ設定または過去のマージコミット履歴から判定する。不明ならユーザーに確認しろgh pr merge <PR番号> --<方式> でマージする制約:
--delete-branch 等）。Phase 3 が成功したら、指示を待たず Phase 4 を自律実行せよ。
gh pr view <PR番号> --json state で MERGED を確認git switch maingit pull制約: