microsoft/idea-quality
Score the QUALITY of a research idea at the idea stage — given a Markdown file with Title / Motivation / Method sections (no experiments needed), produce a per-axis quality assessment with cited evidence and an overall 0–100 score plus a verdict; or, given two such idea files, a blind head-to-head comparison. TRIGGER when the user asks "how good is this idea", "rate / score / grade this research idea or proposal", "review my idea .md before I write it up", "is this contribution strong enough to pursue", "which of these two idea files is stronger", or hands over an idea Markdown file (Title/Motivation/Method) and wants a quality judgment. Use this even when the user does not say the word "score" but clearly wants an assessment of how strong an idea is. DO NOT trigger for prior-art / overlap / "is this novel vs existing work" checks (that is a literature-collision task), for full reviews of finished papers that already have results, or for generating the idea itself.
npx skills add https://github.com/microsoft/ResearchStudio --skill idea-quality
Judge how strong a research idea is at the idea stage — before any experiments exist — and return a quality score with reasons a reviewer would recognize. This skill is self-contained: it judges from first principles on the three axes below. It consults no external corpus, dataset, or other skill, so its judgment is reproducible from the idea text alone.
The idea is a .md file with three sections. Read the file, then map each section to what it feeds:
# Title
<≤ ~15 words: the idea's handle>
## Motivation
<the bottleneck / gap the idea attacks, why it matters, and why it is still open>
## Method
<the proposed contribution as concrete numbered steps>
If a section is missing or thin, infer the most reasonable reading from the rest and note the assumption in the report — do not stall asking for clarification. If the user passes two files (or one file with two ideas) and wants a comparison, run the pairwise track.
A strong score means *the idea is strong*; it does not predict acceptance, which also turns on execution this skill cannot see.
Score on exactly these three. Each is (a) assessable from the idea alone without experiments, (b) able to discriminate strong from weak, and (c) not a proxy for writing polish.
A — Problem position quality. Is the gap the Motivation identifies *real, important, non-obvious, and genuinely open* — or shallow, already-solved, or a conveniently easy target?
B — Method quality. Is the proposed method good in itself? Score it as ONE number, but in the Reason you MUST decompose into three named sub-judgments, because a single number otherwise hides *which* of them is weak:
C — Problem-fit. Does the Method actually target and *plausibly resolve the specific gap in the Motivation* — rather than an adjacent, easier, or different problem?
Always run the absolute track. When comparing two ideas, ALSO run the pairwise track — and treat pairwise as the trustworthy signal, because relative judgments are far less noisy than absolute numbers (which bunch around 3/5). The absolute 0–100 is a readable secondary readout, not a calibrated truth.
Per axis, score 1–5 (integer). There are deliberately no fixed level descriptors — instead every score quotes the specific phrase / element of the idea that justifies it. A score with no quoted evidence is not allowed; the evidence requirement, not a rubric table, is what keeps scores honest. Judge substance, not length or fluency — a short crisp idea can score 5; a long polished one can score 2.
Overall score (equal weight, each axis 1→0 and 5→full):
overall = round(100 * (A + B + C - 3) / 12)
Verdict band: strong ≥ 67 · borderline 34–66 · weak < 34.
A/C gate (overrides the band). A and C are near-necessary, B is not — so:
strong (cap at borderline at best), regardless of the number. Reason: a great method on a trivial problem (low A), or a great problem with a method that doesn't address it (low C), is not a strong idea — and the equal-weight mean would otherwise mislead. State the cap and why in one line.For each axis state which idea is stronger (Idea 1 / Idea 2 / tie) and why, in one line; for axis B, note per-sub-judgment (depth / soundness / feasibility) which arm wins so the diagnostic isn't lost. Then give an overall winner holistically — but problem-fit (C) is near-necessary: a decisive C loss usually decides the overall, even if that idea wins A and B, because a method that doesn't fit its problem isn't the better idea. Decide each axis independently; do not let one axis sway the others.
Judge blind to source. If two ideas are compared as part of an evaluation, do NOT factor in which system/model produced which — provenance is not evidence of quality. (For this to be fair, the two inputs must share the same Title/Motivation/Method format; flag it if they don't.)
For a single idea:
## Idea Review — <title>
**Decomposition**
- Problem / gap (from Motivation): …
- Method (the proposed move): …
- Why it should work: …
(assumptions inferred, if any: …)
**Axis scores**
| Axis | Score (1–5) | Evidence (quoted from the idea) | Reason |
|------|-------------|----------------------------------|--------|
| A — Problem position | | | |
| B — Method quality | | | depth: … · soundness: … · feasibility: … |
| C — Problem-fit | | | |
**Overall: NN / 100 · Verdict: strong | borderline | weak**
<if the A/C gate fired: one line naming the cap and why>
**Strongest point:** <one sentence>
**Most fixable weakness:** <one sentence, phrased as what would raise the score>
For a comparison, output the absolute block for each idea, then:
## Pairwise verdict (Idea 1 vs Idea 2)
| Axis | Stronger | Why (one line) |
|------|----------|----------------|
| A — Problem position | 1 / 2 / tie | |
| B — Method quality | 1 / 2 / tie | depth / soundness / feasibility: who wins each |
| C — Problem-fit | 1 / 2 / tie | |
**Overall winner: Idea 1 | Idea 2 | tie** — <one–two sentence rationale; if a decisive C loss drove it, say so>
Take microsoft/idea-quality from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.