SkillsBench is a benchmark for measuring how effectively AI agents use modular skills—folders containing instructions, scripts, and resources—to complete specialized tasks. It helps researchers and developers evaluate both skill quality and agent behavior, including tasks that require combining multiple skills. The catalogue’s skills and instructions are evaluated as part of this workflow.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add benchflow-ai/skillsbench --skill fjsp-baseline-repair-with-downtime-and-policygit clone --depth 1 https://github.com/benchflow-ai/skillsbenchWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/benchflow-ai/skillsbench/fjsp-baseline-repair-with-downtime-and-policy)<a href="https://agentmods.dev/skills/benchflow-ai/skillsbench/fjsp-baseline-repair-with-downtime-and-policy"><img src="https://agentmods.dev/badge/skills/benchflow-ai/skillsbench/fjsp-baseline-repair-with-downtime-and-policy/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/benchflow-ai/skillsbench/fjsp-baseline-repair-with-downtime-and-policy"><img src="https://agentmods.dev/badge/skills/benchflow-ai/skillsbench/fjsp-baseline-repair-with-downtime-and-policy.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 6 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00052 | $0.01146 |
| Opus 5 | $0.00026 | $0.00573 |
| Sonnet 5 | $0.00010 | $0.00229 |
| Haiku 4.5 | $0.00005 | $0.00115 |
Grade A, and why
fjsp-baseline-repair-with-downtime-and-policy scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
1 near-identical copy found in the catalogue:
- fjsp-baseline-repair-with-downtime-and-policy — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 79 lines — stays where its author put it; the contents beside it link to each section on GitHub.
This skill should be considered when you need to enhance a given infeasible or non-optimal fjsp baseline to a feasible schedule with less makespan considering downtime constraints, job precedence violations, policy budget constraints. The following constraints should be satisfied. end(j, o) <= start(j, o+1). Here j means the job index and o means the operation index. There should be no overlaps on the same machine or with downtime windows. Keep the number of machine changes and the total L1 start-time shift within the policy budgets. You can calculate the number of machine changes by MC = \sum_{(j,o)} [m_{new}(j,o) \ne m_{base}(j,o)]. You can calculate the total L1 start-time shift by Shift_{L1} = \sum_{(j,o)} |start_{new}(j,o) - start_{base}(j,o)|. To achieve this, never start any operation earlier than the baseline. When repairing operations in precedence-aware order, place each operation at the earliest feasible time. Anchor is calculated by anchor(j,o) = \max(start_{base}(j,o), end_{new}(j,o-1)), end_{new}(j,o-1) is end time of the previous operation of the same job at the new schedule. If start > anchor, then start-1 must be infeasible. You guarantee this by scanning integer time forward by +1 from anchor. Jumping to “next gap” without checking every integer may break minimality. If the given baseline is invalid, replace the machine with a feasible one.
Here is the pipeline. For each operation, first find the earliest time to start. It cannot start earlier than the baseline, and it cannot start before the previous operation of the same job finishes. Then list only the machines that are allowed for this operation, and use the processing time that belongs to each machine. For each candidate machine, find the allowed earliest time and pick the first start time that does not overlap with other work on that machine and does not fall into any downtime window. Choose the option that makes the smallest changes overall. Prefer not changing machines and keeping start-time shifts small, and make sure you stay within the policy budgets. After selecting a start time, immediately record this operation on the machine timeline in the same precedence-aware order, so the result matches the evaluator’s step-by-step simulation.
Here are reference codes.
# sorted Downtime windows
downtime[m] = sorted([(start,end), ...])
def overlap(s,e,a,b):
return s < b and a < e
# Precedence-aware repair order
def precedence_aware_order(base_list):
base_map = {(r["job"], r["op"]): r for r in base_list}
base_index = {(r["job"], r["op"]): i for i, r in enumerate(base_list)}
keys = list(base_map.keys())
keys.sort(key=lambda k: (k[1], base_map[k]["start"], base_index[k]))
return keys
def earliest_feasible_time(m, anchor, dur, machine_intervals, downtime, safety=200000):
t = int(anchor)
for _ in range(safety):
if not has_conflict(m, t, t+dur, machine_intervals, downtime):
return t
t += 1
return t
def has_conflict(m, st, en, machine_intervals, downtime):
for a,b in machine_intervals.get(m, []):
if overlap(st,en,a,b):
return True
for a,b in downtime.get(m, []):
if overlap(st,en,a,b):
return True
return False
# Baseline machine may be illegal
base_m = base_map[(j,o)]["machine"]
if base_m not in allowed[(j,o)]:
# baseline is invalid; pick a legal default (min duration is a good heuristic)
base_m = min(allowed[(j,o)], key=lambda m: allowed[(j,o)][m])
base_d = allowed[(j,o)][base_m]
#Use a lexicographic score that matches your priorities
machine_change = int(mm != base_m_orig)
start_shift = abs(st - base_start)
score = (machine_change, start_shift, st, mm)
#Then pick the smallest score, but respect remaining machine-change budget.
#A naive “always keep baseline machine” can cause large start shifts. This often reduces `Shift_L1` enough to pass tight budgets without exploding machine changes. Use a simple trigger to consider alternates *only when it helps*:
THRESH = 6 # tune; small instances often 3~10 works
# First try baseline machine
cand = best_candidate_restricted_to([base_m])
# If shift is large and we still can change machines, search alternates
if (cand.start - base_start) >= THRESH and mc_used < max_mc:
cand2 = best_candidate_over_all_allowed_machines()
if cand2.start < cand.start: # or cand2.shift < cand.shift
cand = cand2
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 79 lines · 52 tokens per session scan A 2668bd6b9c69
fjsp-baseline-repair-with-downtime-and-policy is a skill published in the GitHub repository benchflow-ai/skillsbench (1,764 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 52 tokens to every session and 1,146 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
hotpath_init
Configure hotpath profiling in a Rust project. Adds the hotpath dependency with feature-gated setup, instruments main with hotpath::main, functions with measure/measureall, and wraps channels, mutexes, rwlocks, streams, futures, reqwest clients, axum routers and byte-level I/O with hotpath macros. Use when the user…
portfolio
Cross-chain DeFi portfolio discovery, rebalancing suggestions, and NEAR Intent construction. Activates when the user pastes a wallet address or asks about yield/positions/rebalancing. Bootstraps a per-user "portfolio" project, aggregates positions across all the user's addresses inside one project, and offers a…
llm-council
Query multiple LLM models in parallel from CodeAct and cross-reference their responses.
environment-discovery
Systematic exploration of unknown environments before starting work.
performant-code
Writing efficient code that handles large data and tight constraints.
rag-eval
NVIDIA RAG Blueprint evaluation guidance for measuring retrieval and answer quality with stable datasets, baselines, and reproducible scoring workflows.