메뉴
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".
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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".
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.
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.
| name | review-and-reflect |
| description | 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". |
This PR is almost ready to send for review.
Before doing it:
Review changes against master to understand what has been changed:
git log --oneline master..HEAD
git diff master...HEAD
Reflect on the implementation: Is there anything you wish you'd done differently? Any way you'd have stored the data differently? Are there places to refactor or revisit before pushing?
Check tests: Find tests related to the changes and run them to make sure they pass (follow the rules in @.agents/rules/tests.mdc):
bin/rails test <relevant_test_files>
Code review: Review the code and make improvement suggestions, as a senior developer would. Use @AGENTS.md and @.agents/rules/ as reference for coding standards and project conventions. Pay particular attention to:
current_site).gobierto_* modules unnecessarily)..new(args).call, attr_reader, single responsibility).UI review: If the changes include views, helpers, SASS, or Vue components, eyeball the affected pages on a running app (bin/dev) before pushing. Check that Turbolinks hasn't broken any one-off JS init.
Don't create files related to the review unless you are asked to do so.