Formalize problem
Formalize a research question into precise, testable hypotheses with model assumptions, core properties, and explicit success/failure conditions. Use when asked to formalize, define, or scope a research problem after paper analysis.From its SKILL.md
npx -y skills add SebastianElvis/reaper --skill formalize-problemAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
6.3 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
Formalize Problem
Transform a research goal into precise, testable hypotheses with explicit success/failure conditions.
Usage
Invoke this skill by name with the research goal as a quoted string. On slash-command hosts, prefix with / (e.g. /formalize-problem "<goal>").
formalize-problem "determine if the security proof in Section 4 holds under asynchrony"
Instructions
1. Read Inputs
Always read:
reaper-workspace/notes/clarified-goal.md— refined research goal, scope, assumptions, and success criteriareaper-workspace/notes/paper-summary.md— what the paper claims and how. If this file does not exist (paper-less mode), proceed without it — use the literature review and clarified goal as primary inputs instead.- The research goal from the argument (use the refined goal from
clarified-goal.mdif available)
Read selectively from:
reaper-workspace/notes/literature.md— focus on the "Key Prior Results" and "Gaps Identified" sections, not the full paper tables. Only deep-read individual paper entries if a specific prior result is needed for hypothesis screening. In paper-less mode, this becomes the primary technical context — read it more thoroughly.
2. Identify the Core Question
What exactly needs to be resolved? Be specific. "Is this protocol secure?" is too vague. "Does the safety proof of Protocol X hold when the adversary is adaptive rather than static?" is testable.
3. Pin Down Model Assumptions (must be unambiguous before hypotheses)
Pin down every dimension of the system/trust model. If any dimension is left vague, the investigation will produce ambiguous results. Consult ../reaper/references/model.md for the domain-appropriate checklist of dimensions that must be specified. Every field must have a concrete answer, not "TBD".
Every hypothesis must reference these model assumptions by specifying which parameters it holds under. A hypothesis that states a claim without pinning every relevant dimension is rejected.
4. Apply Importance Filter (Hamming)
Not all questions are equally worth investigating. Prioritize by consequence — ask: "If we resolved this question, who would care and why?" Consult ../reaper/references/model.md for domain-specific examples of how to rank by importance.
5. Apply Gap-Finding (Qian)
Map the dimensions of existing work and find unexplored combinations. Consult ../reaper/references/model.md for the domain-appropriate gap-finding matrix dimensions. Which cells in this matrix are empty? Those are candidate hypotheses.
6. Screen Against Known Impossibilities
For each hypothesis, check whether it contradicts a known impossibility or lower bound. Consult ../reaper/references/impossibility-results.md for the domain-relevant impossibility results and lower bounds.
If a hypothesis asks to prove something that an impossibility result rules out:
- Flag it explicitly in the hypothesis with a warning
- Reformulate: "Under what additional assumptions does this become possible?" or "What weaker property can be achieved?"
- Do NOT leave it as a hypothesis for the investigate skill to waste cycles on
7. Enforce Definitional Hygiene
Each core property listed in the output must be stated precisely. Consult ../reaper/references/definitional-standards.md for the domain-appropriate acceptable definition forms. Informal or ambiguous terms without formal definitions are NOT acceptable — different papers define the same terms differently, so pin it down. If the paper under analysis uses informal definitions, formalize them explicitly and note that you are doing so.
8. Write Output
Write to reaper-workspace/notes/problem-statement.md:
# Problem Statement
## Research Goal
[Restate the goal precisely]
## Model Assumptions
[One field per dimension from `../reaper/references/model.md`. Every dimension must have a concrete answer.]
## Security Properties Under Investigation
[What must hold? List each property with its formal definition or reference.]
1. **[Property name]**: [formal definition or citation]
2. ...
## Performance Metrics
[Concrete targets, if applicable]
- Communication complexity:
- Round complexity:
- Other:
Write ideas to a separate file reaper-workspace/notes/ideas.md:
# Ideas
## Initial Ideas
### H1: [Short descriptive title]
- **Statement**: [Precise, falsifiable claim — specific enough that a reader could disagree]
- **Success condition**: [What evidence would confirm this?]
- **Failure condition**: [What evidence would refute this?]
- **Priority**: High / Medium / Low
- **Rationale**: [Why this priority? What's the consequence of resolving it?]
### H2: [Short descriptive title]
...
Relationship to Brainstorm
/formalize-problem handles initial formalization: pinning down trust assumptions, the core question, definitional hygiene, and the first set of hypotheses. It runs once at the start of the pipeline. The /brainstorm skill handles recurring ideation — generating additional ideas as the investigation progresses, applying Hamming/Qian heuristics to current state, and proposing follow-up hypotheses based on patterns in results. /brainstorm updates the ideas.md that this skill creates (adding new ideas and editing existing ones inline).
Quality Criteria
- Every hypothesis is falsifiable — a reader could disagree with it
- Every hypothesis has explicit success and failure conditions — not "we'll know it when we see it"
- Priorities are justified by consequence, not convenience
- Trust assumptions are complete — no missing dimensions
- The hypotheses collectively cover the research goal — resolving all of them would answer the original question
- At most 5-7 hypotheses — focus beats breadth. If you have more, merge or drop the low-priority ones
clarified-goal.mdis always required — return an error if missing.paper-summary.mdis optional (absent in paper-less mode) — if missing, rely onliterature.mdandclarified-goal.mdinstead
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most research analysis skills give in ~1.3k tokens
Counted across 1,213 of the 2,113 authors here whose files we hold, read 2026-09-06
- Cite sources for every important claimin 47 of 1213, across 38 files
- Separate facts from inferences and recommendationsin 21 of 1213, across 12 files
- Write findings to a markdown filein 19 of 1213
- Label every insight with a confidence levelin 18 of 1213, across 8 files
- Read product marketing context before asking questionsin 18 of 1213, across 8 files
- Rank themes by frequency and intensityin 16 of 1213, across 6 files
- Establish research mode before proceedingin 16 of 1213, across 6 files
- Segment survey responses by customer tier or tenurein 16 of 1213, across 6 files
- Categorize support tickets before analyzingin 16 of 1213, across 6 files
- Weight research sources from the last twelve monthsin 16 of 1213, across 6 files
- Use at least five data points per segmentin 15 of 1213, across 5 files
- Extract verbatim quotes for all research findingsin 15 of 1213, across 5 files
Said here and by no other author read
- read clarified goal and paper summary
- define all system model assumptions
- prioritize questions by consequence
- identify gaps in existing work
- screen hypotheses against known impossibilities
- flag hypotheses contradicting impossibility results
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.