pdd

Plugin pdd from marketplace proof-driven-development in AlexTavor/proof-driven-development. Commands read from the repo's manifest — 1 month ago.

Skills (22)

• assert-by-shape

  A test for a function that returns a structured value MUST compare the whole produced value against one expected fixture (input to output) in a single deep-equality assertion, not a column of per-field assertions on the same object. Use when authoring OR reviewing tests for config loaders, parsers,

• boundary-tests

  For any comparison predicate against a limit (less-than, less-or-equal, greater-than, greater-or-equal), the test suite MUST contain a case at the boundary itself — x equal to the limit, not only values to either side. Use when authoring tests for cost ceilings, retry counts, timeouts, age threshold

• characterize-before-change

  Before changing code you don't fully trust — legacy, inherited, or AI-generated — pin its current behavior in tests first, so a regression turns them red and the tests become the recovered spec. Hold those characterization tests to the same adequacy bar as any other (boundary, no-op, value-pinning)

• cohesion-review

  When a change appends to a module that already exists (a new function, another case, another gate), review the WHOLE resulting module for cohesion, not just the diff. Use this on any PR that GROWS a file rather than adding a new one, the moment a linter flags a file for size or complexity, or whenev

• cover-the-mirror

  Every operation with a natural inverse implies that inverse exists. Create implies delete, open implies close, encode implies decode, acquire implies release, subscribe implies unsubscribe, authenticate implies authorize. When a design or codebase has one half of a mirror pair, the other half MUST e

• decision-gate

  Gate a load-bearing decision before anything is built on it — require an observable kill-condition that would prove the choice wrong, a detector watching for it, and proof proportionate to blast radius and reversibility, ending in a GREEN / RED / OVERRIDE verdict. Use whenever a choice would be cost

• decompose-by-attention

  Carve a unit of work into attention-sized pieces — roughly ~1 minute of operator planning plus ~1 minute of completion review. Use when scoping a plan or a change, or recursively when an existing scope feels too big to hold in one pass.

• derisk-gate

  Before committing a plan, prove the riskiest architectural assumptions with a thin end-to-end walking skeleton, then emit a ranked risk register and a GREEN / RED / OVERRIDE verdict. Use during CARVE before decomposing work into units — on a new package boundary, an unproven integration, a cross-cut

• design-assumptions-register

  Before building on a design or plan, surface the load-bearing assumptions it rests on — the beliefs about environment, dependencies, behavior, timing, and scale that were never consciously chosen — and record each in a committed register with a falsifying condition ("breaks if X"), a consequence-anc

• design-completeness

  Before code is written, a design MUST name three things for every behavior it specifies, the three a complete design of its type always has. Its contract (inputs, outputs, invariants), its failure modes (what can go wrong and what happens then), and its edges (boundary, empty, zero, and maximum case

• footgun-register

  When reading reveals that a name, type, or signature contradicts the real runtime behavior, record it as a footgun — the misleading appearance, the verified reality, a file:line anchor, and a last-verified date — in a committed register. Use while mapping legacy or AI-generated code, whenever a symb

• keep-properties-honest

  A property suite can be all-green and still prove nothing: the tautological property passes because it was written by reading the same code it tests. Guard against it with three checks — source every property from the design or a written constraint (never from the implementation), have a separate pa

• mutation-grading

  Grade whether a test suite actually bites by injecting small bugs (mutants) and checking the tests catch them — line coverage can't tell you this. Every surviving mutant is either a weak test (add a property or case) or dead code (delete it), so read each survivor before trusting the count. Use when

• no-op-paths

  For any method that mutates state conditionally (cleanup, eviction, pruning, GC, expiry, retraction, compaction, vacuum), the test suite MUST contain a test where the trigger condition is NOT met and post-state equals pre-state. Use when authoring tests for prune_* / evict_* / expire_* / gc_* / clea

• one-meaning-per-term

  A load-bearing term in a spec or design MUST carry exactly one meaning. When the same word names two different things (or two words name one thing), readers and parsers silently diverge, and the divergence ships as a bug no reviewer can see because each reader was sure they understood. Use whenever

• pr-sizing

  Decide whether to bundle multiple changes into one PR or ship them standalone. PR size targets the operator's attention (one milestone per PR), not the agent's construction unit (one logical change per PR). Use when composing PRs for structurally similar work — multiple units, multiple amendments, o

• properties

  Pin behavior that ranges over structured input — parsers, validators, classifiers, rule engines, compilers, calculators — with a generated property over the input shape, not a handful of examples. Properties come from two sources: the data's schema (well-formed in → well-formed out, nothing dropped,

• read-the-system

  Before asserting how unfamiliar code behaves at runtime — legacy, inherited, or AI-generated — open and read the actual implementation. A name, type, signature, schema, or grep hit is a lead, not a fact; in this kind of codebase they routinely lie. Use at the start of MAP, or any time you are about

• reproducibility-baseline

  Before changing behavior-critical code, establish a baseline that can prove the change didn't alter behavior — replay-and-diff if the system is deterministic, else golden-master/snapshot or injected seams for the clock, RNG, and I/O. Determinism is the easy case, not an assumption: when a snapshot o

• silent-failure-census

  Sweep a codebase for places that can fail without a trace — swallowed exceptions, ignored error returns, fire-and-forget tasks, unchecked subprocess exits — and record each with its location and a real-vs-benign classification. Use during MAP, or whenever you need to know where a system could be bro

• system-truth-atlas

  Assemble the deliverable of MAP — a committed Phase-0 diagnostic of a codebase you can't fully trust, in four parts: a verified code map, a footgun register, a recovered-system risk register (where the code is already wrong — distinct from derisk-gate's plan-assumption risk), and a silent-failure ce

• trace-requirements-to-tests

  Every requirement, rule, or acceptance criterion a spec or design states MUST be traceable to at least one test that would fail if it were violated, through a mechanically checkable link — a shared identifier the test names, not a human's claim of coverage. Use when building from a spec, PRD, design

Similar plugins