How do I install the Researchforge Results skill?

Run npx skillmds@latest add forger-labs-hq/researchforge-results in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Researchforge Results safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Researchforge Results?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Researchforge Results free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Researchforge Results?

forger-labs-hq (@forger-labs-hq) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Researchforge Results by forger-labs-hq

Name: Researchforge Results
Author: forger-labs-hq

Researchforge Results

Summarize a run's results — ranking, Pareto trade-offs, constraint violations, and rejected experiments — grounded strictly in recorded measurements. Use when the user asks how the experiments went or which variant won.

File contents

Read and explain results

researchforge results show <run-id> --json

The JSON contains everything you may talk about: per-experiment measured metrics, baseline deltas, constraint checks, the ranking, the Pareto frontier over direction-inferable metrics, trade-off notes, and caveats.

How to summarize honestly:

quote only numbers present in the JSON; never estimate, extrapolate, or fill gaps from memory — if a number is not recorded, say so;
include the losers: rejected and failed experiments, with their recorded reasons, are first-class findings;
surface every caveat the engine attached (including the one-off-result caveat) — a single full-benchmark win is promising, not validated;
when candidates trade off (e.g. quality vs latency), present the frontier and let the user choose; do not silently pick for them.

For a visual overview, researchforge dashboard writes a self-contained HTML dashboard (charts of every experiment vs the baseline, the trade-off scatter with the constraint line, the funnel, and validation spread) to .researchforge/reports/dashboard.html — offer researchforge dashboard --open when the user wants to see the results; it is built from the same recorded data and nothing else. For a live view while runs are in progress, researchforge serve --open starts a local read-only monitor (requires pip install "researchforge[serve]").

If a candidate looks like a winner, the next step is the researchforge-validate skill — repeated runs are what earn the word "validated".

Rules

The Python engine is the boundary: never work around a validation error, a protected path, or an approval gate — fix the artifact or ask the user.
Approvals belong to the user: never pass --yes or type a confirmation unless the user explicitly approved that step in this conversation.
Ground every summary in stored data: quote only numbers returned by --json output or files under .researchforge/ — never invent metrics.

---name: researchforge-resultsdescription: Summarize a run's results — ranking, Pareto trade-offs, constraint violations, and rejected experiments — grounded strictly in recorded measurements. Use when the user asks how the experiments went or which variant won.---# Read and explain results```bashresearchforge results show <run-id> --json```The JSON contains everything you may talk about: per-experiment measuredmetrics, baseline deltas, constraint checks, the ranking, the Paretofrontier over direction-inferable metrics, trade-off notes, and caveats.How to summarize honestly:- quote **only** numbers present in the JSON; never estimate, extrapolate, or fill gaps from memory — if a number is not recorded, say so;- include the losers: rejected and failed experiments, with their recorded reasons, are first-class findings;- surface every caveat the engine attached (including the one-off-result caveat) — a single full-benchmark win is *promising*, not *validated*;- when candidates trade off (e.g. quality vs latency), present the frontier and let the user choose; do not silently pick for them.For a visual overview, `researchforge dashboard` writes a self-containedHTML dashboard (charts of every experiment vs the baseline, the trade-offscatter with the constraint line, the funnel, and validation spread) to`.researchforge/reports/dashboard.html` — offer `researchforge dashboard--open` when the user wants to *see* the results; it is built from the samerecorded data and nothing else. For a *live* view while runs are inprogress, `researchforge serve --open` starts a local read-only monitor(requires `pip install "researchforge[serve]"`).If a candidate looks like a winner, the next step is theresearchforge-validate skill — repeated runs are what earn the word"validated".## Rules- The Python engine is the boundary: never work around a validation error, a protected path, or an approval gate — fix the artifact or ask the user.- Approvals belong to the user: never pass `--yes` or type a confirmation unless the user explicitly approved that step in this conversation.- Ground every summary in stored data: quote only numbers returned by `--json` output or files under `.researchforge/` — never invent metrics.

Frequently asked questions