메뉴
Create a well-formed git commit from current changes using session history for rationale and summary; use when asked to commit, prepare a commit message, or finalize staged work.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Creates a pull request on GitHub with proper labels, branch naming, and description formatting. Use when changes are ready to be submitted as a PR.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL.
Land a PR by monitoring conflicts, resolving them, waiting for checks, and squash-merging when green; use when asked to land, merge, or shepherd a PR to completion.
| name | commit |
| description | Create a well-formed git commit from current changes using session history for rationale and summary; use when asked to commit, prepare a commit message, or finalize staged work. |
area: lowercase imperative summary, where the area is the
package, directory, or subsystem touched.git status, git diff, and git diff --staged for actual changes.Read session history to identify scope, intent, and rationale.
Inspect the working tree and staged changes (git status, git diff,
git diff --staged).
Break the work into atomic commits when the change contains more than one logical step. Each commit should deliver a single, reviewable piece of value.
Stage only the files and hunks for the current commit after confirming scope.
Sanity-check newly added files; if anything looks random or likely ignored (build artifacts, logs, temp files), flag it to the user before committing.
If staging is incomplete or includes unrelated files, fix the index or ask for confirmation.
Choose the area prefix from what the commit touches: the package,
top-level directory, or subsystem (e.g., cli: ..., docs: ...,
tests: ...). If a commit spans areas cleanly, that is a sign it should be
split.
Write the subject as area: summary — imperative mood, lowercase after
the colon, <= 72 characters, no trailing period.
Decide whether the commit needs a body:
Skip trailer ceremony. Add Fixes #NNN only when the commit actually
closes an issue.
Wrap body lines at 72 characters.
Create multiline commit messages through stdin with a quoted here-doc, for example:
git commit -F - <<'EOF'
subject
body
EOF
Commit only when the message matches the staged changes: if the staged diff includes unrelated files or the message describes work that isn't staged, fix the index or revise the message before committing.
If the final story is clearer after reordering, squashing fixups, or rewording commit messages, revise the local history before sharing it.
git commit whose messages reflect the
session and present the change as a clear story.Trivial change, subject only:
cli: fix typo in --help output
Non-trivial change, prose body:
config: reject invalid values during startup
Invalid values were accepted during parsing and failed only when first
used, making startup errors harder to diagnose.
Validate each value at the parsing boundary so runtime code can assume
the configuration is valid.