smithers: Skill for Claude Code

.agents/skills/smithers-maintenance/SKILL.md

smithers-maintenance is a skill for Claude Code, Codex from smithersai/smithers. It costs 29 tokens per session (2,198 once invoked), scanned A, original, MIT.

Repository maintenance guidance for the Smithers workspace, covering its command-line tools, generated files, documentation, benchmarks, evaluations, and durable workflows.

In plain words
What is it for?
Use it when changing Smithers targets, builds, tests, linting, documentation, caching, benchmarks, evaluations, or durable flows.
Why use it?
It helps contributors use the current source and command syntax instead of relying on outdated examples, and prevents changes that leave generated files or workflow records inconsistent.

Skill for Claude CodeCodex

Written for no agent in particular: nothing here depends on one. Also seen: installed under .agents/ (shared by several agents); mentions AGENTS.md.

This is smithersai/smithers's own configuration. It tells Claude Code and Codex how to work on smithers itself, so it is not a mod to install elsewhere. Copy it as a starting point and replace the rules that are about this project. Everything smithers configures →

Reuse

Borrowing it

Nothing to install: this file belongs to smithersai/smithers. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.

Copy the file
curl -O https://raw.githubusercontent.com/smithersai/smithers/main/.agents/skills/smithers-maintenance/SKILL.md
Clone the repo
git clone --depth 1 https://github.com/smithersai/smithers

Made for: Claude Code, Codex.

Wrote 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.

agentmods badge for smithers-maintenance

README.md
[![agentmods](https://agentmods.dev/badge/skills/smithersai/smithers/smithers-maintenance/github.svg)](https://agentmods.dev/skills/smithersai/smithers/smithers-maintenance)
Your own site
<a href="https://agentmods.dev/skills/smithersai/smithers/smithers-maintenance"><img src="https://agentmods.dev/badge/skills/smithersai/smithers/smithers-maintenance/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.

agentmods 80×15 button for smithers-maintenance

Your own site · 80×15
<a href="https://agentmods.dev/skills/smithersai/smithers/smithers-maintenance"><img src="https://agentmods.dev/badge/skills/smithersai/smithers/smithers-maintenance.svg" alt="Reviewed on agentmods" width="80" height="20"></a>
Per session 29 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 2,198 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5.1 $0.00029 $0.02198
Opus 5.5 $0.00012 $0.00879
Sonnet 5.5 $0.00006 $0.00440
Haiku 4.5 $0.00003 $0.00220

Measured 3d ago against content hash 22a46d068467, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

smithers-maintenance 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 3d 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.

.agents/skills/smithers-maintenance/SKILL.md · 32 lines

How it starts

The opening of the file, as written. The whole thing — 32 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Smithers maintenance

Use the owning source and current docs on the revision being changed. The source CLI (makeCli() in packages/smithers/src/Cli.ts) is the CLI syntax contract; the installed release can be stale. The 1.0 CLI separates target graph commands (smthrs targets, show target, build|test|lint|docs|review|ci) from durable flow commands (smthrs flow list|plan|start, smthrs runs ...). A flow start receipt does not prove completion; inspect its run and action receipts.

  • Graph or root files: read CONTRIBUTING.md, especially root-file and target-index generation. PACKAGE.ts declares targets; generated companions and the whole declaration-set index have explicit checks. Use pnpm run target-index when that contract calls for regeneration. The tree splits into apps/ and packages/, never by language: a Rust crate lives under packages/ beside its consumer (for example packages/smithers/flows/jj-wasm), so never add a top-level folder per language, such as a crates folder.
  • Build/install/cache: read build, workspace remote caching, and cache trust. The install flow currently supports pnpm only; Bun can still run target tools. Install actions use expected filesystem boundaries and do not enter the shared engine cache. The target /ac cache differs from engine step-cache/artifacts; hosted and self-hosted cache implementations need matching route, bound, and credential behavior.
  • Documentation: Author library documentation in each package's docs/ directory; it ships with the npm package. Run pnpm docs:check to verify tarball contents. Main-site projections use pnpm --filter @smithers/site run sync:docs.
  • Benchmarks or performance claims: read .smithers/flows/bench/README.md. Distinguish the deterministic PR gate from scheduled observed timings, review candidate baselines, and retain methods and limitations with any claim.
  • Evals: read the owning suite's README, including agent and seeded review. Keep offline deterministic gates and deliberate baseline updates separate from live model measurements and spending.
  • Flows: read @smthrs/flow and CLI reference. A file flow at .smithers/flows/<name>/flow.ts (mvp.md M-49) default-exports a tagged Flow.make from @smthrs/flow. Export its action implementations as the optional named layer (Declared.toLayer, AgentAction.layer, or Layer.mergeAll); the registry composes it against the local host platform and agent services. Export implementations directly; the host owns Action.Implementations. Acquire extra dependencies during layer construction so missing services are refused at load. Use stable Node.capture callbacks for canonical persisted composition and matching implementationVersion declarations/registrations for sealed idempotent actions. New authoring uses Effect Schema, not retired JSX/Zod task examples. A decision inside a flow (classify, filter, rank, route, yes/no over items) asks Jev through Classifier.make and the host Evaluator, as one request with one question per item, never through an LLM seat; see jev-check.
  • Plans: read plan and plan-store. Node payloads are persisted as plaintext in node_json and approval cards without redaction; keep credentials out and resolve them at dispatch. Persisted plans are verified on write and read, and append uses an immutable-history compare-and-swap over the approved base and running prefix.
  • Generated or untrusted flow declarations: read core planning rules. Graph.build executes bodies and planning callbacks with the caller's process authority; capability/effect metadata does not sandbox that code. Translate validated data into nodes with trusted code, or plan untrusted code in an externally isolated process.
  • Runtime or persistence: read flows runtime, engine, and engine-store. @smthrs/flow declares behavior, the engine makes decisions, and the storage seam changes where state lives. Node and Bun use distinct native host/SQL adapters over the same SQLite migrations, journal, stores, cache, and recovery. Run migrations before SQL-backed services and use one writer for journal/state transitions; demonstrate cross-runtime recovery and cancellation. Browser bundling alone does not establish durable browser execution.
  • Journal and ownership fencing: read journal and run-store. Ownership is arbitrated by the journal's injectable Consensus strategy (SqlConsensus over flows_consensus_leases by default, Consensus.layerLocal in-process); fenced durable emissions join its guard, so the run must be claimed and activated through it, and the journal and run store must share one strategy instance. RunStore mirrors the outcome on flows_runs, so a fixture that forges ownership in SQL writes both. emitDurableUnfenced is only for genuinely ownerless admission or repair, never a bypass for fence_lost. An expired lease alone does not authorize takeover; LivenessEvidence must be current, and an unknown probe counts as alive.
  • Step cache migrations: read step-cache. The earlier 1.0 RC migration 2002 identity is accepted explicitly; preserve its ledger and cached results during upgrade. An unknown migration identity remains a failure, not a reason to delete a runtime database.
  • Time travel: read time-travel before changing fork, rewind, or their receipts. A durable fork reuses completed prefix attempts by their original action identities and gives new work child-scoped keys; rewind archives future waits and refuses crossed irreversible effects or live descendants. Test recovery after an interrupted mutation.
  • Sync: read sync before changing cursors, subscriptions, or gateway mounts. Persist applied cursor progress with consumer state; change feeds are hints and a re-list is authoritative. Preserve rewind generation handling: lineage_changed requires rebuilding the projection. Branch RPC code is not currently mounted by the gateway.
  • Artifacts: read artifact storage. Its filesystem backend needs trusted host filesystem semantics; kernel-guarded filesystem access cannot substitute for them. Treat deletion as explicit and keep engine-store responsible for liveness/reachability.
  • Browser host: read platform-browser. Its bash, filesystem, and jj views must share one volume; the tab uses the memory engine, and reload durability depends on the mount's sync(). Do not infer browser durability from a successful build or import.
  • Bun host: read platform-bun before changing its filesystem or process adapters. Its trusted filesystem boundary runs the native smithers-jj-export helper (build with cargo build --locked --release -p smithers-ffi --bin smithers-jj-export or set an absolute SMITHERS_WORKSPACE_JJ_EXPORT_BINARY); PATH is never searched. Bun's host bundle is not the browser adapter.
  • Node host: read platform-node before changing containment or process recovery. Confined operations require the smithers-jj-export helper built with the Rust toolchain rust-toolchain.toml pins; a missing helper refuses them. ProcessLedger.layerMemory cannot recover escaped children after a host crash, and permission checks belong around the host service bundle.

Read the full file on GitHub · 32 lines

Changes

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.

  1. 3d ago Changed · +1 lines 22a46d068467
  2. 4d ago Changed 3702a7be6b29
  3. 13d ago Changed 8956f9890153
  4. 17d ago Changed · +2 lines 09e10b7658fd
  5. 18d ago Changed 833cbedbae02
  6. 20d ago Changed 065f5fc8ae86
  7. 21d ago Changed 3d29551aa846
  8. 23d ago Changed 92c926c606d2
  9. 24d ago Changed 0b430b220763
  10. 26d ago First seen · 29 lines · 29 tokens per session scan A 4406cd7d9ebb

Subscribe to this mod's changes

smithers-maintenance is a skill published in the GitHub repository smithersai/smithers (439 stars, last pushed today), licensed MIT. It adds 29 tokens to every session and 2,198 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-25.

Related

Other skills, from other repositories

beevibe-verify-pr

CI verification before marking a PR-bearing task done. Use BEFORE calling mcpbeevibeupdateprogress(done) on any session whose deliverable is a pull request — including the first dispatch (you opened the PR with gh pr create) and any revision dispatch (you pushed new commits to an existing PR). Watches the PR's…

beevibe-ai/beevibe · 172 tokens

cao-contributing

Contribute changes to the CAO (CLI Agent Orchestrator) codebase — the local dev loop, the CI gate map, and the pre-PR checklist. Use when the user says "open a PR", "why did CI fail", "run the checks before I push", "the mypy/Code Quality job is red", "add a test and verify coverage", or when making any code change…

awslabs/cli-agent-orchestrator · 153 tokens

skill-engineering-quality

Use when a repository needs a quality baseline or modernization across one or more detected application stacks, especially linting, formatting, type checking, tests, build validation, developer tooling, hooks, or CI consistency.

IAPro-Community/Orquestrador-Maestro · 46 tokens

bash-pro

Master of defensive Bash scripting for production automation, CI/CD pipelines, and system utilities. Expert in safe, portable, and testable shell scripts.

aAAaqwq/AGI-Super-Team · 35 tokens

cw-gates

Use before claiming any Codewhale change is done, green, or ready to land: the focused-to-broad verification ladder, the budget checks CI enforces, and the rules for what counts as a passing test.

Hmbown/Codewhale · 48 tokens

e2e-testing

Use when reviewing CI coverage, automated checks, or test strategy related to Implement end-to-end testing. Focus on whether the rule is continuously verified, not just documented.

thedaviddias/Front-End-Checklist · 38 tokens