idea-research
Skill0 starsChanged 27 days agoMITView on GitHub
Deep, web-verified research that compares a set of ideas (1-8) against criteria and pass/fail gates - fact-checked dossiers, a gap round, an evaluator panel, REPORT.md and a scores.json. Use for "research these ideas", "compare options against criteria", "deep research on candidates", "which of these should we build", "/idea-research", or when /shape hands over a research job.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- rishabhrawat35/idea-researchtheir own version, first seen Sep 11, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- rishabhrawat35/idea-research★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository12 other files it gives its agents.
- ask-panelSkill
- crew-diffSkill
- crewSkill
- evidence-contractSkill
- graphifySkill
- jcode-workersSkill
- lensSkill
- orchestrateSkill
- prd-reviewSkill
- project-contextSkill
- recallSkill
- shapeSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Gather the inputs: Read the user's documents first (rules, briefs, go/no-go docs), then ask only for what is still missing:
- Very specific: line 30
Dry run first: Call the Workflow with name: "idea-research" and args plus dry_run: true.
- Very specific: line 66
Every prompt carries the freshness rule built from today: facts are web-verified as of that date, the latest edition of every statistic is …
- Very specific: line 69
Keep ideas to what the user listed.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/idea-research: compare ideas against criteria with fresh evidence
Runs the saved Workflow idea-research (~/.claude/workflows/idea-research.js). Each topic is researched and
fact-checked, a critic asks what is missing, an evaluator panel scores every idea on every criterion and judges every
gate, and a synthesis agent writes REPORT.md. scores.json is computed in the script from the evaluators' numbers
(mean, one decimal; gate = majority of pass/fail votes), never by a model. Interface: /shape reference/contract.md
§12.5.
Invoking /idea-research, or a research request from /shape, is the user's opt-in for the Workflow tool.
Steps
- Gather the inputs. Read the user's documents first (rules, briefs, go/no-go docs), then ask only for what is
still missing:
context: the situation in a paragraph, plus the paths of docs agents should read.ideas: 1-8 of{id, name, pitch}. From /shape use the plan's idea node ids (I1) and the criteria'sKids.criteria:{id, name, description, weight}(weighted or lens rubrics).gates:{id, name, description}pass/fail must-haves;gate_docs: absolute paths of teammate or user docs whose criteria are gates (each gets its own research topic). Put those criteria ingatestoo, so evaluators can vote on them.- Optional:
evaluators(personas; a skeptic and a literal reader are always added),topics(replaces the generated topics for a narrow ask),depth"quick"(fewer topics, no gap round, 3 evaluators).
- Build args with
dir(absolute output folder, e.g.<task dir>/research/<n>),today(today's date, YYYY-MM-DD; take it from the system date, not memory) and the fields above. - Dry run first. Call the Workflow with
name: "idea-research"andargsplusdry_run: true. It runs no agent and returnstopics,agentsandmodels. Tell the user the cost in one line, from the result:~54 agents: 43 sonnet, 11 opus (max, full depth), N topics. Ask before the real run, unless the plan's research node already carries the user's go-ahead (in /shape, the node and §12.5 say who asks). - Run it in the background (same args, no
dry_run). A full run takes a long time; keep talking meanwhile. - When done, read
REPORT.md(verdict first) andscores.json. Give the user the verdict, the ranking, any failed gate, and the report path. An invalid-args error names the field: fix it and re-run the dry run.
When called for a plan (from /shape)
Set T (task id), RS (research node id), RUN (workflow run id) and D (the dir) in the environment, then send
research_status first and last. The snippet counts rejected events: it sends done only when none failed.
PLAN=${PLAN:-$HOME/.claude/bin/plan}; : "${T:?}" "${RS:?}" "${RUN:?}" "${D:?}"
ev() { $PLAN event "$T" --by session --source build --json "$1" </dev/null; }
ev "{\"type\":\"research_status\",\"node\":\"$RS\",\"state\":\"running\",\"run\":\"$RUN\"}" | jq -r .summary
# ... after the Workflow returns:
set -o pipefail; failures=0
evs=$(jq -c '.ideas | to_entries[] | .key as $i | ((.value.scores | to_entries[] | {type:"score",node:$i,rubric:.key,value:.value.value,label:.value.label,rationale:.value.rationale,sources:.value.sources,basis:"research"}), (.value.gates | to_entries[] | {type:"score",node:$i,rubric:.key,pass:.value.pass,rationale:.value.note,sources:.value.sources,basis:"research"}))' "$D/scores.json") || failures=1
while read -r e; do
[ -n "$e" ] || continue
ev "$e" | jq -r .summary || failures=$((failures+1))
done <<< "$evs"
if [ "$failures" -eq 0 ]; then st="\"state\":\"done\",\"report\":\"$D/REPORT.md\""
else st="\"state\":\"failed\",\"note\":\"$failures score events failed; see the plan stderr and scores.json\""; fi
ev "{\"type\":\"research_status\",\"node\":\"$RS\",$st}" | jq -r .summaryOn a Workflow failure send state: "failed" with a note instead. A rejected score event (exit 2, for example a rubric
id the plan does not have) makes the run failed: fix the ids in the args, do not edit scores.json. The Workflow itself
throws, naming dir, when no evaluator returns, synthesis returns nothing, or scores.json was not written; treat
that as a failed run (the dossiers stay in dir).
Notes
- Every prompt carries the freshness rule built from
today: facts are web-verified as of that date, the latest edition of every statistic is used, each claim is labelled OPENED / SEARCH-ONLY / INFERRED. - Output files in
dir:<key>.mdand<key>.factcheck.mdper topic,REPORT.md,scores.json. - Keep ideas to what the user listed; do not invent candidates. A failed research or evaluator agent is logged and the
run continues; if no evaluator returns, the run stops and the dossiers stay in
dir.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

