mirror of
https://github.com/phuryn/pm-skills.git
synced 2026-09-20 14:25:53 +03:00
Pawel HurynandClaude Opus 5
76c51f3ae8
I had only used one repo's per-category survival table plus the other's aggregate numbers, and had not looked at the shipping repos' fix history at all. Reading all 105 planted bugs per-bug, and four weeks of real fixes, changed four things. Taxonomy is now thirteen lenses: - Lens 10 (representation and information loss) is promoted to the highest-frequency class in every corpus and given three named sub-shapes: the nullish family (pending/absent/empty/zero/false/failed collapsing into each other), projection and field-set drift (a producer quietly stops emitting a field, consumers degrade instead of failing), and unresolved values stored as resolved ones. Plus the cast/any/suppression tell - an annotation on a boundary marks where two sides disagreed and someone silenced the compiler. - Lens 12 gains reachability: a predicate nothing can satisfy, a handler never wired, a scheduler never started. Reads as correct code; common in the wild. - Lens 13, verification and observability, is new: the check that cannot fail, the oracle measuring the wrong thing, the effect whose absence nothing would notice. It carries a note on WHY it is new - a planted defect is detectable by construction, so silent failure is systematically absent from planted corpora and heavily represented in real fix histories. A checklist trained only on planted bugs will never prompt you to look here. Refutation gains "absorption is not prevention": a cache that usually holds, a retry that usually succeeds, a default that is usually right - none of those refute a finding, they postpone it. Drop only on a mechanism that makes the execution impossible. Corollary: "works nearly always" describes a race. Parallelism gains two constraints: - One model. Fan-out is for coverage, not a second opinion; workers run the coordinator's model. A single foreign worker makes a measured result unattributable. The independent second-model pass stays where it belongs, as an explicit /ship-check step. - Read-only workers. Read, search, navigate - no writes, edits or mutating commands. A worker that can edit drifts from reviewing into silently fixing, and the tree must end identical to how it started or findings cannot be checked against it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01G42vsxSKL7je39AsHZ5aJm
pm-ai-shipping — AI Shipping Kit
For PMs and founders accountable for AI-built code. Document a vibe-coded app, review it for correctness, security and performance defects, 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 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 — The top-level review skill. Correctness is its core; performance and security are optional sub-cases of the same engine. 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 correctness, security and performance reviews, add an independent unsteered pass by a second model, 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
License
MIT