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.

The content is an exceptionally concise, well-sequenced checklist that clearly maps the provider-integration workflow with gating checkpoints. Its main weakness is actionability: it tells Claude what to verify but rarely how, with no executable code or commands.

Suggestions

Add 1-2 executable examples or concrete commands for the highest-value checks (e.g., a snippet to assert routing/fallback behavior or a test scaffold for the smoke path) to lift actionability.

Add an explicit validate→fix→retry feedback loop (e.g., "If a targeted or gate check fails, fix the change and re-run until green before handoff") to formalize error recovery for these production-affecting changes.

Optionally point at where config keys/routing live (file or module paths) so the checklist anchors to concrete locations in the codebase.

Dimension	Reasoning	Score
Conciseness	The body is a lean imperative checklist with no padding and no explanation of concepts Claude already knows; every token earns its place.	5 / 5
Actionability	Bullets are concrete about what to check ("Validate config resolution order (`env > DB > default`)", "Smoke path proving model call routes to expected backend") but provide no executable code, commands, or file paths for the how, leaving key execution details missing.	3 / 5
Workflow Clarity	The flow is clearly sequenced (Change → Compatibility → Verification → Handoff) with explicit checkpoints ("Broad gate checks after targeted checks pass", negative-path tests), but lacks an explicit validate→fix→retry feedback loop for these batch/production-affecting changes.	4 / 5
Progressive Disclosure	At ~40 lines with no external references needed and no bundle files present, the well-organized section structure fully satisfies the simple-skill progressive-disclosure exception.	5 / 5
	Total	17 / 20 Passed

Description

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

The description cleanly states both what the skill does and when to use it, with explicit, natural trigger phrases in third-person voice. It is strong overall, with only minor gaps in trigger synonym coverage and slight overlap risk with general config/auth skills.

Dimension	Reasoning	Score
Specificity	Lists several concrete sub-domains ("LLM provider", "model routing", "OAuth flow", "auth token handling", "provider config", "fallback chain") and states "Enforces provider integration completeness across config, routing, docs, and verification", but the verb is a meta-action rather than multiple concrete doing-actions, leaving minor gaps versus the comprehensive anchor.	4 / 5
Completeness	Both what ("Enforces provider integration completeness across config, routing, docs, and verification") and when ("This skill should be used when the user asks to add or modify...") are explicitly stated with concrete trigger phrases, and the voice is third person, matching the top anchor.	5 / 5
Trigger Term Quality	Trigger phrases are explicit and natural ("LLM provider", "model routing", "OAuth flow", "auth token handling", "provider config", "fallback chain") with some synonym coverage; a few natural variants (e.g. "API key", "model alias") are missing, so it stops short of comprehensive.	4 / 5
Distinctiveness Conflict Risk	The provider-integration niche is clear with distinct triggers and minimal conflict risk, but broad terms like "provider config" and "auth token handling" carry minor overlap with general config or auth skills.	4 / 5
	Total	17 / 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: ab2c160

Reviewed: 4 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.