菜单
Create or update a GitHub pull request for the current branch, committing pending changes first. Use when the user wants to open a PR, update an existing PR, or ship a branch for review.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Hand off the current task to a fresh background agent running in its own workmux worktree, passing a self-contained prompt synthesized from this conversation's context. Use when the user wants to outsource, delegate, or "hand off" implementation work to a separate agent session (e.g. "handoff this fix", "outsource it to a ccd agent", "spin up an agent to do X").
Delegate a code review to pi (`pi /skill:review`) running in a tmux window, then dispatch subagents to fix each finding and check it off the review file. Use when the user wants an automated review-and-fix loop over their current changes.
Teach a topic using the Feynman technique — explain simply, have the user re-explain, identify gaps, re-teach, and loop until they can explain it on their own. Use when the user wants to deeply understand a topic, test their understanding, or mentions "Feynman".
Build a focused 20-hour learning plan for a topic, structured as 10 two-hour sessions following the Pareto principle (20% that drives 80% of results). Use when the user wants to learn a topic fast, build a study plan, or create a structured curriculum.
Ask questions about specific GitHub code repositories using DeepWiki. Use when the user asks about a repo's code, architecture, configuration, modules, APIs, examples, or behavior and provides a GitHub repository in owner/repo form or as a GitHub URL.
Create hand-drawn Excalidraw diagrams from JSON using excalidraw-cli. Use when the user wants diagrams, flowcharts, architecture diagrams, visual explanations, or shareable Excalidraw URLs.
| name | pr |
| description | Create or update a GitHub pull request for the current branch, committing pending changes first. Use when the user wants to open a PR, update an existing PR, or ship a branch for review. |
| argument-hint | [optional PR title, base branch, or description context] |
Create or update a GitHub pull request from the current branch.
Always commit first, then push, then create or update the PR.
The PR description should be written for reviewers who need to quickly understand:
Avoid implementation-first descriptions.
Invoke the /commit skill to stage and commit any pending changes before creating or updating the PR.
If the working tree is clean, skip this step and proceed.
gh pr view --json number,title,body,baseRefName,url 2>/dev/null
If a PR already exists for this branch:
gh pr edit --body "<updated body>"
Only proceed to Step 3 if no PR exists yet.
Get the current branch:
git branch --show-current
Determine the base branch in this order:
main if it exists.master if main does not exist.git remote show origin | grep 'HEAD branch'
If the current branch is the base branch, stop and tell the user they need to create a feature branch before opening a PR.
git push -u origin HEAD
If the push is rejected because of a non-fast-forward update, do not force-push.
Tell the user the branch is behind or diverged and ask how they want to proceed.
Inspect the branch relative to the base:
git log origin/<base>..HEAD --oneline
git diff origin/<base>..HEAD --stat
git diff origin/<base>..HEAD --name-only
When needed, inspect relevant diffs:
git diff origin/<base>..HEAD -- <file>
Before writing the PR body, identify:
Do not simply summarize files changed.
Derive a clear title from the branch name, commits, and user-provided context.
Rules:
Update handoff logicGood examples:
Gate Invoice Tracker handoff on support ingestion readiness
Add per-rule readiness check for invoice support docs
Skip handoff when required support docs are not processed
Write the body using this structure.
Use optional sections only when they add value.
## Summary
<Start with the behavior change in plain English. Explain the problem this PR solves and why it matters. Keep this section reviewer-friendly and avoid leading with internal implementation details.>
<If relevant, explain who benefits: users, ops, downstream systems, maintainers, etc.>
## Behavior change
<Describe what is different after this PR. Include defaults and backward compatibility when relevant.>
## Implementation
<Explain the important implementation details. Focus on decisions reviewers need to understand, not every file touched.>
## Testing
<Describe meaningful test coverage or manual verification.>
## Notes
<Optional. Include rollout notes, config examples, limitations, risks, or follow-ups only if useful.>
If the PR adds config, flags, statuses, rules, or state transitions, include a simple example.
Prefer:
## Notes
Example config:
```json
{
"require_support_ingestion_processed": true
}
```
Default behavior:
* omitted → current behavior
* `false` → current behavior
* `true` → enables the new readiness gate
For status handling, prefer clear bullets:
A document is considered processed only when:
- `auto_passed` → processed
All other states are treated as not processed:
- missing row
- `needs_review`
- `failed`
If the implementation involved a meaningful tradeoff, explain it plainly.
Prefer:
This check happens in application code instead of SQL so skipped records can still emit a decision explaining why they did not proceed.
Avoid:
SQL projects, rules decide.
Clever phrasing is okay in comments, but PR descriptions should optimize for fast reviewer comprehension.
Good:
Ties on `update_time` were not deterministic, so this now uses `(update_time, id)` for stable ordering.
Bad:
Claude review flagged that ties on `update_time` were not deterministic.
Create a new PR:
gh pr create \
--base <base-branch> \
--title "<title>" \
--body "<body>"
After creation, output the PR URL.
If updating an existing PR:
gh pr edit --body "<updated body>"
After updating, output the PR URL.