メニュー
Run a structured first-pass code review on a PR. Use this skill when asked to review a PR, when opening a PR that should be sanity-checked before requesting human review, or when picking up someone else's PR to understand what changed and whether it's ready to merge.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Generate or update a Claude Code .mcp.json file from the project's mcp-servers/mcp.json. Use when the user wants to configure Claude Code's MCP servers from the trusted server set.
Create an mcp.json client configuration from a server.json. Use when the user wants to generate a ready-to-use MCP client config for connecting to an MCP server.
Create a valid MCP Registry server.json file for an MCP server. Use when the user wants to generate, scaffold, or write a server.json for any MCP server project.
Trigger a production release via GitHub Actions, monitor the ECS deployment, and verify the release is healthy. Use this skill when it's time to ship — after the PR is merged, CI is green, and staging has been verified. Also use it when asked to deploy, release, or ship to production.
Block until CI passes or fails on the current PR. Use this skill every time you push a commit and intend to tell the user the work is done — never present a pushed commit as complete without first confirming CI is green. Also use it when waiting on CI before merging, deploying, or moving on to the next task in a multi-step plan.
Deploy the current branch to staging and verify it works end-to-end. Use this skill after CI passes when you need to confirm changes actually work in a real environment before merging — especially for user-facing changes, API modifications, or anything that interacts with external services. Do not consider a PR "ready to merge" for non-trivial changes without a staging check.
| name | initial-pr-review |
| description | Run a structured first-pass code review on a PR. Use this skill when asked to review a PR, when opening a PR that should be sanity-checked before requesting human review, or when picking up someone else's PR to understand what changed and whether it's ready to merge. |
| user-invocable | true |
gh auth status, PR is accessible)gh pr view, gh pr diff)Perform a structured first-pass review of a pull request, checking for the things the team has agreed matter most. This is not a nitpick pass — it's a "catch real problems early" pass.
IMPORTANT: Check every prerequisite below BEFORE doing any work. If any check fails, stop immediately, tell the user which prerequisite is not met, and ask them to fix it. Do NOT proceed, improvise, or attempt workarounds.
gh CLI must be installed and authenticated (gh auth status must succeed)gh pr view must succeed for the target PR)gh pr view <pr> --json title,body,baseRefName,headRefName,files,additions,deletions
gh pr diff <pr>
Read the PR title, description, and full diff. Understand what the PR is trying to accomplish before reviewing any code.
Work through each section below. For each item, note whether it passes, has concerns, or is not applicable. Only flag things that are genuine problems — do not manufacture issues.
Produce a review comment with this structure:
## Summary
One or two sentences on what this PR does and the overall impression.
## Issues
Items that should be fixed before merging. Reference specific files and lines.
## Suggestions
Non-blocking improvements the author could consider.
## Questions
Anything that wasn't clear from the code or description alone.
If the PR looks good, say so plainly. Do not pad the review with filler.
Only post to GitHub if explicitly asked. Use:
gh pr review <pr> --comment --body "$(cat <<'EOF'
<review content here>
EOF
)"
Use --approve or --request-changes in place of --comment when appropriate.