# Ship It

> >

- **Type:** Skill
- **Install:** `agentstack add skill-jaballer-claude-webdev-skills-ship-it`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [jaballer](https://agentstack.voostack.com/s/jaballer)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [jaballer](https://github.com/jaballer)
- **Source:** https://github.com/jaballer/claude-webdev-skills/tree/main/plugins/webdev/skills/ship-it

## Install

```sh
agentstack add skill-jaballer-claude-webdev-skills-ship-it
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Ship It (guided)

This is the hand-holding version of `/webdev:new-feature`. It runs the **same** underlying skills,
but narrates what's happening and why, and pauses for confirmation at each step that's hard to
undo. The aim is that someone new to the workflow finishes with both a merged change *and* an
understanding of what just happened.

**Teach as you go.** The first time each concept comes up, explain it in one plain sentence — what
a *branch* is, what a *commit* is, what a *pull request* is, why tests run before shipping. Don't
lecture; just don't assume the knowledge.

**Apply `/webdev:safe-edit` throughout.** Before anything irreversible (force-push, deleting files,
resetting), classify and confirm per that skill. Default to confirming more often here than in the
power-user flow.

## The guided path

### 1. Make sure we're starting clean
Explain: "We don't change the main copy directly — we make a separate workspace called a *branch*,
so the working version stays safe." **Invoke `/webdev:new-branch`** (and `/webdev:sync-main` first
if the base looks stale). Show the branch name and what it means.

### 2. Decide if we need to plan first
For anything beyond a small isolated change, explain that a few minutes of looking before leaping
saves a lot of rework, and **invoke `/webdev:plan-inventory`**. Walk the user through the inventory
in plain terms and **get their okay before writing code**. For a genuinely small change, say so and
skip it — don't over-ceremony a one-line fix.

### 3. Make the change
Implement it, following the project's existing patterns (lean on `/webdev:explain-codebase` first if
the user doesn't know the codebase). Narrate what you're changing and why in plain language. Keep
the change inside the scope you agreed on — note anything tempting-but-unrelated as "later," don't
fold it in.

### 4. Check it works
Explain: "Tests are an automatic way to confirm we didn't break anything." **Invoke
`/webdev:run-tests`** at the right scope and explain the result. If something fails, walk through
the fix together rather than just silently patching it. If the change is visible in the app,
**invoke `/webdev:verify`** too — seeing the change work in the running app is the most
convincing check there is, especially for someone new to this.

### 5. Save and share the work
Explain commits and PRs in one sentence each, then **invoke `/webdev:commit`** — it runs a careful
self-review, saves the change (*commit*), uploads it (*push*), and opens a *pull request* for review.
Show the PR link and explain that this is where the change gets reviewed before going live.

### 6. Handle any feedback
If a reviewer (a person or an automated bot) leaves comments, explain that this is normal and good,
then **invoke `/webdev:review-pr`** to walk through addressing them. Reassure the user that
review comments aren't criticism of them — they're how code gets better.

### 7. Done
Summarize what shipped in plain language and what happens next (a maintainer merges the PR, or —
once it's approved and the user says go — **invoke `/webdev:merge-pr`** to land it safely and
clean up). Point out one thing they could try on their own next time.

## Tone

- Encouraging and concrete. Celebrate the small wins (first branch, first PR).
- Never make the user feel slow for not knowing something. Define terms the first time, then use them.
- Prefer showing over telling — link the actual branch, the actual PR, the actual test output.
- If the user wants to go faster once they're comfortable, point them at `/webdev:new-feature`.

## Output

When complete, report back in plain language:
- **What we built** · **Branch** · **PR link**
- **Tests**: what passed
- **What's next**: who merges it / how it goes live
- **One thing learned**: a concept the user now knows that they didn't before

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [jaballer](https://github.com/jaballer)
- **Source:** [jaballer/claude-webdev-skills](https://github.com/jaballer/claude-webdev-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-jaballer-claude-webdev-skills-ship-it
- Seller: https://agentstack.voostack.com/s/jaballer
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.