Aris idea creator
Skill JZKK720/cubecloud-skilldbundle-setup/upstream/aris-idea-creator
One-command setup for a full VS Code Copilot Chat agent-skills stack on Windows. 104 skills, 12 CLIs, 7 MCP servers, 74 design systems — all security-gated by SkillSpector.
npx -y skills add JZKK720/cubecloud-skilldbundle-setup --skill aris-idea-creatorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Generate and rank research ideas given a broad direction. Use when user says "brainstorm ideas", "generate research ideas", "what can we work on", or wants to explore a research area for publishable directions. Ported from wanshuiyin/Auto-claude-code-research-in-sleep (ARIS) — methodology only, Claude-Code-specific MCP/CLI/GPU deps stripped for VS Code Copilot.
SKILL.md
7.4 KB, as published. Nobody here has run it
Research Idea Creator
Generate publishable research ideas for the research direction the user provides.
Overview
Given a broad research direction from the user, systematically generate, validate, and rank concrete research ideas. This skill runs the full pipeline inline: landscape survey → idea generation → feasibility filtering → self-review validation → ranked report.
Constants
- OUTPUT_DIR =
idea-stage/— All idea-stage outputs go here. Create the directory if it doesn't exist.
Workflow
Phase 1: Landscape Survey (5-10 min)
Map the research area to understand what exists and where the gaps are.
-
Scan local paper library first: Check
papers/andliterature/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. -
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
-
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
-
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 2: Idea Generation (brainstorm)
Generate 8-12 concrete research ideas using the landscape and gaps from Phase 1.
For each idea:
- One-sentence summary
- Core hypothesis (what you expect to find and why)
- Minimum viable experiment (what's the cheapest way to test this?)
- Expected contribution type: empirical finding / new method / theoretical result / diagnostic
- Risk level: LOW (likely works) / MEDIUM (50-50) / HIGH (speculative)
- Estimated effort: days / weeks / months
Prioritize ideas that are:
- Testable with moderate compute
- 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 surveyed
Be creative but grounded. A great idea is one where the answer matters regardless of which way it goes.
Phase 3: Mechanical consolidation + objective feasibility gate
This phase does NOT judge idea quality, novelty, or impact. Those are verdicts reserved for Phase 4 self-review. Phase 3 only drops ideas that are objectively out of budget.
-
Objective feasibility gate: drop an idea ONLY on a mechanical, budget-based fact:
- estimated compute exceeds what the user has available, OR
- requires a dataset that is provably unavailable. Do NOT drop on "implementation looks complex" — annotate complexity instead.
-
Novelty signal — ANNOTATE, do not eliminate: for each surviving idea, do 2-3 targeted web searches and attach a
prior_worknote (what looks related, with links). This is input for Phase 4, not a filter. -
Impact signal — ANNOTATE, do not eliminate: attach a one-line
so_whatnote (why the result would matter either way).
Every feasible, non-duplicate idea — carrying its prior_work, so_what, and effort_note annotations — proceeds to Phase 4.
Phase 4: Deep Validation (self-review)
Act as a skeptical reviewer and evaluate the full annotated candidate set from Phase 3.
-
Devil's advocate review: For each candidate, critically assess:
- 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?
-
Novelty check: For the top-ranked ideas, do a thorough multi-source literature search (multiple query formulations, recent venues) to verify novelty. Be brutally honest — false novelty claims waste months of research time.
-
Select top ideas: Take the top 2-3 ideas that survive both the self-review and the novelty check.
Phase 5: Output — Ranked Idea Report
Write a structured report to idea-stage/IDEA_REPORT.md:
Lead every recommended idea with its method, in plain language. Before any hypothesis, novelty score, or claim, state in 2-4 concrete steps what we actually build / train / run — no jargon, no claim-IDs. The reader must understand what we do before what we claim.
# Research Idea Report
**Direction**: [user's research direction]
**Generated**: [date]
**Ideas evaluated**: X generated → Y survived filtering → Z recommended
## Landscape Summary
[3-5 paragraphs on the current state of the field]
## Recommended Ideas (ranked)
### Idea 1: [title]
- **Method (what we actually do)**: [2-4 concrete steps in plain language]
- **Hypothesis**: [one sentence]
- **Minimum experiment**: [concrete description]
- **Expected outcome**: [what success/failure looks like]
- **Novelty**: X/10 — closest work: [paper]
- **Feasibility**: [compute, data, implementation estimates]
- **Risk**: LOW/MEDIUM/HIGH
- **Contribution type**: empirical / method / theory / diagnostic
- **Reviewer's likely objection**: [strongest counterargument]
- **Why we should do this**: [1-2 sentences]
### Idea 2: [title]
...
## Eliminated Ideas (for reference)
| Idea | Reason eliminated |
|------|-------------------|
| ... | Already done by [paper] |
| ... | Requires unavailable compute/dataset |
## Suggested Execution Order
1. Start with Idea 1 (lowest risk, clearest signal)
2. Idea 2 as backup
...
## Next Steps
- [ ] Scale up Idea 1 to full experiment
- [ ] If confirmed, iterate with review loops
Key Rules
- The user provides a DIRECTION, not an idea. Your job is to generate the ideas.
- Quantity first, quality second: brainstorm broadly, then filter ruthlessly.
- A good negative result is just as publishable as a positive one. Prioritize ideas where the answer matters regardless of direction.
- Don't fall in love with any idea before validating it. Be willing to kill ideas.
- Always estimate compute cost. An idea that needs 1000 GPU-hours is not actionable for most researchers.
- "Apply X to Y" is the lowest form of research idea. Push for deeper questions.
- Include eliminated ideas in the report — they save future time by documenting dead ends.
- Anti-hallucination: Never fabricate paper titles, authors, or arXiv IDs. Every cited paper must be verified via web search. If uncertain, tag
[UNVERIFIED].
Composing with Other Skills
After this skill produces the ranked report, the user can:
- Run
aris-novelty-checkon the top idea for deep novelty verification - Run
aris-research-litfor a broader literature survey - Implement the top idea and iterate
Gives 0 of the 12 instructions most context ai engineering skills give
Counted across 1,193 of the 1,976 authors here whose files we hold, read 2026-08-06
- dispatch a fresh implementer subagent per taskin 48 of 1193, across 19 files
- dispatch final reviewer after all tasksin 37 of 1193, across 11 files
- provide full task text to the subagentin 31 of 1193, across 10 files
- review spec compliance before code qualityin 27 of 1193, across 10 files
- make the hook script executablein 26 of 1193, across 8 files
- re-snapshot after navigation or DOM changesin 25 of 1193, across 17 files
- answer subagent questions before proceedingin 22 of 1193, across 7 files
- mark task complete in TodoWrite after approvalin 22 of 1193, across 6 files
- merge hook into existing settingsin 21 of 1193, across 3 files
- read files before editing themin 21 of 1193, across 9 files
- ask if installation is global or projectin 20 of 1193, across 2 files
- copy the hook script to target locationin 20 of 1193, across 2 files
Said here and by no other author read
- Scan local paper library first
- Use 5+ different query formulations
- Estimate compute cost and effort
- Drop ideas exceeding budget or needing unavailable data
- Annotate prior work and impact for each feasible idea
- Act as a skeptical reviewer
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.