| name | self-consistency-check |
| description | Force the combination step that a weaker model can't do in one pass — surface conflicts between constraints, and interactions between requirements and edge cases, using a pairwise sweep, a fresh-context cold read by a subagent that never saw your reasoning, and N-version divergence on the hard kernel. Trigger this after producing a plan, design, spec, or multi-constraint solution and BEFORE committing to it — especially when the task carries more than ~3 interacting constraints, a schema/interface decision, or high stakes. Do NOT trigger for a single-constraint or trivial task (17.3 tiers say skip it), for reviewing an already-written code diff (that's code-review), or for verifying tests ran (that's verification-and-review). This skill checks that the DESIGN is internally consistent before code exists. |
Self-Consistency Check
Writing every constraint and edge case down makes a cross-term conflict visible; it does not
make it noticed. A weaker model can read a complete list and still miss that requirement 3
breaks edge case 7 — because noticing the interaction requires holding both in mind at once,
which is exactly the single-pass depth that doesn't transfer. This skill replaces that depth
with procedure: enumeration (which a weaker model does reliably) forced into combination
(which it doesn't do spontaneously). Run it on a plan/design/spec before you build.
Technique 1: Pairwise constraint sweep (always, for >3 constraints)
- List every constraint, requirement, and known edge case and number them C1..Cn. Pull them
from the spec, the plan, and your assumptions log — don't rely on memory.
- Build the grid. Down the side: each constraint. Across the top: each other constraint it
could plausibly interact with, plus each edge case. For every plausible pair (Ci, Cj), write
one of: compatible (one clause why) or CONFLICT (name it).
- Rules that make it real, not ritual:
- Do not skip a pair because it "feels fine" — that feeling is the miss you're hunting.
- Bound it to plausible interactions, not a blind N² (that's ceremony); but when unsure
whether a pair interacts, include it — the cost of a filled cell is one line.
- Every CONFLICT is either resolved in the design now, or logged as an explicit open
decision. A found-but-unresolved conflict is still a win — it's a bug caught pre-code.
Technique 2: Fresh-context cold read (for interacting/high-stakes designs)
You miss the conflict because you're anchored on the path that produced the design. Someone who
never walked that path is structurally better positioned to see it.
- Delegate to a subagent. Give it ONLY the artifacts — the spec and the plan/design.
- Withhold your reasoning trace. Do not tell it what you were thinking or why; that's the
anchor you're trying to escape. Hand it the reasoning and it inherits your blind spot.
- Ask exactly: "Which two statements here cannot both be true? Which requirement has no
handling for which edge case? What does this design assume that it never states?"
- Treat what it finds as findings to resolve, not opinions to weigh.
Technique 3: N-version divergence (for the hard kernel)
Parallelism substitutes for depth on the one part that matters most.
- Identify the hard kernel (problem-framing / §15.1) — the ~20% that decides the outcome.
- Spawn 2–3 subagents to solve just the kernel independently — they must not see each
other's attempts.
- Diff the results. Where they agree, you're probably safe. Where they diverge is the
load-bearing, uncertain decision — the exact spot a single pass would have committed to
blindly. Investigate every divergence; often one branch honored a constraint the others
dropped, which tells you both the right answer and which constraint was slippery.
Worked example
Design: a "share link" feature. Constraints gathered: C1 links expire after 7 days; C2 links are
revocable instantly; C3 access is logged for audit; C4 anonymous (unauthenticated) users may
open a link; C5 GDPR — a user can delete their account and all associated PII.
- Sweep finds what the list alone hid: (C3 × C5) — audit logs record who accessed a link,
but account deletion (C5) must purge PII, and access logs of the deleted user's links are
PII → CONFLICT: the audit-retention policy and the deletion guarantee are unspecified together.
(C4 × C3) — anonymous access logged how? no user id exists → what does "who accessed" even
mean → underspecified. Neither conflict is visible staring at C1–C5 as a list; both surface
the instant you fill the (i,j) cells.
- Cold read subagent, given only the spec, asks: "C2 says instantly revocable, C1 says
7-day expiry — is a revoked link's record kept until day 7 or purged immediately? The spec
never says." A third gap, caught by the un-anchored reader.
- Outcome: three interaction gaps found and resolved (or logged as decisions) before a line of
code — instead of shipping the happy path and discovering the GDPR conflict in an audit.
Done when
For the design under check: a pairwise sweep grid exists with every plausible pair marked
compatible-or-conflict; every conflict is resolved or logged as an explicit open decision;
for interacting/high-stakes designs a fresh-context cold read ran on the artifacts alone; and
for the hard kernel, either you were certain enough to skip divergence (say so) or 2–3
independent attempts were diffed and every divergence investigated. Then hand the consistent
design to task-planning / builder.
