Skip to content
Back to skills

Researchforge Results

ASecurity

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.

  • 7 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 2, 2026
ai-agentspythonbash

Security analysis

A92/100
  • mediumInstalls packages at runtime which could introduce malicious dependencies

Pro shows the line behind each finding and how to fix it

Scanned September 2, 2026

npx -y skills add forger-labs-hq/researchforge --skill researchforge-results --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Researchforge Results?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Researchforge Results
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/forger-labs-hq-researchforge-results/badge)](https://www.skillsdirectory.com/skills/forger-labs-hq-researchforge-results)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: researchforge-results
description: 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

```bash
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.