一键在 Manus 中运行任何 Skill

create-pr

星标79

分支31

更新时间2026年5月6日 11:08

Write and publish a PR for the current branch as a draft, in English. Use when the user says "create PR", "open PR", "submit PR", or wants to publish their branch for review.

安装

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

在 Manus 中运行

来源

PopulateTools

PopulateTools/gobierto

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

下载

在 Manus 中运行

Before creating the PR

Run bundle exec i18n-tasks normalize if any locale file changed.
Run bin/rails test on the affected test files.
Run bundle exec rubocop <changed_files> and npm run eslint / npm run stylelint if Ruby or JS/CSS changed.
Re-read @AGENTS.md "Best Practices" sections to make sure the relevant conventions are honored (site scoping, modular layout, service patterns, strong params, tests).

PR content

Use the template at .github/PULL_REQUEST_TEMPLATE.md — fill the existing sections, don't invent new ones.
Title: capitalized, in English, under ~70 characters. Use the body for details.
"What does this PR do?": one short paragraph framed around user-visible outcome (or developer-visible outcome for refactors).
"How should this be manually tested?": concrete steps. If the change has UI, include the path to visit. If the branch has been deployed to staging (check with git branch --contains HEAD staging), include the staging URL — otherwise note that a staging deploy is needed first.
Tick the "Does this PR change any configuration file?" boxes if you added/changed env vars, config/application.yml, or config/secrets.yml — Ansible may need updates.
Tick the "Does this PR require updating the documentation?" boxes if site config, templates, or modules changed.

Publish

gh pr create --draft --base master --title "<title>" --body-file /tmp/pr-body.md

Use --body-file (write the body to /tmp/pr-body.md first) rather than --body "..." — heredocs and backticks get mangled when passed inline.

After creating the PR, surface the URL to the user.

同仓库更多 Skills

同仓库

create-new-topic-branch

PopulateTools/gobierto

Create a new topic branch for a feature or task. Use when starting work on a new feature, bug, or task that needs its own branch — or when the user says "new branch", "topic branch", "start a feature".

2026-05-0679

deploy-to-staging

PopulateTools/gobierto

Deploy the current branch to staging via the project's webhook-based deploy script. Use when the user says "deploy to staging", "push to staging", or wants to test the branch on staging.

2026-05-0679

fixtures

PopulateTools/gobierto

Guide for using test fixtures correctly. Use when writing or modifying tests that reference fixture data, to avoid inventing names and to keep references consistent with files in test/fixtures/.

2026-05-0679

pr-feedback

PopulateTools/gobierto

Full PR feedback workflow: fetch comments, address issues, let the user review, then push. Use when the user says "fix PR comments", "address PR feedback", or invokes /pr-feedback. Also use when the user just wants to see PR comments without fixing anything.

2026-05-0679

refine-issue

PopulateTools/gobierto

Refine or create a GitHub issue with codebase context, a proposed plan, acceptance criteria, and likely files to change. Preserves the original human request verbatim inside a collapsible <details> block. Three modes: CI (auto-publish edit when $GITHUB_ACTIONS is set), interactive-edit (refine an existing issue with preview+confirm), and interactive-create (compose a new issue from a free-form description with preview+confirm). Use when the user says "refine issue #N", "research and plan issue", "create an issue for ...", or when invoked by an automated refine-issue workflow.

2026-05-0679

review-and-reflect

PopulateTools/gobierto

Review and reflect on PR changes before sending for review. Use when implementation is done and the user wants a final check before creating a PR, or says "review changes", "review and reflect", or "is this ready for review".

2026-05-0679

name	create-pr
description	Write and publish a PR for the current branch as a draft, in English. Use when the user says "create PR", "open PR", "submit PR", or wants to publish their branch for review.

Write and publish a PR for the current branch as a draft, in English.

Before creating the PR

Run bundle exec i18n-tasks normalize if any locale file changed.
Run bin/rails test on the affected test files.
Run bundle exec rubocop <changed_files> and npm run eslint / npm run stylelint if Ruby or JS/CSS changed.
Re-read @AGENTS.md "Best Practices" sections to make sure the relevant conventions are honored (site scoping, modular layout, service patterns, strong params, tests).

PR content

Use the template at .github/PULL_REQUEST_TEMPLATE.md — fill the existing sections, don't invent new ones.
Title: capitalized, in English, under ~70 characters. Use the body for details.
"What does this PR do?": one short paragraph framed around user-visible outcome (or developer-visible outcome for refactors).
"How should this be manually tested?": concrete steps. If the change has UI, include the path to visit. If the branch has been deployed to staging (check with git branch --contains HEAD staging), include the staging URL — otherwise note that a staging deploy is needed first.
Tick the "Does this PR change any configuration file?" boxes if you added/changed env vars, config/application.yml, or config/secrets.yml — Ansible may need updates.
Tick the "Does this PR require updating the documentation?" boxes if site config, templates, or modules changed.

Publish

gh pr create --draft --base master --title "<title>" --body-file /tmp/pr-body.md

Use --body-file (write the body to /tmp/pr-body.md first) rather than --body "..." — heredocs and backticks get mangled when passed inline.

After creating the PR, surface the URL to the user.