mirror of
https://github.com/phuryn/pm-skills.git
synced 2026-09-20 14:25:53 +03:00
Pawel HurynandClaude Opus 5
2e662ac04d
NOT RELEASED. No version bump - versions stay at 2.0.0 across all 9 plugins and marketplace.json, because bumping is the release action and this ships only after it has been tested. On a branch for the same reason. WHY A SKILL AND NOT A FOURTH COMMAND. /security-audit-static is already mature - sink analysis, self-refutation with attacker/victim rules, OWASP backstop, fan-out. Rebuilding that inside something new would duplicate it. The hole in this plugin is CORRECTNESS: there is no bug-finding review at all. So this is one skill with three independently activated dimensions that defers to the existing command for security and points at intended-vs-implemented for the doc-vs-code axis. THE ANCHOR IS THE AGREEMENT, NOT THE FILE. The defects reviewers miss are rarely visible inside one file - they are disagreements between two participants that each read sensibly alone. Engine: map a flow, identify an obligation, inspect EVERY participant, construct a violating execution, trace the consequence, refute, report. Two lenses get a forced probe rather than a checklist mention: authority reconciliation (a requested value is not an applied value) and identity correlation (is the key unique, stable and live under overlap and reuse). Refutation discipline is deliberately stricter than the security command's: a correctness defect can harm only the person who triggered it and still be serious, so the attacker/victim test does not transfer, and 'keep unless disproved' is too permissive. Keep / Drop / Unresolved, with unresolved kept out of the findings list. Parallelism fans out over complete flows, never over files - partitioning by file is exactly the split that hides cross-boundary defects. Overlapping reads are allowed and encouraged. Coverage reports work performed in four states; zero findings is not 'not covered'. Co-designed with GPT-6 Astra (Codex CLI). Contains no project-specific content: no repo names, no paths, no bug identifiers, no defect text - verified by scan. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01G42vsxSKL7je39AsHZ5aJm
36 lines
3.1 KiB
Markdown
36 lines
3.1 KiB
Markdown
# pm-ai-shipping — AI Shipping Kit
|
|
|
|
For PMs and founders accountable for AI-built code. Document a vibe-coded app, audit it for intended-vs-implemented security gaps and performance issues, and produce a reviewer-ready shipping packet.
|
|
|
|
## Overview
|
|
|
|
AI agents write code fast but leave no record of *intent* — what the system should do, who may do what, where the secrets live. Without that record, no human and no auditing agent can tell whether the code is safe to ship. This kit restores reviewability: it documents the system, then audits the gap between what the docs say and what the code does — the class of bug generic scanners miss because they have no model of intent.
|
|
|
|
Start with `/ship-check` for the full sequence, or run a single stage with the specialist commands.
|
|
|
|
## Install
|
|
|
|
Install from the [pm-skills marketplace](https://github.com/phuryn/pm-skills) and enable the `pm-ai-shipping` plugin. Each command can be triggered with `/pm-ai-shipping:<command>` or its short `/<command>` form; skills auto-load when the topic matches.
|
|
|
|
## Skills (3)
|
|
|
|
- **shipping-artifacts** — The durable documentation set that makes an AI-built app reviewable: a core every app needs (architecture, user/permission flows, permissions, variables/secrets, test-coverage map) plus conditional docs added only when they apply (emails, cron, SEO, embedded agents/automation). Defines what each doc must capture and how a reviewer uses it.
|
|
- **code-review** — Review code for actionable correctness, performance, or security defects, each dimension independently optional. Anchors on agreements between participants across a boundary — the defects that are invisible file-by-file because each side looks reasonable alone — forces a violating execution, and refutes every candidate before reporting.
|
|
- **intended-vs-implemented** — The method for finding the gap between what a system is documented to do and what the code actually does, with cited evidence on both sides and without hand-wavy findings.
|
|
|
|
## Commands (5)
|
|
|
|
- `/pm-ai-shipping:ship-check` — Turn a vibe-coded repo into a reviewer-ready shipping packet: document, wire agent context, run security and performance audits, map test coverage, and compile the results.
|
|
- `/pm-ai-shipping:document-app` — Reverse-engineer a 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.
|
|
- `/pm-ai-shipping:derive-tests` — Turn documented intent into a test-coverage map: inventory the tests that exist today, separate them from proposed tests and unverified gaps, mark each unit / guarded-live / manual, and recommend a green-before-merge CI gate.
|
|
- `/pm-ai-shipping:security-audit-static` — Static security audit: map trust boundaries, cross-reference documented intent, self-refute every finding, and report only evidence-backed risks.
|
|
- `/pm-ai-shipping:performance-audit-static` — Static performance audit: find over-fetching, missing indexes, and caching opportunities, ranked by effort and impact.
|
|
|
|
## Author
|
|
|
|
Paweł Huryn — [The Product Compass Newsletter](https://www.productcompass.pm)
|
|
|
|
## License
|
|
|
|
MIT
|