Agent skill

LoopX Benchmark Operator

by loopx-project in loopx-project/loopx

Operates or analyzes a LoopX-managed benchmark experiment: launching runs, maintaining the experiment board, qualifying integrity, and writing case insights.

Apache-2.0Auto-check passedAgent Workflows

Install LoopX Benchmark Operator

skills CLI
$ npx skills add loopx-project/loopx --skill loopx-benchmark -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install loopx-project/loopx loopx-benchmark --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/loopx-project/loopx.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/loopx-benchmark .claude/skills/loopx-benchmark && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
loopx-benchmark
GitHub stars
6.2k
Token cost
~3.6k tokens
SKILL.md length
1,637 words
Files
3
Skills in repo
12
Repo updated
First seen
Licence
Apache-2.0

At a glance

Operates or analyzes a LoopX-managed benchmark experiment: launching runs, maintaining the experiment board, qualifying integrity, and writing case insights.

  • Works in 5 steps: Validate benchmark_study_manifest_v0… → Wrap one allowlisted manifest,… → Run benchmark upload-local without… → …
  • Launching or selecting a run inside a LoopX-managed benchmark
  • SKILL.md covers Capability surface, Share a study through the…, Share exploratory behavior… and Select the operating lane, plus 5 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

This skill only applies to actual run management or post-run analysis, not to a solver simply completing an assigned benchmark task under its own execution contract, even if that task mentions benchmark or evaluation. Installing the skill alone grants no runner, shell, network, credential, or Goal-mutation authority beyond what the current todo and host already allow.

It exposes its capability surface through a JSON catalog entry and a set of benchmark subcommands for showing or updating the experiment board, fencing a source revision, qualifying integrity, and classifying artifacts, and shares study data with other benchmark developers through a typed, validated manifest and upload-envelope flow rather than handing over a raw runner-specific ledger.

When your agent uses it

  • Launching or selecting a run inside a LoopX-managed benchmark
  • Maintaining experiment-board rows for a benchmark study
  • Writing a post-run case insight from a completed benchmark run

Example prompts

  • “Show the experiment board for this benchmark study.”
  • “Qualify the integrity of this benchmark run before we score it.”
  • “Package this run's results as a portable study manifest.”

Requirements

  • The benchmark-toolkit capability installed in LoopX

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Validate benchmark_study_manifest_v0 with benchmark study-validate.
  2. Wrap one allowlisted manifest, experiment-board row, redacted insight, or runtime
  3. Run benchmark upload-local without --execute first, then explicitly execute
  4. Verify the record/digest/revision binding with benchmark upload-readback.
  5. Derive the campaign/arm/case/run packet with benchmark study-dashboard; pass a

What it can do on your machine

Read from SKILL.md and the folder at commit 8205c8b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are bash).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

LoopX Benchmark Operator loads about 3.6k tokens when it runs. Until then it costs about 108 tokens; SKILL.md has 1,637 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~108
When it runs · the whole SKILL.md, loaded when a task matches
~3.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from loopx-project/loopx at commit 8205c8b, republished under its Apache-2.0 licence (© loopx-project). 1,637 words, ~3,645 tokens.

Download SKILL.mdSave it as .claude/skills/loopx-benchmark/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
loopx-benchmark
description
Use when acting as the operator or post-run analyst of a LoopX-managed benchmark experiment through benchmark-toolkit: select or launch runs, maintain experiment-board rows, qualify integrity, or analyze matched comparisons and case insights. Solving an assigned benchmark task under an existing runner does not by itself select this skill. Excludes casual benchmark discussion and ordinary software microbenchmarks.

LoopX Benchmark Workflow

Use this skill to operate or analyze a LoopX-managed benchmark experiment. The builtin benchmark-toolkit capability owns provider-neutral experiment state and integrity boundaries. This packaged skill is its task-triggered Agent playbook.

An assigned solver follows its task instructions and current execution contract. The words “benchmark”, “evaluation”, or “submission” in that task do not grant the operator role or require experiment-board discovery. Use this workflow when the requested work actually includes run management or post-run analysis; an explicit request to use the skill still applies. Keep the solver's task-local validation and authorized submission path distinct from experiment management.

The capability is catalog-ready without a per-Goal enable switch. Installing this skill does not grant runner, shell, network, credential, private-evidence, or Goal mutation authority. Respect the selected todo's required capabilities, any external provider binding, host permissions, and user gates.

Capability surface

  • loopx capability show benchmark-toolkit --format json — catalog entry with usage hints, role boundaries, and the post-run case-insight template.
  • loopx benchmark --help — subcommands (experiment-board-show, experiment-board-upsert, source-revision-fence, integrity-qualification, classify-artifacts).

Share a study through the public-safe contract

When another benchmark developer needs portable study data, use the capability's typed study flow rather than sharing a runner-specific ledger or raw evidence:

  1. Validate benchmark_study_manifest_v0 with benchmark study-validate.
  2. Wrap one allowlisted manifest, experiment-board row, redacted insight, or runtime observation with benchmark upload-envelope.
  3. Run benchmark upload-local without --execute first, then explicitly execute against a caller-selected local JSONL store.
  4. Verify the record/digest/revision binding with benchmark upload-readback.
  5. Derive the campaign/arm/case/run packet with benchmark study-dashboard; pass a compact four-arm contract only when the study preregistered that design.

For case_insight_projection, first upload the same run's active terminal experiment-board row with insight.status=complete. The case, run, and outcome must match; the run row remains the only arm, score, countability, integrity, and treatment-fidelity authority. Reduce private post-run evidence to bounded prose and public-safe handles or digests before building the envelope.

The local provider is a no-network simulation. It does not grant remote upload, publication, credentials, retention, or benchmark submission authority. Adapters keep their native metric names and reduce private post-run evidence before envelope construction.

Share exploratory behavior findings

When the owner authorizes selected behavioral observations but not a complete study release, use behavior_finding records and benchmark behavior-report. See docs/reference/benchmark-behavior-findings.md for the contract. These records require selection rules, sample denominators, observations, interpretations, limitations, counterevidence, and evidence digests; they require neither a run-row upload nor a full study manifest and have no score authority.

Freeze the authorized disclosure projection before rendering. Review the same scope in visible text, foldouts, embedded data, downloads, and PR attachments. Permission to share duration does not grant permission to share outcome totals or deltas. Schema validity and a producer redaction attestation are not publication approval or verification of unshared evidence. Keep selected-case observations explicitly exploratory and retain the relevant limitations and counterexamples.

Select the operating lane

  • Inspect or explain: use capability show and benchmark --help; remain read-only. Do not create an experiment-board row merely because the user asks what the toolkit does.
  • Plan, select, or launch a run: follow the experiment sequence below. The first action is to read the board; a launch still requires an authorized runner and admitted source.
  • Monitor an active campaign: read the board and runtime-owned projections; update only on material run transitions. Do not manufacture progress from a timer tick.
  • Analyze a terminal run: wait until solving is terminal and scoring is complete before reading hidden evaluator evidence or writing a case insight.

For a generic library microbenchmark or an eval with no LoopX Goal/board, use the task's normal tools instead of imposing this workflow.

Experiment sequence

  1. Read the experiment board before launching or selecting a case.

    bash
    loopx benchmark experiment-board-show --goal-id <GOAL_ID> --format json

    Inspect baseline, treatment, explore, countability, effort, and insight rows before choosing the next arm.

  2. Qualify the source revision before each new run admission.

    bash
    loopx benchmark source-revision-fence \
      --source-checkout <clean-source> \
      --expected-revision <PIN> \
      --observed-reference-revision <OBSERVED_HEAD> \
      --require-admitted --format json

    The fence fails closed unless the clean pinned source matches the observed reference head.

  3. Preview, then preregister or mark the run row when it starts.

    bash
    loopx benchmark experiment-board-upsert --goal-id <GOAL_ID> \
      --row-json <running-row.json> --format json
    loopx benchmark experiment-board-upsert --goal-id <GOAL_ID> \
      --row-json <running-row.json> --execute --format json

    The running row uses status=running, empty metrics, and countability={integrity_qualified:false, official_result_present:false, score_countable:false}. Keep the same stable run_id for every transition.

  4. Preview and upsert terminal score, countability, effort, and insight. First run integrity qualification. An automated restricted-access match is a countable suspicion, not a cheating verdict. After solver and scoring are terminal, inspect the real solver trajectory, tool results, and final workspace. Pass a compact benchmark_restricted_access_adjudication_v0 only after that review; confirm cheating only when restricted material was actually disclosed and causally entered a solving or validation decision.

    bash
    loopx benchmark experiment-board-upsert --goal-id <GOAL_ID> \
      --row-json <terminal-row.json> --execute --format json

    The terminal row sets status=completed, fills metrics (primary metric plus guardrails), and updates countability. Only mark score_countable=true when integrity_qualified=true and official_result_present=true. Fill effort and set insight.status to complete after the post-run analysis.

    For non-baseline arms, also reduce the reviewed mechanism facts separately:

    bash
    loopx benchmark treatment-continuation-receipt \
      --observation-json <compact-post-run-observation.json> --format json

    This receipt distinguishes qualified startup from post-start semantic control persistence. It is analysis-only and must not change score countability, integrity qualification, treatment fidelity, or matched-pair eligibility.

  5. Read matched comparisons before selecting the next arm.

    bash
    loopx benchmark experiment-board-show --goal-id <GOAL_ID> --format json

    Only claim paired results from matched_pair_countable comparisons. Keep diagnostic-only explore rows in a separate evidence lane.

Run-row contract

  • benchmark_id, study_id, case_id, run_id, arm_id, arm_role, attempt, status, observed_at, model_id, protocol_id, comparison_protocol_id, claim_scope, primary_metric, guardrail_metrics, metrics, countability, treatment_fidelity, effort, insight are the canonical row fields (schema_version = benchmark_experiment_board_row_v0).
  • Baseline rows must use treatment_fidelity=not_applicable and cannot name a comparison_anchor_run_id. Non-baseline rows must name a comparison_anchor_run_id.
  • Metrics are {"name": {"value": <number>, "unit": <str>, "higher_is_better": <bool>}}; at most 16 entries. The primary_metric must not also be a guardrail metric.
  • score_countable requires status=completed, integrity_qualified=true, and official_result_present=true. score=0 is a valid completed result.
Show full SKILL.md (722 more words)Show less

Source, integrity, and artifact boundaries

  • source-revision-fence is read-only and caller-observed: it performs no fetch, install, or launch. It blocks new admissions only.
  • integrity-qualification reduces private trajectory and runner isolation evidence to a compact public-safe receipt (hashes, counts, reason codes).
  • Scanner hits for restricted source access or host-boundary escape probes set restricted_access_review=suspected while keeping the run score-eligible. Use --restricted-access-adjudication-json for the post-run agent decision; only confirmed disclosure plus causal use disqualifies the score.
  • classify-artifacts classifies benchmark artifact paths without reading them; use it before reading or publishing any candidate artifact.
  • The solver lane must not read hidden tests, verifier sources, gold answers, or official feedback during the solving phase. The post-run analyst may read full private evidence only after the solver is terminal and scoring is complete.
  • capability bind selects an external provider implementation for a Goal; it is not the activation mechanism for this builtin capability. Todo required_capability fields remain runtime prerequisites, not product capability switches.

Curate live comparison views

When the user wants a persistent experiment overview, keep a stable per-task entry point backed by an explicit maintained selection, rather than sending a new long run-query URL after every restart. Keep task switching and full history one interaction away. Use the existing board/runtime projections for run state and the provider's authorized score projection; a display selection must not become a second source of score, integrity, or countability truth.

  • Include the requested baseline families and feedback modes, current experiments, and important mechanism ablations. Do not silently reduce baselines to the official runner: single-task and native-Goal controls may be essential. If a requested baseline is unavailable, say so instead of substituting another arm.
  • By default, move superseded or problem-stopped attempts out of the core view, while retaining their original traces, scores, retirement reason and replacement reference in history. Never select by score or hide a valid low-scoring arm. An explicitly requested historical baseline may remain visible, with its actual status and incomplete duration labeled; display inclusion is not qualification.
  • Keep historical baselines distinct from current experiments. Expose each arm's runner setting, source/scorer version, feedback mode, budget and sampling cadence through concise labels and accessible details. Mark unmatched versions or budgets as diagnostic context rather than implying a causal comparison.
  • Compare common elapsed sampling windows. Show each completed score promptly, with pending, evaluating, failed and missing points distinguishable; never fill missing scores with zero or splice different attempts into one curve. Preserve original capture times and terminal samples.
  • Reconcile the selection on admission, replacement and retirement while keeping the entry URL stable. Maintain campaign-specific identifiers in private operator state; put only reusable guidance in the shipped skill.
  • Verify the rendered view: requested baselines and active ablations appear, retired attempts are reachable through history, and links survive a selection update. Review the populated first viewport for readable labels and navigation; a correct query alone does not establish a usable comparison view.

Campaign monitoring and post-run insight

  • When a campaign starts and the caller authorizes ongoing monitoring, add one continuous_monitor todo. Refresh aggregate score/coverage and write benchmark_case_insight_v0 on material scored-case transitions, with bounded periodic reviews while the campaign remains active.
  • Treat that monitor as an observation lane, not executable delivery. When a material poll discovers bounded repository, runner-repair, or experiment work, use quota monitor-poll --material-change --next-agent-todo with explicit --next-action-kind, repository, and required capabilities so it creates an independent runnable advancement_task. An unchanged poll creates no successor and spends no delivery quota.
  • If the main campaign advancement Todo is waiting for a monitor transition, keep it open and pair resume_when=monitor_changed:<monitor-todo-id> with an already-created independent runnable successor. Do not mark the wait blocked, and do not treat the monitor itself as delivery work.
  • Report only public-safe conclusions (countable baselines, countable treatments, matched pairs, aggregate primary metric by arm, improved/flat/ regressed pair counts). Never copy raw private evidence into a user update.
  • After a solver stops and scoring completes, read the task, real trajectory, final workspace, hidden tests, verifier, and failure/score details; write one benchmark_case_insight_v0 explaining the decisive evidence, why the outcome happened, and what LoopX should test next.
  • For treatment arms, record whether qualified startup was followed by semantic Todo transitions, technical replans, or control closeout. Use startup_only only when a complete authorized post-run review observed no such transition; otherwise absence is unknown. Keep terminal settlement separate.
  • Do not send a repetitive user update when nothing material changed.

© loopx-project, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 2 other files in skills/loopx-benchmark of loopx-project/loopx.

  • SKILL.md
  • .loopx-skill-scope
  • agents/openai.yaml

Open the folder on GitHubat commit 8205c8b

Compare with similar skills

LoopX Benchmark Operator next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

LoopX Benchmark Operator compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
LoopX Benchmark Operator this skillloopx-project/loopx6.2k—~3.6kAutomated safety check: PassApache-2.0
MCP Server Builderanthropics/skills180k62 repos~2.3kAutomated safety check: PassApache-2.0
Diagnosing Superpowers Sessionsobra/superpowers296k3 repos~1.7kAutomated safety check: PassMIT
Darwin Skill Optimizeralchaincyf/darwin-skill6.2k1 repos~4.7kAutomated safety check: PassMIT
Skill Release Gaterohitg00/ai-engineering-from-scratch65k—~1kAutomated safety check: PassMIT
CodeGraph Agent Evalcolbymchenry/codegraph73k—~950Automated safety check: PassMIT

Similar skills

  • MCP Server Builder

    anthropics/skills

    Official

    Guides the design and implementation of Model Context Protocol servers in TypeScript or Python, from tool naming and error messages to evaluation.

    180k GitHub starsUsed in 62 repos~2.3k tokens
    Agent WorkflowsAuto-check passed
  • Investigates a session where Superpowers went wrong, reads the transcripts on disk and produces an evidence-cited report, optionally prepared as a bug report for the maintainers.

    296k GitHub starsUsed in 3 repos~1.7k tokens
    Agent WorkflowsAuto-check passed
  • Darwin Skill Optimizer

    alchaincyf/darwin-skill

    Scores SKILL.md files on a nine-dimension rubric, then improves them in a keep-or-revert loop with independent judge agents, test prompts, git history and human checkpoints.

    6.2k GitHub starsUsed in 1 repo~4.7k tokens
    Agent WorkflowsAuto-check passed
  • Skill Release Gate

    rohitg00/ai-engineering-from-scratch

    Evaluates an Agent Skill bundle before release for structure, trigger quality, artifact improvement, script correctness, safety, installed-tree integrity and host portability.

    65k GitHub stars~1k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • CodeGraph Agent Eval

    colbymchenry/codegraph

    Benchmarks how much CodeGraph helps a coding agent on a real repository, comparing runs with and without it for a chosen local or published version.

    73k GitHub stars~950 tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Mines local Copilot CLI session logs for dotnet/maui to rank costly or failing runs, tag recurring failure modes, propose repo edits and emit guard evals.

    23k GitHub stars~3.4k tokensUpdated today
    Agent WorkflowsAuto-check passed

More from loopx-project/loopx

All 12 skills in this repo
  • LoopX PR Program Manager

    loopx-project/loopx

    Tracks a group of pull or merge requests across repositories as durable LoopX state: inventory, reconcile changes, keep priorities and a roadmap, and monitor over time.

    6.2k GitHub stars~1.9k tokensUpdated today
    Auto-check passed
  • LoopX Self Repair

    loopx-project/loopx

    Diagnoses surprising LoopX behavior, such as stale recommendations or tiny progress, assigns it to the responsible layer and repairs it at the lowest durable level.

    6.2k GitHub stars~2.2k tokensUpdated today
    Auto-check passed
  • LoopX Auto-Research Worker

    loopx-project/loopx

    Role playbook for a LoopX worker running an auto-research lane, with execution checklists, artifact contracts and stop conditions.

    6.2k GitHub stars~3.5k tokensUpdated today
    Auto-check passed
  • LoopX Doc Registry

    loopx-project/loopx

    Registers durable project materials such as design docs, SOPs and research notes in a LoopX project's own registry so future agents can find them without raw URLs or private content.

    6.2k GitHub stars~707 tokensUpdated today
    Auto-check passed
  • LoopX PR Review

    loopx-project/loopx

    Runs an evidence-backed pull request review through the loopx CLI and posts bilingual reviews: a full Chinese review plus one concise English verdict.

    6.2k GitHub stars~3.3k tokensUpdated today
    Auto-check passed
  • LoopX Project Lifecycle

    loopx-project/loopx

    Connects and configures LoopX projects and Goals, repairs project-local state and stale status, syncs registry entries and diagnoses CLI routing.

    6.2k GitHub stars~14k tokensUpdated today
    Auto-check passed

Categories

Questions about LoopX Benchmark Operator

What does LoopX Benchmark Operator do?

Operates or analyzes a LoopX-managed benchmark experiment: launching runs, maintaining the experiment board, qualifying integrity, and writing case insights. This skill only applies to actual run management or post-run analysis, not to a solver simply completing an assigned benchmark task under its own execution contract, even if that task mentions benchmark or evaluation. Installing the skill alone grants no runner, shell, network, credential, or Goal-mutation authority beyond what the current todo and host already allow.

When should I use LoopX Benchmark Operator?

LoopX Benchmark Operator fits situations like: launching or selecting a run inside a LoopX-managed benchmark; maintaining experiment-board rows for a benchmark study; writing a post-run case insight from a completed benchmark run.

How do I install LoopX Benchmark Operator in Claude Code?

Run `npx skills add loopx-project/loopx --skill loopx-benchmark -a claude-code`. Or copy the skill folder (skills/loopx-benchmark in loopx-project/loopx) into .claude/skills/loopx-benchmark in your project. Claude Code loads it when a task matches its description.

How do I install LoopX Benchmark Operator in Codex?

Run `npx skills add loopx-project/loopx --skill loopx-benchmark -a codex`. Or copy the skill folder (skills/loopx-benchmark in loopx-project/loopx) into .agents/skills/loopx-benchmark in your project. Codex loads it when a task matches its description.

Can I use LoopX Benchmark Operator in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add loopx-project/loopx --skill loopx-benchmark -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/loopx-benchmark, .gemini/skills/loopx-benchmark, .github/skills/loopx-benchmark and .opencode/skills/loopx-benchmark in your project.

What does LoopX Benchmark Operator need to run?

SKILL.md names no scripts, command-line tools or credentials: LoopX Benchmark Operator is instructions for the agent only. Our summary lists: The benchmark-toolkit capability installed in LoopX.

Does LoopX Benchmark Operator access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is LoopX Benchmark Operator safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does LoopX Benchmark Operator use?

LoopX Benchmark Operator is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does LoopX Benchmark Operator use?

About 3.6k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to LoopX Benchmark Operator?

Skills that share tags, products or a category with LoopX Benchmark Operator: MCP Server Builder (anthropics/skills, 180k stars), Diagnosing Superpowers Sessions (obra/superpowers, 296k stars), Darwin Skill Optimizer (alchaincyf/darwin-skill, 6.2k stars) and Skill Release Gate (rohitg00/ai-engineering-from-scratch, 65k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains LoopX Benchmark Operator?

loopx-project (a GitHub organization) maintains it in loopx-project/loopx, which has 6,167 GitHub stars. The repository holds 12 skills in this directory. The repository was last updated on October 7, 2026.

Source: loopx-project/loopx on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.