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.

72

Quality

88%

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

SKILL.md
Quality
Evals
Security

Quality

Content

77%

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

The body is a well-structured, actionable design doctrine with clear decision procedures and validation gates, but it is verbose for its length and monolithic rather than progressively disclosed into reference files.

Suggestions

Tighten rhetorical padding and drop or compress 'The short version' recap to reduce tokens, since it restates the thesis and disciplines already covered.

Split the densest material (the deciding-table rationale, the five disciplines' deep examples) into a reference file under references/ and link to it from SKILL.md to enable progressive disclosure.

Collapse the cross-references to companion skills into a single consolidated 'Related skills' line to reduce repetition of the $pedantic/$etiology/$naming pointers.

DimensionReasoningScore

Conciseness

The doctrine assumes Claude's intelligence (no basic-concept explanations) but carries rhetorical padding ('The asymmetry is brutal', 'you're about to break one') and a full 'short version' recap that restates earlier sections, so it could be tightened.

2 / 3

Actionability

Though code-free, it provides concrete, executable decision procedures (a first-match-wins deciding table, a ranked three-rung extension ladder, a test-as-spec discipline) that a Claude authoring an SDK can follow directly, satisfying the instruction-skill actionability bar.

3 / 3

Workflow Clarity

Multi-step processes are clearly sequenced with explicit gates — the deciding table ('walk these in order, first match wins'), the extension ladder ('reach down only when the rung above doesn't fit'), and the promotion contract's 'could a stranger build the next caller against this API alone?' validation test.

3 / 3

Progressive Disclosure

It is well-sectioned and its $-prefixed companion-skill references are one-level-deep and clearly signaled, but the ~265-line body is monolithic with no bundle files splitting out detailed material, fitting the score-2 'content that should be separate is inline' anchor.

2 / 3

Total

10

/

12

Passed

Description

100%

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

The description is specific, third-person, and explicit about both what the skill does and when to use it, with rich natural trigger terms and a well-bounded niche. It is one of the strongest descriptions the rubric is designed to reward.

DimensionReasoningScore

Specificity

Names multiple concrete surfaces and actions (published packages, separately-versioned consumers, FFI bindings, 'refuse', 'rejects the wrong contents', 'core, not customizable'), matching the score-3 anchor for multiple specific concrete actions.

3 / 3

Completeness

Explicitly answers both what (doctrine: refuse wrong contents, core-not-customizable) and when (explicit 'Use when authoring or evolving any such surface...' with concrete examples), matching the score-3 anchor.

3 / 3

Trigger Term Quality

Covers natural developer terms a user would say ('SDK', 'published packages', 'FFI bindings', 'TypeScript', 'Rust', 'engine crates', 'contract a second author will compile against') with an explicit Use-when clause enumerating concrete triggers.

3 / 3

Distinctiveness Conflict Risk

A clear niche (Grida SDK design doctrine, foreign-boundary surfaces) with distinct triggers and explicit demarcation from companion skills ($sdk-seam, $naming), making conflict with other skills unlikely.

3 / 3

Total

12

/

12

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.

Validation16 / 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.