ワンクリックでManusで任意のスキルを実行

pr

スター1

フォーク0

更新日2026年6月11日 23:16

Commit, push, and open a pull request for the current change. Use when the user says "open a PR", "ship this", "commit and push", or as the PR step of /ship. Handles branch hygiene, commit message quality, and PR description.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

leighstillard

leighstillard/ship-skills

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

PR

Step 1: Pre-flight

git status and git diff — review everything that would be committed. Confirm no secrets, no debug prints, no unrelated files, no .env, no large binaries.
Confirm you are NOT on the default branch. If you are, create a branch: short, kebab-case, scoped (fix-yamaha-diagram-dedupe, not leigh-changes-3).
git pull --rebase origin <default-branch> on the feature branch if it's stale; resolve conflicts before committing more work on top.

Step 2: Commit

Stage deliberately (git add <paths>), not git add -A, unless you have verified every untracked file belongs.
Commit message: imperative summary line ≤72 chars stating what and why, body only if the why isn't obvious from the diff. Follow the repo's existing convention (check git log --oneline -15 — if the repo uses conventional commits, use them).
One logical change per commit where practical. Don't fragment artificially.

Step 3: Push and open PR

git push -u origin <branch>
gh pr create --title "<summary>" --body "<body>"

PR body structure (adapt to any repo PR template — check .github/PULL_REQUEST_TEMPLATE.md first):

What — one or two sentences.
Why — link the issue/ticket (Linear ID if one exists in context).
How verified — paste the evidence from the verify step: commands run, behaviours confirmed. This section is mandatory; "tests pass" alone is insufficient.
Risk / rollback — anything reviewers should watch; how to revert if it goes wrong.
Screenshots if the design-check step produced any.

Step 4: Post-create

Apply labels and reviewers per repo convention if discoverable.
Output the PR URL.

Gotchas

gh must be authenticated; if gh auth status fails, stop and tell the user rather than fiddling with credentials.
Never force-push to a branch with existing review activity without explicit instruction.
If the diff is large (>~400 lines changed), say so and ask whether to split before opening — large PRs rot in review.
Do not amend or rewrite commits that are already pushed unless asked.
If CI config changed in this diff, call it out explicitly in the PR body — reviewers consistently miss it.

このリポジトリの他の Skills

同じリポジトリ

babysit

leighstillard/ship-skills

Shepherd an open PR to merge. Watches CI, fixes failures, addresses review comments, resolves merge conflicts, and enables auto-merge when green. Use after opening a PR, when the user says "babysit", "watch the PR", "get this merged", or as the final step of /ship.

2026-06-111

design-check

leighstillard/ship-skills

Visual and UX review pass for any change that touched UI — frontend components, HTML, CSS, templates, dashboards, CLI output formatting, or anything a human looks at. Use whenever a diff includes UI files, when the user asks for a design review, or as part of /ship. If the diff touched nothing user-visible, state that and exit immediately.

2026-06-111

ship

leighstillard/ship-skills

Take a finished change from local diff to merged PR. Use whenever the user says "ship it", "/ship", "get this merged", or has a completed change ready to go out. Drives the change to a goal state through non-negotiable quality gates.

2026-06-111

verify

leighstillard/ship-skills

Prove a change actually works before it ships. Use whenever a change is "done" and needs validation — after implementing a feature, fixing a bug, or before opening a PR. Also trigger when the user says "verify", "check this works", "is this actually working", or invokes /ship. Tests passing is not sufficient evidence; this skill drives the change end-to-end.

2026-06-111

Step 1: Pre-flight

git status and git diff — review everything that would be committed. Confirm no secrets, no debug prints, no unrelated files, no .env, no large binaries.

Confirm you are NOT on the default branch. If you are, create a branch: short, kebab-case, scoped (fix-yamaha-diagram-dedupe, not leigh-changes-3).

git pull --rebase origin <default-branch> on the feature branch if it's stale; resolve conflicts before committing more work on top.

Step 2: Commit

Stage deliberately (git add <paths>), not git add -A, unless you have verified every untracked file belongs.

Commit message: imperative summary line ≤72 chars stating what and why, body only if the why isn't obvious from the diff. Follow the repo's existing convention (check git log --oneline -15 — if the repo uses conventional commits, use them).

One logical change per commit where practical. Don't fragment artificially.

Step 3: Push and open PR

git push -u origin <branch> gh pr create --title "<summary>" --body "<body>"

PR body structure (adapt to any repo PR template — check .github/PULL_REQUEST_TEMPLATE.md first):

What — one or two sentences.

Why — link the issue/ticket (Linear ID if one exists in context).

How verified — paste the evidence from the verify step: commands run, behaviours confirmed. This section is mandatory; "tests pass" alone is insufficient.

Risk / rollback — anything reviewers should watch; how to revert if it goes wrong.

Screenshots if the design-check step produced any.

Step 4: Post-create

Apply labels and reviewers per repo convention if discoverable.

Output the PR URL.

Gotchas

gh must be authenticated; if gh auth status fails, stop and tell the user rather than fiddling with credentials.

Never force-push to a branch with existing review activity without explicit instruction.

If the diff is large (>~400 lines changed), say so and ask whether to split before opening — large PRs rot in review.

Do not amend or rewrite commits that are already pushed unless asked.

If CI config changed in this diff, call it out explicitly in the PR body — reviewers consistently miss it.

name	pr
description	Commit, push, and open a pull request for the current change. Use when the user says "open a PR", "ship this", "commit and push", or as the PR step of /ship. Handles branch hygiene, commit message quality, and PR description.