菜单
Use when opening or rewriting a pull request and the reviewer needs a concise, truthful explanation of why the change exists, how it works, which decisions matter, and where to look carefully.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Write or rewrite concise reviewer-first pull request titles and descriptions for Pardes manager publication. Use approved intent, owner reports, conditional verifier reports, and narrow factual details without filler.
Use when a completed or active Codex coding session should be evaluated as a workflow run, especially to identify where orchestration skills, sub-agent delegation, worktree routing, verification handoffs, PR monitoring, or compaction recovery worked well or caused friction.
Use when a user installs the Codex workstreams plugin, asks to set it up, or sees permission prompts for workstream checkpoints, reports, or temporary pull-request body files.
Use when a coding objective spans multiple workflow phases or pull requests and needs a persistent manager to coordinate investigation, architecture, planning, implementation, verification, PR creation, review feedback, and merge gates across a long-running session.
Use when an approved PR-sized coding goal needs execution through an owner worker and optional supporting workers in manually managed Git worktrees.
Use when a coding task is not understood well enough to choose an implementation direction, including broad feature requests, unfamiliar code paths, bugs with multiple plausible causes, and work that benefits from parallel read-only exploration before architecture or planning.
| name | write-pr-description |
| description | Use when opening or rewriting a pull request and the reviewer needs a concise, truthful explanation of why the change exists, how it works, which decisions matter, and where to look carefully. |
A reviewer should understand the change in under a minute. Pull intent from the approved PR goal, accepted commits, owner-worker report, and verifier summary. Inspect specific diff details only when needed for an accurate callout. Never fabricate motivation.
Describe impact or behavior. Do not use a branch name, file path, or vague placeholder.
### Why?
<1-3 sentences describing the real problem or motivation>
### How?
<1-2 sentences describing the high-level technical approach>
### Decisions
- <meaningful tradeoff, rejected alternative, or scope choice with its reason>
### Callouts
- <surface where reviewer attention is valuable>
Use N/A when Decisions or Callouts has no meaningful content. Add issue
links on their own lines when relevant.
Follow a stronger repository-specific PR template when one exists.