resolve-beagle

# Resolve: Close Spec Gaps

Take a spec produced by `brainstorm-beagle` and close its remaining gaps — both the explicit Open Questions and the latent ones the self-review missed — by researching, proposing answers, and rewriting the spec in place.

The terminal state is a spec with no known open questions and no placeholder requirements. Planning can start immediately after.

<hard_gate>
This skill does not write code, scaffold projects, design architecture, or create implementation plans. It only edits the spec document. "Answering an open question" means proposing a WHAT/WHY answer with rationale — never a HOW. If a question turns out to require implementation design, defer it with a note and move on.
</hard_gate>

## Gates (pass before next step)

Objective pass conditions so steps are not skippable by assertion alone:

1. **Spec located** — The target file path is known and `Read` succeeds (or the user supplied a valid path after you listed 3–5 recent `docs/specs/` candidates).
2. **Gap list published** — One message lists every explicit Open Question bullet **and** each latent gap you will treat as in-scope. **Do not dispatch research** until the user adjusts the list (add/remove/defer) **or** explicitly tells you to proceed with that list.
3. **Research artifact per gap** — Before you present a proposal for gap *G*, you have a structured note for *G*: recommended answer, 1–2 rejected alternatives with reasons, and evidence (file:line, URL, or in-spec citation). No proposal without that artifact.
4. **One proposal queue** — Do not open the next gap’s proposal until the current gap has a clear outcome (accepted, revised wording applied, rejected with what happens next, or deferred with reason).
5. **Rewrite reconciled** — After editing, you read the full spec once and resolve cross-section contradictions; then run the self-review checklist from `../brainstorm-beagle/references/spec-reviewer.md` with failures fixed in-session unless the user opts for a follow-up pass.
6. **Commit** — No `git commit` unless the user answered yes to the commit prompt in § Committing.

## Workflow

1. **Locate the spec** — explicit path from the user, or the most recent file in `docs/specs/`
2. **Extract gaps** — parse Open Questions *and* audit for latent issues (placeholders, vague requirements, missing rationale, contradictions)
3. **Show the gap list** — present everything you plan to close in one summary so the user can add or remove items before research starts
4. **Dispatch research** — one task per gap, in parallel via subagents when available; otherwise sequentially inline
5. **Propose answers** — one proposal at a time, with recommendation + alternatives + evidence
6. **Rewrite the spec in place** — migrate resolved items to the right sections; nothing silently dropped
7. **Self-review** — same checklist `brainstorm-beagle` uses (see `../brainstorm-beagle/references/spec-reviewer.md`)
8. **Ask about committing** — prompt the user whether to commit the edit; don't commit unprompted

```
Locate spec → Extract gaps → Show list ──→ User adds/removes
                                          → Dispatch research (parallel if possible)
                                          → Propose answers (one at a time)
                                                → User decision → next
                                          → Rewrite spec in place
                                          → Self-review (fix inline)
                                          → Ask about committing
```

## Locating the spec

If the user gave a path, use it.

Otherwise, list the 3–5 most recently modified files in `docs/specs/` and ask: "Work on `<most recent>`, or another one?" Don't scan the whole directory tree — specs are top-level per `brainstorm-beagle`'s convention.

If no spec directory exists, ask the user for the path.

## Extracting gaps

Two categories count as gaps:

**Explicit gaps** — every bullet under the spec's `Open Questions` heading is one research task.

**Latent gaps** — issues that slipped past the brainstorm's self-review. Scan the spec for:

| Problem | What it looks like |
|---------|-------------------|
| Placeholder | TBD, TODO, "to be determined", ellipsis used as content |
| Vague requirement | "fast", "simple", "good", "user-friendly", "intuitive" — nothing to verify against |
| Missing rationale | Constraint or Out-of-Scope item with no "why" |
| Contradiction | Requirement conflicts with another requirement, with a constraint, or with Out of Scope |
| Untestable success | No observable way to verify the requirement was met |
| Implementation leakage | A requirement prescribes HOW instead of describing WHAT |

The reason to treat latent gaps as first-class: a spec that says "fast" or "good UX" hasn't been answered just because nothing was explicitly flagged. Planning will trip over those same words. Close them here.

Before dispatching research, show the combined list to the user in one message — "here's what I'm planning to close" — and let them add, remove, or defer items. Don't ask permission one-by-one; that's the proposal step.

## Dispatching research

Each gap gets exactly one research task. Classify each task first — the type determines which tools the research needs:

| Task type | Looks like | Tools |
|-----------|-----------|-------|
| Codebase pattern | "How does the existing `--start-at` pattern work?" "Where is `SKILL_MAP` defined?" | search the codebase (grep/glob/read) |
| External / API | "What does the agent's SDK expose for sub-agent spawning?" "Does Codex have hooks?" | web search and page fetch (if web access is available) |
| Design tradeoff | "What should the merged report format be?" "How should deduplication work?" | Reasoning + analogous reference points already in the spec |
| Scope / policy | "Should config/docs files route to a stack or fallback?" | Reasoning tied to the spec's own Core Value and Constraints |

### With subagents (preferred)

**If the agent supp