sdk-design

Design guidance for an SDK, a software interface that other applications or separately released packages use.

In plain words
What is it for?
Use it when designing or changing published TypeScript or Rust packages, foreign-function bindings, WebAssembly modules, or other public interfaces.
Why use it?
It helps keep the public interface small and understandable, so future changes do not create unnecessary breaking changes for users.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/gridaco/nothing/sdk-design
Any agent
npx skills add gridaco/nothing --skill sdk-design
Clone the repo
git clone --depth 1 https://github.com/gridaco/nothing

Made for: Claude Code, Codex.

Per session 192 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 3,459 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin 95% copy Near-identical to another mod 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 $0.00192 $0.03459
Opus 5 $0.00096 $0.01729
Sonnet 5 $0.00038 $0.00692
Haiku 4.5 $0.00019 $0.00346

Measured 2d ago against content hash e3c71a64acb8, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

sdk-design 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 2d 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.

Origin

This is a copy

95% identical to sdk-design — 7 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

.agents/skills/sdk-design/SKILL.md · 285 lines

How it starts

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

sdk-design

This is not a style guide. Style and language-specific code shape are downstream (see $code-ts, $code-react for the TS sides). This is about what an SDK refuses to do — the discipline that keeps a package small, legible, and replaceable, regardless of language.

The thesis

An SDK lives or dies by what it refuses to expose. Default is core; customization is the exception. Every public knob is a contract you cannot retract without a semver break and a coordinated migration across every downstream call site.

A library with too few knobs is easy to grow. A library with too many is impossible to retire. The asymmetry is brutal — design from it.

This doctrine applies whether the package ships as an npm scope, a crate, a header-only library, a WASM module, a Python wheel, a hosted service with an SDK, or a pair of microservices defining a shared message vocabulary. The mechanics of "publish" differ; the discipline of "refuse the wrong contents" does not.

Scope: what counts as an SDK

This is the gate. The skill says "SDK," not "package," because the two are different. An SDK is:

  • A surface that crosses a foreign-or-foreign-treated boundary. Published to a registry (npm, crates.io, PyPI); linked by a separately-versioned consumer (a desktop binary against a crate, a generated WASM/FFI binding); or authored as if a foreign consumer existed even if one doesn't yet (any package whose README documents it as a public surface, anything tagged for publication, anything in a *-hosted suffix family).
  • Versioned independently of its callers, even if today every caller lives in the same monorepo and ships on the same commit. The intent to be replaceable is what counts.

What this excludes — where the doctrine is welcome but not load-bearing:

  • A package with exactly one internal caller, shipping on the same commit, where if the caller's needs changed the package would be rewritten freely. That's not an SDK; that's a refactored module that happens to live in packages/. Adopt the parts of this skill that pay; skip the rest without apology.
  • One-off helper crates pulled in by a single binary in crates/. Same logic.

Read the full file on GitHub · 285 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. 2d ago First seen · 285 lines · 192 tokens per session scan A e3c71a64acb8

Subscribe to this mod's changes

sdk-design is a skill published in the GitHub repository gridaco/nothing (43 stars, last pushed 2d ago), licensed Apache-2.0. It adds 192 tokens to every session and 3,459 once invoked, about $0.0010 per session on Opus 5. A static security scan graded it A with 0 findings. It is 95% identical to sdk-design, differing in 7 lines, and is treated as a copy.

Related

Other skills, from other repositories

freya

Freya Rust GUI framework best practices, patterns, and conventions. Use when writing Freya components, hooks, elements, or working on a Freya project.

marc2332/freya · 35 tokens

docs-svg-kit

Author SVG figures for Grida docs — diff-able, version-controlled vector diagrams embedded in doc pages instead of screenshots. Provides reusable primitives (selection chrome, size badges, anchor pins, resize cursors, click ripples), color/typography tokens, a starter template, and finished examples to crib from.…

gridaco/grida · 145 tokens

editor-perf

Guides performance investigation, benchmarking, and optimization of the Grida Canvas web editor (TypeScript reducer, Immer, React hooks). Use when profiling reducer dispatch cost, diagnosing slow interactions (drag, resize, color change), writing or running editor benchmarks, instrumenting with PerfObserver, or…

gridaco/grida · 69 tokens

sdk-seam

Discipline for the seam between two SDKs (or two sides of one contract) that the same hand writes. The failure mode: "we own both sides" produces dirty contracts no foreign reviewer would accept. The exercise: pretend the other side is FFI, IPC, or a network protocol you cannot rewrite. Spawn an adversarial subagent…

gridaco/grida · 142 tokens

agent-system

Grida AI agent system work: @grida/daemon (DaemonServer, loopback HTTP perimeter, files/workspaces, secrets store, daemon discovery) and @grida/agent (the agent tenant: sessions, providers/BYOK, runtime/tool execution, skills discovery, prompts, tiers, sandbox hosts). Use for packages/grida-daemon/…

gridaco/grida · 127 tokens

ai-models

Research, compare, and update AI model configurations. Covers text model tiers, image and video generation models, image tool models, pricing data sourcing, and provider-cost metering against prepaid org credit. Use when bumping model versions, adding new models, updating pricing, or auditing model specs against…

gridaco/grida · 65 tokens