zedarvates/frugal-skills

Instructions for evaluating upstream agent-run caching with exact hashes, code fingerprints and fuzzy matches. Use for repeated runs with comparable inputs; verify cache validity before skipping execution. Not for project scan caching (cache) or model-answer caching (response-cache).

Instructions for the upstream inter-agent binary transport: quantized vectors, shared dictionaries, deltas and repeated-section hashes. Use when repeated machine-facing messages need a compact wire format. Not for human-readable payloads, content compression (universal-compressor), memory compression (agent-intel) or report JSON (ultra-compact).

Guidance for upstream learning across loops: distillation, skill retrieval, fix-cost and route estimates, memory compression and aggregate statistics. Use for questions spanning runs or sessions. Not for recurring-failure correction (botte-learn), local hardware placement (local-router) or tool selection (tool-router).

Instructions for upstream Policy A9 analysis of concurrent missions with at least 70% vocabulary overlap and no declared shared locks. Use to review possible duplicated agent work; confirm findings against the actual missions. The upstream finding contract has five policy fields.

Guidance for the upstream agent-state contract: backend-neutral lifecycle state, declared capabilities and repository-relative mutation scopes. Use before planning routing, continuation, messaging or concurrent writes; verify actual host support instead of inferring capabilities.

Instructions for the upstream ambient-status-v1 Windows overlay and its scoped metrics. Use to plan passive token and routing visibility outside the terminal. Requires a separately installed compatible runtime and valid local ledgers; missing measurements stay unavailable.

Guidance for upstream image-matching GUI tests with OculiX/SikuliX: prepare a JSON scenario, button images, runner and evidence checks. Use for local desktop, game or web UI testing. Runtime, Java, screenshots and optional local vision hardware are separate prerequisites; an installation is not proof of a passed test.

Guidance for the upstream audit DAG and its derived machine-facing and HTML views. Use to plan one canonical findings representation with addressable nodes; verify that derived views preserve it. Not for generating detector findings or choosing a compact JSON format alone (ultra-compact).

Instructions for the upstream cloud-to-small-classifier distillation module. Use to inspect its documented CLI and prerequisites before planning a distillation workflow. The executable module and trained models are not included in this catalog.

Guidance for upstream memory storage, recall, compression and consolidation, conceptually inspired by Stanford AutoMem. Use to plan a learning-oriented memory workflow; inspect the installed implementation and storage policy before persisting data.

Instructions for upstream effort-based local/cloud routing and model fusion (cascade, draft-refine, vote). Use to plan routing, configured providers or model collaboration. Check compatible backends, credentials, budgets and measured capability before execution; this catalog does not route calls or guarantee a fallback.

Instructions for the upstream routing benchmark and its fixed decision corpus. Use to inspect estimated routing costs against a declared baseline, or to plan reproducible evidence. Decision estimates are not measured provider bills, production savings or validation of this instruction catalog.

Guidance for deploying a separately installed Botte Secrete runtime into a target project: MCP configuration, directive audit, local configuration and setup report. Use when planning project onboarding. Inspect proposed configuration changes and verify host integration; this catalog does not install services or guarantee savings.

Guidance for upstream recorded-session analysis and proposed correction rules (scan, apply, status). Use to investigate recurring failure patterns; validate each proposed rule before applying it. Not for loop distillation (agent-intel), structural code detection or governed long-term memory (memory-hub).

Instructions for upstream small-classifier inference, active learning, calibration and dataset review. Use when a routing or effort decision needs a separately trained classifier. Requires compatible model files and Rust or numpy runtime components. Not for tier selection (nn-router), generative calls (llm-backends) or lexical tool selection.

Instructions for the upstream HTTP compression proxy between an agent and its configured LLM endpoint. Use to plan proxy integration and inspect compression behavior. Runtime and target endpoints are separate prerequisites; remote or cloud targets receive forwarded data, and savings require measurement.

Guidance for upstream wrap, unwrap, list and status commands that route an installed agent through a compression proxy. Use to plan integration without editing the agent binary; check wrapper and destination configuration. Not for compression policy, payload compression, MCP installation or measured savings.

Instructions for upstream project-scan caching with get_or_scan, an audit-report slot and a documented 24-hour TTL. Use when sequential agents may reuse a compatible scan; validate freshness and analysis inputs. Not for model-answer caching, agent-run caching or per-file fingerprint gates.

Instructions for upstream Policy A5 analysis of intra-module passthrough chains deeper than five links. Use before considering call-stack flattening; the upstream design reuses the A3 wrapper predicate and five-field finding contract. Review findings before refactoring.

Guidance for the upstream capability registry and lexical curator, organized as SENSE, DECIDE, ACT, REMEMBER, GOVERN and DEPLOY. Use to inspect the toolkit map or plan capability selection. A catalog entry describes a workflow; it does not prove that its runtime is installed or available.

Instructions for an upstream adversarial review workflow with counter-auditor, counter-developer, counter-optimizer and verdict orchestration. Use to challenge an existing result on critical work. Not for producing the first audit or fixes (mousquetaires), or mechanically reviewing one diff (simplify-code).

Guidance for the upstream project-checkup sequence: policy, directives, metrics, infrastructure, duplication, security, documentation, knowledge integrity and drift. Use after updates or during onboarding. Run only with the compatible runtime and inspect collected evidence; one checkup does not establish completeness or optimality.

Guidance for asking up to five targeted questions with explicit defaults when scope is ambiguous or a wrong assumption would be expensive. Explicit auto may accept optional defaults; silence is not approval for a blocking decision. Not for precondition checks (preflight) or choosing known implementation options (decision-ladder).

Instructions for upstream cluster discovery, configured-backend selection and task delegation. Use to plan work across a trusted homelab or inspect its declared capacity. Verify endpoints, receiver policy and capability before sending tasks; this catalog does not deploy a receiver or guarantee backend availability.

Instructions for upstream Policy A1 analysis: cyclomatic complexity above 10 or function length above 50 AST statements, with five policy finding fields. Use to plan Python complexity review and interpret evidence. Not for duplication (code-duplication), global state/import cycles (code-state) or passthrough functions (code-wrappers).

Instructions for upstream Policy A6 analysis of duplicated Python bodies using normalized AST hashes and an optional semantic mode; the documented minimum is six statements. Use to plan duplication review and examine five-field findings. Not for complexity (code-complexity) or skill-description overlap (skill-finder); verify equivalence before merging code.

Instructions for the upstream SHA-256 code-fingerprint cache and re-analysis gate. Use to assess whether an earlier analysis can be reused after checking code, analysis configuration and dependency changes. This is not a findings detector; use code-complexity, code-duplication, code-state or code-wrappers for findings.

Guidance for evaluating dependencies, standard-library options, flat architecture, data layout, datastore choices and verification before announcing results. Use before adding a dependency or layer. The full upstream RULES.md and any project-specific file limit are separate prerequisites; do not invent a missing ceiling.

Instructions for upstream Policy A2 review of mutable module-level state and cycles in the local AST import graph, excluding TYPE_CHECKING blocks. Use before isolating tests or flattening imports and inspect the five-field evidence. Not for duplication (code-duplication) or passthrough functions (code-wrappers).

Instructions for upstream Policy A3 review of unchanged argument-forwarding functions with no distinct transformation, guard, decorator or docstring. Use to plan wrapper review and inspect the five-field evidence; dynamic-name references and non-1:1 signatures are excluded. Not for complexity or module-level state/import cycles.

Instructions for a separately installed ComfyUI HTTP workflow: prompt-node configuration, queueing, model inspection and workflow templates. Use to plan image generation with a configured local instance. The host, models, templates and upstream INTEGRATION.md are not supplied here. Not for image reading or local endpoint routing.

Instructions for upstream Policy A11 review of completion claims lacking a referenced test, command output, artifact hash or passed validation. Use before trusting a done/fixed report. Examine the actual evidence; the catalog does not run the detector or prove the claimed result.

Guidance for upstream goal-to-plan orchestration through capability selection, layer ordering and command annotations. Use to plan Botte workflows or inspect optional execution modes. Runtime, capabilities and host authority must be verified; execution and confirmation gates belong to the compatible upstream implementation.

Instructions for upstream context allocation under a token budget using a 0/1 knapsack model over relevance and token cost. Use to plan which skills or documents to load; verify the installed solver, cost estimates and scaling before interpreting optimality. Not for prefix measurement (context-profiler), typed slicing (context-slicer) or ranking without a budget (skill-finder).

Instructions for the legacy upstream log-pattern compressor: repetitions, common patterns and sampled distinct lines. Use only for existing callers while consolidation is pending; universal-compressor with log content is the suggested path for new work. No measured reduction is established by this catalog.

Guidance for upstream prefix measurement or estimation across agent directives, core rules, MCP schemas, skill catalogs and host memory. Use to plan context-budget diagnostics and compare available windows. Label estimates and unavailable measurements; not for context selection (context-budget), pruning or code-change detection.

Instructions for upstream typed context slicing by headings and markers, with token estimates, priorities and task-type selection. Use to plan how several agents can consume relevant portions of shared context. Not for explicit-budget selection (context-budget) or permanently pruning unused sections (prefix-pruner).

Guidance for upstream named context windows and loop deltas (step, merge, stats). Use to plan context reuse across iterations; verify the separately installed store and its invalidation rules. Not for per-agent prompt-prefix differences (prefix-tree) or file-analysis caching (code-fingerprint).

Instructions for upstream routing-outcome analysis and bounded threshold adaptation. Use to inspect local/cloud rates, escalation, verified success and measured usage before proposing updates or resets. Threshold policies are described here; improvement or savings require evidence from actual runs.

Instructions for estimating task resources and provider costs with a separately installed runtime. Use estimates for planning, then compare them with measured usage, hardware costs and current provider prices; estimates are not billed-cost guarantees.

Instructions for the upstream workflow: Optimisations DAG/RAG — waves, pruning, memoization, routing.

Instructions for the upstream workflow: Generate one self-contained, timestamped HTML dashboard of the system's cost picture — routing savings (control loop), metric trends, current metrics, and the cost of outstanding fixes. Also renders as a live ANSI terminal view (--tui, --watch) and serves a live HTTP API (api.py). Use when the user wants a single visual view of cost/savings/health over time, or a live terminal view they don't have to open a browser for.

Instructions for the upstream workflow: Ponytail-inspired YAGNI enforcement — explicit need, existing code, stdlib, native platform, installed dependency, one-liner, then evidence-gated new code.

Instructions for displaying an upstream routing dashboard from a scripted scenario or project event log. The runtime is installed separately, and scripted fixture output is not evidence of live routing or savings.

Instructions for a compact notation for code changes and findings with severity and operation markers. Verify the installed parser and round-trip behavior before using it as a report format. Not for JSON report compaction or general content compression.

Instructions for the upstream workflow: Audit a project's AI-agent guidance files — CLAUDE.md, AGENTS.md, .cursorrules, copilot-instructions.md, GEMINI.md, intent docs and specs, in markdown, text or HTML. Use when checking whether a repo has agent instructions, whether they are healthy/consistent, or before an agent starts work on an unfamiliar codebase. Also use when the user mentions CLAUDE.md, AGENTS.md, agent rules, 'does this project have instructions', or stale/oversized directive files.

Instructions for drafting documentation or session notes with separately configured model backends. Confirm the selected local and cloud endpoints, data handling and costs before invocation. Use for documentation and session summaries; not for prompt-prefix analysis.

Instructions for the upstream workflow: Scoped documentation map for multi-component projects (server + client + tools + …). Detects components, classifies every doc as global vs component-scoped, and produces a per-component index (DOCS.md) listing local docs + links to the relevant global docs — so an LLM coder bounded to one component loads only its scope, not every other component's documentation. Frames token cost (full project docs vs scoped load) and treats .md as LLM-facing, .html as human reference. Use when a project has several components and you want to cut the docs an agent must read, or asks how to organise docs for a monorepo.

Instructions for the upstream workflow: Orchestration patterns for efficient agents — classify and act, fan out and synthesize, adversarial verification, generate and filter, tournament — each addressing one of three failure modes: agent laziness (declares more than it does), self-preference (judging its own work) and goal drift (losing the objective in a long session). Use when designing or debugging a multi-agent workflow rather than a single call. Not for the retroactive-loop controller — use loop-optimizer; not for the parallel review of one diff — use simplify-code; not for delegating a task — use the agent delegation surface.

Instructions for the upstream workflow: Measure tokens, cloud calls, money, latency and local energy per verified task without storing task content.

Instructions for the upstream workflow: Append-only JSONL decision log (.botte/events.jsonl) that every filter in the belt writes to — routing, cache hits, escalations, micro-NN outputs. The single source of truth demo mode, the live dashboard, and session replay all read from. Use when you want to see or emit a live feed of routing/cache/escalation decisions, or when building a tool that needs to watch the belt work in real time.

Instructions for the upstream workflow: Static analysis for JS/TS codebases through the external Fallow CLI — health score with hotspots, dead code, semantic duplication, circular dependencies, PR risk from a diff, and JSON export, plus the Python companion and the combined audit script. Use when auditing a JS/TS project. Fallow is a third-party Rust binary: treat its report as an input to an audit, not as a proof on its own. Not for Python structural analysis — use the code_* detectors; not for the coding rules themselves — use code-rules.

Instructions for the upstream workflow: A bundle of nine local static analyzers — dead code, duplication, complexity, secrets, taint and data-flow security, boundaries, feature flags, hot paths and blast radius — with a health score and grade and compact JSON, SARIF or markdown output. Use for the broad, one-pass view of a codebase. Not for the five-field policy findings of A1, A2, A3 and A6 — use code-complexity, code-duplication, code-state and code-wrappers; not for the JS/TS external analyser — use fallow.

Instructions for upstream repository exploration using targeted read, glob and search operations with a compact file-and-line report. Confirm the runtime before invoking its commands and measure latency and host model usage. Not for choosing skills or profiling the always-on prefix.

Instructions for the upstream workflow: List a project's correctable issues — confirmed dead code, duplication, stale directive references — each with a tokens·model·money·time cost estimate and a total. Plan-only by design (never edits code automatically). Use when the user asks what's worth fixing and what each fix costs.

Instructions for the upstream workflow: Aggregate status across the fleet, sortable by project tokens saved, lines of code or number of fixes — a read-only view over the canonical fleet registry that the dashboard writes. Use when you need a portfolio-level roll-up across projects. This module deliberately reads the dashboard registry instead of keeping its own, so the two can no longer diverge. Not for editing the registry — use dashboard (fleet add); not for measuring one project's context cost — use context-profiler.

Instructions for the upstream workflow: Edge vision inference on the Hailo-8 accelerator — object detection, image classification and OCR through compiled .hef models, with the available model table, the Python API (detect, classify, ocr) and the MCP tools when the accelerator host is reachable. Use when an image or a video frame must be detected, classified or read locally at edge power. Not for extracting text from video or audio — use media-loader, which composes this; not for generating an image — use comfyui; not for the local endpoint routing decision — use local-router.

Instructions for the upstream workflow: Vérification différentielle — ne vérifie que les sections modifiées.

Instructions for the upstream workflow: Build a bounded, read-only manifest of explicitly selected local repositories and dispersed deployments before comparing or migrating fixes.

Instructions for the upstream workflow: Expose auto_route/local_chat/fusion/find_skills/infra_tips to Hermes-Agent (or any framework that expects OpenAI-function-calling tool specs instead of MCP) — plus a one-call MCP config generator for the zero-code path if the framework already speaks MCP. Use when connecting the toolkit's routing belt to another agent framework.

Instructions for the upstream workflow: A compounding knowledge layer for sessions — a goal layer, a retrieved knowledge layer and a history layer filter every response, and a harvest step writes the session's learnings back into the local vector store, so a new session starts from retrieved memory instead of a re-injected history. Use when repeated sessions should accumulate knowledge rather than restart. Not for governed memory with sensitivity, visibility and a promote or forget lifecycle — use memory-hub; not for caching model responses — use response-cache; not for measuring the injected context — use context-profiler.

Instructions for the upstream workflow: Audit the local cluster's hardware/software/MCP setup and recommend changes that cut token cost — GPU upgrades, Hailo NPU for vision, moving the inference node to Linux, running Qdrant locally, wiring MCP — with an ASCII cluster diagram. Also provides an auto one-pass audit (directives + infra + code duplication + skills) on the project. Use when the user asks how to reduce token/usage cost via hardware/infra, wants cluster setup tips, an ASCII diagram of their setup, or a quick all-in-one audit.

Instructions for fetching and extracting source text, optionally structuring it with a configured model, and storing it through a separately installed Qdrant service. Verify endpoints and embedding mode; hash features are not semantic embeddings. Use for source ingestion and recall.

Instructions for the upstream workflow: Discover, audit and use local LLM servers (LM Studio, Ollama, LocalAI, vLLM, llama.cpp) on this machine or the network to offload work from the cloud and save tokens. Use when the user mentions local models, LM Studio, Ollama, 'run it locally', token savings via local hardware, or wants to know what models their machine can run.

Instructions for the upstream workflow: MCP server that lets Claude Code (or any MCP client) discover and call local LLM servers (LM Studio, Ollama, …) as tools, to offload cheap tasks off the cloud. Use when the user wants to wire local models into their agent, register an MCP server, or have the agent automatically route simple tasks to local hardware.

Instructions for the upstream workflow: Assemble the context a delegated sub-agent needs — the shared core agent file plus the agent's own delta — with single and batch loading and a helper that suggests which agents fit a task. Use when spawning named agents that must share one contract. Not for choosing among tools — use tool-router or skill-finder; not for loading skills into the context under a budget — use context-budget.

Instructions for designing an upstream local-model harness with task gates, output constraints, grounding, verification and escalation. These checks can detect some invalid outputs but do not guarantee factual accuracy. Evaluate the installed model and verifier on representative tasks.

Instructions for matching tasks to separately configured local text, vision, speech or image capabilities. Verify hardware, models and endpoint availability before routing. Not for choosing a model tier, selecting a tool or performing media extraction.

Instructions for the upstream workflow: Orchestrate a retroactive loop with token economy — a controller that picks the next loop action from extracted features, tracks progress state and stop reasons, and can replay a baseline loop to compare against the optimized one. Use when an iterate-until-done loop must be bounded and its cost measured rather than left to a fixed iteration count. Not for the persistent windows a loop reads — use context-windows; not for distilling what the loop learned — use agent-intel; not for running the loop's sub-agents — use the agent delegation surface.

Instructions for the upstream workflow: MCP Gateway — expose all the toolkit skills comme outils MCP. Découverte automatique, schémas d'entrée, transport stdio. Compatible Claude Code, Codex, Cursor, et tout client MCP.

Instructions for assessing the upstream media-loader prototype. Its current video, audio, image and PDF paths include simulated or placeholder extraction results, not a working media pipeline. Use to plan and verify real adapters; never present placeholder text or detections as extracted evidence.

Instructions for the upstream workflow: The governed agent memory store — searchable entries with context bundles and an explicit propose, promote and forget lifecycle, typed assets, sensitivity levels and visibility, exposed as MCP tools whose access checks can refuse a read. Use when durable agent memory must be inspectable, permissioned and revocable rather than implicit. Not for caching model responses — use response-cache; not for compressing an in-flight message — use agent-compression or universal-compressor; not for scanning sessions for failure patterns — use botte-learn.

Instructions for the upstream workflow: Run several skills as one governed pipeline in which every stage executes inside its own sandbox, and nothing is written until an approval gate passes — plan, execute isolated stages, cross-review, then apply with budgets and rollback. Use when the pipeline itself is the object of interest: mechanical isolation between stages, an explicit gate before any write, and a rollback path. Not for the named blue-team pipeline of audit, fix, optimize and consolidate — use mousquetaires; not for a single detector run — use the code detectors directly; not for bounding a retroactive loop and measuring its cost — use loop-optimizer; not for the adversarial challenge alone — use cardinal.

Instructions for collecting component-level project metrics and separating estimated context costs from measured provider usage. Use to report LOC, duplicate groups, directive health and routing observations with their scope and evidence; do not infer savings from missing counters.

Instructions for the upstream workflow: Independent strategic outsider above the blue and red teams. Use for architecture resets, high-cost research decisions, inherited assumptions, and stalled adversarial reviews; do not use for routine review or autonomous mutation.

Instructions for the upstream workflow: The blue team pipeline — audit, fix, optimize, consolidate — with an auditor agent, a developer agent, an optimizer agent and an orchestrator, exposed as a CLI over a project. Use when the user wants a code audit, automated fixes or token optimization across a project. Not for challenging an existing result — use cardinal; not for the five-field policy findings alone — use the code_* detectors.

Instructions for upstream rule-based intent classification, regex entity extraction and keyword frequency. The classifier can use hash-derived numeric features without a model; this does not measure the host agent consumption. Not for generative reasoning or learned semantic embeddings.

Instructions for reviewing the upstream micro-model audit's heuristic labels. Training-script keywords, metadata fields and test-text matches are inspection clues, not verified provenance or measured accuracy. Inspect the underlying data and real assertions before treating a grounded label as evidence.

Instructions for the upstream workflow: Estimate a task's complexity and route it to the right model tier, with batch routing and routing statistics (route, batch_route, routing_stats, estimate_complexity). Use when the question is which tier a task deserves. Not for choosing the local host that will serve it — use local-router; not for choosing among tools — use tool-router or skill-finder; not for running a trained classifier on numeric features — use botte-nn.

Instructions for the upstream workflow: Integration, monitoring and meta-optimisation across the module set — health check, module heal, agent sync, budget optimisation, module registration and an integration report (health, optimize, sync, heal, budget, register, integrate). Use when the question is whether the assembled pipeline is coherent rather than whether one module works. Not for the per-module read-only checkup — use checkup; not for the token cost of one project — use context-profiler or cost-estimator.

Instructions for the upstream workflow: Install cross-agent MCP plugins into supported coding agents through one installer with a declared list of supported tools, so several agents get the same server without per-agent manual configuration. Use when wiring an MCP server into more than one agent. Not for discovering what should be installed — use mcp-gateway or skill-finder; not for routing an agent's traffic through the compression proxy — use botte-wrap; not for the governed memory store exposed as MCP — use memory-hub.

Instructions for upstream context pruning using recorded usefulness: auto, aggressive and conservative strategies. Validate the records and preserve required instructions; do not assume fixed token savings. Not for context transport deltas or prefix measurement.

Instructions for the upstream workflow: Registry of each agent's stable prompt prefix in one compressed trie, so feedback loops and multi-agent exchanges send only the diff instead of the full prompt (register, diff, common, stats). Deterministic and local, with a store under ~/.botte. Use when several agents share a large common prefix and the repeated transmission is the cost. Not for deleting sections that nobody uses — use prefix-pruner; not for per-loop windows over a shared context — use context-windows; not for detecting repeated prompts in the logs — use prompt-repetition.

Instructions for the upstream workflow: Make the token-saving optimizations automatic instead of opt-in — a committed project policy plus a UserPromptSubmit hook that injects the prefer-local rules and suggested skills on every prompt, so a fresh prompt (after a component update, or from another dev/agent) never bypasses local routing. Use when the user wants the prefer-local behaviour enforced automatically, consistency across multiple devs/agents, or asks why their prompts aren't using local models by default.

Instructions for structuring a prompt as role, context, task, instructions, constraints, output format and success criteria. A local-model execution requires a configured backend; an agent-authored template is not an upstream execution. Not for repeated-prefix detection or skill selection.

Instructions for the upstream repeated-prompt detector: review long recurring prefixes in event logs using its declared policy thresholds. Confirm policy files and evidence fields before running it. Not for prompt rewriting, prefix measurement or delta transport.

Instructions for the upstream workflow: Observe content-free botte-llm call shapes, review repeated read-only workflows, and run only locally approved declarative recipes.

Instructions for reviewing identical failed retries in upstream event logs, accounting for context and fingerprint changes and excluding declared transient errors. Verify the installed detector and evidence before treating a retry as redundant.

Instructions for the upstream workflow: Persist any audit as a timestamped Markdown and/or HTML file (name + date + time) under .botte/reports/, browsable at any time, and list saved reports. Use when the user wants audits saved to consultable files, a history of audits, or to export a checkup/metrics/infra report as .md or .html.

Instructions for the upstream ResponseCache exact query/model/context lookup and optional lexical word-overlap matching. The main cache does not implement a semantic vector service. Use only when cached output remains valid for the context; not for durable governed memory or project-scan caching.

Instructions for the upstream workflow: Compact command output before it reaches the model — prefix a shell command with the wrapper and it returns a filtered, smaller form (test failures only, build errors grouped, compact diff, compact status), with meta commands for savings statistics, missed-usages discovery and an unfiltered proxy mode. Use on the verbose and repetitive commands: tests, builds, git, package managers, containers and file listings. Not for compressing model input in general — use universal-compressor; not for the per-turn compression policy — use token-shaper.

Instructions for the upstream workflow: Lightweight SBOM scanner for Python/Rust/Node dependencies

Instructions for the upstream workflow: Scan Python skills and MCP servers for malicious code — dangerous imports, network exfiltration, filesystem abuse, subprocess injection, obfuscation, crypto weakness, environment leaks, and supply-chain attacks. Use when auditing code for security, running pre-commit hooks, or preparing CI/CD security gates.

Instructions for the upstream workflow: Agents autobudgétaires — gèrent leur propre budget token.

Instructions for the upstream workflow: Create, validate, and render a bounded provider-neutral session brief without storing raw transcripts or secrets. Use before switching model, agent, host, or context window.

Instructions for the upstream workflow: A three-reviewer parallel pass over a diff — one reviewer on code reuse, one on quality, one on efficiency, each receiving the whole diff and required to cite file:line evidence — then findings are merged, false positives discarded, conflicts resolved by a stated priority order, fixes applied scoped to the diff, and targeted tests and linter run. Use when asked to simplify, clean up or review recent changes. Not for detecting smells across a whole tree — use the code_* detectors; not for the conceptual rules — use code-rules or karpathy-guidelines.

Instructions for the upstream single-implementation abstraction detector. Confirm the compatible runtime and analysis policy; review ABC, Protocol and abstract-base findings as candidates, with evidence, rather than automatic refactoring authority.

Instructions for selecting skill files by lexical or fuzzy matching, with an optional configured model reranker. Use for ambiguous skill/tool choices and consult the arbitration table. This catalog supplies the files, not the search runtime. Not for per-project profiles or budget allocation.

Instructions for producing an upstream project skill profile with always, conditional and disabled entries. Measure project needs and context use before changing it; no fixed savings are established here. Not for one-query ranking, global prefix measurement or budget allocation.

Instructions for upstream task assignment, bin packing and dependency scheduling. LPT and FFD are heuristics rather than general optimality guarantees; validate capacities, dependencies and algorithm assumptions. Not a bundled solver runtime.

Instructions for the upstream workflow: One-line summary of the belt's session activity (tokens saved, cache hits, local/cloud split, escalations) for a terminal statusline — Claude Code's statusLine hook, tmux, or any shell prompt. Reads .botte/events.jsonl. Use when the user wants a persistent, passive view of savings while they work, or asks to set up a statusline.

Instructions for the upstream workflow: Compact LLM-facing JSON and optionally emit round-trip-verified TOON for beneficial tabular data.

Instructions for the upstream workflow: Fail-closed evidence and planning contracts for self-hosting decisions — a validated catalogue with digest, capability coverage evaluation, inventory import and export, upstream source auditing, recommendation carrying its own evidence, deployment profiles and states, install plans and TCO scenarios. Use when a self-hosting or subscription decision must be justified by evidence rather than asserted. A recommendation fails closed when coverage or provenance is missing. Not for auditing code structure — use the code_* detectors; not for the token cost of a project — use context-profiler or cost-estimator.

Instructions for upstream model-tier planning using task requirements, configured endpoints, usage estimates and budgets. Local computation also has hardware and operating costs; measure actual provider usage. Not for micro-model classification or task-type hardware placement.

Instructions for the upstream TokenCompressor reversible TC1 codec: zlib compression of UTF-8 text with base85 encoding. All current level names use the same codec; historical hashing, pruning and schema strategies are not used by compress(). Not for direct model-readable content compaction.

Instructions for selecting an upstream per-turn shaping policy: compression level, output target and verbosity. Verify the runtime and measure task quality and costs. Not for actually compressing a payload or measuring the always-on prefix.

Instructions for upstream tool specification, lexical routing, route validation and evaluation before adopting a heavier router. The runtime and fixtures are separate; use measured results rather than assuming token savings. Not for skill selection or model-tier choice.

Instructions for the upstream workflow: Trajectory learning — stores solver trajectories and searches similar past optimizations to inform future decisions

Instructions for the upstream workflow: Track a project's audit metrics over time (directive score, duplication, LOC, always-on cost, fix count, recurring Markdown review state) and show the change since the previous run. Use to see whether the project is getting healthier/cheaper across audits.

Instructions for upstream compact JSON report formats: short keys, arrays and deltas. Use only with a compatible decoder and retained baseline, and verify round-trip data and measured size. Not for prose compression or binary inter-agent transport.

Instructions for the current upstream content compressor: JSON whitespace minification, exact repeated-line summaries, ANSI removal and code passthrough. Optional restoration retains originals in process memory; durable stores and sampling/truncation are not implemented by this API. Measure bytes and fidelity; not model token savings.

Instructions for the upstream workflow: Track the reviewed Ponytail and RTK baselines, local RTK version, documentation drift, and optional remote Git changes.

Instructions for an experimental upstream fixed-width finding-vector codec and in-memory store. It encodes severity, type, file-reference hash, line and action; it is not a learned embedding or a Qdrant integration and cannot reconstruct original paths or descriptions. Retain the original findings for human reports.

Instructions for the upstream workflow: Deterministic preflight for local full-frame versus ROI visual-token budgets, evidence coverage, verifier fallback, privacy, and cache separation.

Instructions for the upstream workflow: Minimal HTTP endpoint that exposes the router to no-code workflows — a POST route that takes a prompt and a task type and returns the routing decision as JSON, on a configurable port. Use to let an external workflow system (n8n and similar) call the router without importing Python. Boundary: the listener binds all interfaces and performs no authentication, so it must stay on a trusted local network and is not a public entry point. Not for the routing decision itself — use auto-router; not for a general HTTP surface — see the module registration pattern in code-rules.