putio/sdk-dev
Develop or review put.io SDK repositories, API clients, and client libraries across TypeScript, Swift, Kotlin, and similar packages. Use when adding or changing namespaces, tightening request or error types, aligning SDK behavior with backend and app usage, updating SDK verification flows, or checking how an SDK repo should be documented and released.
90
90%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
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.
This is a strong skill description that clearly defines its scope around put.io SDK development and review, lists concrete actions and languages, and includes an explicit 'Use when' clause with specific trigger scenarios. The description is well-structured, uses third person voice, and provides enough detail to distinguish it from general coding or API skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: developing/reviewing SDK repositories, adding/changing namespaces, tightening request/error types, aligning SDK behavior with backend, updating verification flows, and handling documentation/release processes. | 3 / 3 |
Completeness | Clearly answers both 'what' (develop or review put.io SDK repositories, API clients, and client libraries across multiple languages) and 'when' (explicit 'Use when' clause listing specific trigger scenarios like adding namespaces, tightening types, aligning SDK behavior, updating verification flows, and checking documentation/release). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'SDK', 'API clients', 'client libraries', 'TypeScript', 'Swift', 'Kotlin', 'namespaces', 'request types', 'error types', 'put.io', 'verification flows', 'documented and released'. Good coverage of terms a developer working on SDK repos would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive due to the specific product scope (put.io), the focus on SDK/API client development specifically, and the enumeration of particular languages and tasks. Unlikely to conflict with general coding skills or other product-specific skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured SDK development skill with strong actionability—concrete commands, clear workflows, and a specific endpoint change recipe make it immediately usable. The workflow clarity is excellent with proper validation checkpoints and source-of-truth ordering. The main weaknesses are moderate verbosity (some redundancy between sections) and the inability to verify that referenced bundle files actually exist, though the progressive disclosure structure is reasonable.
Suggestions
Tighten the Verification section by removing redundant explanations of the two-layer testing model (already covered in Quick Rules and Main Workflow) and consolidating the example commands.
Consider moving the Guardrails section content into references/patterns.md since most points restate constraints already mentioned in the workflow, keeping only novel guardrails inline.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient and avoids explaining basic concepts, but some sections are somewhat verbose—e.g., the Verification section repeats similar ideas about deterministic vs live tests multiple times, and the Guardrails section restates points already covered in the workflow. Could be tightened by ~20%. | 2 / 3 |
Actionability | Provides concrete, executable commands (rg searches, verify commands, gradlew), a specific step-by-step endpoint change recipe with exact ordering, and real bash examples. The guidance is specific enough to be directly followed rather than interpreted. | 3 / 3 |
Workflow Clarity | The Main Workflow is clearly sequenced with 8 numbered steps including explicit validation (step 7: run canonical verify and fix failures before continuing). The Endpoint Change Recipe provides a traceable sub-workflow with verification steps. Feedback loops are present—check backend before widening, run verify and fix before continuing. | 3 / 3 |
Progressive Disclosure | References to sdk-vision.md, patterns.md, and language-notes.md are well-signaled with clear descriptions of what each contains. However, no bundle files were provided to verify these exist, and the skill itself is moderately long with some content (like Guardrails) that could potentially be in a referenced file. The 'Start Here' section provides good navigation but the overall document could benefit from moving detailed verification examples to a reference. | 2 / 3 |
Total | 10 / 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.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
Reviewed
Table of Contents