compare-core
Skill1 starsChanged 3 months agoMITView on GitHub
Type: shared-lib (deterministic) · Used by: compare-to-baseline + run-k6-action gate + perf-run-one · Status: LIVE (P1) Executable implementation: .github/actions/run-k6-action/compare-core.js (Node, zero deps). This SKILL.md is the spec; the JS is the code BOTH delivery surfaces run — the CI gate via action.yml, the agentic loop via the compare-to-baseline skill. Any rule change updates this spec AND the JS together, in the same commit. You are compare-core. You receive a parsed contract and a baseline file and must produce a verdict.…
In this repository42 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- k6-browser-testSkill
- k6-load-testSkill
- k6-playwright-converterSkill
- k6-smoke-testSkill
- k6-test-plannerSkill
- apply-ws2-conventionsSkill
- author-resilient-playwrightSkill
- build-status-viewsSkill
- choose-k6-execution-modeSkill
- compare-to-baselineSkill
- corroborate-2-sourcesSkill
- curate-baselinesSkill
- doc-consistency-checkSkill
- emit-otlp-and-prometheusSkill
- estimate-token-costSkill
- explore-product-structureSkill
- file-perf-regression-jiraSkill
- func-verdictSkill
- heal-playwright-suiteSkill
- k6-profile-benchmarkSkill
- k6-profile-loadSkill
- k6-profile-soakSkill
- k6-profile-spikeSkill
- k6-profile-stressSkill
- learn-via-k6-docsSkill
- link-grafana-panelSkill
- notify-responsible-teamSkill
- open-draft-prSkill
- parse-k6-json-summarySkill
- parse-playwright-summarySkill
- perf-run-logSkill
- run-k6-scriptSkill
- run-ledgerSkill
- run-playwright-suiteSkill
- scope-reviewSkill
- scrub-har-secretsSkill
- triage-func-verdictSkill
- triage-perf-verdictSkill
- verify-k6-scriptSkill
- verify-playwright-suiteSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 0 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 33
Write verdict.json with overall_verdict: "fail" and STOP
- Very specific: line 38
Look for a matching entry in contract.endpoints by name or metric field
- Very specific: line 39
If an expected endpoint is absent from the contract → mark it verdict: "red", reason: "missing from run output"
- Very specific: line 51
If p95 is null or non-numeric in the contract → verdict "red", reason "p95 not recorded"
- Very specific: line 71
If there are no endpoints at all in the baseline → overall_verdict = "no-baseline", do NOT set red.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
compare-core
The ONE verdict implementation — imported everywhere so skill, Action, and workflow can never disagree.
Type: shared-lib (deterministic) · Used by: compare-to-baseline + run-k6-action gate + perf-run-one · Status: LIVE (P1)
Executable implementation:
.github/actions/run-k6-action/compare-core.js(Node, zero deps). This SKILL.md is the spec; the JS is the code BOTH delivery surfaces run — the CI gate viaaction.yml, the agentic loop via thecompare-to-baselineskill. Any rule change updates this spec AND the JS together, in the same commit.
Prompt
You are compare-core. You receive a parsed contract and a baseline file and must produce a verdict. This is pure deterministic logic — no model judgment, no inference.
Inputs
contract — contents of reports/<run_id>/contract.json (from parse-k6-json-summary)
baseline — contents of baselines/<team>.<profile>.json
run_id — string (for labeling output)
exit_code — integer (from run-k6-script; 97 = FAIL regardless of metrics)Step 1 — Immediate FAIL on exit code 97
If exit_code == 97:
- Set
overall_verdict = "fail" - Set
reason = "k6 abort (exit 97) — run did not complete" - Skip all threshold math
- Write verdict.json with
overall_verdict: "fail"and STOP
Step 2 — Check for missing expected endpoints
For each endpoint defined in baseline.endpoints (or baseline.metrics — check both keys):
- Look for a matching entry in
contract.endpointsbynameormetricfield - If an expected endpoint is absent from the contract → mark it
verdict: "red",reason: "missing from run output"
Step 3 — Per-endpoint verdict
Two states only: green or red.
p95 verdict:
if p95 <= p95_red_ms → "green"
else → "red"If p95 is null or non-numeric in the contract → verdict "red", reason "p95 not recorded"
Fail closed on a malformed threshold. A gate must never pass on bad data. If a
threshold entry has neither a numeric p95_red_ms nor an error_rate_red, the metric
has no usable red line → verdict "red", reason "no usable threshold in baseline".
(A NaN comparison such as p95 > undefined silently yields green, so both operands are
guarded explicitly.)
Error rate override:
if error_rate > error_rate_red → override verdict to "red", reason "error_rate exceeded"Step 4 — Overall verdict
overall_verdict = worst of all per-endpoint verdicts
priority: fail > red > greenIf there are no endpoints at all in the baseline → overall_verdict = "no-baseline", do NOT set red.
Step 5 — Compute deltas
For each endpoint:
delta_ms = contract p95 - baseline p95_red_ms (positive = over threshold)
delta_pct = (delta_ms / baseline p95_red_ms) * 100 (round to 1 decimal)Step 6 — Write verdict.json
Write reports/<run_id>/verdict.json:
{
"run_id": "<run_id>",
"team": "<from baseline>",
"profile": "<from baseline>",
"env": "<from baseline>",
"overall_verdict": "green" | "red" | "fail" | "no-baseline",
"exit_code": <n>,
"endpoints": [
{
"name": "<string>",
"metric": "<string>",
"p95_ms": <integer or null>,
"p95_red_ms": <integer>,
"delta_ms": <integer>,
"delta_pct": <float>,
"verdict": "green" | "red",
"reason": "<string — only set if red>"
}
],
"missing_endpoints": ["<name>", ...],
"summary_line": "<one human-readable line: overall verdict + worst delta>"
}Step 7 — Return
Return the verdict object. The caller (compare-to-baseline) writes it to disk.
Tools
None — pure deterministic logic. Read baseline + contract files; write verdict.json.
Data
- Reads:
reports/<run_id>/contract.json,baselines/<team>.<profile>.json - Writes:
reports/<run_id>/verdict.json
Hard rules
- Exit code 97 = FAIL unconditionally — never evaluate thresholds on a crashed run.
- Missing endpoint = red — a baseline endpoint absent from the run is always red.
- p95 null = red — a metric that wasn't recorded is a data gap treated as red.
- Two verdicts only: green or red — no amber, no warning, no partial. Below threshold = green, at or above = red.
- One implementation — this file IS the verdict logic.
compare-to-baseline,run-k6-action, andperf-run-oneall call this. Never duplicate the math. - p95 is the compared percentile everywhere — do not act on p50/p99 as the primary verdict.
- No model calls — this runs on the gate hot path (0-model-call budget).
Frozen skill registry: AGENTS.md in this repo
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

