원클릭으로 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

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.

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.