agentleFS
renzrollonrenzrollon/interlock/skills/dispatch/SKILL.md

dispatch

Skill61 starsChanged 7 days agoMITView on GitHub

Route a request to the right interlock skill, after one batched pre-flight that loads git state, OpenSpec status, open tasks and graph presence in a single pass. Use when you are not sure which skill applies, or at the start of a session to orient before doing anything else.

  • Installs packages

40 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use edge-detection, odds-analysis and 8 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • noahowshSkill

    edge-detection

    Comparing a tennis model's probability with the market: no-vig close, expected value at the best available price, closing line value, fractional Kelly sizing, and the checks that separate an estimated edge from noise. Use when the user has a probability and wants to know whether a price is better than fair, how large a stake is reasonable, or whether an edge is real. Requires a probability the user trusts. Do not use for fetching prices: see odds-explorer. Do not use for devig math alone: see odds-analysis. Do not use for historical testing: see backtesting.

    Also in 4 projects that use this

  • noahowshSkill

    odds-analysis

    Odds math for two-way tennis markets: American to implied probability, margin, devigging (multiplicative, power, Shin), no-vig fair odds, consensus across books, favorite-longshot bias, and expected value of a price. Use when the user asks what a price implies, how to remove the vig, what the true probability is, or how to compare books. Do not use for fetching or comparing live prices: see odds-explorer. Do not use for deciding a bet against a model: see edge-detection.

    Also in 4 projects that use this

  • agiprolabsSkill

    walk-forward-validation

    Walk-forward validation framework for trading strategies and ML models with time-series-aware splits, overfit detection, and regime-aware validation

    Also in 4 projects that use this

  • Yahmez3Skill

    backtesting

    Use when backtesting a trading strategy — evaluating a signal series against historical price data and computing performance metrics (Sharpe, Sortino, max drawdown, CAGR, win rate, expectancy). Triggers on "backtest this strategy", "what's the Sharpe on X", "run a walk-forward test", or "compare strategies A and B". Produces equity curves, trade logs, and tear sheets.

    Also in 4 projects that use this

  • ffsshhttiikkSkill

    feature-engineering

    Machine learning feature engineering

    Also in 4 projects that use this

  • varun29ankuSSkill

    orchestrate

    This skill should be used when the user asks to 'orchestrate a task', 'break down work into parallel agents', 'coordinate subtasks', 'run agents in parallel', or mentions 'multi-agent'. Decomposes complex tasks into tracked subtasks, dispatches parallel subagents, and coordinates until completion.

    Also in 4 projects that use this

  • +3 more from noahowsh

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 38 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run these in one turn, joined with .

    line 17
  2. Distinctive:

    When two routes fit, prefer the earlier phase.

    line 78
  3. Distinctive:

    When the request genuinely does not fit any skill, say so and handle it directly.

    line 80

“Common” is measured: kept by at least 6 in 10 of the 38 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Figure out where the user actually is in the flow, then route. One cheap pre-flight beats an exploratory warm-up.


Step 0 — Pre-flight, batched

Run these in one turn, joined with ; not && — you want every answer regardless of which ones fail:

git branch --show-current; git status --short; git log --oneline -5
openspec --version
openspec list --json 2>/dev/null
interlock changes 2>/dev/null
ls -t .claude/handoff/explore-*.md 2>/dev/null | head -3
ls .claude/graph/GRAPH_REPORT.md .claude/graph/DOCS_DIGEST.md 2>/dev/null

That is Rules 2 and 3 of ${CLAUDE_PLUGIN_ROOT}/shared/TOOL-ECONOMY.md: read state, do not re-derive it. Do not traverse the tree to reconstruct what these already tell you.


The flow

graph → docs-digest → bootstrap        (once per repo)
/interlock:spec    explore → artifacts → review     ⟵ STOPS. Human reviews.
/interlock:ship    waves → verify → commit  (workflow, zero-touch; --strict adds review)
/interlock:settle  summary → pull request

The gap between spec and ship is deliberate. Never bridge it automatically — if a spec is ready, say so and let the user start ship. The user can bridge it themselves with /interlock:spec --continue, but that is theirs to ask for; routing never offers it.

ship is a dynamic workflow. /interlock:ship is a skill trampoline that launches it via the Workflow tool (scriptPath → workflows/ship.js). Invoke the skill interlock:ship (or call Workflow with that scriptPath yourself). Do not treat a missing Workflow-namespaced command as "ship does not exist" — the skill is the entry point. If the trampoline halts because the Workflow tool is unavailable, that is the runtime gap (v2.1.154+, Dynamic workflows on in /config); do not implement the loop inline.


Routing table

SituationRoute to
No openspec/ directory, or no specs on an existing codebase/interlock:bootstrap
No .claude/graph/, and the session will explore or review heavily/interlock:graph (build)
Docs context too large, or the digest is stale/interlock:docs-digest
"How does X work?", "what breaks if I change Y?", tracing, comparing options/interlock:explore
"I want to build / fix X" — no change exists yet/interlock:spec
A change exists with reviewed artifacts and unchecked tasks/interlock:ship — only if the user asked to ship, and this conversation has not already run ship
Leftover unchecked boxes after a ship workflow just returnedReport them. Do not route to ship.
Implementation done, diff needs review/interlock:review-code
Artifacts written but not yet reviewed/interlock:review-artifacts
Suite is red, or a CI log was pasted/interlock:fix-tests
"Explain this code" / "what changed in that commit?"/interlock:explain-code
Need a QA checklist for a change/interlock:manual-test-plan
Work is done and needs committing/interlock:commit
PR needs creating or updating/interlock:settle
"I want to skip the checkpoint" / "don't stop and make me read it"/interlock:spec --continue — advanced. Opt-in, fail-closed, and it stops anyway on anything a machine cannot settle. It cannot catch a wrong idea; only the read can.

Prerequisite checks before routing:

  • openspec --version printed no version — say so before routing. On command not found (or the shell's equivalent) the CLI is missing: name interlock openspec provision (run nothing yourself; spec and bootstrap run it), or the user's own npm install -g @fission-ai/openspec@latest. A bare interlock that answers command not found means the session predates the plugin; until a new session, node "${CLAUDE_PLUGIN_ROOT}/cli/interlock" runs it, and those calls ask for approval. On any other error it is installed but does not run (usually a Node.js older than 20.19.0): quote the error, not the install line. Either way an empty openspec list here is the CLI, not an empty project, and spec and bootstrap both stop at their first command until it runs. ship still reads artifacts from disk.
  • Routing to ship — run interlock validate <change> first. Not ready means route to spec, not ship. If a ship workflow already returned in this conversation, leftover boxes are a report, not a retry.
  • Routing to spec with no explore brief and a question that spans subsystems — run explore first.
  • Routing to anything that reads the graph when .claude/graph/ is absent — offer to build it once.

Ambiguity

When two routes fit, prefer the earlier phase. Exploring when you should have specced costs one turn; shipping when you should have specced costs a bad change and a review cycle.

When the request genuinely does not fit any skill, say so and handle it directly. Not everything is a workflow, and forcing an ordinary question through a skill is worse than just answering it.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

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.