메뉴
End-to-end PR lifecycle: create PR, wait for CI, review, fix issues, merge - all in one invocation. Use when: (1) User says "/pr-ship", (2) User wants to ship current changes as a complete PR lifecycle, (3) User wants to resume shepherding an existing PR.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | pr-ship |
| description | End-to-end PR lifecycle: create PR, wait for CI, review, fix issues, merge - all in one invocation. Use when: (1) User says "/pr-ship", (2) User wants to ship current changes as a complete PR lifecycle, (3) User wants to resume shepherding an existing PR. |
End-to-end PR lifecycle shepherd: create PR → wait for CI → review → fix → merge. Single invocation, single PR.
Announce at start: "Using pr-ship skill to shepherd this PR from creation to merge."
/pr-ship [pr_number] [--no-auto-merge]
| Parameter | Default | Description |
|---|---|---|
pr_number | none | Resume from an existing PR (skip creation) |
--no-auto-merge | off | Require user confirmation before merge instead of auto-merge |
Track these values in conversation context throughout the session:
PR_NUMBER - current PR numberPHASE - current phase (create / ci-wait / review / fix / merge)RETRY_COUNT - CI failure + review fix retry counter (max 3, shared), initialized to 0AUTO_MERGE - true unless --no-auto-merge is passedEMPTY_CI_COUNT - consecutive empty CI check counter (max 3), initialized to 0Skip if pr_number is provided. When skipping, set PR_NUMBER from the argument and jump to Phase 1.
Parse arguments:
# Detect --no-auto-merge flag
AUTO_MERGE=true
if echo "$ARGUMENTS" | grep -q -- '--no-auto-merge'; then
AUTO_MERGE=false
fi
# Detect pr_number (first numeric argument)
PR_NUMBER=$(echo "$ARGUMENTS" | grep -oE '[0-9]+' | head -1)
If PR_NUMBER is set: set RETRY_COUNT = 0, EMPTY_CI_COUNT = 0, skip to Phase 1.
If PR_NUMBER is not set: invoke oss-pr to create the PR:
/oss-pr
After oss-pr completes, extract PR_NUMBER from the PR URL in its output. Set RETRY_COUNT = 0, EMPTY_CI_COUNT = 0.
Check CI status:
gh pr view $PR_NUMBER --json statusCheckRollup \
--jq '.statusCheckRollup[] | {name: .name, status: .status, conclusion: .conclusion}'
Required jobs (same list as pr-review):
Code QualityUnit Tests (ubuntu-latest)Unit Tests (macos-14)Unit Tests (windows-2022)Coverage Testi18n-checkInformational exclusions: codecov/patch and codecov/project - always excluded from failure checks.
| CI Status | Action |
|---|---|
| All required jobs SUCCESS, no non-informational failures | → Phase 2 |
| Any required job QUEUED or IN_PROGRESS | ScheduleWakeup 270s, re-check |
statusCheckRollup empty (CI never triggered) | Approve workflow (see below), ScheduleWakeup 270s |
| Any non-informational job FAILURE or CANCELLED | → CI Failure Handler |
HEAD_SHA=$(gh pr view $PR_NUMBER --json headRefOid --jq '.headRefOid')
REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')
RUN_IDS=$(gh api "repos/$REPO/actions/runs?head_sha=$HEAD_SHA&status=action_required" \
--jq '.workflow_runs[].id')
for RUN_ID in $RUN_IDS; do
gh run approve "$RUN_ID" --repo "$REPO"
done
Then EMPTY_CI_COUNT++ and ScheduleWakeup 270s to re-check. If EMPTY_CI_COUNT >= 3 (~13.5 minutes), abort:
CI has not triggered after ~13.5 minutes of waiting. Check the repository CI configuration, then re-invoke
/pr-ship $PR_NUMBER.
Step 1 - Check retry budget:
If RETRY_COUNT >= 3:
Maximum retry count reached (3/3). Manually inspect PR #$PR_NUMBER, then re-invoke
/pr-ship $PR_NUMBER.
Exit.
Step 2 - Identify failures:
# Get failed job names
FAILED_JOBS=$(gh pr view $PR_NUMBER --json statusCheckRollup \
--jq '[.statusCheckRollup[] | select(.conclusion == "FAILURE" or .conclusion == "CANCELLED") | select(.name | test("^codecov/") | not) | .name] | join(", ")')
Report to user:
CI failed: $FAILED_JOBS. Attempting fix ($RETRY_COUNT/3)...
Step 3 - Fetch failure details:
REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')
# Find the failed run IDs
HEAD_SHA=$(gh pr view $PR_NUMBER --json headRefOid --jq '.headRefOid')
FAILED_RUN_IDS=$(gh api "repos/$REPO/actions/runs?head_sha=$HEAD_SHA&status=failure" \
--jq '.workflow_runs[].id')
# Get logs for each failed run
for RUN_ID in $FAILED_RUN_IDS; do
gh run view "$RUN_ID" --repo "$REPO" --log-failed 2>/dev/null | tail -100
done
Step 4 - Fix in worktree:
REPO_ROOT=$(git rev-parse --show-toplevel)
WORKTREE_DIR="/tmp/wayland-ship-${PR_NUMBER}"
HEAD_BRANCH=$(gh pr view $PR_NUMBER --json headRefName --jq '.headRefName')
# Clean up stale worktree
git worktree remove "$WORKTREE_DIR" --force 2>/dev/null || true
# Create worktree
git fetch origin "$HEAD_BRANCH"
git worktree add "$WORKTREE_DIR" "origin/$HEAD_BRANCH" --detach
# Symlink node_modules
ln -s "$REPO_ROOT/node_modules" "$WORKTREE_DIR/node_modules"
Fix only CI-reported errors (lint errors, type errors, test failures) in the worktree. No refactoring, no scope expansion.
After fixing, run local quality gate:
cd "$WORKTREE_DIR"
bun run lint:fix
bun run format
bunx tsc --noEmit
bun run test
Step 5 - Commit and push:
cd "$WORKTREE_DIR"
git add -u
git commit -m "fix(<scope>): resolve CI failures"
git push origin HEAD:$HEAD_BRANCH
No AI signature in commits.
Step 6 - Cleanup worktree:
cd "$REPO_ROOT"
git worktree remove "$WORKTREE_DIR" --force 2>/dev/null || true
Step 7 - Increment and loop:
RETRY_COUNT++. ScheduleWakeup 270s → re-enter Phase 1.
Invoke pr-review in interactive mode, passing the PR number explicitly:
/pr-review $PR_NUMBER
(No --automation flag - this is an interactive session.)
| Review Conclusion | Action |
|---|---|
| ✅ APPROVED (including LOW-only) | → Phase 4 |
| ⚠️ CONDITIONAL | → Phase 3 |
| ❌ REJECTED | → Phase 3 (pr-fix triage decides if auto-fixable) |
Check retry budget first:
If RETRY_COUNT >= 3:
Maximum retry count reached (3/3). Manually inspect PR #$PR_NUMBER, then re-invoke
/pr-ship $PR_NUMBER.
Exit.
Invoke pr-fix in interactive mode, passing the PR number explicitly:
/pr-fix $PR_NUMBER
(No --automation flag.)
Fix pushed successfully: RETRY_COUNT++. ScheduleWakeup 270s → back to Phase 1 (wait for CI on new commit).
Fix aborted (all issues dismissed, or user rejected CRITICAL dismissal):
pr-fix produced no fixes. Continue shepherding this PR? (yes/no)
gh pr merge $PR_NUMBER --squash --auto
Output:
✅ PR #$PR_NUMBER has been set to auto-merge and will merge automatically once CI passes.
Display summary:
=== PR #$PR_NUMBER Ready ===
Title: <title>
Changes: +<additions> / -<deletions> (<file_count> files)
Review: <conclusion>
CI: All passing
Type merge to confirm merge, or abort to cancel.
Fetch summary data:
gh pr view $PR_NUMBER --json title,additions,deletions,changedFiles \
--jq '{title: .title, additions: .additions, deletions: .deletions, files: .changedFiles}'
gh pr merge $PR_NUMBER --squash → output ✅ PR #$PR_NUMBER merged.This skill uses /loop dynamic mode for CI waiting. Each ScheduleWakeup call:
ScheduleWakeup(
delaySeconds: 270,
reason: "waiting for CI on PR #$PR_NUMBER (check N)",
prompt: "/pr-ship $PR_NUMBER"
)
Interval: 270s uniformly (under 5-min prompt cache TTL).
When to call ScheduleWakeup:
When NOT to call ScheduleWakeup:
Co-Authored-By, no Generated with in any commit or commentbot:* labelsgh repo view --json nameWithOwner --jq '.nameWithOwner'/tmp/wayland-ship-<PR_NUMBER> (distinct from pr-automation's /tmp/wayland-pr-* and pr-verify's /tmp/wayland-verify-*)0. Parse args: pr_number? --no-auto-merge?
1. Phase 0: /oss-pr (skip if pr_number given)
2. Phase 1: CI wait loop
- check statusCheckRollup
- passing -> Phase 2
- running -> ScheduleWakeup 270s
- not triggered -> approve workflow + ScheduleWakeup 270s
- failed -> retry_count < 3? fix + push + ScheduleWakeup 270s : abort
3. Phase 2: /pr-review (interactive)
- APPROVED -> Phase 4
- CONDITIONAL/REJECTED -> Phase 3
4. Phase 3: /pr-fix (interactive)
- pushed -> retry_count++, back to Phase 1
- aborted -> ask user
5. Phase 4: merge
- default: gh pr merge --squash --auto
- --no-auto-merge: confirm then gh pr merge --squash
Wayland's own how-to guide: explains what Wayland can do and gives the exact steps to operate it. Covers what can Wayland do, connecting an AI provider or model, creating an assistant, building and launching a workflow, setting up a team, scheduling a task, connecting an MCP server or outside tool, and switching models or using Flux Auto. Use when the user asks what Wayland can do, what features exist, how do I connect a provider or model, how do I add Claude or OpenAI or Gemini, how do I create or edit an assistant, how do I build or run a workflow, how do I set up a team of assistants, how do I schedule a task or set up a recurring job, how do I connect an MCP server or outside tool, or how do I switch models or turn on Flux Auto automatic model routing. Do NOT use when the user wants help with a non-Wayland task (writing, coding, research, document creation) — those have their own skills; this skill is only about operating Wayland itself.
Security operations center expertise covering SIEM query writing, alert triage workflows, incident investigation procedures, IOC analysis, threat hunting techniques, playbook design, log analysis patterns, Splunk and Elastic SIEM queries, alert fatigue reduction, escalation procedures, and shift handoff practices. Use when the user asks about soc analyst, soc analyst best practices, or needs guidance on soc analyst implementation. Do NOT use when the user needs a different specialized skill or is asking about an unrelated technology domain.
Orchestrates the process of deploying a software application to production, from CI pipeline verification through monitoring confirmation, chaining six software-development skills into a structured release workflow. Use when the user needs to deploy an application to production with a repeatable, safe process that includes database migration, monitoring, and rollback planning. Do NOT use for local development setup, staging-only deployments, or infrastructure provisioning without application deployment.
End-to-end workflow for building a complete DevOps pipeline from an empty repository through CI/CD, infrastructure as code, monitoring, alerting, and incident response. Covers the full lifecycle from first commit to production-grade operations. Use when the user wants to devops pipeline from scratch or needs a structured multi-step process for this goal. Do NOT use when the request is a single-step task or requires professional advice beyond educational guidance.
Orchestrates end-to-end production incident management from detection through resolution and retrospective, chaining five skills into a complete incident lifecycle pipeline. Covers triage, log investigation, monitoring verification, documentation, and team retrospective. Use when handling a production incident that affects users and requires coordinated response, investigation, resolution, and follow-up. Do NOT use for non-production issues, minor bugs that do not affect users, or planned maintenance activities.
Orchestrates the full incident lifecycle from initial triage through postmortem documentation, chaining five software-development skills into a structured incident management workflow. This workflow chains the incident-response skill with logging, monitoring, deployment, and documentation skills. Use when the user is handling an active production incident and needs a structured process from detection through resolution and postmortem. Do NOT use for non-production issues, planned maintenance, or post-incident analysis only (use technical-documentation directly for standalone postmortems).