Files
Pawel Huryn 8202bdd7f1 Release v2.0.0: add pm-ai-shipping plugin, red-team execution skill, refresh README
New
- pm-ai-shipping (9th plugin) — AI Shipping Kit: document a vibe-coded app, audit
  security/performance against intended behavior, map test coverage, and compile a
  reviewer-ready shipping packet (2 skills, 5 commands).
- pm-execution: strategy-red-team skill + /red-team-prd command (now 16 skills, 11 commands).

Changed
- Bump all versions 1.0.1 -> 2.0.0 (marketplace.json + all 9 plugin.json) in lockstep.
- README: new plugins.png hero + examples.png in "How It Works"; counts updated to
  9 plugins / 68 skills / 42 commands across tagline, install block, and per-plugin sections.
- CLAUDE.md: 9-plugin structure, plugin table, and version note updated.

Validator: 9 plugins, 68 skills, 42 commands, 110 components, 0 warnings.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-05 18:49:54 +02:00

4.2 KiB

description, argument-hint
description argument-hint
Turn a vibe-coded repo into a reviewer-ready shipping packet — document the app, wire agent context, run security and performance audits, map test coverage, and compile the results <repo path or area; defaults to the whole repository>

/ship-check -- Is This Safe to Ship?

Your AI wrote the code. This command answers the question you actually have — is it safe to ship? — by running the full shipping sequence and compiling the results into one reviewer-ready packet a human can sign off on.

/ship-check does not replace the specialist commands. It coordinates them and produces the final artifact none of them produce alone: the shipping packet.

Invocation

/ship-check
/ship-check the payments service
/ship-check supabase/functions

The shipping sequence

Run on $ARGUMENTS (or the whole repository if empty). Each step builds on the last — the ordering is the point, because every audit is only as good as the documented intent it can compare the code against.

Step 1: Document the system

Ensure the system docs exist and are current (run /document-app if they're missing or stale). Apply the shipping-artifacts skill — the core set (architecture, flows, permissions, variables) plus any conditional docs that apply (emails, cron, seo, automation). These docs are the intended-state baseline for everything that follows.

Step 2: Wire the agent operating context

Create or refresh CLAUDE.md (and a thin AGENTS.md pointing to it) derived from the system docs — the operating instructions the next AI coding agent inherits: what the system is, the trust boundaries, what may and may not be touched, where the guardrails are. This is a different artifact from the system docs: instructions, not description.

Step 3: Security audit

Run the security pass (/security-audit-static), applying the intended-vs-implemented skill to flag where the code diverges from permissions.md, flows.md, and architecture.md. Summarize surviving findings.

Step 4: Performance audit

Run the performance pass (/performance-audit-static) — over-fetching, missing indexes, caching. Summarize findings.

Step 5: Derive the test-coverage map

Run /derive-tests to turn the documented rules — and the gaps the audits just surfaced — into a coverage map (tests.md): which rules are pinned by tests that exist today, which are only proposed, which are guarded-live or manual, and which have no verification at all. Running this after the audits is deliberate: each confirmed finding becomes a concrete regression test to pin, so the same gap can't silently reopen on the next AI edit. This is the operational form of "documented == implemented," and the unverified boundary rules feed straight into the launch-blocker assessment below.

Step 6: Compile the shipping packet

## Shipping Packet: [repo / area]

### Documentation Inventory
| Doc | Status (present / stale / missing / n/a) | Notes |

### Agent Context
CLAUDE.md / AGENTS.md: [created / updated / already current]

### Test Coverage
[Rules pinned by tests that exist today · proposed but not yet written · guarded-live/manual · and the documented rules nothing verifies yet]

### Security Summary
[Counts by severity + the surviving findings, each: Risk · Attack · Impact · Fix]

### Performance Summary
[Findings by view/route/table, each: Recommendation · Effort · Priority]

### Launch Blockers
[Unresolved Critical/High items — including any boundary rule that is both unverified and unaudited — that should stop a ship]

### Recommended Next Actions
[Concrete owner actions or commands to run next]

Notes

  • This is a handoff compiler: the value is sequencing plus synthesis, not re-deriving each audit.
  • If documentation is missing, the packet says so loudly — an audit without documented intent is incomplete, and the inventory makes that visible rather than hiding it.
  • Findings are code-review results, not confirmed exploits; the packet is a basis for human sign-off, not a substitute for it.
  • Run the specialist commands directly (/document-app, /derive-tests, /security-audit-static, /performance-audit-static) when you only need one stage.