菜单
Use when addressing PR review comments on stacked jj branches. Triggered by phrases like "address review comments", "fix PR feedback", "respond to review on stacked branch", or "update the PR with reviewer suggestions".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Lint prose against Simplified Technical English (ASD-STE100) rules. Use when the user asks to check, lint, or simplify technical writing (specs, manuals, procedures, docs) for STE compliance, or mentions ASD-STE100 or Simplified Technical English.
Any time committing, pushing, or creating new revisions is mentioned, use this commit flow.
Step-by-step procedure for building a Claude Code channel integration. Use when creating a new channel plugin that connects Claude Code to external systems via MCP, named pipes, webhooks, or chat platforms.
This skill should be used when the user asks to "set up a dev environment", "create a workspace", "open a browser pane", "split terminal", "spin up frontend and backend", "use cmux", "manage cmux panes", "run commands in cmux", or mentions cmux workspaces, panes, surfaces, or browser automation. Provides workflow guidance for orchestrating multi-pane development environments with terminal and browser surfaces.
Use when merging a stack of stacked PRs with jj. Triggered by phrases like "merge the PR stack", "merge the stacked PRs", "land these PRs", or "merge the stack into main".
Use when writing python code. Can be used for code review.
| name | stacked-pr-review |
| description | Use when addressing PR review comments on stacked jj branches. Triggered by phrases like "address review comments", "fix PR feedback", "respond to review on stacked branch", or "update the PR with reviewer suggestions". |
You are a staff engineer addressing code review feedback on a stack of jj branches, keeping the fix as a clean, separate revision rather than squashing it into the parent.
Read PR review comments using gh api:
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments
Identify which branch the PR targets (this is the "target bookmark").
Navigate to the target branch by creating a new revision on top of it:
jj new <target-bookmark>
This places the working copy directly on the target branch, ready for the fix.
Make code changes to address the review comments. Only change what's needed to satisfy the reviewer — don't refactor or clean up unrelated code.
Describe the fix with a concise commit message:
jj describe -m "address review: <brief description of what was fixed>"
Identify downstream stacked branches — these are any branches that were originally built on the target bookmark and now need to be rebased onto the fix:
jj log --revisions 'descendants(<target-bookmark>)' --no-graph
Note the revision IDs of any downstream branches.
Rebase downstream branches onto the fix:
jj rebase -s <downstream-rev-id> -d @
Run this for each downstream branch that needs to move. @ refers to the current fix revision.
Resolve any rebase conflicts, if they appear:
jj log will show conflicted revisions with a ! marker.jj new <conflicted-rev-id> — create a resolution revision on top of it<<<, ===, >>>)jj squash — fold the resolution into the conflicted revisionjj log shows no ! markers.Retag bookmarks to point to the updated revisions:
jj bookmark set <bookmark-name> -r <rev-id>
Do this for each downstream bookmark that moved during the rebase.
Push all affected branches in one command:
jj git push --bookmark <bookmark1> --bookmark <bookmark2> ...
Include the fix revision's bookmark AND all downstream bookmarks.
Verify: visit the PRs on GitHub (or run gh pr view <pr-number>) to confirm the pushes updated the right branches. Check that CI is triggered.
jj bookmark list to inspect.