structured-research

structured-research validates an explicit assumption before it leaks into planning or code. It operationalizes the belief into a falsifiable question, recommends a research methodology from a catalog, gathers cited evidence, and returns a graded verdict (Confirmed / Refuted / Inconclusive) with an advisory recommendation.

Core principle: An assumption is not evidence. Evidence is not a verdict. A verdict is advisory, not a decree.

When to use itCopy Anchor Link

• A belief is still an assumption: "I think X works this way", "this library probably supports Y", "Z is the fast path".
• The assumption is about to enter planning/development unvalidated and the cost of being wrong is real.

When not to use it:

• Generating or exploring ideas → pocket-pitching / pocket-grinding (those diverge; this validates).
• Fixing a known defect → bug-hunting.
• The claim is settled and needs implementing → hotfix.

Boundary with pitching/grindingCopy Anchor Link

PrerequisitesCopy Anchor Link

One falsifiable assumption per run. If your belief bundles several claims, the skill asks which one to validate.

How to invoke itCopy Anchor Link

/pocketto:structured-research "is it true that Postgres floor-divides integers?"

On Pi: "validate this assumption", "is it true that", "research whether".

How it worksCopy Anchor Link

The three iron laws:

LAW 1: NO VERDICT WITHOUT EVIDENCE
LAW 2: SEEK REFUTATION, NOT JUST CONFIRMATION
LAW 3: THE VERDICT IS ADVISORY

1. Assumption intake: the belief is restated as a precise, testable claim; you confirm the restatement (silence is not confirmation).
2. Method selection: 1–3 methods from the catalog, always including at least one adversarial method (Falsification, Counterexample Hunt, Pre-Mortem…). A research run that only seeks confirmation is invalid. The recommendation is non-binding. You can pick, drop, or combine.
3. Evidence gathering: the right tool per method, with Context7 for library claims, web search for published facts, code scans for project-internal behavior. Every finding carries its source; no source, not evidence.
4. Curation gate: after all evidence, an advisor pass pressure-tests it (strong vs weak, contradictions, gaps). If no advisor is available, the curation runs inline with that explicitly stated. The gate is never skipped; only its executor changes.
5. Graded verdict: Confirmed | Refuted | Inconclusive with confidence, tied to cited evidence, plus what would change this verdict and a non-binding recommendation.

Outputs and artifactsCopy Anchor Link

docs/pocket/research/YYYY-MM-DD-kebab-slug/research-report.md

Approval gates and constraintsCopy Anchor Link

• The operationalized question must be explicitly confirmed before research starts.
• The verdict is advisory: the maintainer decides. Next-step options (adopt, run again, carry into grinding/planning, stop) are presented, not executed.
• A verdict without cited sources cannot be produced; refutation is mandatory.

ExampleCopy Anchor Link

Illustrative: "our Postgres driver retries idempotently" → operationalized to the exact retry semantics on the installed version; methods: Documentation-vs-Reality Check (triangulation) + Falsification (adversarial); evidence from version-matched docs and a reproduction test; verdict Refuted (medium confidence) with the counter-evidence cited and a recommendation to add an idempotency key.

Related documentationCopy Anchor Link

• Grinding: where a confirmed input goes next
• Structured planning
• Standalone skills