Menu
Create a JJ commit with a clear, repository-appropriate message. Use when the user asks to commit or save current working-copy changes.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Babysits or watches an open GitHub PR until merge-ready, continuously reacting to new review comments and CI failures throughout the PR's life. Use when asked to 'babysit the PR', 'watch the PR', monitor, or keep an eye on a PR over time — not a one-shot request to resolve review comments or debug one CI failure (those are separate skills). GitHub only, including GitHub Enterprise.
Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm, think through scope, decide what to build, or needs collaborative product framing before planning. Also use when the user must scope work in territory they say they do not know ("I know nothing about X but need to...") or asks for a blindspot pass — mapping the decision surface before questions begin. Not for executing already-specified work — direct implementation, debugging, or code review where no product scope is left to decide. Not for a decisive verdict on whether to adopt or switch to a specific external technology, library, or platform — brainstorming scopes what to build, not whether to commit to an outside option.
Structured code review for bugs, regressions, tests, and standards. Use before PRs or when asked for review; interactive mode can fix locally, while mode:agent reports only for pipeline callers.
Commit with JJ, push through `jj git` interoperability, and open or update a GitHub PR. Use when asked to ship/open a PR or only write, rewrite, or apply a PR description.
Diagnosis loop for bugs and failing behavior. Use for errors, stack traces, regressions, failed tests, issue-tracker bugs, stuck investigations after failed fixes, or asks to debug/fix a bug.
Review requirements, plans, or specs with role-specific lenses. Use when the user wants to improve an existing planning document.
| name | ce-commit |
| description | Create a JJ commit with a clear, repository-appropriate message. Use when the user asks to commit or save current working-copy changes. |
Describe and finish one or more coherent JJ changes from the working-copy commit. Done means each intended change has a validated description, the resulting change and commit IDs are reported, and any remainder in @ is named explicitly.
Jujutsu has no staging area: the working copy is a commit (@), and most jj commands snapshot file-system changes into it. jj commit describes @ and creates a new working-copy change on top. With filesets, selected changes remain in the commit being finished and unselected changes move to the new working-copy child.
Run each command as its own shell tool call. Do not join commands with shell operators, pipes, substitutions, or redirects. A non-zero exit is state to interpret, not a failure to hide.
| Command | Purpose | Failure meaning |
|---|---|---|
jj workspace root | Repository root | Not a JJ repository; report and stop |
jj status | Working-copy and conflict state | Repository cannot be read; report and stop |
jj diff | Current content changes | No output means no content change |
jj bookmark list -r @ | Bookmarks at the working-copy change | Empty output is normal |
jj bookmark list -r @- | Bookmarks at its parent | Empty output is normal |
jj log -r '::@' --limit 10 --no-graph | Recent local descriptions and topology | No prior history is available |
jj log -r '::@' --limit 10 --no-graph -T 'description ++ "\n"' | Repository message syntax and style | No compatible history is available |
The final command reads JJ description history for the required local message-style check; all VCS mutation remains JJ-native. Re-read jj status and jj diff immediately before each commit because commands snapshot the working copy and concurrent edits may change it.
If jj status reports no changes in @, report that there is nothing to finish and stop. Do not create an empty change.
If jj status reports conflicts, resolve them before finishing the change. Use jj resolve for an available merge tool or edit the materialized conflict directly, then rerun jj status and jj diff. Do not finish a conflicted change.
Bookmarks are named pointers and do not follow the working copy. A working-copy change does not need a bookmark merely to be committed, so do not create or move one in this skill unless the user explicitly asks.
Based on https://go.dev/wiki/CommitMessage and on past commit messages that you can see in git log, compose commit messages adherent to the present standards.
The repository-local instructions and the git log syntax dynamically derived from repository history through JJ always win; apply Go guidance only when compatible. Communicate the change's purpose clearly, keep the first line useful in history, and add explanatory context when a future reader needs it. Fixed prefixes, types, scopes, subjects, templates, and examples are prohibited; do not add capitalization, line-length, or body rules without repository-local evidence.
Scan the changed paths for distinct concerns. If file-level groups are clearly independent, finish them separately. If separation is ambiguous, keep one change. Do not use interactive splitting unless the user explicitly requests hunk-level separation.
Each change must preserve one reviewable purpose. Include related tests, generated outputs, and documentation with the behavior they validate or describe unless local conventions require another grouping.
At each change-description composition site, apply this instruction exactly:
Based on https://go.dev/wiki/CommitMessage and on past commit messages that you can see in git log, compose commit messages adherent to the present standards.
The repository-local instructions and the git log syntax dynamically derived from repository history through JJ always win; apply Go guidance only when compatible. Describe the purpose and material effect accurately. Add a body only when it carries motivation, tradeoffs, compatibility notes, or other context not clear from the first line. Fixed prefixes, types, scopes, subjects, templates, and examples are prohibited.
For one change:
jj commit -m "<repository-derived-message>"
For a multiline description, use the available file-writing capability to create $(jj workspace root)/.tmp/rocketclaw/ce-commit/<unique-id>.txt. If no JJ repository exists, use the current project directory's .tmp/rocketclaw/ce-commit/<unique-id>.txt as the matching local fallback; this skill otherwise reports the missing repository and stops. Then run:
MESSAGE=$(<workspace-local-message-file>)
jj commit -m "$MESSAGE"
For multiple file-level groups, pass the group's filesets before -m. Each fileset selects changes retained in the change being finished; unselected changes move to the new working-copy child. Re-run jj status and jj diff after every path-limited commit before selecting the next group. Do not use staging-area or non-JJ commit commands.
Without filesets, jj commit is equivalent to describing @ and creating a new empty working-copy change on top. Do not run an additional jj new.
For every completed change, inspect it with jj log -r @- --no-graph and, when needed, jj show -r @-. Validate its description with this instruction:
Based on https://go.dev/wiki/CommitMessage and on past commit messages that you can see in git log, compose commit messages adherent to the present standards.
The repository-local instructions and the git log syntax dynamically derived from repository history through JJ always win; apply Go guidance only when compatible. Fixed prefixes, types, scopes, subjects, templates, and examples are prohibited. If the description does not match the actual change or present repository standard, edit it with jj describe -r @- -m "<repository-derived-message>"; for a message file, load its contents into MESSAGE and pass -m "$MESSAGE", then validate it again.
Run jj status after the final commit. Report every completed change ID, commit ID, and first line. If @ is not empty, report the remaining paths rather than claiming all changes were committed.