Pawel Huryn
8202bdd7f1
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>
77 lines
4.2 KiB
Markdown
77 lines
4.2 KiB
Markdown
---
|
|
description: 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
|
|
argument-hint: "<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.
|