haiggoh
UserRun Claude Code on free inference — two equal lanes: local Apple-Silicon MLX models, and free-tier cloud APIs (Gemini, NVIDIA, Groq +12). Dispatch sub-tasks off your paid session, or run a whole session free. Additive overlay; private config stays local.
Categories
Indexed Skills (23)
local-agents
Use when the user wants to offload Claude Code work to a LOCAL MLX model to save cost — PRIMARILY dispatching a delegatable sub-task from their normal cloud session (Opus/Sonnet), and secondarily running a full local session. Triggers: "dispatch this to a local model", "offload this locally to save cost", "run this on qwen locally", "start a local session / local mode", "run the local model tournament", or working offline. Explains how to drive the local-agents overlay: dispatch focused prompts (main use), launch a full local session (niche), and run the diagnostic harnesses. Do NOT use for ordinary cloud work that isn't being offloaded.
continue-on-fallback
Use WHEN work must keep moving but the current model is unavailable — the cloud budget is exhausted, the local model is down, or a session is dying and needs to hand off. Triggered by a budget wall, a dead local endpoint, or the need to preserve in-flight work for another agent. Do NOT use for a normal in-budget turn, for choosing between equally-available models, or for verifying already-produced output (that is verify-delegated-work).
free-agents
Use when the user wants to run Claude Code work on FREE inference instead of the paid gateway — either a LOCAL MLX model or a free cloud API. PRIMARILY dispatching a delegatable sub-task from their normal paid session (Opus/Sonnet); also running a full free session. Triggers: "dispatch this to a local model", "offload this to save cost", "run this on qwen locally", "start a local session / local mode", "run a remote session", "use a free API for this", "run the model tournament", or working offline. Explains how to drive the free-agents overlay: dispatch focused prompts (main use), launch a full session on either lane (remote is faster; local is for offline and long unattended runs), and run the diagnostic harnesses. ALSO use the moment you are about to delegate anything after being asked to use free/local agents, or when you catch yourself reaching for the Agent/Task tool to "delegate cheaply" — that tool CANNOT route to a free model and silently runs a full-price subagent; this skill has the only routes tha
no-hidden-changes
Use before adopting any change that disables, hides, parks, removes, or relocates something, or uses a custom side-channel (a `_disabled`/`_backup` key or shadow file) instead of a tool's built-in toggle, menu, or setting. Also applies when a change keeps hiding state that has since become valid (stale state lies too), or ships an in-place edit to a versioned/published artifact (plugin, package, shared config) without bumping its version, or edits a DERIVED copy instead of its source (an installed plugin cache, a symlinked live file, a build output, a generated config) where the next update silently reverts it, or lands unrelated work as one lump on the default branch, switches the branch of a checkout other tooling resolves through, stages with `git add -A`, or rewrites published history (a force-push or a moved tag), or installs durable automation (a hook, cron job, launch agent, or background script) without first surveying for an existing mechanism that already does the job or recording what it installed.
cc-transcript
Distill a native Claude Code session transcript into a compact, line-addressable capsule for handoff to another model, for code review, or for archival. Use when a session is too long to re-read or to resume, when context must be carried into a fresh session or an external LLM, or when the user asks to compact, capsule, distill, or hand off a transcript. Invokes the installed cc-transcript CLI.
autopilot
Use when the user asks to run a whole queue of open work unattended — "autopilot", "run everything you can", "clear what you can while I am away", "full auto on my open items". Orchestrates the complete run as an explicit checklist: triage the queue into tiers, execute the autonomous pile without stopping, then close out with a gated list. Start here rather than at an individual phase when the request covers the whole run.
close-out-the-run
Use WHEN an unattended run is ending: the autonomous pile is exhausted, a resource limit is close, or the user has called a stop. Reconcile the durable records the run touched, stop cleanly at the gated boundary instead of churning, and write a wrap that says why each remaining item was left and how to resume it. Do NOT use for scoring the queue (triage-for-autonomy) or for mid-run execution (execute-unattended).
execute-unattended
Use DURING an unattended run, once triage has produced a do-now pile: keep moving without stopping between items, switch away the instant something needs a human, protect against irreversible edits before touching a file, and carry each shippable change through to confirmed-live. Do NOT use for choosing what to work on (triage-for-autonomy) or for the closing reconciliation (close-out-the-run).
run-to-completion
Use when the work already in view in THIS conversation is an elaborate multi-step plan or spans several open projects AND most of the needed information is gathered, or when the user signals "autonomous" / "continuous" / "full auto" / "run to completion" / "keep going without stopping". Proactively offer to execute that plan continuously, without pausing between steps, resolving routine decisions yourself instead of asking. Do not trigger for a single straightforward task or when requirements are still unclear — offer this mode, don't force it. For a whole standing QUEUE of open items to be cleared unattended, start at autopilot instead.
triage-for-autonomy
Use BEFORE starting an unattended run, to score an existing queue of open items — a to-do list, an issue tracker, plan steps, or a persistent open-items store — into what is safe to do now, what is autonomous but heavy, and what is gated on a human. Produces a tier verdict plus a gate reason per item, and ranks the gated pile by how cheaply each item could be released so an attended pass asks the best questions first. Do NOT use for executing the items (execute-unattended), for the closing wrap (close-out-the-run), or for walking gated items with the user present (ungate-queue).
ungate-queue
Use when the user wants to work THROUGH the blocked items on a queue with you present — "unblock these", "walk me through what is gated", "let us clear the questions" — or immediately after an unattended run reports items it could not do. Turns each gate reason into the single question that would release the item, records the answer on the item, and STOPS there: removing the gate is the whole job, and the work it releases belongs to a later unattended run. Do NOT use for unattended execution (autopilot, execute-unattended), and do NOT slide into doing the work you just unblocked.
offload-to-local
Use when PLANNING or decomposing ANY multi-step task, and whenever your plan involves reading, searching, summarizing, transforming, drafting, extracting, or editing across files — regardless of whether cost is mentioned. Also when you're about to do delegatable/bulk/mechanical work on a paid cloud model, or you notice you're about to burn cloud tokens on work a smaller model could do. It routes delegatable work to a free local model — by DEFAULT to the broad `operator` role, escalating to a specialist role only when needed — instead of spending cloud tokens. Explicit triggers: starting a multi-step plan (especially under a budget constraint / Credit Efficient Mode), "save cost/tokens", "do this locally", "offload this", "use the local model for this". Do NOT use it to offload frontier-reasoning, architecture, security-critical, or final-review work.
compose-the-payload
Use WHEN assembling the MATERIAL for a stateless dispatch — file contents, large corpora, or structured data — so the source never enters the orchestrator context. Do NOT use for writing the instructions about that material, verifying output, guarding runtime, or isolating work.
guard-shared-runtime
Use BEFORE modifying the local execution environment (installing packages, upgrading dependencies, changing config) or when the local inference server behaves unexpectedly. Triggered by dependency changes, reinstall checks, or server wedges. Do NOT use for verifying output, isolating work, or composing payloads.
isolate-parallel-work
Use BEFORE dispatching work that touches files or requires exclusive access to a server/port. Triggered by the need to run multiple agents concurrently or to prevent clobbering. Do NOT use for verifying output, guarding runtime, or composing payloads.
verify-delegated-work
Use AFTER a delegate (local model, cloud subagent, or external tool) returns output that modifies state, generates code, or asserts facts. Triggered by the need to validate correctness before trusting the result. Do NOT use for planning, briefing, or runtime checks. Covers ground-truth comparison, mutation testing of generated tests, and the retry ceiling.
brief-the-delegate
Use WHEN writing the instruction/prompt for a stateless dispatch. Triggered by the need to disambiguate task boundaries, ordering, or output format. Do NOT use for verifying output, guarding runtime, or composing payloads.
compose-the-payload
Use WHEN assembling the MATERIAL for a stateless dispatch — file contents, large corpora, or structured data — so the source never enters the orchestrator context. Do NOT use for writing the instructions about that material, verifying output, guarding runtime, or isolating work.
guard-shared-runtime
Use BEFORE modifying the local execution environment (installing packages, upgrading dependencies, changing config) or when the local inference server behaves unexpectedly. Triggered by dependency changes, reinstall checks, or server wedges. Do NOT use for verifying output, isolating work, or composing payloads.
isolate-parallel-work
Use BEFORE dispatching work that touches files or requires exclusive access to a server/port. Triggered by the need to run multiple agents concurrently or to prevent clobbering. Do NOT use for verifying output, guarding runtime, or composing payloads.
offload-to-local
Use when PLANNING or decomposing ANY multi-step task, and whenever your plan involves reading, searching, summarizing, transforming, drafting, extracting, or editing across files — regardless of whether cost is mentioned. Also when you're about to do delegatable/bulk/mechanical work on a paid cloud model, or you notice you're about to burn cloud tokens on work a smaller model could do. It routes delegatable work to a free local model — by DEFAULT to the broad `operator` role, escalating to a specialist role only when needed — instead of spending cloud tokens. Explicit triggers: starting a multi-step plan (especially under a budget constraint / Credit Efficient Mode), "save cost/tokens", "do this locally", "offload this", "use the local model for this". ALSO use before ANY delegation once cost or free/local agents have been mentioned, and whenever you are about to call the Agent/Task tool hoping it will be cheap — it cannot reach a free model and defaults to a full-price subagent, so read this for the routes t
verify-delegated-work
Use AFTER a delegate (local model, cloud subagent, or external tool) returns output that modifies state, generates code, or asserts facts. Triggered by the need to validate correctness before trusting the result. Do NOT use for planning, briefing, or runtime checks. Covers ground-truth comparison, mutation testing of generated tests, and the retry ceiling.
brief-the-delegate
Use WHEN writing the instruction/prompt for a stateless dispatch. Triggered by the need to disambiguate task boundaries, ordering, or output format. Do NOT use for verifying output, guarding runtime, or composing payloads.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.