| name | crypto_skeptical-review |
| description | Perform adversarial review as a manager-invoked skill. Challenge optimistic narratives, find stale dependencies, demand discriminative tests, and emit durable skeptical review artifacts before hypotheses, validation claims, or solver readiness are accepted. |
Crypto Skeptical Review
Purpose
Use this skill whenever the manager needs a structured skeptical pass. This is not a second agent. It is a review skill invoked by the single manager to deliberately shift from proposal mode into challenge mode. The goal is to reduce overconfidence, surface hidden assumptions, and produce a durable challenge record that a human can audit.
The skill exists because proof-oriented cryptanalysis fails when promising stories are allowed to mature into solver logic without resistance. The manager must therefore pause at specific checkpoints and run a skepticism pass that tries to break the current narrative using the existing artifacts, dependency graph, invalidation map, and branch-specific evidence.
When to use
Invoke this skill at a minimum in the following moments:
- after hypotheses have been constructed and prioritized
- after meaningful validation results exist and before a hypothesis is treated as operationally verified
- before solver readiness is accepted and before the final solver is treated as deterministic
Also invoke it when:
- a branch changes materially
- a specialist path introduces new assumptions
- remote behavior looks stateful or unstable
- artifacts were invalidated and then regenerated
- the leading path changed because of research or decode reinterpretation
- two plausible paths remain live and the manager is tempted to collapse them too early
Required inputs
Review all relevant upstream artifacts, including but not limited to:
artifacts/hypotheses.jsonartifacts/out/hypothesis_matrix.jsonartifacts/out/hypothesis_priority.jsonartifacts/out/hypothesis_scores.jsonartifacts/out/validation/validation_index.jsonartifacts/out/validation/validation_summary.jsonartifacts/out/findings.jsonartifacts/out/solver_plan.jsonartifacts/out/solver_verification.jsonartifacts/out/dependency_graph.jsonartifacts/out/invalidation_rules.jsonartifacts/out/hash_report.json- any branch-specific decode, hybrid, oracle, or specialist artifacts
Required outputs
Produce the review artifact that matches the review moment:
artifacts/out/verifier/hypothesis_challenge.jsonartifacts/out/verifier/validation_challenge.jsonartifacts/out/verifier/solver_readiness_review.json
You may also write supporting notes under artifacts/out/verifier/ when the challenge cannot be captured cleanly in a single structured artifact, but the canonical review artifact for the phase is still mandatory.
Review method
For each claim set under review:
- restate the claim narrowly and without flourish
- identify every dependency artifact the claim relies on
- mark the weakest dependency in the chain
- identify the cheapest discriminative test that would falsify the claim
- check whether that test already exists and whether it still survives invalidation rules
- identify stale assumptions, removed alternatives, and branch-merge mistakes
- record whether the claim is accepted, disputed, or conditionally acceptable
- if conditional, state the exact gating evidence still missing
What to challenge
The skill should aggressively search for:
- unsupported jumps from data to interpretation
- decode ambiguity quietly treated as certainty
- transport or formatting artifacts mistaken for cryptographic evidence
- stale summaries whose inputs changed after hashing or invalidation
- vulnerability-family confusion, especially across RSA, stream/XOR, oracle, or hybrid routes
- branch collapse where multiple plausible paths were merged too early
- solver determinism claims that still depend on timing, luck, or manual judgment
- feasibility claims without measured throughput or bounded cost
- findings summaries that still mention removed hypotheses, removed caps, or invalidated sub-results
Edge-case catalog
Pay extra attention to recurring process failures:
- score inflation after research without new local evidence
- repeated-key or nonce-reuse claims from too few samples
- remote transcripts assumed stateless when the remote is actually stateful
- RSA routes chosen because of large integers without checking framing or encoding first
- oracle routes chosen because of response variance that is really transport noise
- decode branches accepted without preserving ambiguity and confidence
- final summaries that retain indirect references to removed routes
- solver plans that silently rely on fixtures, comments, or hardcoded examples rather than live challenge values
Validation gate
A skeptical review artifact passes only if it:
- names the reviewed claim set
- lists the dependency artifact set
- names the main disputes or confirms that no material disputes remain
- states the missing tests, if any
- records the final disposition as
accepted, disputed, or conditional
- contains enough detail that the manager can act on it without re-deriving the challenge logic
An empty agreement note is not a valid review. A rubber stamp is a failure. The review must either challenge the path or explain why the path survived challenge.
