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>

pm-ai-shipping/commands/derive-tests.md

@@ -0,0 +1,114 @@
+---
+description: Turn documented intent into a test-coverage map — inventory the tests that exist today, derive use-case cases from the system docs, separate existing coverage from proposed tests and unverified gaps, mark each unit / guarded-live / manual, and recommend a green-before-merge CI gate
+argument-hint: "<repo path or area; defaults to the whole repository>"
+---
+
+# /derive-tests -- Turn Intent Into Tests
+
+The docs say what the system *should* do. An audit finds where the code *doesn't*. Tests are what stop that gap from reopening after the next AI edit. This command reads the documented intent, turns each load-bearing rule into a concrete test case, sorts them into what to automate, what needs a guarded live run, and what stays manual — then recommends the CI gate that keeps `main` honest.
+
+This produces a coverage map (`tests.md`) and concrete test cases, not a finished suite — you or the next agent implement the deterministic ones.
+
+## Invocation
+
+```
+/derive-tests
+/derive-tests the checkout flow
+/derive-tests supabase/functions
+```
+
+## Prerequisite: documented intent
+
+Tests are derived from the docs, so the docs come first. If `/documentation/*.md` is missing or thin, run `/document-app` (and `/derive-tests` reads `flows.md`, `permissions.md`, and `automation.md` most heavily). You cannot map coverage to rules you never wrote down — where intent is absent, say so rather than inventing rules to test.
+
+## The workflow
+
+### 1. Read the intent — and the tests that already exist
+
+Read the applicable system docs (architecture, flows, permissions, variables, and any of emails, cron, seo, automation that exist). Apply the **shipping-artifacts** skill for what each doc should contain, and the **intended-vs-implemented** skill for the discipline of treating docs as claims to verify, not proof.
+
+Then inventory the **existing test suite** — the test files, what they actually assert, and what runs in CI today. The map you produce must distinguish coverage that exists *now* from coverage you're *proposing*; skipping this step yields a falsely-green map that claims rules are pinned when nothing checks them. If there are no tests, say so plainly — that is itself a finding.
+
+### 2. Extract the rules worth testing
+
+Pull out the load-bearing, deterministic rules — the ones whose violation crosses a trust, data, money, tenant, or privacy boundary:
+
+- authorization allow **and deny** cases (especially the boundary crossings in `flows.md` and the matrix in `permissions.md`),
+- input validation and output encoding at each sink,
+- idempotency of jobs and dedup keys,
+- fail-closed defaults (error / timeout / cache-miss / flag paths that must deny, not allow),
+- side-effect conditions (exactly when an email sends, a write commits, a paid action fires),
+- public-data-only constraints on public or bot routes,
+- the output-contract and tool-surface limits of any agent in `automation.md`.
+
+Skip cosmetic behavior. A rule earns a test when getting it wrong harms someone other than the actor.
+
+### 3. Build the coverage map
+
+One row per use case: **rule → expected behavior (incl. the negative case) → evidence source (doc + code) → test type → status (existing / proposed / none)**. The status column is what keeps the map honest — mark a rule *existing* only when a test in the repo actually asserts it today.
+
+Test types:
+
+- **unit** — pure and deterministic, no external services.
+- **integration (deterministic)** — exercises real wiring against a local or in-memory dependency (test DB, mocked provider) and runs the same way every time.
+- **guarded live** — needs a real external DB, email provider, LLM, or third party. Runs only behind an explicit flag, never in the default CI run.
+- **manual** — UI/visual or judgment calls. A reviewer checklist item, not an automated test.
+
+**What CI must require:** the deterministic local set — unit plus deterministic integration tests, the ones that pass or fail the same way on every run with no live dependencies. Prefer **unit** where the decision logic can be isolated; reach for **integration** when the rule lives in the wiring (middleware, RLS, auth guards) and only a real-but-local dependency can exercise it. Guarded-live and manual rows never gate the default run.
+
+When a rule can only be exercised live, you can extract its *decision* into a pure helper so the logic is unit-testable — but only as a **complement, not a replacement** for testing the real enforcement. The unit test proves the helper's logic; it does **not** prove the framework actually calls it. Wiring and policy enforcement (route middleware, DB row-level security, auth guards, provider config) still needs an integration or guarded-live check, or the helper becomes a policy shadow that passes while the real path is unprotected.
+
+### 4. Propose the tests
+
+For each rule you can pin with a deterministic automated test (unit or integration), write the case: name, arrange/act/assert intent, and the negative case it must reject. Group cases by the doc or flow they defend. Prefer the smallest test that pins the rule — one clear assertion per boundary beats a sprawling integration test that fails for ten reasons.
+
+### 5. Recommend the CI gate
+
+Recommend — don't silently install — a CI setup matched to the repo's stack and existing tooling:
+
+- run the **deterministic local set on every pull request** (unit + any integration test that runs without live services),
+- keep **guarded-live tests opt-in** (manual or scheduled, never blocking),
+- **gate merges to `main` on green** via a required status check + branch protection.
+
+Output the workflow file and the branch-protection setting as a clearly-labeled suggestion for the user to approve, not an applied change.
+
+### 6. Report coverage and gaps
+
+Write `tests.md` in three clearly separated sections:
+
+- **Existing coverage** — rules a test in the repo pins *today* (from the Step 1 inventory).
+- **Proposed tests** — the cases you're recommending but that don't exist yet, by type.
+- **Gaps** — documented rules with **no verification at all**, ranked by what crossing them exposes.
+
+The gaps are the backlog, and they are exactly where the next AI edit can silently break a boundary. Be honest that proposed ≠ existing: a rule isn't covered until a test actually asserts it.
+
+## Output
+
+```
+Test Coverage: [scope]
+
+| Use case | Rule (doc) | Expected behavior (+ deny case) | Evidence | Type | Status |
+|----------|-----------|---------------------------------|----------|------|--------|
+[status: existing / proposed / none]
+
+### Existing coverage
+[tests already in the repo, each tied to the rule it pins]
+
+### Proposed tests
+[grouped by flow/doc — name · assert · negative case · type]
+
+### Recommended CI gate
+[workflow snippet for the detected stack + "green-before-merge" branch-protection note]
+
+### Gaps — documented but unverified
+[rules with no test yet, ranked by what crossing them exposes]
+```
+
+Optionally write the coverage map to `/documentation/tests.md` and the full report to `/reports/test_plan_{timestamp}.md`.
+
+## Notes
+
+- This is the verification half of "documented == implemented": the audits find today's gap, these tests stop it from reopening tomorrow.
+- Don't fabricate rules to manufacture coverage. If the docs are silent, the gap is in the docs — fix `/document-app` first.
+- Don't wire external services into the default CI run; flaky live tests erode the green-before-merge gate until people start ignoring it.
+- Covers test derivation only. For the gap audit itself use `/security-audit-static`; for the full document → audit → test → packet sequence use `/ship-check`.

pm-ai-shipping/commands/document-app.md

@@ -0,0 +1,60 @@
+---
+description: Reverse-engineer an AI-built codebase into the system documents reviewers and auditors need — a core set (architecture, flows, permissions, variables) plus conditional docs (emails, cron, SEO, automation) when they apply
+argument-hint: "<repo path or area; defaults to the whole repository>"
+---
+
+# /document-app -- Make the System Reviewable
+
+Produce the durable documentation an AI-built app is missing: an honest map of what the system is, who can do what, and where the risk lives. These docs are the foundation every later audit compares the code against.
+
+## Invocation
+
+```
+/document-app
+/document-app supabase/functions
+/document-app the backend
+```
+
+## Workflow
+
+### Step 1: Scope
+
+Audit **$ARGUMENTS**. If empty, document the whole repository, prioritizing backend code, auth, data access, background jobs, and anything that sends, schedules, or exposes data.
+
+### Step 2: Reverse-Engineer the Docs
+
+Apply the **shipping-artifacts** skill. Reading the code as the source of truth, produce the applicable documents in `/documentation/`.
+
+**Core (always):**
+
+- `architecture.md` — system overview, stack, auth flow, trust boundaries
+- `flows.md` — the permission-relevant journeys: each protected step's authz check, the trust-boundary crossings, and the side effects each flow causes
+- `permissions.md` — roles, scope derivation, resource × operation × role matrix, RLS vs. code-enforced checks
+- `variables.md` — config & secrets mapped to risk and rotation
+
+**Conditional (only if the capability exists — otherwise note its absence in one line):**
+
+- `emails.md` — notification path, templates, retry/backoff, failure visibility
+- `cron.md` — scheduled-work inventory, idempotency, internal-call auth
+- `seo.md` — SPA preview approach, route coverage, metadata sanitization
+- `automation.md` — embedded agents/automations: trigger, tool surface, steering vs. hard guardrails, output contract, app-owned side effects, approval gates
+
+Be brutally honest about the current state without being paranoid. Skip any conditional document that doesn't apply and say so. Add a "Related Documents" reference in `architecture.md` for each doc produced. (The test-coverage map, `tests.md`, is produced separately by `/derive-tests`.)
+
+### Step 3: Report
+
+Summarize what was created or updated, what was skipped and why, and any gaps where the code was too unclear to document confidently (those are the first things to fix).
+
+### Step 4: Offer Next Steps
+
+- "Want me to **derive a test-coverage map** (`/derive-tests`) so each documented rule has a verification plan?"
+- "Want me to **run a security audit** now that the intended behavior is documented?"
+- "Should I **check for performance issues** — over-fetching, missing indexes, caching?"
+- "Want me to **run `/ship-check`** to wire agent context and produce a full shipping packet?"
+
+## Notes
+
+- These docs describe *this* system — keep generic theory and finished templates out.
+- Write for two readers: a human reviewer and the next AI coding agent.
+- Don't include an "updated date" line.
+- The agent operating-context file (`CLAUDE.md` / `AGENTS.md`) is produced separately at the `/ship-check` handoff step — it's instructions derived from these docs, not system documentation.

pm-ai-shipping/commands/performance-audit-static.md

@@ -0,0 +1,59 @@
+---
+description: Static performance audit of AI-built code — find over-fetching, missing indexes, and caching opportunities, ranked by effort and impact
+argument-hint: "<repo path or area; defaults to the whole repository>"
+---
+
+# /performance-audit-static -- Find What Won't Scale
+
+A focused performance review for AI-built code. Agents optimize for "it works on my seed data," not "it holds at 100× the rows." This command finds the three failure modes that surface as data grows — over-fetching, missing indexes, and absent caching — and ranks fixes by effort and impact.
+
+This is a static review of code and queries, not a load test.
+
+## Invocation
+
+```
+/performance-audit-static
+/performance-audit-static src/views
+```
+
+## Scope
+
+Audit **$ARGUMENTS**. If empty, review the whole repository, prioritizing list and dashboard views, frequently hit endpoints, and large tables.
+
+## The audit
+
+### 1. Over-fetch in view payloads
+
+Review components that render list or dashboard views. Identify fields fetched from the database but never used in the frontend, `SELECT *` on wide tables, missing pagination, absent lazy loading, and redundant loads. Suggest a minimal field set per component or route.
+
+### 2. Missing or inefficient indexes
+
+Review queries, filters, and RPCs used in production views. Identify missing or inefficient indexes based on sort, filter, and join conditions, focusing on large tables and hot endpoints. Give specific index definitions, not "add an index."
+
+### 3. Caching opportunities
+
+Review endpoints and data-access patterns for frequently called paths that return static or rarely changing data. Identify where frontend or backend caching helps, and specify the invalidation rule for each — caching without an invalidation plan is a correctness bug in waiting.
+
+## Output
+
+Report findings per view, route, or table:
+
+```
+Performance Audit: [scope]
+
+<view / route / table>:
+  - Finding: <what is slow or wasteful>
+  - Recommendation: <specific change — field set, index definition, cache + invalidation>
+  - Effort: Low | Medium | High
+  - Priority: Low | Medium | High
+  - Expected effect: <e.g. payload size, query time, load time>
+```
+
+End with what's already efficient (say it explicitly) and what needs runtime profiling to confirm. Optionally write the report to `/reports/performance_audit_{timestamp}.md`.
+
+## Notes
+
+- Rank by impact-per-effort — one missing index on a hot table usually beats ten micro-optimizations.
+- Don't flag theoretical inefficiency with no growth path; flag what breaks as rows or traffic scale.
+- This command covers performance only. For authorization, injection, and data-exposure risks, use `/security-audit-static`.
+- For an end-to-end pass with documentation and a shipping packet, use `/ship-check`.

pm-ai-shipping/commands/security-audit-static.md

@@ -0,0 +1,86 @@
+---
+description: Static security audit of AI-built code — map trust boundaries, cross-reference documented intent, self-refute every finding, and report only evidence-backed risks
+argument-hint: "<repo path or area; defaults to the whole repository>"
+---
+
+# /security-audit-static -- Audit the Code You Already Have
+
+A focused, self-contained security audit for AI-built code. It keeps a small, durable engine — map the boundaries, check intent against implementation, refute before reporting — and refuses to emit anything it can't back with cited evidence.
+
+This is a review, not a guarantee: it produces code-review findings, not confirmed exploits.
+
+> Method adapted from the public, Apache-2.0 `security-guidance` plugin in Anthropic's
+> `claude-plugins-official` repository. Not affiliated with or endorsed by Anthropic.
+
+## Invocation
+
+```
+/security-audit-static
+/security-audit-static supabase/functions
+```
+
+## Scope
+
+Audit **$ARGUMENTS**. If empty, audit the whole repository, prioritizing request handlers, auth, data access, background jobs, and anything that renders, fetches, executes, logs, or stores user-controlled data. For non-trivial scopes, fan out with parallel subagents — one per function/module cluster, each running the mapping and inspection (steps 1–3); then merge candidates and run the self-refute (step 4) yourself over the full set.
+
+## The audit (small engine, strong constraint)
+
+### 1. Map entry points to trust boundaries and sinks
+
+Optimize for recall first — read every file in scope in full, then grep for handler, route, RPC, and shared-helper names to find callers and downstream sinks. Reading the file that contains the bug is what prevents missing it.
+
+Entry points: HTTP/RPC handlers, edge/serverless functions, webhooks, queue consumers, upload handlers, auth callbacks, cron-triggered endpoints. Sinks: raw SQL / query filters, shell/exec, `eval` / `new Function` / dynamic imports, HTML render and templates, outbound fetches, filesystem paths, IAM/role writes, logs and analytics, deserializers (incl. YAML/XML and archive extraction), response headers / cache-control, and **LLM prompts and tool calls** (prompt injection). For every value reaching a sink, decide whether an attacker can influence it and trace it back to its source.
+
+### 2. Inspect the four high-value paths
+
+Authorization, data access, session/identity, and input→output encoding. Compare sibling handlers — if one enforces a check another omits, the omission is a finding. Follow cross-file flows; input in module A reaching a dangerous operation in module B is where the real bugs hide.
+
+### 3. Cross-reference intended vs. implemented
+
+Apply the **intended-vs-implemented** skill against `/documentation/*.md`. A rule documented but not enforced in code is a finding on its own. If the docs are absent, note it and recommend `/document-app` first — an intent audit needs intent on record.
+
+### 4. Self-refute every candidate
+
+For each finding, try to disprove it. Default to **keep** unless you find cited evidence (file + line) for one of: a real sanitizer/encoder/validator/authorization check stops the exploit *at the sink*; the sink is non-dangerous (typed, hardcoded, isolated, schema-decoded); a frontend gate is independently re-enforced on the backend; an unvalidated credential is immediately forwarded to an upstream system that validates it; a config/flag gates the path and users can't influence it per request; or the path isn't reachable in production.
+
+Name the **attacker** and the **victim**: refute if the only victim is the attacker on their own machine/account/tenant/data and no shared system or privilege boundary is crossed; keep if the impact reaches other users, tenants, shared infrastructure, billing, email reputation, secrets, or compliance-sensitive data. **Never apply attacker-equals-victim refutation to SSRF/outbound-network sinks, shared billing or quota sinks, data-exposure findings, cross-tenant or cross-principal flows, or server-side execution/rendering** — those harm someone other than the attacker by definition. Never refute a finding merely because the code is pre-existing — pre-existing bugs are the point. Do not speculate.
+
+### 5. Report only what survives
+
+## High-miss checklist (technology-shaped, not stack-specific)
+
+Apply these — they're where AI-built apps most often fail:
+
+- **Service-role / disabled-RLS boundaries** — if the DB client bypasses row-level security, *every* authorization decision must be in code; flag queries missing the org/owner filter.
+- **Auth-provider drift** — claims from an external identity provider (e.g. Clerk) trusted without verifying how they map to data scope.
+- **Gate/action field mismatch** — permission checked on one ID, action performed on an independent ID never proven to belong to it.
+- **Forgeable request signals** — endpoints gated by `?source=cron`, `?bot=1`, guessable headers, or unsigned webhook-like payloads instead of real auth. Raise severity when the endpoint mutates data, sends email, or triggers paid usage.
+- **Output encoding vs. input validation** — user data interpolated into HTML, `<title>`, attributes, JSON-LD, SQL, or Markdown must be encoded for *that* sink; input validation doesn't count. (XSS, CSP gaps.)
+- **SSRF / renderer abuse** — attacker-influenced URLs, HTML, SVG, or Markdown reaching an outbound fetch or a renderer (headless browser, PDF/OG-image generator).
+- **Parser / validator differentials** — the validator accepts a value the consumer interprets differently: unanchored regex, `startsWith`/substring allowlists, URL-parser disagreement, encoding/case/slash/path-normalization mismatch, or validation on one representation and execution on another.
+- **Fail-open paths** — error, `catch`, timeout, cancellation, cache-miss, stale-cache, feature-flag, or boundary-value branches that default to *allow*. AI code loves a permissive fallback.
+- **Secrets / PII to observability** — credentials, tokens, emails, or sensitive data reaching logs, traces, analytics, or error bodies; check error branches especially.
+- **Public-data-only violations** — SPA/SEO bot routes or "public" endpoints over-fetching private fields.
+
+## Output
+
+Group surviving findings by file, sorted by severity, in the standard format:
+
+```
+Security Audit: [scope]
+
+<file>:
+  N. [SEVERITY] [Category] <location>
+     Risk Level: Critical | High | Medium | Low
+     Attack Scenario: <attacker -> sink -> impact, step by step>
+     Impact: <what data or functionality is compromised>
+     Solution: <concrete code change>
+```
+
+End with: the root-cause theme across findings; **what is well-built — say it explicitly**; and what you could not verify and the user should double-check. Optionally write the report to `/reports/security_audit_{timestamp}.md`.
+
+## Notes
+
+- Don't report generic hardening with no concrete impact, outdated deps without a reachable path, or test/mock code unless it ships. Logic and authorization bugs with no classic sink still count.
+- This command covers security only. For over-fetching, indexes, and caching, use `/performance-audit-static`.
+- For an end-to-end pass that documents first and produces a shipping packet, use `/ship-check`.

pm-ai-shipping/commands/ship-check.md

@@ -0,0 +1,76 @@
+---
+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.