provider-integration-checklist

This skill should be used when the user asks to add or modify an "LLM provider", "model routing", "OAuth flow", "auth token handling", "provider config", or "fallback chain". Enforces provider integration completeness across config, routing, docs, and verification.

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

78%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.

An exemplarily lean, well-structured checklist skill whose only real weakness is actionability: it tells Claude what to verify but never how. Adding one concrete executable example per checklist (a test command, a config-resolution snippet, a smoke-path probe) would close the gap.

Suggestions

Add a concrete example for at least one item per checklist, e.g. the config-resolution-order check could show a 3-line env/DB/default resolution snippet, and the smoke path could show the actual command or request used to prove routing.

Add a short feedback loop for the verification stage: what to do when a targeted check or the smoke path fails (fix, re-run narrow tests, then re-run the gate).

Make the Required Handoff items actionable by specifying where evidence goes (e.g. 'paste test summary and smoke-path output into the handoff').

Dimension	Reasoning	Score
Conciseness	Every line is a terse directive ("Validate config resolution order (`env > DB > default`)", "Keep unknown-provider errors actionable") with zero padding and no explanation of concepts Claude already knows. Leanest possible form — every token earns its place.	5 / 5
Actionability	Concrete validation targets are named (resolution order, model identifier parsing, token redaction, fallback chains), but no commands, code, file paths, or examples show how to execute any check — "Narrow tests for changed provider/routing/auth paths" is direction rather than instruction. This matches the 'some concrete guidance but incomplete; missing key details' anchor, not 4, which requires executable commands.	3 / 5
Workflow Clarity	A clear sequence exists (Change → Compatibility → Verification → Handoff) with an explicit gate ("Broad gate checks after targeted checks pass") and negative-path tests. It is not 5 because no error-recovery feedback loop is described (what to do when the smoke path routes to the wrong backend).	4 / 5
Progressive Disclosure	The body is under 50 lines, well-organized into distinct checklist sections, and needs no external references; no bundle files exist and none are referenced. Per the rubric's simple-skill guidance, this is a 5.	5 / 5
	Total	17 / 20 Passed

Description

75%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 well-constructed description with an explicit when-clause and six natural trigger terms. The 'what' half is its weaker side: 'Enforces provider integration completeness' is an abstract statement of intent rather than a list of concrete capabilities.

Suggestions

Replace the abstract 'Enforces provider integration completeness' with 2-3 concrete actions, e.g. 'Validates provider config keys, model routing and fallback chains, and OAuth/token handling; verifies docs and tests stay in sync'.

Add a few natural trigger variations users are likely to say, such as 'add OpenAI/Anthropic support', 'API key handling', or 'switch the default model'.

Dimension	Reasoning	Score
Specificity	"Enforces provider integration completeness across config, routing, docs, and verification" enumerates four concrete coverage areas rather than abstract filler, matching the 'several specific actions; minor gaps' anchor. It falls short of 5 because the 'what' is a single abstract verb ('enforces') over domains, not a list of concrete actions.	4 / 5
Completeness	Both parts are present: an explicit when-clause ("This skill should be used when the user asks to add or modify...") with concrete trigger phrases, and a what ("Enforces provider integration completeness across config, routing, docs, and verification"). It is not 5 because the 'what' is abstract and lacks concrete actions like the anchor's 'Extract text and tables'.	4 / 5
Trigger Term Quality	Six natural trigger phrases a user would actually say are quoted: "LLM provider", "model routing", "OAuth flow", "auth token handling", "provider config", "fallback chain" — good coverage matching the anchor. It is not 5 because common variations like "add OpenAI support", "API key", or "switch default model" are missing.	4 / 5
Distinctiveness Conflict Risk	The provider-integration niche with triggers like "fallback chain" and "OAuth flow" is mostly distinct with only minor overlap risk against generic auth/security or testing skills. Not 5, since 'auth token handling' and 'provider config' could overlap with broader configuration or secrets-management skills.	4 / 5
	Total	16 / 20 Passed

Validation

100%

Warnings & errors only

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: spacedriveapp/spacebot
Path: .agents/skills/provider-integration-checklist/SKILL.md
Commit: 5c2ee47

Reviewed: 9 days ago

Table of Contents

Discovery Implementation Validation

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.