ワンクリックで
ship
변경사항 커밋/푸시 워크플로우 자동화. 이슈 생성, 브랜치 생성, 원자적 커밋, 검증, push, PR 생성 후 CI 폴링/실패 복구까지 한 번에 진행해 달라는 명시적 요청에서 사용한다.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
변경사항 커밋/푸시 워크플로우 자동화. 이슈 생성, 브랜치 생성, 원자적 커밋, 검증, push, PR 생성 후 CI 폴링/실패 복구까지 한 번에 진행해 달라는 명시적 요청에서 사용한다.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | ship |
| description | 변경사항 커밋/푸시 워크플로우 자동화. 이슈 생성, 브랜치 생성, 원자적 커밋, 검증, push, PR 생성 후 CI 폴링/실패 복구까지 한 번에 진행해 달라는 명시적 요청에서 사용한다. |
현재 변경사항을 분석하여 이슈 생성 → 브랜치 생성 → 원자적 커밋 → CI → 푸시 → PR → CI 폴링/실패 복구까지 자동화합니다.
ship - 변경사항 분석 후 새 이슈 생성하여 진행ship {문서경로} - 지정된 계획 문서를 참조하여 진행 (이슈 번호 추출)| 항목 | 참조 문서 |
|---|---|
| 이슈 템플릿 | @.github/ISSUE_TEMPLATE/feature.md |
| 브랜치 네이밍 | @docs/conventions/BRANCH_STRATEGY.md |
| 커밋 메시지 | @docs/conventions/COMMIT_CONVENTION.md |
| PR 작성 | @docs/conventions/PR_CONVENTION.md |
git status --porcelain
git diff --name-only
ship {문서경로} 시:
ship 시:
@.github/ISSUE_TEMPLATE/feature.md 템플릿 따라 생성
@docs/conventions/BRANCH_STRATEGY.md 규칙 따라 생성
git-master스킬을 호출해 COMMIT 절차를 수행한다. 변경사항을 논리적 단위로 분리하고 원자적 커밋을 생성한다. 프로젝트에 @docs/conventions/COMMIT_CONVENTION.md 가 있으면 해당 규칙을 따른다.
중요:
docs/plan/디렉토리에 현재 작업 중인 이슈 관련 문서가 있는지 확인
# 이슈 번호로 관련 문서 검색
ls docs/plan/ | grep -i "ISSUE_{이슈번호}"
문서가 존재하면:
docs: 이슈 #{번호} 계획 문서중요: 아래 체크리스트를 순서대로 실행하고, 각 단계 완료 후 다음으로 진행
- 프로젝트 컨벤션에 정의된 자동화 절차가 있으면 그 절차를 우선 적용할 것
- 스킬이 있는 항목은 해당 스킬을 사용해 검증할 것
체크리스트 (순서대로 실행 필수):
backend/frontend/database/ui/ux 및 관련 라이브러리/프레임워크로 분류하고, 해당 도메인과 매칭되는 스킬이 있으면 모두 검토/리뷰 실행
vercel-react-best-practices, web-design-guidelines, nestjs, sqlite, tanstack-query, github-graphqlgh issue edit)리뷰 실행 결과 기록(필수):
git push -u origin {브랜치명}
@docs/conventions/PR_CONVENTION.md 템플릿 따라 PR 생성
gh pr create --repo boostcampwm2025/web19-estrogenquattro \
--title "{타입}: {설명}" \
--body "..."
핵심: 8단계에서 생성한 PR의 GitHub Actions CI run만 모두 통과할 때까지 계속 폴링한다. CodeRabbit/Copilot 등 외부 리뷰 체크는 대기 대상에서 제외한다. 실패가 발생하면 즉시 분석하고 수정 커밋을 반영한 뒤 다시 폴링한다.
PR 식별자 확보
PR_NUMBER="{8단계에서 생성한 PR 번호}"
POLL_INTERVAL_SEC=60
상태 폴링 (60초 간격 반복)
HEAD_BRANCH=$(gh pr view "$PR_NUMBER" --json headRefName --jq .headRefName)
HEAD_SHA=$(gh pr view "$PR_NUMBER" --json commits --jq '.commits[-1].oid')
gh run list --limit 100 --json databaseId,headBranch,headSha,event,status,conclusion,name,url,createdAt --jq \
".[] |
select(.headBranch == \"$HEAD_BRANCH\" and .headSha == \"$HEAD_SHA\" and .event == \"pull_request\") |
[.name, (.conclusion // .status // \"PENDING\"), .url] |
@tsv"
상태 판정 규칙
PENDING/IN_PROGRESS/QUEUED/WAITING이 하나라도 있으면 sleep "$POLL_INTERVAL_SEC" 후 재조회SUCCESS만 남으면 종료FAILURE/ERROR/CANCELLED/TIMED_OUT이 하나라도 있으면 아래 실패 복구 절차 수행실패 복구 절차
HEAD_BRANCH=$(gh pr view "$PR_NUMBER" --json headRefName --jq .headRefName)
HEAD_SHA=$(gh pr view "$PR_NUMBER" --json commits --jq '.commits[-1].oid')
gh run list --limit 50 --json databaseId,headBranch,headSha,event,status,conclusion,name,url,createdAt --jq \
".[] | select(.headBranch == \"$HEAD_BRANCH\" and .headSha == \"$HEAD_SHA\" and .event == \"pull_request\") | [.databaseId, .name, .status, .conclusion, .url] | @tsv"
gh run view {RUN_ID} --log-failed
debug-loop 스킬과 도메인 스킬을 사용해 원인 재현/분석 후 수정 반영예외 처리
아래 항목을 함께 요약 출력한다.
GitHub PR URL을 인자로 받아 merge conflict(병합 충돌) 유무를 판정하고, 충돌이 없으면 즉시 종료한다. 충돌이 있으면 충돌 파일/원인 커밋을 추적해 어떤 PR/브랜치에서 유입된 변경인지 식별한 뒤, 양쪽 PR/이슈의 plans(또는 docs/plan) 문서를 찾아 의도한 구현을 모두 보존하는 형태로 충돌을 해결하고 commit+push 해서 PR이 다시 mergeable 해질 때까지 확인한다. PR 병합 충돌 해결을 요청받으면 사용한다.
GitHub PR URL을 인자로 받아 현재 브랜치가 PR의 head branch와 일치하는지 검증한 뒤, GitHub Actions CI 실패 원인을 분석/수정하고 commit+push 후 CI 성공을 폴링으로 확인하는 복구 루프를 수행한다. CodeRabbit/Copilot 같은 코드리뷰 체크는 제외하고 GitHub Actions run만 대상으로 한다. PR CI 실패 복구를 요청받으면 사용한다.
버그 상황과 로그를 받아 재현을 최우선으로 수행하고, git 변경/프로젝트 문서 기반 원인 가설을 반복 검증해 해결한다. 방향 변경이 필요하면 사용자 승인 후 진행한다.
구현 계획 문서를 6가지 관점으로 순차 리뷰하고, 수동 텍스트 승인 루프로 의견/승인을 받아 즉시 반영한 뒤 반복 루프를 수행한다.
GitHub 이슈 URL을 인자로 받아 이슈 정보를 확인하고 git worktree 기반 작업 브랜치를 생성한 뒤 이슈 계획 문서를 만든다. 이슈 URL 기준으로 브랜치/worktree/계획 문서 초기화를 요청할 때 사용한다.
Analyze current branch changes against a base branch, identify documentation that should be updated, and directly edit those docs. Use when asked to sync docs with branch changes before merge, release, or PR review.