Delegate Local

Delegate Local

Offload non-agentic text tasks to locally-installed models via the local inference backend. The headline value is privacy (content stays on-device) and context protection (the main-agent window is not consumed by paragraph-fills); token cost savings are real but typically pennies per session and a side effect, not the reason to reach. Local models are strong summarisers and weak reasoners — scope accordingly.

Core insight (from local-brain): you do not need a framework. You need context | ollama run model.

Operating mode

Default to auto-delegate. When this skill is loaded into the conversation and the user's task matches the Fits list below, delegate immediately without asking permission. After every successful delegate.sh call, read the delegate-meta: line emitted to the tool's stderr — it carries model, tier, backend, tokens_local, and duration_ms as space-separated key=value pairs (plus recipe="NAME" when a --recipe flag was used). String-typed fields are double-quoted (model="qwen3.6:35b-a3b-q8_0"); integer fields are bare. On recipe calls the line may also carry checks_failed=N (a deterministic output check the model's text still violates — eyeball that aspect before using it) and checks_autofixed=N (a trailing padding clause the wrapper auto-stripped for you — quickly confirm nothing meaningful was lost). In your reply, surface the model and the local-token count so the user can both spot a bad answer and see what stayed on-device: e.g. "Delegated to qwen3.6:35b-a3b-q8_0 (prose tier) — ~578 tokens kept local in 1.4 s." Frame it as "kept local," not "saved from Claude" — tokens_local is the local model's tokenizer view of total chars in + out divided by 4 (the same value scripts/metrics-summary.sh rolls up under estimated_tokens_avoided), not Anthropic's billable count. Do not ask "should I delegate this?" — the skill being loaded means yes by default. Re-confirm only if the task is borderline or the input contains content the user explicitly flagged as sensitive.

If the user says any of: "delegate where it fits", "use ollama where appropriate", "auto-delegate", "route to local where it makes sense", or similar — treat that as durable consent for the rest of the conversation: from that point on, every matching task goes through ollama run without further prompting.

When to delegate

Fits:

• Summarise a long log, diff, file, or PR description.
• Draft a commit message, changelog entry, or release note for a single-file mechanical change.
• Classify or triage N items (relevant/noise, bug/feature).
• Closed-form classification with an explicit, finite option set (e.g. "high|medium|low|info" severity, "REAL|FP" filter against a stated allowlist). The 2026-05-03 retrospective measured 5/5 reps perfect on FP-filter when the allowlist rule was explicit and a one-shot example was included.
• Compose structured prose from a fixed list of items (PR comment from a findings list, release-note bullets from a changelog block). The 2026-05-03 retrospective measured 3/3 PASS on PR-comment composition once the prompt forbade placeholder substitution explicitly.
• First-pass "what does this file do" over many files.
• Extract structured fields (JSON) from free-form text.
• Reformat or rewrite prose.
• Minimal single-file code patches where you supply the failing test alongside the source and verify by re-running the test after applying the patch. Scope is narrow and the verification step is load-bearing — multi-file edits, cross-module reasoning, and tests the director cannot re-run are out of scope. See the v8 probe evidence and the director-side pattern in the Reasoning-tier and Discipline sections.

Do NOT delegate:

• Multi-step reasoning, planning, or tool-calling.
• Tasks needing repo-wide context that does not fit one prompt.
• Code correctness, security, architectural judgements.
• Anything whose output directly triggers a destructive or shared-state action without review.
• The user asked for your analysis specifically.

The natural shape is structure is yours, prose is delegated: headings, code blocks, file links, table layouts, and CLI examples are decisions to own; flowing paragraphs of explanatory text are what the model fills. Tasks that look textual but encode structural decisions (link-index rewrites, table moves, cross-reference collapses, "delete this section and replace with a pointer to the canonical home") are not delegation candidates even though their output is text — the work is deciding which home is canonical, not writing prose.

Density threshold — per-edit AND session-level: if you would otherwise type more than ~4 paragraphs of fresh prose in a single delegation site, the skill earns its keep. But also evaluate at session level: if the session will produce more than ~4 paragraphs of total delegatable prose across all edits combined, delegation is the default even if each individual edit is small. A docs-cleanup session touching 9 files with 1-2 paragraphs each is well above threshold in aggregate, even though no single edit crosses it alone. When in doubt, delegate — the setup overhead of delegate.sh is near-zero and a rejected output costs less than writing it yourself.

If ollama is not on PATH or ollama list is empty, do the work yourself and mention why.

Supervised code drafts — a divergent, executable second opinion

The discriminator is sharper than "weak agent, so don't." Local models are weak unsupervised agents but usable as a supervised draft generator under a verify loop. This is scoped to delegation as a sub-step of your own implementation work — the skill still does not own feature implementation, you do — and within that work you may delegate one bounded code draft. The reason it earns its keep is something a self-generated draft cannot give you: a differently-trained model proposes an approach, or makes a mistake, you would not have generated yourself, and running the draft answers "does it compile, pass the test, behave as I assumed" empirically rather than by static reasoning.

Fire a code draft only when BOTH hold:

• Value trigger (at least one): the approach is genuinely forked and you are unsure which way to go; OR executing the draft would teach more than reasoning about it (a compile result, a test result, real API behaviour).
• Bounded guard (always): a single file or function, small output, with a concrete verification — a test to run or an explicit acceptance check — named up front.

The draft is always disposable. Verify before keeping anything: apply it and run the named verification; a draft that applies but fails the verification is treated as a REFUSE, never kept on the strength of its prose. Use --recipe code-draft — it routes to the code tier and emits a focused full snippet, not a diff. Record the honest verdict afterwards via delegate-feedback.sh --source agent: hit if you kept it, miss if it was useless, or scaffold "" if you discarded the code but the divergence or the executable feedback genuinely improved your result. This is not "delegate all coding" — generic, low-divergence, easily-self-drafted code does not qualify, because for those the local round-trip only adds latency. The amendment is an experiment under an evidence gate; see ADR 0025.

Pattern

Three steps, in order, every time: gather → delegate → verify.

1. Gather the context you can fit in a short prompt (≤ 8k tokens; local models degrade above that).
2. Delegate with a constrained prompt that asks for an exact output shape.
3. Verify every specific claim the model returns against the actual files before acting on it. Treat the model's output as a hypothesis, not a finding.

Use scripts/delegate.sh "" — it resolves the tier to a model, calls Ollama's POST /api/generate with thinking suppressed (think:false by default; override with DELEGATE_THINK=true if reasoning chains genuinely help) and temperature:0, and appends one JSON line per invocation to ~/.claude/skills/delegate-local/metrics.jsonl for scripts/metrics-summary.sh to roll up later. The HTTP API returns clean text, so no ANSI stripping is needed downstream.

The ≤ 8k tokens is a theoretical upper bound; the practical ceiling on a given host is often much lower. The 2026-05-05 IP-146 share-readiness session observed qwen3.6:35b via delegate.sh hanging for 3+ minutes on a single bundled ~1.3k-char prompt and being killed by the harness with exit 144. Splitting the same content into atomic single-paragraph prompts (~350 chars each) returned in 10–20 s per call. If delegate.sh appears to hang for more than ~30 s with no output, the prompt-plus-stdin is probably too large for your host — kill the call and break it into smaller atomic sub-tasks rather than waiting. First call against a freshly-loaded model is also slower than subsequent calls against the same model, because the daemon warms up; this is fixed-cost per model, not per call.

Recipe-shaped prompts have a sharper threshold than the byte-count framing suggests — issue #110's 2026-05-13 follow-up measured the 35B-class prose-tier model stalling on ~3-4 KB recipe inputs on both Ollama and MLX while a 0.6B-class model handled the same shape in 1 second; see prompts/pr-description.md calibration history for the full evidence.

Pitfall — shell-variable expansion leaks secrets or drops tokens. Any prompt argument referencing a literal $VARNAME token (environment variables, CI variables, shell parameters) must be single-quoted, wrapped in a .md rather than just a description of "use the prose tier". Recipes ship the proven prompt skeleton, the canonical context-gathering commands, the verbatim-example anchors, and the explicit anti-hallucination guards drawn from prior session HITs. The reason they exist: small / local models default to whatever output shape is most common in their training (bullets when asked for "concise commit message"), and abstract style descriptors do not reliably override that prior — verbatim-example anchoring plus explicit guards do. Each guard in a recipe corresponds to a real past MISS, so the recipe accumulates calibration over time without rediscovering it every conversation.

Recipe-covered tasks are hard triggers, not judgement calls. When you are about to write a commit message, use --recipe commit-message. When you are about to write a PR description, use --recipe pr-description. When you are about to summarise an issue, use --recipe summarise-issue. When you are about to draft a maintainer reply to a contributor or reporter (a PR-review comment, an issue status comment, a bug-report one-liner), use --recipe maintainer-reply. When you are about to draft the body of a new GitHub issue from facts, use --recipe github-issue-body. When you are about to classify or triage a list of items into a fixed set of buckets, use --recipe bulk-classify. When you are about to write the intro narrative for a release announcement, use --recipe release-announcement. Do not skip the recipe because "this one is simple enough to write directly" — the recipes exist precisely because the setup cost is near-zero and the calibration guards prevent the small regressions (wrong conventional-commit type, padding tails, hallucinated file references) that hand-written prompts rediscover every time. The only valid reasons to skip a recipe are when the content requires multi-file reasoning context that exceeds the 8k token prompt limit, or when the recipe is flagged as flaky or refused on the resolved model (such as pr-description on 35B-class models).

Gather the listed context and invoke bash scripts/delegate.sh --recipe --var key=value ... "". The --recipe flag prepends the recipe's prompt template, substitutes each {{key}} placeholder from the matching --var, and refuses to send a partly-substituted template to the model so missed inputs surface as a clear error rather than a degraded answer. When you are about to write a commit message and have the staged diff in hand, git diff --cached | bash scripts/delegate.sh --recipe auto --var why="..." prose "..." lets the wrapper infer the commit-message recipe from the piped diff and backfill recent_commits/diff_stat from git, so the only thing you supply is the intent — one call instead of assembling every --var by hand. Always record the verdict after the call via bash scripts/delegate-feedback.sh --source agent hit|miss [reason] — --source agent tags it as the agent's own usage judgment (did you use the output as-is, or rewrite/discard it), which is the honest meaning of a verdict the agent records about its own delegation, and keeps it out of the human taste-judgment tier the headline hit-rate is computed from (ADR 0015); a human recording their own taste judgment omits --source. Without a verdict the delegation stays as an "untracked" metrics row and the recipe library cannot self-correct from production data. delegate.sh prints a one-line stderr reminder after every successful call to make this step impossible to forget (silenceable via DELEGATE_LOCAL_NO_VERDICT_NUDGE=1 for callers who genuinely don't want it). By default delegate-feedback.sh attaches the verdict to the most recent delegate row in the metrics JSONL and refuses if that row is older than 5 minutes — a safeguard for the cases where metrics were off (DELEGATE_LOCAL_NO_METRICS=1) or the delegation was killed before its row was written, since the implicit "most recent row" would otherwise be someone else's delegation. Pass --ts to pin the verdict to a specific delegate row when you need to bypass this. Recipes start small — prompts/commit-message.md and prompts/pr-description.md today — and grow append-style as new HIT patterns get distilled. If a task pattern recurs and no recipe covers it, the discipline is to file a prompt-pattern issue so the recipe library tracks coverage gaps rather than letting them evaporate. See prompts/README.md for the recipe shape and contribution flow.

Parallel-capture callers that fan N delegations into N background shells and want clean per-call output files (bash delegate.sh ... > out_$i.txt 2>&1 &) historically had to choose between contaminated stdout (the nudge line mixed into out_$i.txt via 2>&1) and lost coverage (silencing the nudge via DELEGATE_LOCAL_NO_VERDICT_NUDGE=1 and never recording the verdict). DELEGATE_LOCAL_VERDICT_NUDGE_FD=N resolves the trade-off by redirecting the nudge to caller-chosen file descriptor N instead of fd 2; the recipe is DELEGATE_LOCAL_VERDICT_NUDGE_FD=3 bash delegate.sh prose "X" > out.txt 2>&1 3>>nudge.log — stdout+stderr land cleanly in out.txt, the nudge accumulates on nudge.log via fd 3, and coverage tracking stays intact because the caller can post-process nudge.log to drive a verdict-recording loop. The gotcha: the caller must redirect fd N to somewhere (file, pipe, or another fd); if fd N is closed when the nudge fires, the write fails silently and no nudge lands anywhere.

Discipline for closed-format work

The 2026-05-03 retrospective measured the same 4-sub-task suite with and without prompt discipline. Without discipline (single shot, thinking on, no example, four sub-tasks bundled in one prompt) the local model scored 1.5 of 4. With discipline (thinking off, one-shot example, atomic single-sub-task call, explicit qualifier rules) qwen3-coder-next:latest scored 3.6 of 4 — within 9% of Haiku's 3.95. The same four practices recur in 2026 practitioner reports:

• One sub-task per call — but batch independent prose items. Bundling multiple sub-tasks in one prompt collapses the "single atomic output" property that makes local models reliable. If you have four things to classify, four delegate.sh calls are more reliable than one prompt that asks for four answers. The exception is independent prose items of the same shape (modul

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: IsmaelMartinez
• Source: IsmaelMartinez/delegate-local
• License: MIT

Install and usage instructions live in the source repository linked above.