You are running the `/ship` workflow. This is **non-interactive, fully automated**. Do NOT ask for confirmation at any step. The user said `/ship` which means DO IT. Run straight through and output the PR URL at the end. **Only stop for:** - On the base branch (abort) - Merge conflicts that can't be auto-resolved - Test failures - Pre-landing review finds ASK items needing user judgment - MINOR or MAJOR version bump needed **Never stop for:** - Uncommitted changes (always include them) - PATC...
Install via CLI
openskills install Kit4Some/Oh-my-ClaudeClaw<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly. Run: node scripts/gen-skill-docs.mjs -->
---
name: ship
description: >
Automated release workflow with comprehensive quality gates. Triggers on "배포",
"릴리스", "ship it", "PR 만들어", "release", "deploy", "create PR", "push this",
"ship". Non-interactive: user says /ship, next thing they see is the PR URL.
Delegates commit organization to OMC git-master, review to code-reviewer,
verification to verifier. Sends PR notification via messenger.
allowed-tools:
- Bash
- Read
- Write
- Edit
- Grep
- Glob
- Agent
- AskUserQuestion
---
# Ship — Fully Automated Release Workflow
You are running the `/ship` workflow. This is **non-interactive, fully automated**.
Do NOT ask for confirmation at any step. The user said `/ship` which means DO IT.
Run straight through and output the PR URL at the end.
**Only stop for:**
- On the base branch (abort)
- Merge conflicts that can't be auto-resolved
- Test failures
- Pre-landing review finds ASK items needing user judgment
- MINOR or MAJOR version bump needed
**Never stop for:**
- Uncommitted changes (always include them)
- PATCH/MICRO version bump (auto-pick)
- CHANGELOG content (auto-generate from diff)
- Commit message approval (auto-commit)
## Preamble
Before executing this skill:
1. **Load context from memory**:
```
memory_search(query: "{skill-relevant-query}", associative: true, limit: 5)
memory_search(tag: "{skill-name}", limit: 3)
```
Review returned memories for relevant past context, decisions, and patterns.
2. **Check OMC state for active work**:
```
state_get_status()
```
If conflicting active tasks exist, warn the user before proceeding.
3. **Detect current branch** (for git-related skills):
```bash
git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "not-a-git-repo"
```
4. **Check proactive mode**:
```
state_read("occ-proactive")
```
If `"false"`: do NOT proactively suggest other OpenClaw-CC skills during this session.
Only run skills the user explicitly invokes.
5. **Log skill activation**:
```
memory_daily_log(type: "note", entry: "Skill activated: /{skill-name}")
```
## Memory Context Loading
Before starting work, load relevant context from the 3-layer memory system:
```
# Search for related past work
memory_search(query: "{task description}", associative: true, limit: 5)
# Search by relevant tags
memory_search(tag: "{relevant-tag}", limit: 3)
# Check for recent related daily logs
memory_search_date(start: "{7 days ago}", end: "{today}", category: "daily-logs", limit: 5)
```
**Use retrieved context to**:
- Avoid repeating past mistakes
- Build on previous decisions
- Maintain consistency with established patterns
- Reference related knowledge graph nodes
If critical related memories exist, summarize them before proceeding:
```
Found {N} related memories:
- {memory_1 title}: {brief relevance}
- {memory_2 title}: {brief relevance}
```
---
## Step 0 — Base Branch Detection
## Base Branch Detection
Detect the correct base branch for diff and PR operations:
```bash
# Method 1: Check if there's an existing PR for this branch
BASE=$(gh pr view --json baseRefName -q .baseRefName 2>/dev/null)
# Method 2: Check repo default branch
if [ -z "$BASE" ]; then
BASE=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name 2>/dev/null)
fi
# Method 3: Fallback to common defaults
if [ -z "$BASE" ]; then
if git show-ref --verify --quiet refs/heads/main 2>/dev/null; then
BASE="main"
elif git show-ref --verify --quiet refs/heads/master 2>/dev/null; then
BASE="master"
else
BASE="main"
fi
fi
echo "Base branch: $BASE"
```
Use `$BASE` for all subsequent operations:
- `git diff origin/$BASE...HEAD` — Changes on this branch
- `git log origin/$BASE..HEAD` — Commits on this branch
- `gh pr create --base $BASE` — PR targeting correct branch
---
## Step 1 — Pre-flight Checks
1. Check current branch. If on base branch, **abort**: "You're on the base branch. Run /ship from a feature branch."
2. Run `git status` (never use `-uall`). Uncommitted changes are always included.
3. Run `git diff $BASE...HEAD --stat` and `git log $BASE..HEAD --oneline` to understand what's being shipped.
---
## Step 2 — Merge Base Branch (BEFORE tests)
Fetch and merge the base branch so tests run against the merged state:
```bash
git fetch origin $BASE && git merge origin/$BASE --no-edit
```
If merge conflicts: try auto-resolve simple ones. If complex, **STOP** and show them.
If already up to date: continue silently.
---
## Step 2.5 — Test Framework Bootstrap
## Test Framework Detection & Bootstrap
Detect the project's test framework automatically:
```bash
# Check package.json for test command
TEST_CMD=""
if [ -f "package.json" ]; then
TEST_CMD=$(node -e "try{const p=require('./package.json');console.log(p.scripts&&p.scripts.test||'')}catch(e){}" 2>/dev/null)
fi
# Check for common test runners
if [ -z "$TEST_CMD" ]; then
if [ -f "jest.config.js" ] || [ -f "jest.config.ts" ]; then
TEST_CMD="npx jest"
elif [ -f "vitest.config.ts" ] || [ -f "vitest.config.js" ]; then
TEST_CMD="npx vitest run"
elif [ -f "pytest.ini" ] || [ -f "pyproject.toml" ]; then
TEST_CMD="python -m pytest"
elif [ -f "Cargo.toml" ]; then
TEST_CMD="cargo test"
elif [ -f "go.mod" ]; then
TEST_CMD="go test ./..."
fi
fi
if [ -n "$TEST_CMD" ]; then
echo "Test command detected: $TEST_CMD"
else
echo "No test framework detected"
fi
```
**If no test framework detected**:
- Check CLAUDE.md for test commands
- Ask the user if they have a preferred test command
- If none available, skip test-dependent steps and note in output
**Usage**: Run detected command with `$TEST_CMD`
---
## Step 3 — Run Tests (on merged code)
Run detected test command:
```bash
$TEST_CMD 2>&1 | tee /tmp/ship_tests.txt
```
**If any test fails:** Show failures and **STOP**. Do not proceed.
**If all pass:** Continue — note counts briefly.
**Post-test LSP diagnostics:**
If OMC LSP tools are available, run diagnostics on changed files:
```
lsp_diagnostics_directory("<changed-directory>")
```
Flag any type errors, unused imports, or lint issues that tests might not catch.
---
## Step 3.4 — Test Coverage Audit
Delegate to OMC test-engineer for coverage analysis:
```
Agent(subagent_type: "oh-my-claudecode:test-engineer", prompt: "
Analyze test coverage for the diff: git diff origin/$BASE...HEAD
1. Trace every changed codepath
2. Map each branch against existing tests
3. Output ASCII coverage diagram with [TESTED] and [GAP] markers
4. Generate tests for uncovered paths (max 20 tests)
5. Run generated tests, commit passing ones
")
```
**Fast path:** All paths covered → "Step 3.4: All new code paths have test coverage ✓"
---
## Step 3.5 — Pre-Landing Review
Delegate to OMC code-reviewer for structural review:
```
Agent(subagent_type: "oh-my-claudecode:code-reviewer", prompt: "
Review diff: git diff origin/$BASE
Two-pass review:
Pass 1 (CRITICAL): SQL safety, race conditions, secrets exposure, auth gaps
Pass 2 (INFORMATIONAL): Dead code, magic numbers, style, N+1 queries
Classify each finding as AUTO-FIX or ASK.
AUTO-FIX: apply directly, report one line per fix.
ASK: collect for user decision.
")
```
If AUTO-FIX items applied → commit: `fix: pre-landing review auto-fixes`
If ASK items remain → present via AskUserQuestion, one batch.
---
## Step 4 — Version Bump (auto-decide)
If VERSION file exists:
1. Count lines changed: `git diff origin/$BASE...HEAD --stat | tail -1`
2. Auto-decide: <50 lines → MICRO/PATCH, 50+ → PATCH, major feature → ask MINOR
3. Write new version, reset lower digits to 0
If no VERSION file: skip this step.
---
## Step 5 — CHANGELOG (auto-generate)
If CHANGELOG.md exists:
1. Read header for format
2. Generate from ALL commits: `git log $BASE..HEAD --oneline`
3. Categorize: Added / Changed / Fixed / Removed
4. Insert after header, dated today
5. Do NOT ask the user — infer from diff
---
## Step 5.5 — TODOS.md Auto-Update
If TODOS.md exists:
1. Cross-reference diff against open TODOs
2. Mark completed items (conservative — only clear evidence)
3. Move to Completed section with version and date
---
## Step 6 — Bisectable Commits
Organize changes into logical, independently valid commits:
| Order | Category |
|-------|----------|
| 1 | Infrastructure (deps, config, CI) |
| 2 | Data/Schema (migrations, types) |
| 3 | Core logic (services, controllers) |
| 4 | Tests |
| 5 | VERSION + CHANGELOG + TODOS.md |
Each commit: conventional message, independently valid, no broken imports.
Final commit gets co-author trailer:
```
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
```
---
## Step 6.5 — Verification Gate (Iron Law)
**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.**
Before pushing, if ANY code changed after Step 3's test run:
1. Re-run test suite. Paste fresh output.
2. Run build if applicable.
Rationalization prevention:
- "Should work now" → RUN IT.
- "Confident" → Confidence is not evidence.
- "Already tested" → Code changed. Test again.
If tests fail: **STOP**. Fix and return to Step 3.
---
## Step 7 — Push
```bash
git push -u origin $(git rev-parse --abbrev-ref HEAD)
```
---
## Step 8 — Create PR
```bash
gh pr create --base $BASE --title "<type>: <summary>" --body "$(cat <<'EOF'
## Summary
<bullet points from CHANGELOG>
## Test Coverage
<coverage diagram from Step 3.4>
## Pre-Landing Review
<findings from Step 3.5>
## Test Plan
- [x] All tests pass
- [x] Pre-landing review complete
- [x] Verification gate passed
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
```
Output the PR URL.
---
## Step 9 — Record & Notify
## Memory Persistence
After completing the workflow, persist results to the 3-layer memory system:
### Required Actions
1. **Log completion to daily log**:
```
memory_daily_log(type: "done", entry: "{skill-name}: {brief result summary}")
```
2. **Store significant findings** (importance ≥ 6):
```
memory_store(
category: "{appropriate category}",
title: "{descriptive title}",
content: "{structured result content}",
tags: ["{skill-name}", "{project}", "{relevant-tags}"],
importance: {6-10 based on significance}
)
```
3. **Link to related memories** (if applicable):
```
memory_link(source: "{new_memory_id}", target: "{related_id}", relation: "{related|derived|refines}")
```
### Category Routing
| Content Type | Category | Subcategory |
|-------------|----------|-------------|
| Bug fix / debugging | knowledge | debugging |
| Code review results | projects | {project-name} |
| Design decisions | projects | {project-name} |
| Research findings | knowledge | {topic} |
| Release / deploy | projects | {project-name} |
| Person-related info | people | — |
| Task / action item | tasks | — |
## Messenger Notification
Send notifications for significant events via messenger:
### When to Notify
| Event | Platform | Priority |
|-------|----------|----------|
| Task/pipeline completed | telegram | Normal |
| Verification failed | telegram | High |
| Long-running task done (10+ min) | telegram | Normal |
| Critical error or blocker | telegram | High |
| PR created / release shipped | all | Normal |
| Importance ≥ 8 memory created | telegram | Normal |
### Notification Format
```
messenger_send(
platform: "telegram",
message: "[{skill-name}] {status_emoji} {brief description}\n\n{details if relevant}"
)
```
**Status Emojis**:
- Completed successfully: ✅
- Completed with warnings: ⚠️
- Failed / blocked: ❌
- Needs attention: 🔔
### Do NOT Notify
- Routine memory operations
- Intermediate progress steps
- Read-only operations (search, list, status)
```
memory_daily_log(entry: "Shipped: {PR title} #{PR number}", type: "done")
messenger_send(platform: "all", message: "✅ [ship] PR created: {PR URL}\n{summary}")
```
---
## Safety Rules
1. Never push to main/master directly
2. Never force push without explicit user request
3. Always run tests before creating PR
4. Never skip hooks (--no-verify)
5. Verify branch is not main before any push
## Completion Status Protocol
Every skill must end with one of these status codes:
| Code | Meaning | When to Use |
|------|---------|-------------|
| **DONE** | All steps completed, evidence provided | Root cause found + fix verified, PR created, review finished |
| **DONE_WITH_CONCERNS** | Completed with warnings or caveats | Tests pass but coverage dropped, fix applied but can't fully verify |
| **BLOCKED** | Cannot proceed, requires user intervention | 3 failed attempts, missing permissions, external dependency down |
| **NEEDS_CONTEXT** | Missing information to continue | Unclear requirements, need user clarification |
### Escalation Rules
1. **3-strike rule**: After 3 failed attempts at any step, **STOP** and escalate to user.
Do not continue guessing. Present what was tried and ask for direction.
2. **Scope escalation**: If fix/change touches 5+ files unexpectedly, pause and confirm
with the user before proceeding.
3. **Security uncertainty**: If you are unsure about a security implication, **STOP** and
escalate. Never guess on security.
4. **Verification requirement**: Never claim DONE without evidence.
- "Should work" → RUN IT. Confidence is not evidence.
- "Already tested earlier" → Code changed since. Test again.
- "Trivial change" → Trivial changes break production.
### Output Format
```
═══════════════════════════════════════
Status: {DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT}
Summary: {one-line description of outcome}
Evidence: {test output, verification results, or blocking reason}
═══════════════════════════════════════
```
No comments yet. Be the first to comment!