formalize-problem · diff
git:20260502.5bc84e8 to git:20260912.5e86435
44 added, 74 removed. Audit A to A.
---
name: formalize-problem
- description: "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."
+ description: "This skill defines a research question as testable hypotheses. You use it to specify model assumptions, properties, and success or failure conditions."
user-invocable: true
argument-hint: "<research-goal>"
license: Apache-2.0
---
# Formalize Problem
- Transform a research goal into precise, testable hypotheses with explicit success/failure conditions.
+ You must read and apply the [language rules](../reaper/references/language.md) before you write any output.
## 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>"`).
+ You invoke this skill by name with a quoted research goal. Slash-command hosts use `/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 criteria
- - `reaper-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.md` if available)
+ You read these inputs:
- **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.
+ - `reaper-workspace/notes/clarified-goal.md` supplies the goal, scope, assumptions, and success criteria.
+ - `reaper-workspace/notes/paper-summary.md` supplies the paper's claims, if this file exists.
+ - The argument supplies the initial goal. You prefer the refined goal in `clarified-goal.md`.
- ### 2. Identify the Core Question
+ You read Key Prior Results and Gaps Identified in `reaper-workspace/notes/literature.md`. You read individual paper entries when hypothesis checks need them. Without a paper summary, you use the literature review as the main technical input. You read it in more detail in this case.
- 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.
+ ### 2. Define the Core Question
- ### 3. Pin Down Model Assumptions (must be unambiguous before hypotheses)
+ You state the exact claim with its property and adversary model.
- 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".
+ ### 3. Specify Model Assumptions
- 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.
+ You use the model dimensions in `../reaper/references/model.md`. You give a concrete answer for each applicable dimension before you create hypotheses. You do not leave fields as `TBD`. Each hypothesis specifies all model parameters that its claim needs.
+ You reject a hypothesis that omits a relevant dimension.
- ### 4. Apply Importance Filter (Hamming)
+ ### 4. Set Priorities
- 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.
+ You rank questions by the effect of their answers. You state who needs the answer and why. You use the domain examples in `../reaper/references/model.md`.
- ### 5. Apply Gap-Finding (Qian)
+ ### 5. Find Research Gaps
- 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.
+ You map existing work across the dimensions in `../reaper/references/model.md`. You use empty combinations as candidate hypotheses.
- ### 6. Screen Against Known Impossibilities
+ ### 6. Check Impossibility Results
- 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.
+ You check each hypothesis against `../reaper/references/impossibility-results.md`. If a known impossibility or lower bound rules out the claim, you take these actions:
- If a hypothesis asks to prove something that an impossibility result rules out:
- 1. **Flag it explicitly** in the hypothesis with a warning
- 2. **Reformulate**: "Under what additional assumptions does this become possible?" or "What weaker property can be achieved?"
- 3. Do NOT leave it as a hypothesis for the investigate skill to waste cycles on
+ 1. You identify the conflict in the hypothesis.
+ 2. You change the question to specify additional assumptions or a weaker property.
+ 3. You remove the impossible positive claim from the investigation queue.
- ### 7. Enforce Definitional Hygiene
+ ### 7. Define Properties
- 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.
+ You use the definition forms in `../reaper/references/definitional-standards.md`. You give each core property a precise definition. If the paper uses an informal definition, you provide a formal definition. You state that you made this definition.
### 8. Write Output
- Write to `reaper-workspace/notes/problem-statement.md`:
-
- ```markdown
- # 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`:
-
- ```markdown
- # Ideas
+ You write `reaper-workspace/notes/problem-statement.md` with title `# Problem Statement` and these level-two sections:
- ## Initial Ideas
+ - **Research Goal:** You state the precise goal.
+ - **Model Assumptions:** You give concrete answers for all applicable model dimensions.
+ - **Security Properties Under Investigation:** You give each property a formal definition or citation.
+ - **Performance Metrics:** You state applicable communication, round, and other targets.
- ### 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?]
+ You write `reaper-workspace/notes/ideas.md` with title `# Ideas` and section `## Initial Ideas`.
+ Each hypothesis uses `### H1: [Short title]`, with consecutive H numbers.
+ Each entry has these fields:
- ### H2: [Short descriptive title]
- ...
- ```
+ - **Statement:** You state a precise claim that evidence can refute.
+ - **Success condition:** You state the evidence that confirms the claim.
+ - **Failure condition:** You state the evidence that refutes the claim.
+ - **Priority:** You use High, Medium, or Low.
+ - **Rationale:** You explain the effect of resolving the claim.
- ### Relationship to Brainstorm
+ ## 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).
+ This skill defines the initial problem. The `brainstorm` skill revises ideas during investigation. The orchestrator can repeat formalization when the problem changes.
- ### Quality Criteria
+ ## 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.md` is always required — return an error if missing. `paper-summary.md` is optional (absent in paper-less mode) — if missing, rely on `literature.md` and `clarified-goal.md` instead
+ - The hypotheses together answer the research goal.
+ - You limit the initial set to 5-7 hypotheses. You combine or remove less important ideas if necessary.
+ - If `clarified-goal.md` is missing, you return an error.
+ - If `paper-summary.md` is missing, you use `literature.md` and `clarified-goal.md`.