본문으로 건너뛰기
cccskills
무료GitHub에 공개

pr

Open or update one GitHub pull request for the current work: a conventional-commits title and a description that always includes why and benefits, and never a second PR for the same head. Use when the user asks to open a PR, create a pull request, update or refresh the PR description, ship the branch, or "make a PR". On the default branch, create a new branch first. If this head already has a PR, edit it — do not create another. Do not open a PR unless the user asked.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

연동 도구GitHub
설치 방법 보기

포함된 파일(2)

  • SKILL.md5.9 KB
  • references/description.md4.1 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Open / update a pull request

This folder is the whole skill — enough to open a PR in any repo. Do not require the repo's AGENTS.md to operate. If you already know repo extras (ticket-as-scope, extra body sections, branch pattern, a PR template), apply them on top of this skill — never instead of Why and Benefits.

Read references/description.md before writing title or body.

Drive GitHub through the local authenticated gh CLI. Prefix gh with GH_PAGER=cat. Never merge. Never force-push unless the user asked. Always end the reply with the PR URL on its own last line.

When to open (and when not to)

Only run this skill when the user asked to open, create, update, or refresh a PR.

SituationAction
User did not ask to open or update a PRDo nothing. Do not create "while you're here".
Default branch, clean tree, no unique commitsStop. Do not open an empty PR.
Default branch, has work to shipAlways create a new branch first (step 1). Never commit or push on the default branch.
Feature branch, unique commits, no PR for this headPush (if needed) and create one PR (step 3).
Feature branch, a PR already exists for this headUpdate that PR (step 4). Never gh pr create.
gh pr view / list shows a PR whose headRefName ≠ current branchStop. Do not edit the wrong PR.
Work is unfinished / user said WIPOpen or convert to draft. Title may use a [WIP] prefix.
Diff contains secrets, credentials, or .env filesStop and tell the user. Do not open.
Two unrelated problems on the same branchFlag the mixed scope. Do not silently describe them as one change. Do not split the branch unless asked.

One head → one PR. Updating means rewriting title and body for the whole branch, not appending "also…".

0. Context (always, in parallel)

git status -sb
git branch --show-current
git log --oneline -8
git diff && git diff --cached
git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null || true
GH_PAGER=cat gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
command -v gh && GH_PAGER=cat gh auth status

Default branch: the gh value, else main, else master.

If gh is missing or unauthenticated: still author title + body to a temp file, then give the user the exact git push and gh pr create --body-file commands. Do not invent a web-API fallback.

Decide:

  • type: feat | fix | docs | chore | refactor | perf | test | build | ci (or another Conventional Commits type that fits). Use ! for a breaking change.
  • scope: a ticket id if the user, branch, or commits have one (ABC-123); otherwise the area the diff belongs to. Omit (scope) when none is honest.
  • summary: short imperative phrase (the what, not the why).

Title, under 72 characters:

<type>(<scope>): <imperative summary>

If the branch already has a conventional subject that still describes the whole branch, reuse it. Do not title the PR after the last commit alone.

1. Branch

On the default branch

Create a new branch before any commit, push, or gh pr:

git checkout -b <type>/<scope>-<slug>

If the repo documents a branch pattern, use that instead. <slug> is 2–4 lowercase words from the change. Uncommitted work comes along.

If the work is not yet committed and the user asked for a PR, commit it on the new branch (conventional subject; body = why). Commit only files that belong to this change; ask if the dirty tree is mixed.

Already on a feature branch

Stay on it. Do not fork another branch. Do not create a second PR.

2. Existing PR?

GH_PAGER=cat gh pr list --head "$(git branch --show-current)" --json number,title,url,body,headRefName
  • Empty → create (step 3).
  • One row, headRefName matches current branch → update (step 4).
  • Anything else → stop.

3. Create (no PR yet)

git push -u origin HEAD

Draft the body from references/description.md. Write it to a temp markdown file (avoids shell escaping). If .github/PULL_REQUEST_TEMPLATE* (or docs/pull_request_template.md) exists, fill that structure and still include Why and Benefits.

GH_PAGER=cat gh pr create --base "<default-branch>" --head "$(git branch --show-current)" \
  --title "<type>(<scope>): <imperative summary>" \
  --body-file <tmp.md>

Add --draft when the work is unfinished. Delete the temp file after. If a hook or CI gate blocks create, fix the reported failure and retry. Do not skip hooks.

4. Update (PR already exists)

Re-read git log <default-branch>...HEAD and the full diff since the branch diverged — not just the latest commit. If the branch has unpushed commits, git push first (no --force unless asked). Rewrite title and body so they describe the branch as it is now.

GH_PAGER=cat gh pr edit <number> --title "<conventional title>" --body-file <tmp.md>

Only pass --title when the current title is wrong. Do not append "also updated…". Replace the description.

5. Report

Say whether the PR was created or updated, plus one line on what changed. Wait for review. Do not merge, do not request reviewers, do not comment, unless the user asked.

Always end the reply with the PR URL on its own last line. No extra sentence after it.

GH_PAGER=cat gh pr view --json url --jq '.url'

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

ci

무료

Read GitHub Actions CI for the current branch or open PR, triage failing checks, reproduce locally, and fix scoped issues until green. Use whenever the user mentions CI failures, red checks, failed pipeline, GitHub Actions, merge blocked, fix the build, babysit CI, gh run failed, ruff/ty errors, failing pytest, example run failed, or asks to check CI on this branch — even if they only paste a log snippet. Also use after implementing a feature when tests, lint, or typecheck might have broken.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

wandelbotsgmbh/wandelbots-nova462026년 10월 16일 업데이트

Authoritative reference for working with the released Wandelbots NOVA API v2 in the wandelbots-nova Python SDK. Use whenever a task touches the NOVA API, the generated `wandelbots_api_client` models (`nova.api.models.*`), motion planning requests (`plan_trajectory`, `MotionGroupSetup`, `LimitSet`, `LimitsOverride`), robot limits, or torque/velocity/acceleration/jerk limits. Reach for this skill before guessing field names or assuming a field exists — the installed client reflects the RELEASED API, while nightly specs may contain unreleased fields. Especially relevant for controller-reported limits (e.g. KUKA torque) and any "does field X exist / how is it forwarded to the planner?" question.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

wandelbotsgmbh/wandelbots-nova462026년 10월 16일 업데이트

wandelbotsgmbh의 스킬 모두 보기

이 스킬의 문제 신고