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 xuansenpa1/skillrevise --skill fjsp-baseline-repair-with-downtime-and-policygit clone --depth 1 https://github.com/xuansenpa1/skillreviseWrote 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/xuansenpa1/skillrevise/fjsp-baseline-repair-with-downtime-and-policy)<a href="https://agentmods.dev/skills/xuansenpa1/skillrevise/fjsp-baseline-repair-with-downtime-and-policy"><img src="https://agentmods.dev/badge/skills/xuansenpa1/skillrevise/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/xuansenpa1/skillrevise/fjsp-baseline-repair-with-downtime-and-policy"><img src="https://agentmods.dev/badge/skills/xuansenpa1/skillrevise/fjsp-baseline-repair-with-downtime-and-policy.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.
This is a copy
100% identical to fjsp-baseline-repair-with-downtime-and-policy — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
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 xuansenpa1/skillrevise (56 stars, last pushed 7d ago), licensed MIT. 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. It is 100% identical to fjsp-baseline-repair-with-downtime-and-policy, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
local-ai-agents
Build local-first AI agents that run entirely on a developer workstation with Microsoft Foundry Local and Qwen function-calling models. Covers Small Language Models (SLMs), the OpenAI-compatible local endpoint, sandboxed local tools, local RAG with Chroma, local MCP servers, hybrid cloud/local routing, and the…
next-cache-components-adoption
Turn on Cache Components in a Next.js app and resolve the blocking routes it surfaces. Use when the user wants to enable, adopt, or migrate to Cache Components, flip the cacheComponents flag, work through a flood of blocking-prerender / instant validation errors, run the cache-components-instant-false codemod, or…
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…
insight-error-page
Write or audit an insight-kind error page for the Next.js dev overlay. Use when creating a new errors/ .mdx page, auditing an existing one, or checking that a page matches the framework fix cards. Covers page structure, title alignment, FixCard cards with Copy prompt button, code snippets, terminology verification…