メニュー
Write a clear, useful PR description — a tight Why / How / Decisions / Callouts structure that tells a reviewer what changed and why, with no filler. Use whenever you open or rewrite a pull request.
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 | pr-description |
| description | Write a clear, useful PR description — a tight Why / How / Decisions / Callouts structure that tells a reviewer what changed and why, with no filler. Use whenever you open or rewrite a pull request. |
| user-invocable | true |
A good PR description answers three things fast: why does this exist, what did it do, and what should I look at? Use this exact structure, and keep every section short — a reviewer should grasp the change in under a minute.
Meaningful, and about impact — what the change does for the product or system, not how it's implemented. Never a branch name, a file path, or "fix stuff".
1–3 sentences: the actual problem or motivation. Pull it from the real context; don't invent one. If you genuinely don't know why, find out before opening the PR.
1–2 sentences: a short technical summary for a technical reader — the approach, not a file-by-file walkthrough.
One bullet per meaningful tradeoff, abandoned alternative, or scope choice — each with the reason. N/A if there were none.
One bullet per spot a reviewer should look harder at — risky surfaces, things that look innocuous but have knock-on effects, one-way doors. Callouts — N/A if everything is straightforward.
That's it: an honest title, four short sections, and nothing the diff already says.
