# Idea Creator

> Generate and rank research ideas given a broad direction. Use when user says "找idea", "brainstorm ideas", "generate research ideas", "what can we work on", or wants to explore a research area for publishable directions.

- **Type:** Skill
- **Install:** `agentstack add skill-wanshuiyin-auto-claude-code-research-in-sleep-idea-creator`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [wanshuiyin](https://agentstack.voostack.com/s/wanshuiyin)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [wanshuiyin](https://github.com/wanshuiyin)
- **Source:** https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep/tree/main/skills/idea-creator

## Install

```sh
agentstack add skill-wanshuiyin-auto-claude-code-research-in-sleep-idea-creator
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Research Idea Creator

Generate publishable research ideas for: $ARGUMENTS

## Overview

Given a broad research direction from the user, systematically generate, validate, and rank concrete research ideas. Standalone, Phase 1's landscape survey is **inline** (WebSearch — it does not invoke `/research-lit`); Phases 4-5 invoke `/novelty-check`, `/run-experiment`, and `/monitor-experiment` for validation and pilots. For the full sub-skill pipeline (`/research-lit` → idea generation → `/novelty-check` → `/research-review`), run `/idea-discovery` (Workflow 1), which orchestrates this skill.

## Constants

- **PILOT_MAX_HOURS = 2** — Skip any pilot estimated to take > 2 hours per GPU. Flag as "needs manual pilot".
- **PILOT_TIMEOUT_HOURS = 3** — Hard timeout: kill pilots exceeding 3 hours. Collect partial results if available.
- **MAX_PILOT_IDEAS = 3** — Pilot at most 3 ideas in parallel. Additional ideas are validated on paper only.
- **MAX_TOTAL_GPU_HOURS = 8** — Total GPU budget for all pilots combined.
- **REVIEWER_MODEL = `gpt-5.5`** — Default model for the Codex backend. Must be an OpenAI model (e.g., `gpt-5.5`, `o3`, `gpt-4o`). Manual backend uses whatever model the user chooses, **but it must be a non-Claude model** — the executor is Claude, so pasting into any Claude product makes Claude judge Claude and voids the cross-model invariant (see `shared-references/reviewer-routing.md`).
- **REVIEWER_BACKEND = `codex`** — Default: Codex MCP (xhigh). Override with `— reviewer: oracle-pro` for Oracle MCP, or `— reviewer: manual` for Manual Review MCP. If manual-review MCP is unavailable, stop and print the install command; do not fall back to Codex. See `shared-references/reviewer-routing.md`.
- **OUTPUT_DIR = `idea-stage/`** — All idea-stage outputs go here. Create the directory if it doesn't exist.

> 💡 Override via argument, e.g., `/idea-creator "topic" — pilot budget: 4h per idea, 20h total`.

## Reviewer Calling Convention

When calling the reviewer for idea evaluation, branch on REVIEWER_BACKEND:

**If REVIEWER_BACKEND = `codex`:**
  Use `mcp__codex__codex` for new review threads.
  Use `mcp__codex__codex-reply` for follow-up rounds (reuse threadId).

**If REVIEWER_BACKEND = `manual`:**
  Use `mcp__manual_review__review` for new review threads with:
    prompt: [exact same prompt that would go to Codex]
    config: {"model_reasoning_effort": "xhigh"}
  Save the returned `threadId`.
  Use `mcp__manual_review__review_reply` for follow-up rounds with:
    threadId: [saved manual-review threadId]
    prompt: [follow-up prompt]
    config: {"model_reasoning_effort": "xhigh"}

Content fidelity: the manual reviewer should see the same substantive bundle
content Codex would read. If the manual UI supports file upload / attachment,
reuse the same bundle file; otherwise paste the bundle contents inline because
remote web UIs cannot read your local filesystem paths. Review tracing applies
equally to both backends.

## Workflow

### Phase 0: Load Research Wiki (if active)

**Skip this phase entirely if `research-wiki/` does not exist.**

If `research-wiki/` exists, resolve the canonical helper using the
shared resolution chain (see `../research-wiki/SKILL.md` for the
contract):

```bash
cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
ARIS_REPO="${ARIS_REPO:-$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null)}"
WIKI_SCRIPT=".aris/tools/research_wiki.py"
[ -f "$WIKI_SCRIPT" ] || WIKI_SCRIPT="tools/research_wiki.py"
[ -f "$WIKI_SCRIPT" ] || { [ -n "${ARIS_REPO:-}" ] && WIKI_SCRIPT="$ARIS_REPO/tools/research_wiki.py"; }
[ -f "$WIKI_SCRIPT" ] || {
  echo "WARN: research_wiki.py not found at .aris/tools/, tools/, or \$ARIS_REPO/tools/." >&2
  echo "      The idea-creation primary output (idea ranking) will still be produced." >&2
  echo "      Wiki integration (load query_pack, write idea pages, add edges, rebuild query_pack) will be skipped." >&2
  echo "      Fix: rerun 'bash tools/install_aris.sh', export ARIS_REPO, or 'cp /tools/research_wiki.py tools/'." >&2
  WIKI_SCRIPT=""
}
```

```
if research-wiki/query_pack.md exists AND is less than 7 days old:
    Read query_pack.md and use it as initial landscape context:
    - Treat listed gaps as priority search seeds
    - Treat failed ideas as a banlist (do NOT regenerate similar ideas)
    - Treat top papers as known prior work (do not re-search them)
    Still run Phase 1 below for papers from the last 3-6 months (wiki may be stale)
else if research-wiki/ exists but query_pack.md is stale or missing:
    if [ -n "$WIKI_SCRIPT" ]: python3 "$WIKI_SCRIPT" rebuild_query_pack research-wiki/
    Then read query_pack.md as above
```

### Phase 1: Landscape Survey (5-10 min)

Map the research area to understand what exists and where the gaps are.

1. **Scan local paper library first**: Check `papers/` and `literature/` in the project directory for existing PDFs. Read first 3 pages of relevant papers to build a baseline understanding before searching online. This avoids re-discovering what the user already knows.

2. **Search recent literature** using WebSearch:
   - Top venues in the last 2 years (NeurIPS, ICML, ICLR, ACL, EMNLP, etc.)
   - Recent arXiv preprints (last 6 months)
   - Use 5+ different query formulations
   - Read abstracts and introductions of the top 10-15 papers

2. **Build a landscape map**:
   - Group papers by sub-direction / approach
   - Identify what has been tried and what hasn't
   - Note recurring limitations mentioned in "Future Work" sections
   - Flag any open problems explicitly stated by multiple papers

3. **Identify structural gaps**:
   - Methods that work in domain A but haven't been tried in domain B
   - Contradictory findings between papers (opportunity for resolution)
   - Assumptions that everyone makes but nobody has tested
   - Scaling regimes that haven't been explored
   - Diagnostic questions that nobody has asked

### Phase 1.5: Parallel lens fan-out (Tier-aware) — breadth, not verdict

Idea generation benefits from **breadth**: more independent analytic angles
surface more candidate ideas. This skill fans out *candidate generation*
across analytic **lenses**, then funnels every candidate through the single
Phase-4 cross-model jury. Fan-out widens the jury's input; it never makes the
accept/reject decision. This follows
[`shared-references/fan-out-pattern.md`](../shared-references/fan-out-pattern.md);
the verdict stays cross-model per
[`shared-references/acceptance-gate.md`](../shared-references/acceptance-gate.md)
(idea novelty/quality is a Type-B verdict — same-family generation is fine,
same-family *acquittal* is not).

**Lenses** (the structural-gap angles from Phase 1, step 3):
`method-transfer` (works in domain A, untried in B) · `contradiction`
(conflicting findings to resolve) · `untested-assumption` (everyone assumes,
nobody tested) · `scaling-regime` (unexplored regime) · `diagnostic`
(question nobody asked). This set is a floor, not a ceiling — add a
domain-specific lens when the direction warrants.

**Tier-portable dispatch** (the Phase-4 jury downstream is identical on every tier):
- **Tier 1** (Workflow available): spawn one **Claude subagent per lens**;
  each runs the Phase-1 survey *through its lens* and the Phase-2 generation
  prompt *restricted to that lens*, returning candidates as structured output.
- **Tier 2** (Agent tool, no Workflow): spawn the same per-lens subagents via
  the Agent tool.
- **Tier 3** (no spawning): enumerate the lenses sequentially in one pass —
  the original single-thread behavior, made explicit. No capability assumed.

> **Why the lens shards are Claude, not Codex.** Generation is candidate
> production, not a verdict, so same-family is safe — and Codex MCP is
> **serial** (concurrent codex calls hang), so spending its scarce capacity
> on parallel generation is both unsafe-to-parallelize and wasteful. Reserve
> Codex for the one Phase-4 jury call. On Tier 1/2 the lens subagents are the
> generators; the single Phase-2 codex brainstorm below still runs once as an
> optional cross-model *seed* (a generator, not a judge), and its ideas join
> the merged pool.

**Per-shard output** (the generation-fan-out schema from
[`fan-out-pattern.md`](../shared-references/fan-out-pattern.md) — `shard_id` +
`candidates[]` + per-item `dedup_key`):
```json
{"shard_id": "", "candidates": [{"summary": "...", "hypothesis": "...",
  "mve": "...", "contribution_type": "...", "risk": "...", "effort": "...",
  "dedup_key": ""}]}
```

**Merge + mechanical dedup**: union all lenses' ideas; cluster near-identical
ideas by hypothesis (mechanical similarity only — **never** drop one for being
"weak"; weakness is a Phase-4 verdict, not a merge step). The deduped union is
the candidate set that enters Phase 3.

### Phase 2: Idea Generation (brainstorm with external LLM)

Use the selected reviewer backend (see Reviewer Calling Convention) for divergent thinking.

For the `codex` backend, **do not inline the full landscape + gaps prompt**
once it stops being tiny. Write the full brainstorming request to
`idea-stage/codex_brainstorm_bundle.md`, then keep the MCP prompt short:

```
mcp__codex__codex:
  model: REVIEWER_MODEL
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    Read the idea-generation bundle at  and follow all instructions in it.
```

*For `manual` backend:* use `mcp__manual_review__review` with the same bundle
contents. If the manual-review UI supports attachments, attach
`idea-stage/codex_brainstorm_bundle.md`; otherwise paste the bundle contents
inline. Save the returned `threadId` for Phase 4 follow-up.

Bundle contents:

```
    You are a senior ML researcher brainstorming research ideas.

    Research direction: [user's direction]

    Here is the current landscape:
    [write the Phase-1 landscape map into this bundle file]

    Key gaps identified:
    [write the Phase-1 gap summary into this bundle file]

    Generate 8-12 concrete research ideas. For each idea:
    1. One-sentence summary
    2. Core hypothesis (what you expect to find and why)
    3. Minimum viable experiment (what's the cheapest way to test this?)
    4. Expected contribution type: empirical finding / new method / theoretical result / diagnostic
    5. Risk level: LOW (likely works) / MEDIUM (50-50) / HIGH (speculative)
    6. Estimated effort: days / weeks / months

    Prioritize ideas that are:
    - Testable with moderate compute (8x RTX 3090 or less)
    - Likely to produce a clear positive OR negative result (both are publishable)
    - Not "apply X to Y" unless the application reveals genuinely surprising insights
    - Differentiated from the 10-15 papers above

    Be creative but grounded. A great idea is one where the answer matters regardless of which way it goes.
```

Save the threadId for follow-up.

### Phase 3: Mechanical consolidation + objective feasibility gate

> **This phase does NOT judge idea quality, novelty, or impact.** Those are
> Type-B verdicts reserved for the Phase-4 cross-model jury (see
> [`shared-references/acceptance-gate.md`](../shared-references/acceptance-gate.md)).
> Eliminating ideas here on a same-family novelty or impact call would
> pre-filter the jury's input with same-family quality judgment — exactly
> what [`fan-out-pattern.md`](../shared-references/fan-out-pattern.md) forbids.
> Phase 3 only (a) finishes the mechanical dedup from the fan-out merge and
> (b) drops ideas that are **objectively** out of budget. Everything else
> passes through **annotated, not eliminated** — the jury decides.

1. **Objective feasibility gate (Type-A — safe same-model)**: drop an idea
   ONLY on a mechanical, budget-based fact:
   - estimated compute > 1 week of available GPU time, OR
   - requires a dataset that is provably unavailable.
   These are objective resource facts. Do **not** drop on "implementation
   looks complex" — annotate complexity as `effort_note` instead.

2. **Novelty signal — ANNOTATE, do not eliminate**: for each surviving idea,
   do 2-3 targeted searches and attach a `prior_work` note (what looks
   related, with links). This is *input for the jury*, not a filter. The
   authoritative novelty verdict is Phase 4's `/novelty-check` (multi-source +
   cross-model). Do **not** drop an idea here because it "might already be
   done."

3. **Impact signal — ANNOTATE, do not eliminate**: attach a one-line
   `so_what` note (why the result would matter either way). Do **not** drop on
   a same-family "a reviewer wouldn't care" call — "would a reviewer care?" is
   *precisely* the question the Phase-4 cross-model devil's-advocate asks.
   Forward the note; let the jury rule.

Every feasible, non-duplicate idea — carrying its `prior_work`, `so_what`, and
`effort_note` annotations — proceeds to Phase 4. Typically only the
budget-infeasible are dropped; the cross-model jury, not the executor, does
the quality narrowing.

### Phase 4: Deep Validation (the cross-model jury)

**This is the jury.** It receives the FULL annotated candidate set from
Phase 3 (Phase 3 no longer pre-narrows on quality), and the **cross-model
reviewer — not the executor — does the quality/novelty narrowing.** Run the
steps in this order so the cheap cross-model triage gates the expensive
per-idea novelty search:

1. **Cross-model triage (devil's advocate) — ranks ALL candidates first.**
   Use the selected reviewer backend (see Reviewer Calling Convention). For
   `codex`, use `mcp__codex__codex-reply` (same thread). For `manual`, use
   `mcp__manual_review__review_reply` with the saved threadId. For the
   `codex` backend, write the full annotated candidate set to
   `idea-stage/codex_triage_bundle.md` and send only a path-based follow-up:
   ```
   Read the idea-triage bundle at  and follow all instructions in it.
   ```
   For the `manual` backend, attach that same bundle if possible; otherwise
   paste its contents inline. Bundle contents:
   ```
   Here is the full annotated candidate set (deduped, budget-feasible):
   [write all candidates with their prior_work / so_what / effort_note notes]

   For each, play devil's advocate:
   - What's the strongest objection a reviewer would raise?
   - What's the most likely failure mode?
   - Is the prior_work note a real novelty problem, or differentiable?
   - How would you rank these for a top venue submission?
   - Which 2-3 would you actually work on, and why?
   ```
   The reviewer's ranking is the authoritative quality verdict. The executor
   does not eliminate candidates on its own taste before or instead of this.

2. **Novelty check — on the reviewer's top picks only.** Run the
   `/novelty-check` workflow (multi-source search + cross-model verification)
   on the ideas the triage ranked worth pursuing. This bounds the expensive
   multi-source search to the survivors instead of every candidate, while
   keeping the novelty verdict cross-model.

3. **Select for pilots**: take the top 2-3 ideas that survive both the
   cross-model triage and the novelty check forward to Phase 5.

### Phase 5: Parallel Pilot Experiments (for top 2-3 ideas)

Before committing to a full research effort, run cheap pilot experiments to get empirical signal. This is the key differentiator from paper-only validation.

1. **Design pilots**: For each top idea, define the minimal experiment that would give a positive or negative signal:
   - Single seed, small scale (e.g., small dataset subset, fewer epochs)
   - Target: 30 min - PILOT_MAX_HOURS per pilot on 1 GPU
   - **Estimate GPU-hours BEFORE launching.** If estimated time > PILOT_MAX_HOURS, reduce scale (fewer epochs, smaller subset) or flag as "needs manual pilot"
   - Clear success metric defined upfront (e.g., "if metric improves by > 1%, signal is positive")

2. **Deploy in parallel**: Use `/run-experiment` to launch pilots on different GPUs simultaneously:
   ```
   GPU 0: Pilot for Idea 1
   GPU 1: Pilot for Idea 2
   GPU 2: Pilot for Idea 3

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [wanshuiyin](https://github.com/wanshuiyin)
- **Source:** [wanshuiyin/Auto-claude-code-research-in-sleep](https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-wanshuiyin-auto-claude-code-research-in-sleep-idea-creator
- Seller: https://agentstack.voostack.com/s/wanshuiyin
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.