メニュー
Write and publish a PR for the current branch as a draft, in English. Use when the user says "create PR", "open PR", "submit PR", or wants to publish their branch for review.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | create-pr |
| description | Write and publish a PR for the current branch as a draft, in English. Use when the user says "create PR", "open PR", "submit PR", or wants to publish their branch for review. |
Write and publish a PR for the current branch as a draft, in English.
bundle exec i18n-tasks normalize if any locale file changed.bin/rails test on the affected test files.bundle exec rubocop <changed_files> and npm run eslint / npm run stylelint if Ruby or JS/CSS changed.@AGENTS.md "Best Practices" sections to make sure the relevant conventions are honored (site scoping, modular layout, service patterns, strong params, tests)..github/PULL_REQUEST_TEMPLATE.md — fill the existing sections, don't invent new ones.git branch --contains HEAD staging), include the staging URL — otherwise note that a staging deploy is needed first.config/application.yml, or config/secrets.yml — Ansible may need updates.gh pr create --draft --base master --title "<title>" --body-file /tmp/pr-body.md
Use --body-file (write the body to /tmp/pr-body.md first) rather than --body "..." — heredocs and backticks get mangled when passed inline.
After creating the PR, surface the URL to the user.
Create a new topic branch for a feature or task. Use when starting work on a new feature, bug, or task that needs its own branch — or when the user says "new branch", "topic branch", "start a feature".
Deploy the current branch to staging via the project's webhook-based deploy script. Use when the user says "deploy to staging", "push to staging", or wants to test the branch on staging.
Guide for using test fixtures correctly. Use when writing or modifying tests that reference fixture data, to avoid inventing names and to keep references consistent with files in test/fixtures/.
Full PR feedback workflow: fetch comments, address issues, let the user review, then push. Use when the user says "fix PR comments", "address PR feedback", or invokes /pr-feedback. Also use when the user just wants to see PR comments without fixing anything.
Refine or create a GitHub issue with codebase context, a proposed plan, acceptance criteria, and likely files to change. Preserves the original human request verbatim inside a collapsible <details> block. Three modes: CI (auto-publish edit when $GITHUB_ACTIONS is set), interactive-edit (refine an existing issue with preview+confirm), and interactive-create (compose a new issue from a free-form description with preview+confirm). Use when the user says "refine issue #N", "research and plan issue", "create an issue for ...", or when invoked by an automated refine-issue workflow.
Review and reflect on PR changes before sending for review. Use when implementation is done and the user wants a final check before creating a PR, or says "review changes", "review and reflect", or "is this ready for review".