propose-answers
For each gap a drive's search could not close and only the person can confirm — who may decide, how we will know it works, how big it will get — draft our own proposed answer from what the drive's sou
SKILL.mdcore/components/skills/propose-answers/SKILL.md
GitHubpropose-answers
A person who gave a loop a prototype knows what it is for. A list of questions makes them do the loop's work. This skill does that work: it drafts the answer we would put, from what we already saw, and shows why — so the person only says yes or corrects.
Input
| Field | Required | Meaning |
|---|---|---|
gaps |
yes | The search groups still partly or open that research cannot answer — each with its plain question, what is missing, and any partial answer |
sources |
yes | The loop's Source evidence (for a prototype: views, journeys, the page) |
run |
yes | What the loop made: the proposed intents, the domain, its capabilities (the product model's files for this run) |
out |
yes | Where to write the proposals (<working>/proposals.json) |
Process
- For each gap, ask first: does the context already settle it? A product the prototype shows
as an internal tool has no revenue question; a tool the prototype shows one person using is
not asked about teams of thousands. If so, close it
settled, say what settles it, and name what that rests on (basis: the quote, screen or trace). A settled point is shown to the person in the brief; it is never dropped silently. - Otherwise draft our proposed answer — the answer we would put if no one corrected us:
- start from what the source shows (one reviewer on every screen → "the person who asked decides"), what memory holds, and what the run made (a counter of what waits → "settled when nothing waits");
- make it concrete and checkable (a number, a role, a rule), never "it depends";
- mark a value the person must set (a target, a period) as our default, not a fact.
- Write its basis — the quote, screen, memory trace or reasoning it rests on — and its context — the one or two facts the person needs to judge it without opening the prototype.
- Never write a question as a proposal, and never answer from the model alone. If nothing in
the source, memory or the run supports an answer, the gap stays open for research
(
author-knowledge-page) — not a guess.
Output
proposals.json: {"proposals": [{"group", "closed_by": "proposal | settled", "answer", "basis", "context", "why"}]} — answer, basis and context for a proposal; why and
basis for settled.
Rules
- No basis, no proposal: every proposed answer names what it rests on.
- Sample data is sample data: the shop inside a review tool's mockup tells you how the tool shows things, not facts about the tool's own users.
- Never decide for the person; a proposal is what they confirm or correct.