---

name: idea-discovery description: "Workflow 1: Full idea discovery pipeline to go from a broad research direction to validated, pilot-tested ideas. Use when user says "找idea全流程", "idea discovery pipeline", "从零开始找方向", or wants the complete idea exploration workflow." argument-hint: "[research-direction]" allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob, WebSearch, WebFetch, Skill, mcp__codex__codex, mcp__codex__codex-reply

Workflow 1: Idea Discovery Pipeline

Orchestrate a complete idea discovery workflow for: $ARGUMENTS

Overview

This skill chains sub-skills into a single automated pipeline:

/research-lit → /idea-creator → /novelty-check → /research-review → /research-refine-pipeline
  (survey)      (brainstorm)    (verify novel)    (critical feedback)  (refine method + plan experiments)

Each phase builds on the previous one's output. The final deliverables are a validated idea-stage/IDEA_REPORT.md with ranked ideas, plus a refined proposal (refine-logs/FINAL_PROPOSAL.md) and experiment plan (refine-logs/EXPERIMENT_PLAN.md) for the top idea.

Constants

• PILOT_MAX_HOURS = 2 — Skip any pilot experiment estimated to take > 2 hours per GPU. Flag as "needs manual pilot" in the report.
• PILOT_TIMEOUT_HOURS = 3 — Hard timeout: kill any running pilot that exceeds 3 hours. Collect partial results if available.
• MAX_PILOT_IDEAS = 3 — Run pilots for at most 3 top ideas in parallel. Additional ideas are validated on paper only.
• MAX_TOTAL_GPU_HOURS = 8 — Total GPU budget across all pilots. If exceeded, skip remaining pilots and note in report.
• AUTO_PROCEED = true — When true, checkpoints are informational: report the selected option and continue in the same turn. Set to false to ask for explicit user confirmation and end the turn at each selection checkpoint.
• REVIEWER_MODEL = gpt-6-astra — Model used via Codex MCP. Must be an OpenAI model (e.g., gpt-6-astra, o3, gpt-4o). Passed to sub-skills.
• OUTPUT_DIR = idea-stage/ — All idea-stage outputs go here. Create the directory if it doesn't exist.
• ARXIV_DOWNLOAD = false — When true, /research-lit downloads the top relevant arXiv PDFs during Phase 1. When false (default), only fetches metadata. Passed through to /research-lit.
• COMPACT = false — When true, generate compact summary files for short-context models and session recovery. Writes idea-stage/IDEA_CANDIDATES.md (top 3-5 ideas only) at the end of this workflow. Downstream skills read this instead of the full idea-stage/IDEA_REPORT.md.
• RENDER_HTML = true — When true (default), auto-render idea-stage/IDEA_REPORT.md to HTML at workflow end via /render-html. Uses --no-review (the source MD already went through novelty + cross-model review during Phase 3). Set false to skip, or pass — render html: false.
• REF_PAPER = false — Reference paper to base ideas on. Accepts: local PDF path, arXiv URL, or any paper URL. When set, the paper is summarized first (idea-stage/REF_PAPER_SUMMARY.md), then idea generation uses it as context. Combine with base repo for "improve this paper with this codebase" workflows.
• RESUMABLE = true — Record stage evidence under .aris/runs/<run_id>.json and require a deterministic evidence gate before declaring the final report complete.

💡 These are defaults. Override by telling the skill, e.g., /idea-discovery "topic" — ref paper: https://arxiv.org/abs/2406.04329 or /idea-discovery "topic" — compact: true.

Checkpoint execution rule

Resolve AUTO_PROCEED once from $ARGUMENTS before Phase 0 and keep that mode for the entire workflow.

• AUTO_PROCEED=true is non-blocking. A checkpoint is a progress update, not a question. State the result and the automatically selected next action, then continue executing in the same turn. Do not ask for confirmation, request user input, sleep, wait for silence, or end the turn at a checkpoint.
• AUTO_PROCEED=false is blocking. Present the options, ask the user, and end the turn. Resume only after an explicit reply.

Never implement auto-proceed as “ask, then continue if there is no response.” Once a turn ends, silence cannot resume the workflow. The user can still interrupt a non-blocking run at any time.

This rule governs only AUTO_PROCEED-controlled selection checkpoints. If the user explicitly enables a Feishu interactive gate, that external approval or reply is an intentional blocking exception; wait for that user-controlled gate rather than treating it as a silence timeout. Feishu off/push-only modes remain non-blocking under AUTO_PROCEED=true.

Per-stage evidence gate (RESUMABLE = true)

Resolve run_state.py and idea_discovery_gate.py through the same canonical helper chain used by /research-pipeline: .aris/tools/ → tools/ → $ARIS_REPO/tools/ → ~/.aris/repo/tools/. If either helper is unavailable, the final report is BLOCKED; do not silently continue without a state record.

For a new run, derive <run_id> from the direction slug and date, then start this ordered state record with --executor <actual-Claude-model> (for example, claude-sonnet-4.5):

research-lit,idea-creator,novelty-check,research-review,research-refine-pipeline

For each phase, mark running on entry and done --artifact <path> only after its artifact is present. Use these artifact locators so the final gate can check the canonical report rather than scattered scratch files:

| Phase | Artifact locator | |---|---| | research-lit | idea-stage/IDEA_REPORT.md#literature-landscape | | idea-creator | idea-stage/IDEA_REPORT.md#ranked-ideas | | novelty-check | idea-stage/IDEA_REPORT.md#novelty-verification | | research-review | idea-stage/IDEA_REPORT.md#external-critical-review | | research-refine-pipeline | refine-logs/FINAL_PROPOSAL.md |

novelty-check and research-review are reviewer-bearing phases. A done status or a heading alone is not review evidence. After each phase has folded substantive findings into its anchored report section, first record it done, then, only after the configured reviewer actually returns a positive, identity-bearing verdict, record the cross-family receipt using the actual returned model and durable thread/trace id:

<resolved-python> <resolved-run_state.py> accept . <run_id> novelty-check --verdict-id "<thread-or-trace-id>" --reviewer "<actual-reviewer-model>"
<resolved-python> <resolved-run_state.py> accept . <run_id> research-review --verdict-id "<thread-or-trace-id>" --reviewer "<actual-reviewer-model>"

Never invent either value and never call accept without the positive verdict required by the run-state contract. For novelty-check, both PROCEED and PROCEED WITH CAUTION are positive verdicts — caution is guidance for the pilot, not a rejection; only ABANDON is negative. For research-review, positive means the review's bottom line does not argue for abandoning the idea — a list of named risks is not a rejection. If the review ends without a clear stance, ask the same reviewer thread for a one-line verdict (proceed or abandon) and record on that answer; never infer positivity from silence. A negative verdict does not grant a review receipt. Leave the phase done and the final gate BLOCKED, select a surviving or new idea, then re-run that reviewer-bearing phase. Do the same if the reviewer is unavailable, returns no valid identity/response, or its output was not folded into the report.

At the end of Phase 5, run:

<resolved-python> <resolved-idea_discovery_gate.py> . <run_id> --report idea-stage/IDEA_REPORT.md

The gate writes its result to gates.idea-discovery-evidence in the run state. On PASS, it has validated (but never created) the two review receipts, all required artifacts, and non-empty anchored report sections. Per-phase acceptance stays with each stage's own cross-model gate. On a non-zero exit, it writes explicit BLOCKED: <stage> evidence missing lines to the report; do not present the workflow as complete. On — resume <run_id>, start from the first non-terminal phase and re-run the gate before finalizing.

Pipeline

Phase 0: Load Research Brief (if available)

Before starting any other phase, check for a detailed research brief in the project:

1. Look for RESEARCH_BRIEF.md in the project root (or path passed as $ARGUMENTS)
2. If found, read it and extract:
   • Problem statement and context
   • Constraints (compute, data, timeline, venue)
   • What the user already tried / what didn't work
   • Domain knowledge and non-goals
   • Existing results (if any)
3. Use this as the primary context for all subsequent phases — it replaces the one-line prompt
4. If both RESEARCH_BRIEF.md and a one-line $ARGUMENTS exist, merge them (brief takes priority for details, argument sets the direction)

If no brief exists, proceed normally with $ARGUMENTS as the research direction.

💡 Create a brief from the template: cp templates/RESEARCH_BRIEF_TEMPLATE.md RESEARCH_BRIEF.md — keep it to ~1-2 pages (4-8k chars); long material goes in separate files referenced by path.

Phase 0.5: Reference Paper Summary (when REF_PAPER is set)

Skip entirely if REF_PAPER is false.

Summarize the reference paper before searching the literature:

1. If arXiv URL (e.g., https://arxiv.org/abs/2406.04329):

   • Invoke /arxiv "ARXIV_ID" — download to fetch the PDF
   • Read the first 5 pages (title, abstract, intro, method overview)

2. If local PDF path (e.g., papers/reference.pdf):

   • Read the PDF directly (first 5 pages)

3. If other URL:

   • Fetch and extract content via WebFetch

4. Generate idea-stage/REF_PAPER_SUMMARY.md:

# Reference Paper Summary

**Title**: [paper title]
**Authors**: [authors]
**Venue**: [venue, year]

## What They Did
[2-3 sentences: core method and contribution]

## Key Results
[Main quantitative findings]

## Limitations & Open Questions
[What the paper didn't solve, acknowledged weaknesses, future work suggestions]

## Potential Improvement Directions
[Based on the limitations, what could be improved or extended?]

## Codebase
[If `base repo` is also set: link to the repo and note which parts correspond to the paper]

🚦 Checkpoint: Present the summary to the user:

📄 Reference paper summarized:
- Title: [title]
- Key limitation: [main gap]
- Improvement directions: [2-3 bullets]

Proceeding to literature survey with this as context.

Phase 1 and Phase 2 will use idea-stage/REF_PAPER_SUMMARY.md as additional context — /research-lit searches for related and competing work, /idea-creator generates ideas that build on or improve the reference paper.

Phase 1: Literature Survey

Invoke /research-lit to map the research landscape. Idea discovery is exactly the place where Gemini's AI-driven broad coverage adds value, so include gemini as a source by default unless the user already specified an explicit — sources: directive in their idea-discovery invocation:

# If $ARGUMENTS already contains "— sources:", pass through unchanged
# (the user is in control of source selection):
/research-lit "$ARGUMENTS" — composed: idea-stage/IDEA_REPORT.md

# Otherwise (the common case), include gemini explicitly for broader discovery:
/research-lit "$ARGUMENTS" — sources: all, gemini — composed: idea-stage/IDEA_REPORT.md

— composed: idea-stage/IDEA_REPORT.md puts /research-lit in composed mode (see Output hygiene above): it returns the landscape for folding into the report instead of writing a standalone landscape file. The report doesn't exist yet at Phase 1 — the directive names the forthcoming canonical doc, and /idea-creator creates it in Phase 2.

If gemini-cli is not installed, /research-lit skips the Gemini source gracefully with a warning — no break to the pipeline. Users who want to force-disable Gem