kw-question

# /kw-question — from a vague idea to a good research question This is the **upstream** step. `/kw-explore` assumes you already have a question worth pursuing and builds the technical route to attack it. `/kw-question` decides **whether the question is worth asking at all**, and sharpens it until it is. Run this first when the user has an idea, a gap, or a stalled project — not yet a real question. > Method distilled from public research-craft sources — Alon & Fischbach (problem choice as a > trainable skill), Platt's *strong inference* (rival hypotheses + discriminating tests), > Alvesson & Sandberg (challenge hidden assumptions, not just gap-spot), the Heilmeier > Catechism (explicit goals/risks/success-failure criteria), Hamming & Nielsen (keep a list of > important, attackable problems) — and the synthesis in the **good-question** project > (<https://github.com/Rimagination/good-question>). Re-expressed here; credit to them. Outputs go in the **user's project** (a Question Card markdown). Nothing is written to the knowledge base — a question is not yet a principle. ## The bar: a question is "good" only if it has all seven 1. **Stakes** — answering it changes theory, method, practice, policy, or the next research step. 2. **Specificity** — evidence can directly touch it; it is not a topic. 3. **Rivalry** — at least 2-3 competing explanations exist. 4. **Falsifiability** — some achievable result could weaken, revise, or kill the claim. 5. **Pilot feasibility** — a credible proof-of-concept can start within ~2 weeks (or the user's stated constraint). 6. **Negative learning** — even a failed/negative result teaches something (a boundary, a mechanism, a method). 7. **Grounding** — claims trace to public sources, or are explicitly labeled as inference (do not invent field consensus). ## Workflow 0. **Diagnose the starting point.** Classify what the user actually has: a broad interest, a literature gap, a half-formed idea, a draft proposal, or a stalled project. The starting category determines what's missing. 1. **Ground a short domain brief** (only if the question is knowledge-dependent and you're unsure). Keep facts (with sources) separate from inference. If the library is linked, `kw search` the topic to see what mechanisms already exist — but do NOT invent consensus you can't ground. 2. **Diverge — generate candidate questions** with structured lenses, e.g.: - challenge a hidden assumption the field takes for granted (Alvesson & Sandberg); - flip the default / reverse the causal arrow; - name the *discriminating* observation two rival explanations would disagree on (Platt); - shrink scope until evidence can touch it; widen until it matters. Produce several variants, not one. 3. **Converge — filter by the seven-point bar.** Drop candidates that are only novel, have no audience, cannot fail, or teach nothing when negative. 4. **Rewrite weak forms into real questions.** A topic, a method, a benchmark, or "there's a gap in X" is NOT a question. Convert each into a testable proposition. 5. **Editor desk-reject pass.** For each survivor, state the single strongest reviewer objection and either fix it or discard the candidate. Be the harsh reviewer, not the cheerleader. 6. **Emit a Question Card** for each surviving question. ## Question Card → write to `<project>/problems/<slug>/QUESTION.md` ``` - Working title: - The question (1-2 sentences): - Why it matters (stakes): - Core assumption challenged: - Competing hypotheses (2-3): - Discriminating observation / experiment: - Falsification conditions (what result kills or revises it): - Two-week pilot (the cheapest credible proof-of-concept): - Strongest reviewer objection (+ your answer): - Best next action: - Grounding: [sources cited | labeled inference] ``` If several survive, present them ranked and let the user pick the one to pursue. ## Handoff — the user's choice After the card(s), ask explicitly: > "问题已经磨好了。要用 **/kw-explore** 把它做成技术路线吗?(映射原则库 → 找缺口 → 补读论文 → 组装带出处的方案。)还是先停在这张卡片?" - **Yes →** invoke `/kw-explore`. It takes `QUESTION.md` as its Phase 0 input: skip re-framing the *worth* of the question (already done here) and go straight to decomposing its **structure** for library matching. - **No →** stop. The Question Card stands on its own (e.g. for a proposal abstract or a lab discussion). Never push a question into the technical route the user hasn't chosen to pursue.