Good Question

Help a researcher turn a vague interest, literature gap, rough idea, failed project, or proposal draft into a strong scientific question. Do not merely list ideas; shape questions until they are important, tractable, falsifiable, and easy to defend to a skeptical colleague.

Integration with stable-jarvis

This skill is deployed as a first-class skill within the stable-jarvis project (位于 skills/good-question/). It interoperates with the existing research toolchain.

Enhanced Retrieval: Tool Mapping

When the workflow calls for "enhanced retrieval" (增强检索), use the following stable-jarvis native tools instead of generic web search. Choose based on what evidence is needed:

For semantic search over Obsidian, always check index freshness first (build_index.py --stats) before searching. The index at temp/obsidian/embeddings.json is shared with paper-deep-reader — if a deep read was just completed, the index is likely current.

Three-Source Retrieval Strategy

The tools above map to three complementary knowledge sources. Follow this tiered approach — exhaust closer sources before reaching outward:

Tier 1 — Obsidian Vault (primary): This is your curated cyber brain. Search exhaustively with multiple query angles before moving on. Use mcp__obsidian__search_notes for keyword search and obsidian-semantic-search for conceptual search. Follow [[wikilinks]] trails between notes. Read every relevant note in full.

Tier 2 — Zotero Library (secondary): Bridges your notes to published literature. Use mcp__zotero-mcp__search_library for keyword search, mcp__zotero-mcp__semantic_search for conceptual discovery, and mcp__zotero-mcp__get_content for full-text reading.

Tier 3 — Web Search (complement): Use web-research, exa-search, or arxiv-search when (a) the user requests current literature, (b) Obsidian + Zotero return insufficient results for a decisive claim, (c) the field is fast-moving and curated sources may be outdated, or (d) you need to verify whether a claimed literature gap genuinely exists. Web search results feed into the analysis body; they do not need separate listing in the final card.

Bridge with paper-deep-reader

When the user invokes good-question after completing a paper-deep-reader analysis, the deep-reader output provides a rich starting point that should be consumed directly rather than starting the workflow from zero.

Detection: Check whether outputs/deep-reader/{item_key}/ exists and contains:

• report.md — the full deep-reading report
• good-question-bridge.json — structured bridge file (generated by paper-deep-reader Phase 8)
• zotero_kb.json — Zotero knowledge base search results
• meta.json — paper metadata

Consumption:

1. If good-question-bridge.json exists, load it directly. It contains pre-extracted stated limitations, implied weaknesses, future directions, and personal insights — these map to the "Has a candidate idea" starting state in the workflow (Step 1 diagnosis)
2. If only report.md exists, read the "局限性与未来方向" (Limitations & Future Directions) and "个人评价与启发" (Personal Insights) sections — these become the candidate ideas
3. The zotero_kb.json and obsidian_kb.json (if present) provide pre-built Domain Brief material — do not rebuild from scratch. Use these to identify what related work already exists and what gaps are genuine
4. The meta.json provides the source paper's title, authors, arxiv ID — use this to establish what has already been done (the deep-reader paper itself), so candidate questions are positioned beyond it

Workflow shortcut: When bridge files are detected, the workflow compresses:

• Step 0 (Information Gate): context is already rich → skip to Step 1
• Step 1 (Diagnose): auto-set to "Has a candidate idea" with multiple specific starting points
• Step 2 (Build Context): pre-filled from meta.json + KB files + bridge file

Good Question Cards and all intermediate analysis are written to two locations:

Obsidian vault (primary, for knowledge persistence):

• Good Question Cards → 00 Inbox/Research Questions/{paper_title_short} - Research Question.md
• Use [[wikilinks]] to link back to:
  • The deep-reader report (if applicable): [[{paper_title} Deep Reading Report]]
  • Related KB notes identified during analysis
  • Relevant Zotero entries
• Frontmatter includes: tags, source paper, date, zotero_key (if applicable)

outputs/ directory (for process archival and debugging):

• Full analysis record → outputs/good-question/{item_key or date}/
  • domain-brief.md — compact Domain Brief with evidence ledger
  • candidates.md — all candidate questions with scores and lens annotations
  • shortlist.md — ranked shortlist with repair/rejection notes
  • editor-desk-gate.md — desk-reject checks for top candidates
  • good-question-cards.md — final Good Question Cards
• If bridged from paper-deep-reader, use the same item_key for cross-referencing

Output Configuration

Operating Principles

• Prefer one sharp question over many decorative ideas.
• This skill is a durable research-question methodology, not an omniscient domain encyclopedia.
• Treat novelty as insufficient unless the question also matters.
• Separate a topic, a problem, a hypothesis, and a project plan.
• Make hidden assumptions explicit before proposing methods.
• Ask at most one short clarifying question if the field, constraint, or existing idea is missing; otherwise proceed with stated assumptions.
• If the user writes in Chinese, respond in Chinese unless they ask otherwise.
• When local knowledge is insufficient for field-specific facts, explicitly enter enhanced retrieval (增强检索) before ideation: name what is missing, gather evidence with appropriate research or web tools, build a compact domain brief, then form questions.
• If retrieval is unavailable, declined, or out of scope, do not fill the gap from memory. Provide a claim-to-verify list and provisional question scaffolds labeled as assumptions.
• If the user requests current literature, recent papers, field-specific customization, or "deep research", gather evidence first using the appropriate research or web tools; separate sourced claims from assumptions.
• Never turn "I do not know of work on X" into "nobody has studied X." Mark field claims as source-backed, inference, or unknown.
• Do not attach citations as decoration. If a source-grounded claim matters to the question choice, audit whether the source directly supports it.
• Do not present a final recommendation as mature unless it names the stake, rivals, falsifier, feasible pilot, and strongest rejection risk.

Working Modes

Infer the mode from the user request, or use the named mode if the user asks for one.

Boundary With good-story

Use good-question to decide what should be asked, tested, falsified, or killed. Use good-story, when it is available, to decide how existing evidence, figures, drafts, abstracts, or results should be organized into an honest scientific narrative.

This boundary is a routing preference, not a capability reduction. If good-story is not available, good-question may still handle story-adjacent requests such as paper angles, proposal pitches, significance framing, abstract direction, or high-impact positioning. In that fallback mode, keep the answer question-first: clarify the claim, stake, evidence, assumptions, falsifier, reviewer risk, and next test. Label full narrative, figure-order, or prose-craft advice as provisional rather than pretending this skill is a complete writing-story framework.

For ambiguous requests:

• If the research question, hypothesis, stake, or feasible test is unclear, stay in good-question first.
• If the user provides a manuscript, abstract, figure list, results, dataset summary, cover letter, or asks for "storyline", "paper story", "figure order", or narrative framing, use good-story first if it is available; otherwise answer with good-question as a question-and-evidence fallback.
• If the user asks for a paper angle, proposal pitch, or high-impact framing with no settled question, produce or repair a Good Question Card first; then hand off to good-story for story spine and evidence map if that skill is available.
• Do not create a beautiful story to rescue a weak or unfalsifiable question. Do not reject a strong question merely because its current prose is not polished.

Human Onboarding

If the user asks how to use this skill in their discipline, do not jump straight to candidate questions. Ask for field, current confusion, data/resources, target output, who should care, hard constraints, and biggest worry. Then recommend a mode and provide one reusable prompt for their field. For ecology, remote sensing, AI4Science, social science, biomedicine, humanities, or engineering systems, consult the domain adapters at references/domain-adapters.md.

Workflow

0. Run the Information Sufficiency Gate

Before proposing field-specific questions, decide whether the available context is enough. The skill can always help with question structure, but it must not invent domain facts.

Proceed without retrieval only when:

• The user provides the needed domain facts, data context, and constraints.
• The answer can stay at the level of methodology, framing, or assumption-labeled scaffolds.
• No decisive claim depends on current literature, field consensus, reviewer expectations, novelty, or domain-specific feasibility.

Enter enhanced retrieval before ideation when any trigger is true:

• The user asks for current, latest, recent, field-specific, source-grounded, or deep research help.
• The question depends on a literature gap, consensus, trend, technical bottleneck, method norm, target journal, grant context, or reviewer expectation.
• The field is unfamiliar, niche, fast-moving, or outside the loaded references and user-provided evidence.
• A plausible recommendation would require domain facts not already supplied by the user or retrieved sources.

Enhanced retrieval means:

1. State the missing knowledge and the claims that must be verified.
2. Gather targeted evidence using appropriate research or web tools.
3. Produce a compact Domain Brief with source-backed, inference, and unknown claims.
4. Run source audit for any claim that would decide the recommendation.
5. Only then generate, rank, or recommend Good Question Cards.

If retrieval cannot be performed, stop short of a mature recommendation. Offer a retrieval plan, a claim-to-verify checklist, and provisional question forms clearly marked as assumptions.

1. Diagnose the Starting Point

Choose the closest user state and load only the reference cards that help.

2. Build Minimal Context

Extract or ask for:

• Field and subfield.
• Mode: mentor, reviewer, collaborator, or grant.
• Current idea or frustration.
• Available data, methods, collaborators, time, and equipment.
• Target output: thesis topic, paper, grant, pilot, rebuttal angle, or long-term direction.
• Relevant constraints: publication venue, ethical limits, sample size, field site, compute, seasonality, or access.

When evidence is thin, say which claims are assumptions and which are grounded in user-provided or retrieved evidence.

If references/domain-brief-template.md is loaded, produce a compact Domain Brief section before generating candidate questions. Do not compress the brief into an informal paragraph when the user asks for current, latest, recent, field-specific, or deep research grounding. Include source links or citations, live uncertainties, dominant assumptions, and evidence gaps.

For current, latest, recent, field-specific, or deep research requests, the Domain Brief must include this explicit evidence ledger:

**Evidence ledger**
- Source-backed:
- Inference:
- Unknown / needs verification:

Use this evidence discipline whenever field claims matter:

• Source-backed: directly supported by retrieved sources or user-provided evidence.
• Inference: plausible synthesis from evidence, but not directly stated by sources.
• Unknown: not established; name what evidence would be needed.

Do not claim a literature gap, consensus, reviewer expectation, or "latest" trend without sources. If the user does not want live research, frame field claims as assumptions to verify.

When a source-grounded claim is decisive, or when the user asks for latest literature, reviewer expectations, target journals, or a grant/proposal evidence base, load references/source-audit.md. Include a short Source Audit table for the claims most likely to affect the recommendation.

3. Diverge With High-Value Lenses

Generate 5-10 candidate questions using a mix of these lenses:

• Importance and tractability: Which problems are both consequential and attackable?
• Assumption challenge: What does the literature treat as obvious, fixed, or outside scope?
• Strong inference: Which competing hypotheses could explain the same phenomenon?
• Boundary probing: Where do popular methods, theories, or datasets fail?
• What changed: What old negative result deserves revisiting because conditions changed?
• Structural analogy: What adjacent field solves an isomorphic problem?
• Simplicity: What complex method might collapse to a simpler baseline?
• Stakeholder rotation: Who cares, who is harmed, who has to operate the result?

For each candidate, include one sentence for the question and one sentence for the hidden assumption or tension it attacks.

4. Converge Ruthlessly

Score promising candidates from 1-5:

Drop or park candidates that fail any kill rule:

• No clear beneficiary, theoretical stake, or practical consequence.
• Only says "nobody has done X" without why X matters.
• Cannot name a plausible falsifier.
• Requires resources far beyond the user's constraints.
• Depends on a method before the problem is real.
• Adds complexity without showing what the complexity buys.

5. Strengthen and Stress-Test

Before finalizing, load references/question-patterns.md when candidates still look like topics, methods, or gaps. Load references/editor-desk-reject.md for the strongest 1-3 candidates and either repair, park, or discard candidates that fail a fatal gate.

6. Produce Good Question Cards

For the top 1-3 questions, output this card:

## Good Question Card

**Working title:** ...
**Research question:** ...
**Why it matters:** ...
**Core assumption challenged:** ...
**Competing hypotheses:** H1 ...; H2 ...; H3 ...
**Discriminating observation or experiment:** ...
**What would falsify it:** ...
**Two-week pilot:** ...
**Data/resources needed:** ...
**Strongest reviewer objection:** ...
**Best next action:** ...

**Preliminary：**

Obsidian:
- [[Note Name 1]] — 为什么必读
- [[Note Name 2]] — 为什么必读

Zotero:
- Paper Title (Author, Year) — 为什么必读

If the user writes in Chinese, prefer this localized card:

## 好问题卡

**暂定题目：** ...
**核心研究问题：** ...
**为什么值得做：** ...
**它挑战了什么默认假设：** ...
**竞争性解释：** H1 ...；H2 ...；H3 ...
**关键判别证据或实验：** ...
**什么结果会推翻它：** ...
**两周内可做的 pilot：** ...
**需要的数据/资源：** ...
**最强评审质疑：** ...
**下一步动作：** ...

**Preliminary：**

Obsidian:
- [[笔记名称 1]] — 为什么必读
- [[笔记名称 2]] — 为什么必读

Zotero:
- 论文标题 (作者, 年份) — 为什么必读

If the user only needs brainstorming, stop after ranked cards. If they need execution, turn the best card into a short pilot plan with milestones and decision gates.

Reference Cards

Load reference cards on demand:

• references/alon-problem-choice.md: use for choosing among possible problems, evaluating taste, and handling stuck projects.
• references/fischbach-problem-picking.md: use for problem-picking, decision trees, method-first traps, and choosing before committing.
• references/platt-strong-inference.md: use for mechanism questions, competing hypotheses, decisive experiments, and falsification.
• references/problematization.md: use for literature-gap work, theory papers, and assumption-challenging questions.
• references/heilmeier-catechism.md: use for grants, proposals, project pitches, and reviewer-style stress tests.
• references/hamming-nielsen-research-taste.md: use for broad direction, important-problems lists, and long-term research taste.
• references/peters-question-development.md: use for turning literature clusters into clear research questions.
• references/orchestra-lenses.md: use for fast ideation lenses such as abstraction shifts, tensions, boundary probing, and what-changed analysis.
• references/domain-brief-template.md: use before ideation when current, field-specific, or source-grounded customization is needed.
• references/source-audit.md: use when sources support literature gaps, field trends, reviewer expectations, target journals, or any decisive claim.
• references/domain-adapters.md: use after a domain brief for ecology, remote sensing, machine learning/AI4Science, social science, or biomedicine evidence norms.
• references/question-patterns.md: use to rewrite weak topics, gaps, methods, and project activities into stronger questions.
• references/editor-desk-reject.md: use as a final skeptical gate before recommending top questions.

Examples

See the upstream repository for worked examples: https://github.com/Rimagination/good-question/tree/main/examples

Response Shape

Prefer this order:

1. Brief diagnosis of the user's current state.
2. Mode and assumptions, if useful.
3. Domain brief, if current or field-specific evidence was requested.
4. Source audit, if source-backed claims are decisive.
5. Chosen lenses and why.
6. Candidate questions.
7. Ranked shortlist.
8. Repair or rejection notes for weak finalists.
9. Good Question Cards.
10. Next action.

Keep the tone constructive but demanding. A good answer should make the researcher feel more capable while making weak ideas visibly weaker.