一键在 Manus 中运行任何 Skill

pr-publish

星标3

分支0

更新时间2026年6月14日 23:11

Publishes finished work as a GitHub pull request: discovers branch state, drafts or refreshes a layered PR description, pushes safely, and creates or updates the PR.

安装

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

在 Manus 中运行

来源

djenriquez

djenriquez/claude-plugins

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

下载

在 Manus 中运行

PR Publish

Publish completed branch work as a PR, or refresh the current branch's existing PR. Treat $ARGUMENTS as extra drafting context such as linked issues, incident notes, or validation evidence.

Load references/github-pr-workflow.md before making branch or PR decisions. Load references/pr-description-style.md when drafting the body.

Core Rules

Do not publish with modified or staged tracked files; ask what belongs in the PR.
Never force-push.
If the local and remote branch diverged, stop and ask.
Do not auto-commit tracked changes.
If the current branch is the default branch and the only changes are untracked files, you may create a feature branch, stage those explicit new paths, and commit them with an inferred conventional commit message.
Describe the merged end state relative to the base branch, never the path taken to build it. Re-read each sentence as a reviewer who has only seen the base branch and the diff, and cut anything that presupposes the branch's commit history (see references/pr-description-style.md).
Print the final title and body before publishing so the transcript records what was sent.

Workflow

Discover state in parallel:
- git status --short --branch
- current branch and default branch
- commits and diff from the merge base
- current branch PR via gh pr view --json number,body,title,state,baseRefName,headRefName,url
Stop for the safety cases in references/github-pr-workflow.md.
Gather only framing context that materially changes the PR body:
- linked issue or incident references from commits, branch name, PR body, or $ARGUMENTS
- reproduction, logs, dashboards, or validation evidence for bug fixes
- affected users, services, or operators when not obvious from the diff
Draft a conventional-commit title under 70 characters.
Draft the body using references/pr-description-style.md, then re-read each sentence against the base-branch frame and rewrite any journey-relative phrasing before printing.
Push the branch normally if it is not already on origin.
Create or update the PR:
- no existing PR: gh pr create --title "<title>" --body "<body>"
- existing open PR: update the body; update the title only if it is generated, non-conventional, or over 70 characters
Print the PR URL.

Output

End with:

PR published: <url>
Title: <title>

If stopped for safety, report the exact condition and the next safe command or decision needed from the user.

同仓库更多 Skills

同仓库

full-dev-flow

djenriquez/claude-plugins

Runs the complete development workflow from session context to reviewed pull request: write a spec, run spec-review and revise the spec, create bits tasks, drain the bits implementation queue, commit, publish a PR, run self-review-loop, and post /assisted-review-heavy. Use when the user asks for the full dev flow, spec-to-PR workflow, plan/build/publish workflow, or wants an agent to carry a discussed feature through spec, implementation, PR publication, and automated review.

2026-07-093

interview

djenriquez/claude-plugins

Interview users to turn an issue, rough plan, or implementation idea into spec-ready decisions. Use when the user asks to interview/probe/question a plan, when issue-to-spec needs design clarification, or before writing a spec that depends on product, technical, rollout, or scope decisions.

2026-07-093

issue-to-spec

djenriquez/claude-plugins

Orchestrates the full investigation-to-spec workflow starting from a GitHub issue. Phase 1: explore the issue and codebase to build context. Phase 2: interview the user from a problem-solving perspective. Phase 3: author a spec and publish it to docs/specs/. Phase 4: assess complexity and conditionally launch the spec-review skill. Phase 5: harden the spec with review feedback.

2026-07-093

spec-review

djenriquez/claude-plugins

Reviews a spec with risk-scaled specialist agents, deduplicates findings, and returns a binary APPROVED / REVISIONS NEEDED verdict.

2026-07-093

write-spec

djenriquez/claude-plugins

Authors a human-first design spec: a plain-language narrative reviewers can absorb in minutes, backed by an implementation appendix with the exhaustive detail agents need. Use when the user asks to write a spec or design doc from a discussion or investigation, or to rewrite an existing spec that is too verbose for human review.

2026-07-093

code-review

djenriquez/claude-plugins

Runs a lean, risk-scaled code review: one generalist pass first, specialists only when triggered by evidence, and external debate only for high-risk escalation.

2026-06-113

name	pr-publish
description	Publishes finished work as a GitHub pull request: discovers branch state, drafts or refreshes a layered PR description, pushes safely, and creates or updates the PR.
argument-hint	(optional) freeform notes, linked issue, or observability evidence to incorporate
disable-model-invocation	false
allowed-tools	["Bash(git:)","Bash(gh:)","Read","Glob","Grep","AskUserQuestion"]

PR Publish

Publish completed branch work as a PR, or refresh the current branch's existing PR. Treat $ARGUMENTS as extra drafting context such as linked issues, incident notes, or validation evidence.

Load references/github-pr-workflow.md before making branch or PR decisions. Load references/pr-description-style.md when drafting the body.

Core Rules

Do not publish with modified or staged tracked files; ask what belongs in the PR.
Never force-push.
If the local and remote branch diverged, stop and ask.
Do not auto-commit tracked changes.
If the current branch is the default branch and the only changes are untracked files, you may create a feature branch, stage those explicit new paths, and commit them with an inferred conventional commit message.
Describe the merged end state relative to the base branch, never the path taken to build it. Re-read each sentence as a reviewer who has only seen the base branch and the diff, and cut anything that presupposes the branch's commit history (see references/pr-description-style.md).
Print the final title and body before publishing so the transcript records what was sent.

Workflow

Discover state in parallel:
- git status --short --branch
- current branch and default branch
- commits and diff from the merge base
- current branch PR via gh pr view --json number,body,title,state,baseRefName,headRefName,url
Stop for the safety cases in references/github-pr-workflow.md.
Gather only framing context that materially changes the PR body:
- linked issue or incident references from commits, branch name, PR body, or $ARGUMENTS
- reproduction, logs, dashboards, or validation evidence for bug fixes
- affected users, services, or operators when not obvious from the diff
Draft a conventional-commit title under 70 characters.
Draft the body using references/pr-description-style.md, then re-read each sentence against the base-branch frame and rewrite any journey-relative phrasing before printing.
Push the branch normally if it is not already on origin.
Create or update the PR:
- no existing PR: gh pr create --title "<title>" --body "<body>"
- existing open PR: update the body; update the title only if it is generated, non-conventional, or over 70 characters
Print the PR URL.

Output

End with:

PR published: <url>
Title: <title>

If stopped for safety, report the exact condition and the next safe command or decision needed from the user.