Idea Discovery

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:

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: