ship

Original：🇺🇸 English
Not Translated

Deploy approved features to production. Creates PRs, runs pre-deployment checks, and updates TASKS.md. Use after /document completes. Supports task IDs for easier invocation.

3installs
Sourceeljun/workflow-skills
Added on

NPX Install

npx skill4agent add eljun/workflow-skills ship

SKILL.md Content

/ship - Deployment Agent

Model: haiku (scripted deployment commands)

Command Flags

FlagShortDescription
--help
-h
Show available commands and options
--version
-v
Show workflow skills version

Flag Handling

On 
-h
or 
--help
:
/ship - Deployment Agent

Usage:
  /ship {ID}                         Create PR for a task
  /ship -h, --help                   Show this help message
  /ship -v, --version                Show version

Arguments:
  {ID}    Task ID (number) or task filename (e.g., 001-auth-jwt)

Pre-deployment checks:
  - Build passes
  - TypeScript compiles
  - Lint passes

Creates:
  - Feature branch: feature/{ID}-{task-name}
  - Pull Request with task documentation links

Examples:
  /ship 1                            # Ship task #1
  /ship 001-auth-jwt                 # Using task filename

Next: Merge PR, then /release
On 
-v
or 
--version
: Display:
Workflow Skills v1.5.1
https://github.com/eljun/workflow-skills

When to Use

Invoke 
/ship {ID}
when:
  • Task is in "Approved" status in TASKS.md
  • Documentation is complete
  • Ready to deploy to production
Example: 
/ship 1
or 
/ship 001-dashboard-redesign

Task ID Resolution

The 
{ID}
can be:
  • Numeric ID: 
    1
    , 
    2
    , 
    3
    → Looks up in TASKS.md, finds matching task document
  • Padded ID: 
    001
    , 
    002
    → Same as numeric
  • Full filename: 
    001-dashboard-redesign
    → Direct file reference

Workflow

/ship {ID}
       ↓
1. Resolve task ID → find task document
2. Verify task is approved in TASKS.md
3. Check Automation field (manual | auto)
4. Move to "Ready to Ship" in TASKS.md
5. Run pre-deployment checks
6. Create/update branch (feature/{ID}-{task-name})
7. Create Pull Request (with task ID reference)
8. Update TASKS.md with PR link
       ↓
After merge → Update "Merged" column (stay in "Ready to Ship")
       ↓
/release → Moves to "Shipped" with version
IMPORTANT: Items stay in "Ready to Ship" even after merge. Only 
/release
moves items to "Shipped" with the release version. This ensures proper release tracking.

Auto Mode Behavior

When task document has 
Automation: auto
:
After PR is created, the automation pipeline completes:
[AUTO] Pipeline complete!

Task: #{ID} - {Task Title}
Branch: feature/{ID}-{task-name}
PR: #{number} - {link}

Pre-deployment checks:
- Build: PASS
- TypeScript: PASS
- Lint: PASS

The PR is ready for your review and merge.
TASKS.md updated to "Ready to Ship"
Note: In auto mode, we still create the PR and notify you - you decide when to merge. The automation does NOT auto-merge.

Multi-Task Commit Tracking

When shipping a task that was implemented as part of multi-task execution, commits are tracked via the 
[task-{ID}]
prefix:
bash
# Find all commits for a specific task
git log --oneline --grep="\[task-1\]"

# Example output:
# a1b2c3d [task-1] feat: Add JWT authentication middleware
# e4f5g6h [task-1] feat: Add token refresh logic
This allows 
/ship
to:
  1. Identify which changes belong to which task
  2. Generate accurate PR descriptions
  3. Reference specific commits in the PR body

Pre-Deployment Checklist

IMPORTANT — Context Efficiency: The task document and test report contain all the context you need. Do NOT perform broad codebase exploration. Focus only on deployment-related checks below.

1. Verify Approval Status

Check TASKS.md:
  • Task must be in "Approved" section
  • Feature doc exists
  • Test report shows PASS

2. Review Changes

bash
git status
git diff main...HEAD
Verify:
  • All intended files are changed
  • No unintended changes
  • No sensitive files (
    .env
    , credentials)

3. Run Pre-Deployment Checks

bash
# Build check
pnpm build

# Type check
pnpm typecheck

# Lint check
pnpm lint
All must pass before creating PR.

Update TASKS.md

Move task to "Ready to Ship":
markdown
## Ready to Ship

| ID | Task | Branch | PR | Merged | Task Doc |
|----|------|--------|----|--------|----------|
| 1 | Quick Actions Redesign | feature/1-quick-actions | Pending | No | [001-quick-actions.md](...) |
Note: The "Merged" column tracks merge status. Items stay here until 
/release
is run.

Git Workflow

Branch Strategy

Use task ID in branch names for clarity:
feature/{ID}-{task-name}     - New features (e.g., feature/1-auth-jwt)
fix/{ID}-{task-name}         - Bug fixes (e.g., fix/2-login-redirect)
enhance/{ID}-{task-name}     - Enhancements (e.g., enhance/3-dashboard)

If Branch Already Exists on Origin (Worktree Flow)

When 
/implement
ran with worktree isolation, it already committed and pushed the branch. Check first:
bash
git ls-remote --heads origin feature/{ID}-{task-name}
If the branch exists on origin → do not checkout. Go straight to PR creation:
bash
gh pr create --base main --head feature/{ID}-{task-name} --title ...
This keeps the user's working directory on 
main
.

If Branch Doesn't Exist (Manual / Fallback Flow)

bash
git checkout -b feature/{ID}-{task-name}
# Stage only the files changed by this task (avoid accidentally committing .env or unrelated files)
git add {files-changed-by-this-task}
git commit -m "[task-{ID}] feat: {description}

{Detailed description of changes}

Task: docs/task/{ID}-{task-name}.md
Test: docs/testing/{ID}-{task-name}.md

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>"
git push -u origin feature/{ID}-{task-name}

Create Pull Request

Use GitHub CLI to create PR:
bash
gh pr create --title "[Task #{ID}] {PR Title}" --body "$(cat <<'EOF'
## Summary

{2-3 bullet points describing the changes}

## Task Documentation

- **Task ID:** #{ID}
- **Task Doc:** [docs/task/{ID}-{task-name}.md](link)
- **Test Report:** [docs/testing/{ID}-{task-name}.md](link)
- **Feature Doc:** [docs/features/{feature}.md](link)

## Changes

| File | Change |
|------|--------|
| `path/to/file` | Description |

## Commits

{List commits with [task-{ID}] prefix}

## Testing

- [x] E2E tests passed (see test report)
- [x] Manual testing completed
- [ ] Ready for code review

## Screenshots

{If UI changes, include before/after}

---

Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

PR Checklist

Before creating PR, verify:

Code Quality

  • Build passes (
    pnpm build
    )
  • No TypeScript errors
  • Lint passes (
    pnpm lint
    )
  • No console.log statements
  • No commented-out code

Documentation

  • Task document complete
  • Test report shows PASS
  • Feature documentation updated
  • User guide updated (if user-facing)

Security

  • No hardcoded secrets
  • No 
    .env
    files included
  • API keys not exposed
  • Proper auth checks in place

Testing

  • E2E tests pass
  • Manual testing done
  • Edge cases handled

Update TASKS.md with PR

After PR is created:
markdown
## Ready to Ship

| ID | Task | Branch | PR | Merged | Task Doc |
|----|------|--------|----|--------|----------|
| 1 | Quick Actions Redesign | feature/1-quick-actions | [#123](link) | No | [001-quick-actions.md](...) |

Post-Merge Actions

After PR is merged, update the "Merged" column but keep in "Ready to Ship":

1. Update TASKS.md Merged Status

markdown
## Ready to Ship

| ID | Task | Branch | PR | Merged | Task Doc |
|----|------|--------|----|--------|----------|
| 1 | Quick Actions Redesign | feature/1-quick-actions | [#123](link) | ✅ Jan 26 | [001-quick-actions.md](...) |
IMPORTANT: Do NOT move to "Shipped" yet. Items stay in "Ready to Ship" until 
/release
is run. This allows 
/release
to:
  1. Know which items need to be included in the release
  2. Properly track which release each feature belongs to

2. Update Task Document Status

Update task document to reflect merge:
markdown
> **Status:** MERGED
> **Merged:** {Date}
> **PR:** #{number}

3. When to Run /release

After one or more items are merged, run 
/release
to:
  • Create versioned release with changelog
  • Move ALL merged items from "Ready to Ship" to "Shipped"
  • Tag each item with the release version
markdown
## Shipped

| ID | Task | PR | Release | Shipped |
|----|------|-----|---------|---------|
| 1 | Quick Actions Redesign | [#123](link) | v1.2.0 | Jan 26 |

Handling Issues

Build Fails

  1. Fix the build errors
  2. Commit fixes
  3. Re-run checks
  4. Continue with PR

PR Review Requested Changes

  1. Make requested changes
  2. Commit with descriptive message
  3. Push to branch
  4. Re-request review

Merge Conflicts

  1. Fetch latest main
  2. Rebase or merge main into branch
  3. Resolve conflicts
  4. Push updated branch

Deployment Verification

After merge, verify deployment:

Vercel (Web)

  • Check Vercel dashboard for deployment status
  • Verify preview URL works
  • Check production URL after deploy

Rollback Procedure

If issues found in production:
  1. Quick fix: Create hotfix branch, PR, merge
  2. Revert: 
    git revert {commit}
    and create PR
  3. Document: Add to test report what was missed

Summary Output

Check the task document for 
Automation: auto
field.

Manual Mode

Deployment initiated for: #{ID} - {Task Title}

Branch: feature/{ID}-{task-name}
PR: #{number} - {link}

Pre-deployment checks:
- Build: PASS
- TypeScript: PASS
- Lint: PASS

TASKS.md updated to "Ready to Ship"

Next Steps:
  1. Review and merge the PR
  2. After merging, run /release to create versioned release

Auto Mode

[AUTO] Pipeline complete!

Task: #{ID} - {Task Title}
Automation: Full pipeline executed

Summary:
├── /task ✓ (task document created)
├── /implement ✓ (code written)
├── /test ✓ (tests passed)
├── /document ✓ (docs updated)
└── /ship ✓ (PR created)

Branch: feature/{ID}-{task-name}
PR: #{number} - {link}

Pre-deployment checks:
- Build: PASS
- TypeScript: PASS
- Lint: PASS

The PR is ready for your review and merge.

Related Skills

SkillWhen to Use
/implement
If fixes needed before shipping
/test
If additional testing needed
/document
If docs need updates
/release
After multiple items merged, create versioned release

Recommended Plugins (Install Separately)

These plugins must be installed separately. Once installed, they MUST be invoked — do not skip them:
PluginInstall FromWhen to Invoke
vercel-react-best-practices
vercel-labs/agent-skillsReact/Next.js code fixes
supabase-postgres-best-practices
supabase/agent-skillsDatabase-related fixes