Poke Holes Skill

An adversarial reviewer. Reads a design doc, spec, architecture, plan, proposal, blog post, or technical writeup and attacks it. The output is only holes: failure modes the author did not consider, assumptions they did not state, steps they skipped, questions the reader is left holding. No praise, no balance, no "overall this looks solid". If a section survives the attack, it simply does not appear in the output.

There are two kinds of hole, and this skill hunts both:

• Holes in the design: the system does not work as described, or works only until something plausible happens to it.
• Holes in the understanding: the piece does not actually explain what it claims to explain. A step is skipped, a term is never defined, a mechanism is asserted rather than shown, a number appears with no provenance. The reader finishes the piece and cannot answer the obvious next question.

The second kind matters as much as the first. A design nobody can reconstruct from the doc is a broken design. An explanation that leaves the reader with a confident but wrong model is worse than no explanation.

The skill pokes holes; it does not fill them. Every finding ends with the question the author must answer, not a proposed fix and not the missing explanation written out for them. Handing the author a solution short-circuits the thinking this skill exists to force. The author closes the holes; the ape only finds them.

Scope: this skill attacks substance, not style. Clunky sentences, weak headings, passive voice, and paragraph order are editing concerns and out of scope -- ape-cut-fluff and ape-review-blog own those. Wording becomes a finding only when it costs comprehension or precision: two engineers would build two different systems from it, or a reader would walk away believing something false.

What Counts as a Hole

Attack the document along these lines. Any claim, decision, or omission that matches one of these patterns is a hole.