{"code":0,"data":{"id":548,"slug":"falsify-the-problem","name":"falsify-the-problem","tagline":"Challenge the current problem formulation before solving it. Use when explicitly invoked, or when…","description":"## Overview\n\nChallenge the current problem formulation before solving it. Use when explicitly invoked, or when meaningful framing uncertainty and non-trivial intervention cost or risk coexist; do not auto-activate for verified diagnoses or mechanical edits.\n\n# falsify-the-problem\n\n> Falsify the problem before solving it.\n\nAnswer **Are we solving the right problem?** Challenge the current formulation,\nseek disconfirming evidence, and hand the result back to the host agent.\nDo not design or implement the solution inside this skill.\nUse the same protocol across domains; examples are not domain-specific workflows.\n\n## 1. Decide whether to enter\n\n- Explicit invocation of `falsify-the-problem`: always enter. Strong existing\n  evidence can justify a brief `KEEP` without alternatives or a new test.\n- Automatic activation: require BOTH meaningful formulation uncertainty AND\n  non-trivial intervention cost or risk. Neither alone is enough.\n- Useful signals include solution-shaped requests, a hypothesis treated as fact,\n  repeated failed attempts, and costly or hard-to-reverse proposed changes.\n  Signals are reasons to check the gate, not unconditional triggers.\n- Usually do not auto-activate for a verified diagnosis, obvious syntax or\n  compilation error, typo, translation, formatting, mechanical transformation,\n  deterministic local edit, or very cheap reversible intervention.\n- Mere logical possibility of another explanation is insufficient.\n\n`BYPASS` is an activation decision, never an evidence verdict. When bypassing,\nleave the original task with the host; do not manufacture an adversarial report.\nIf explicitly invoked on a supported diagnosis, use `KEEP`, not `BYPASS`.\n\n## 2. Separate the claims and preserve their sources\n\nDistinguish these five objects, even when the user combines them in one sentence:\n\n| Object | Meaning | Example |\n| --- | --- | --- |\n| Observation | Something observed, measured, or reported | User reports P99 rose from 300 ms to 2.8 s |\n| Interpretation | Meaning assigned to an observation | The database is slow |\n| Causal Hypothesis | A specific mechanism proposed to explain it | Lock contention delays requests |\n| Problem Formulation | What kind of problem is being solved | Database service time dominates the slow tail |\n| Solution | A proposed intervention | Add Redis |\n\nObservation != Interpretation != Causal Hypothesis != Problem Formulation != Solution.\n\nFor each consequential observation, retain the source and relevant scope:\n\n- `tool-observed`: name the file, command, trace, or other inspected artifact.\n- `user-reported`: retain attribution, including measurements supplied by a user.\n- `document-reported`: identify the document and its claim.\n- `experimentally observed`: identify the experiment and conditions.\n- `measurement-derived`: identify inputs, transformation, and sampling limits.\n\nThese labels can combine. Reading a report with a tool verifies what the report\nsays, not that its underlying claim is true. A local simulated fixture is evidence\nabout that fixture, not independent verification of a real incident.\nNever upgrade user reports into independently verified facts.\nRecord uncertainty about coverage, freshness, comparability, or missing data\nwhere it could change the conclusion. Do not fabricate observations or execution.\n\nState the **Current Problem Formulation** explicitly. If inferred from a proposed\nsolution, mark it as inferred; do not attribute it to the user as a stated belief.\nKeep this original formulation as the reference for the overall verdict through\nthis pass. A replacement is `REFORMULATE`, not a silently relabeled `KEEP`.\nPreserve claim strength: a possible contributor, a primary explanation, and an\nexclusive explanation are different claims. Do not infer exclusivity from a\nproposed solution or refute a stronger claim than the request requires.\n\n## 3. Build materially different live formulations\n\nAsk what would change the kind of problem being investigated. Competing causes\nwithin one formulation are not automatically competing problem formulations.\n\nTwo formulations should materially differ in at least one consequential dimension:\nfailing variable, mechanism class, abstraction level, system boundary, expected\nevidence, investigation path, or intervention target.\n\nIf two formulations predict nearly the same evidence and lead to nearly the same\ninvestigation path, they are probably superficial variants. Merge them.\nFor example, weak embeddings, small embeddings, and old embeddings usually belong\nto one representation-quality formulation. Retrieval construction, ranking,\ngeneration grounding, evaluation validity, and query distribution can change the\nframing when they predict meaningfully different evidence.\n\nKeep only plausible, decision-relevant alternatives. Do not mechanically fill a\nquota. Let evidence and the pending decision determine the live set; more\ncandidates are not evidence of better reasoning. Presentation limits in section 9\ndo not justify dropping a materially different, decision-relevant candidate.\n\nCandidates need not be mutually exclusive. If several mechanisms coexist, test\nwhich framing explains the material failure at the relevant scope; do not force a\nwinner from evidence that supports a mixed or narrower formulation.\n\n## 4. Find load-bearing assumptions and distinct predictions\n\nPrioritize assumptions whose failure would materially weaken or collapse a live\nformulation. Avoid exhaustive lists or generic questions about everything.\nInclude measurement validity only when it bears on the decision.\n\nFor each important live formulation, connect:\n\n`Formulation -> load-bearing assumption -> observable prediction -> contrary evidence`\n\nA prediction must distinguish live formulations, not restate their names.\nExample: a service-time framing predicts elevated service spans in slow requests;\na capacity framing predicts rising pre-service wait with concurrency; a measurement\nframing predicts disagreement between raw samples and reported aggregation.\nState the population, comparison, and meaningful difference when available.\nDo not invent numerical thresholds without a basis; explain qualitative criteria.\n\nBefore choosing the test, make one lightweight **Shared-Frame / Coverage Check**:\ndo the live formulations all rely on one consequential, untested premise about\nthe relevant boundary, measurement path, causal layer, population, time scope,\nor optimization target? Select what matters here; do not audit a category checklist.\nIf that premise failing would undermine the whole set, and a plausible alternative\nwould change the decision and predict different evidence, add at most **ONE\nOutside-Frame Challenger**. Name the shared premise and its contrasting prediction\nbriefly when decision-relevant. Generic \"measurement could be wrong\" is insufficient;\nground the challenger in this task. If none is warranted, proceed without one.\nDo not chain coverage audits or expand the set merely to satisfy a quota.\n\n## 5. Select ONE Primary Discriminating Test for this round\n\nWhen beginning an investigation round under unresolved uncertainty, choose\n**exactly ONE Primary Discriminating Test**. This is one per round, not one forever.\nChoose the cheapest currently available test with substantial discriminatory\ninformation relative to cost, risk, and execution time.\n\nAsk: would plausible different outcomes materially change the relative support\nof the live formulations? If not, choose a better test.\nAn outcome predicted by several live formulations may localize the failure without\ndistinguishing them. Prefer a matched comparison that separates the relevant\nfactor; otherwise retain those formulations rather than assigning the outcome\nto one by default.\n\nSpecify:\n\n- **Test:** one bounded comparison or observation, its source, and its scope.\n- **Why this first:** which live formulations it separates and why its value\n  exceeds the cost of the next plausible option.\n- **Possible outcomes:** what would strengthen, weaken, or kill which candidates.\n  Include inconclusive or mixed outcomes where plausible.\n- **Remaining uncertainty:** what this test cannot establish.\n\nOne test can require several retrieval or computation steps if they serve one\npredeclared comparison and\n\n## Source\n- Repo: https://github.com/ordinary-s/falsify-the-problem\n- Path: (repo root)","category_id":6,"author":"ordinary-s","repo_url":"https://github.com/ordinary-s/falsify-the-problem","install_cmd":"","tags":["ordinary-s","github"],"score":8.8,"quality":7.5,"usability":9.6,"security":10,"popularity":5,"stars":42,"views":2,"verified":1,"created_at":"2026-09-17 07:07:41","updated_at":"2026-09-17 07:07:43","current_version":"1.0.0","downloads":14,"icon_url":"","structure":6,"content":10,"engineering":10,"assessment":{"total":88,"vetoed":false,"date":"2026-09-17","notes_en":"Single-file adversarial-framing methodology skill (from ordinary-s/falsify-the-problem): challenges the problem formulation before solving, with a five-object claim taxonomy, one Primary Discriminating Test per round, evidence-update labels and a KEEP/WEAKEN/KILL/REFORMULATE/INSUFFICIENT-EVIDENCE verdict system. Capability manifest (6.0): reads only the user's request and project evidence via host tools (read-only exploration explicitly bounded to the comparison); side effects: none — implementation, migration and expensive changes are explicitly prohibited before validation; network destinations: none in skill content; credentials: none; persistence: none. Capabilities match declared scope. Package ships repo artifacts (README x2, SEO.md, docs/ marketing site, evals/ suite) alongside the skill.","dims_en":{"d1":"Precise activation gate (explicit invocation OR uncertainty+cost conjunction, with an explicit do-not-auto-activate boundary); keyword/synonym richness is thin for a philosophy-flavored skill.","d2":"292-line self-contained SKILL.md with no offloading (defensible for a protocol), but the distributed package mixes README/README.zh-CN/SEO.md, a docs/ static site and an evals/ suite into the skill bundle.","d3":"Superb protocol design: entry gating, claim-strength preservation with provenance labels, material-difference merging rules, exactly-one discriminating test per round with outcome maps, honest evidence-update semantics (missing evidence is not contrary evidence), STOP conditions, and tiered compact-output paths with delta reporting.","d4":"Exceptionally precise, internally consistent writing; every rule is falsifiable and anti-quota; no contradictions found across SKILL.md and evals.","d5":"Valid minimal frontmatter; no scripts by design; no internal path references to break; docs site links are external and valid.","d6":"Capability manifest matches declared scope: no scripts, no network, no credentials, no persistence; docs site is static with no tracking; strong honesty rules (never upgrade user reports to verified facts, do not fabricate observations or execution)."}},"dyn_test":null,"category_slug":"productivity","category_name":"Productivity","category_icon":"⚡","versions":[{"version":"1.0.0","changelog":"Imported from ordinary-s/falsify-the-problem@master","file_size":350724,"created_at":"2026-09-17 07:07:43"}],"related":[{"slug":"academy-guide","name":"academy-guide","tagline":"Stop and check this skill before finishing any reply to a question about how to use Claude or a C…","score":9.6,"category_icon":"⚡"},{"slug":"threejs-world-generation","name":"threejs-world-generation","tagline":"Build deterministic, editable, free-viewpoint Three.js worlds from text or structured briefs. Use…","score":9.6,"category_icon":"⚡"},{"slug":"linkedin-reply-handler","name":"linkedin-reply-handler","tagline":"Draft a reply to one LinkedIn comment from its URL, or sweep a whole thread from just the post UR…","score":9.5,"category_icon":"⚡"},{"slug":"ponytail-audit","name":"ponytail-audit","tagline":"Whole-repo audit for over-engineering. Like ponytail-review, but scans the entire codebase instea…","score":9.5,"category_icon":"⚡"}],"topic":{"slug":"jev-agent","title":"Jev & Agent Workflow"}}}