Menu
Read this skill before making commits
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Write messages, comments, PR reviews, Slack posts, and other prose in Sean's voice. Use when drafting anything that will be sent under Sean's name — code review comments, postmortem feedback, Slack messages, GitHub comments, coaching notes, design feedback, strategic takes. Triggers: 'write like me', 'in my voice', 'draft a comment for me', 'sound like me', 'sharpen this', 'this still sounds like AI'.
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".
Implement a piece of work based on a spec or set of tickets.
Plan a huge chunk of work — more than one agent session can hold — as a shared map of investigation tickets, and resolve them one at a time until the way to the destination is clear.
Move todos through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs. Maps to pi's built-in todo tool; see ../todo-tracker.md for the full tracker → tool mapping.
Turn the current conversation into a spec and publish it as a todo — no interview, just synthesis of what you've already discussed.
| name | commit |
| description | Read this skill before making commits |
| license | From mitsuhiko/agent-stuff |
Create a commit for the current changes using Conventional Commits format with a polished, highly descriptive message.
<type>(<scope>): <summary>
type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.Signed-off-by).Detect which VCS to use before doing anything else:
.jj/ exists in the repo root → use jj (even if .git/ also exists — colocated repos have both).git/ exists → use gitPrefer jj whenever available.
Use these steps when the repo has .jj/:
Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review jj st and jj diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run jj log --no-graph -r 'ancestors(@, 50)' -T 'description.first_line() ++ "\n"' to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Commit. Choose the path based on the body:
Trivial single-line subject, no body (e.g. fix: typo):
jj commit -m "<subject>"jj commit -m "<subject>" <filesets>Multi-paragraph body, OR any body containing backticks / $(...) / em-dashes / non-ASCII punctuation — go via a tempfile to avoid shell injection (see the jujutsu skill's "Safe message passing" section for the full rationale):
write tool to put the full commit message (subject line, blank line, body paragraphs) into /tmp/jj-commit-msg.txt. Do not use cat <<EOF — heredocs still expand backticks and $().jj describe --stdin < /tmp/jj-commit-msg.txt
jj new
jj commit does not support --stdin, so use a placeholder then rewrite):
jj commit <filesets> -m "placeholder"
jj describe @- --stdin < /tmp/jj-commit-msg.txt
Avoid jj commit -m "<subject>" -m "<body>" for anything non-trivial — each -m is a separate shell-evaluated argument, and prose bodies have repeatedly triggered backtick execution and Unicode mangling.
jj mental model: There is no staging area. The working copy (
@) IS a commit.jj commitdescribes the current working copy and creates a new empty@on top. When file paths are given, only those files stay in the committed change — everything else moves to the new@.
Use these steps when the repo only has .git/:
git status and git diff to understand the current changes (limit to argument-specified files if provided).git log -n 50 --pretty=format:%s to see commonly used scopes.git commit -m "<subject>" (and -m "<body>" if needed).