CtrlK
BlogDocsLog inGet started
Tessl Logo

sdk-design

Doctrine for designing and evolving any **SDK** Grida ships — TypeScript, Rust, or otherwise. "SDK" here means a surface that crosses a foreign-or-foreign-treated boundary: published packages, separately-versioned consumers, FFI bindings, public-by-design modules. An SDK's job is to refuse; a strict, honest surface rejects the wrong contents and keeps the package testable in isolation. Default is "core, not customizable"; customization is the exception, defended by a deciding table. Use when authoring or evolving any such surface — `@grida/*` published packages, engine crates (gridaco/nothing `crates/*`) published or FFI-exported, intent/message vocabularies, any contract a second author will compile against. Internal-only helper packages are welcome to follow, not forced. Companion skill for two-sided contract work: $sdk-seam. Critique partners: $pedantic, $etiology. Related: $naming.

64

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/sdk-design/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A tightly written, highly actionable doctrine: decision tables with first-match-wins semantics, an ordered extension ladder, and concrete promotion and test rules, all without textbook padding. Its main gap is progressive disclosure — the entire doctrine lives in one SKILL.md with no reference files, so longer treatments (D5/naming corollaries, the deciding-table walkthrough) are inlined rather than split out.

Suggestions

Split the deepest sections into one-level-deep reference files (e.g., references/deciding-table.md with worked examples, references/disciplines.md for D1-D5) and keep SKILL.md as the overview plus the short version, surfacing each with a clearly signaled 'See X' link.

Add an explicit feedback checkpoint to the decision workflows, e.g. 'after walking the table, re-check the chosen rung against the violated anti-goal and re-walk if the anti-goal was threatened, not crossed' — a validate/retry loop for the deciding process.

Trim rhetorical framing lines ("The asymmetry is brutal — design from it", "That's the point") and the closing eight-bullet restatement, or compress 'The short version' into a single pointer to the section headers.

DimensionReasoningScore

Conciseness

The body is dense original doctrine with no padding over concepts Claude already knows — every section states a rule and its consequence. Minor trimmable overhead remains (rhetorical flourishes like "The asymmetry is brutal — design from it" and the closing 'short version' restating all eight rules), which keeps it at 'efficient; minor instances of over-explanation' rather than lean-and-perfect.

4 / 5

Actionability

The core procedures are concrete and executable: a first-match-wins deciding table with explicit outcomes, an ordered three-rung extension ladder, the >=2-internal-consumers promotion gate, and a named test-discipline rule. Per the rubric's instruction-only note the absence of code is not penalized; a few directives remain abstract ("Invest heavily before a name escapes its file") and D5 largely defers to $naming, so it stops short of fully-executable guidance.

4 / 5

Workflow Clarity

Multi-step decision processes are clearly sequenced with explicit ordering semantics ("walk these in order. First match wins"; "Reach down only when the rung above doesn't fit") and consequences for each branch (promoting too early vs. too late). No validate-and-retry feedback loop is needed for a design-doctrine skill with no destructive operations, but no explicit re-check loop exists either, placing it at 'clear sequence with most checkpoints present'.

4 / 5

Progressive Disclosure

There are no bundle files at all (references/, scripts/, assets/ are absent), so all ~265 lines of doctrine — five full disciplines, the deciding table, the promotion contract, and test doctrine — live inline in SKILL.md. Cross-skill references ($sdk-seam, $naming, $pedantic, $etiology) are clearly signaled and section headers are good, but content that naturally belongs in separate reference files (e.g., D5, which already says 'See $naming for the full treatment') is inlined, matching 'some structure but... content that should be separate is inline'.

3 / 5

Total

15

/

20

Passed

Description

78%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A precise, well-scoped description with an explicit 'Use when' clause, concrete trigger surfaces, clear exclusions, and explicit sibling-skill disambiguation. Its main weakness is that it describes a doctrine at a conceptual level rather than listing multiple concrete capabilities, which costs it specificity.

Suggestions

Add one or two concrete capability verbs to complement the doctrine framing (e.g., 'Walks a first-match-wins deciding table for customization requests and an ordered three-rung extension ladder') so the 'what' enumerates specific actions.

Include a couple of natural synonyms users would say ("public API design", "library publishing", "semver surface") alongside the existing trigger terms to broaden keyword coverage.

DimensionReasoningScore

Specificity

The description names the domain (SDK design doctrine) and gives a couple of concrete actions ("designing and evolving", "rejects the wrong contents", "Default is core, not customizable"), but it is a doctrine summary rather than an enumeration of several specific operations, so it matches the 'names domain and 1-2 concrete actions' anchor rather than the comprehensive-coverage anchor.

3 / 5

Completeness

Both 'what' (doctrine for designing/evolving SDK surfaces; the SDK's job is to refuse; default is core, not customizable) and 'when' are answered explicitly, with a concrete "Use when authoring or evolving any such surface" clause enumerating trigger surfaces (published packages, FFI-exported crates, intent/message vocabularies) plus explicit exclusions for internal-only helpers.

5 / 5

Trigger Term Quality

Strong natural-term coverage — "SDK", "published packages", "separately-versioned consumers", "FFI bindings", "engine crates", "any contract a second author will compile against" — phrases a user would plausibly say. A few natural synonyms ("public API", "library", "versioning") are missing, so it sits at 'good keyword coverage; a few natural terms missing' rather than the comprehensive anchor.

4 / 5

Distinctiveness Conflict Risk

A clear niche — SDK/public-surface design doctrine — with explicit disambiguation from sibling skills ("Companion skill for two-sided contract work: $sdk-seam; Related: $naming"). Minor overlap risk remains with $sdk-seam and $naming territory, and the trigger "any contract a second author will compile against" is somewhat broad, so it is 'mostly distinct' rather than minimal-conflict.

4 / 5

Total

16

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
gridaco/grida
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.