pr-description

星标10

分支3

更新时间2026年7月30日 07:21

Use when drafting, writing, or opening a pull request (gh pr create), or asked for a PR title/body/description.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

SevereOverfl0w

SevereOverfl0w/.files

打开 GitHub 仓库查看创作者相关仓库

下载

PR description

Voice

Use the prose-voice skill.

No ticket-number prefix on the title, no trailing period.
No ## Test plan heading and no - [ ] checklists.
No mention of earlier revisions, intermediate versions, or abandoned approaches ("earlier revisions split out…", "previously this used…", "this no longer does X"). Describe the change as it lands against the base branch — the linear history the diff produces — not the path taken to get there. The reader wants the final shape, not the detour.
Length scales with change weight. Trivial → title-only (empty body is fine) or 1–2 sentences. Substantial → ## Summary / ## Why prose, optionally a results table. Headings are fine at size.
Build-on / by-analogy when it fits — link the prior work ("Continuing from…", "Building on…") or point at an existing pattern ("same shape as X").
Body describes the why: How the PR works is answered by the code, not the PR Description.

Hard rule: review before create

Direct gh pr create is blocked by a hook — this flow is the only path.

Draft to a temp file (/tmp/pr-<slug>.md) using the template below.
Open for review via the remote-edit skill (blocking open).
On return, re-read the file. Parse front matter → flags, first content line → title, remainder → body.
Create it: PR_SKILL=1 gh pr create --title <title> --body-file <body> [flags]. The PR_SKILL=1 prefix is what the hook allows through — omit it elsewhere.

Default template

---
# gh pr create fields — leave blank to omit. Title = first line below, body = rest.
base:                 # -B  branch to merge into (default: repo default)
head:                 # -H  branch with the commits (default: current)
reviewer:             # -r  handle(s), comma-separated
assignee:             # -a  login(s), @me for self
label:                # -l  name(s), comma-separated
milestone:            # -m  name
project:              # -p  title
draft: false          # -d  true to open as draft
no-maintainer-edit: false   # --no-maintainer-edit
---
Title goes on this line

Body prose goes here.

Map each non-empty front-matter key to its flag (comma-separated values → repeated flags, e.g. label: a,b → -l a -l b). Booleans emit the bare flag only when true. Title comes from --title (first content line), body from --body-file (the content after the title, written to its own temp file).

同仓库更多 Skills

同仓库

linear-ticket

SevereOverfl0w/.files

Use when drafting, writing, or filing a Linear ticket/issue, or asked for a Linear title/body/description.

2026-07-3010

prose-voice

SevereOverfl0w/.files

Writing voice for authored prose — PR bodies, Linear tickets, review comments, commit messages.

2026-07-3010

remote-edit

SevereOverfl0w/.files

Hand a file to the user's running editor and block until they finish editing it. Use whenever a draft (PR body, ticket, commit message, any generated file) needs the user's review before you act on it, or when a task says "open this in my editor/vim/nvim".

2026-07-3010

clojure-style

SevereOverfl0w/.files

Clojure style guidelines. Activate before writing or editing Clojure code

2026-07-1610

grill-me

SevereOverfl0w/.files

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design.

2026-07-1410

to-issues

SevereOverfl0w/.files

Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.

2026-07-1410

PR description

Voice

Use the prose-voice skill.

No ticket-number prefix on the title, no trailing period.

No ## Test plan heading and no - [ ] checklists.

No mention of earlier revisions, intermediate versions, or abandoned approaches ("earlier revisions split out…", "previously this used…", "this no longer does X"). Describe the change as it lands against the base branch — the linear history the diff produces — not the path taken to get there. The reader wants the final shape, not the detour.

Length scales with change weight. Trivial → title-only (empty body is fine) or 1–2 sentences. Substantial → ## Summary / ## Why prose, optionally a results table. Headings are fine at size.

Build-on / by-analogy when it fits — link the prior work ("Continuing from…", "Building on…") or point at an existing pattern ("same shape as X").

Body describes the why: How the PR works is answered by the code, not the PR Description.

Hard rule: review before create

Direct gh pr create is blocked by a hook — this flow is the only path.

Draft to a temp file (/tmp/pr-<slug>.md) using the template below.

Open for review via the remote-edit skill (blocking open).

On return, re-read the file. Parse front matter → flags, first content line → title, remainder → body.

Create it: PR_SKILL=1 gh pr create --title <title> --body-file <body> [flags]. The PR_SKILL=1 prefix is what the hook allows through — omit it elsewhere.

Default template

--- # gh pr create fields — leave blank to omit. Title = first line below, body = rest. base: # -B branch to merge into (default: repo default) head: # -H branch with the commits (default: current) reviewer: # -r handle(s), comma-separated assignee: # -a login(s), @me for self label: # -l name(s), comma-separated milestone: # -m name project: # -p title draft: false # -d true to open as draft no-maintainer-edit: false # --no-maintainer-edit --- Title goes on this line Body prose goes here.

name	pr-description
description	Use when drafting, writing, or opening a pull request (gh pr create), or asked for a PR title/body/description.