formalize-problem git:20260412.0de6bfaA

Immutable. This exact content never changes and is served at /api/v1/blob/13a11ac496149221.

---
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."
user-invocable: true
argument-hint: "<research-goal>"
---

# Formalize Problem

Transform a research goal into precise, testable hypotheses with explicit success/failure conditions.

## Usage

```
/reaper: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)

**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 `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 `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 `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 `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:
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

### 7. Enforce Definitional Hygiene

Each core property listed in the output must be stated precisely. Consult `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`:

```markdown
# Problem Statement

## Research Goal
[Restate the goal precisely]

## Model Assumptions
[One field per dimension from 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

## 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.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