result-to-claim
Use when experiments complete to judge what claims the results support, what they don't, and what evidence is still missing. Codex MCP evaluates results against intended claims and routes to next action (pivot, supplement, or confirm). Use after experiments finish — before writing the paper or running ablations.
npx skills add majiayu000/claude-skill-registry --skill result-to-claim --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Result-to-Claim Gate > 🔒 **Do not wrap this skill in `/loop`, `/schedule`, or `CronCreate`.** It is > verdict-bearing — it judges whether results support a claim. Re-running that > verdict on a wall-clock timer adds no new signal (the verdict changes only > when the *results* change, not when the clock ticks). What you actually want > to schedule is the *external wait that precedes it* — experiments done → then > run this gate **once**. See > [`shared-references/external-cadence.md`](../shared-references/external-cadence.md). Experiments produce numbers; this gate decides what those numbers *mean*. Collect results from available sources, get a Codex judgment, then auto-route based on the verdict. ## Context: $ARGUMENTS ## When to Use - After a set of experiments completes (main results, not just sanity checks) - Before committing to claims in a paper or review response - When results are ambiguous and you need an objective second opinion ## Workflow ### Step 1: Collect Results Gather experiment data from whatever sources are available in the project: 1. **W&B** (preferred): `wandb.Api().run("<entity>/<project>/<run_id>").history()` — metrics, training curves, comparisons 2. **EX
- Context: $ARGUMENTS
- When to Use
- Workflow
- Step 1: Collect Results
- Step 1.5: Deterministic evidence pre-check (before spending a Codex call)
- Step 2: Codex Judgment
- Step 3: Parse and Normalize
- Step 3.5: Check Experiment Integrity (if audit exists)
- Step 4: Route Based on Verdict
- Step 5: Update Research Wiki (if active)
- Rules
- Review Tracing
Policy B = warn-and-skip: nothing here may abort the audit. cd is non-fatal, the
helper run is explicitly non-blocking, no pipefail-fragile pipe.
cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" 2>/dev/null || true
if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills.txt ]; then
fi
mkdir -p .aris
if [ -n "$EVIDENCE_CHECK" ]; then
python3 "$EVIDENCE_CHECK" . --batch .aris/claims.json > .aris/evidence_precheck.json 2>.aris/evidence_precheck.err || true
if [ -s .aris/evidence_precheck.json ] && python3 -c "import json,sys;json.load(open('.aris/evidence_precheck.json'))" 2>/dev/null; then
cat .aris/evidence_precheck.jsonWhat does the result-to-claim skill do?
Use when experiments complete to judge what claims the results support, what they don't, and what evidence is still missing. Codex MCP evaluates results against intended claims and routes to next action (pivot, supplement, or confirm). Use after experiments finish — before writing the paper or running ablations.
How do I install it?
Run `npx skills add majiayu000/claude-skill-registry --skill result-to-claim --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From majiayu000/claude-skill-registry, a repository with 534 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.