Claude Skills by nahid-sparktales

A skill is `skills/<category>/<id>/SKILL.md`, plus a `manifest.json` beside it, plus `references/` and `scripts/` when they earn their place. Keep the layers apart. A skill says **how to perform one specialized thing**. It does not say who is responsible (a role), what external system exists (an MCP), or how several capabilities combine into one repeatable run (a recipe). A skill teaches; it never authorizes.

Handle requested Agent Dispatcher work with direct execution or prepared specialist guidance. Includes named roles, context inspection and controls.

Scope an agent or subagent before it is built — the one job it owns, the smallest tool set that closes that job, what it must never do, and the evidence it has to return. Use when adding an agent, subagent or automated role to a system, when deciding which tools it gets, when an existing agent loops, over-reaches or reports work it did not do, or when reviewing someone else's agent design. Not for wording the prompt itself, not for deciding what occupies its context window, and it never grant...

Build an eval suite that can actually detect a regression — cases pulled from real traffic, graders that check properties rather than vibes, a recorded baseline, and per-case diffs in both directions. Use before claiming a prompt, model or agent change is an improvement, when agent behaviour must not regress, or when someone reports "it seems better" after eyeballing a handful of outputs. Not for tracing what one run did (llm-observability), not for testing deterministic code, and never as ev...

Decide what actually occupies the model's window — progressive disclosure through an index, retrieval versus inlining, what compaction must preserve, and what loading everything costs. Use when a prompt or agent pulls in many files, docs or tool transcripts, when quality decays over a long session, when choosing between fetching at runtime and pasting up front, or when a context has to be trimmed or summarized. Not for the wording of the prompt, not for an agent's job and tool boundaries, and...

See what an agent actually did — one trace per run with nested model, tool and retrieval spans, token and latency accounted per step, and failures clustered by mechanism instead of read one at a time. Use when an agent misbehaves in ways you cannot reproduce, when cost or latency is unexplained, when "it sometimes fails" is the whole bug report, or before writing evals when you do not yet know which failures exist. Not for judging whether an output is correct (agent-evals), and not a replacem...

Build an MCP server, or bring an existing one into a project — choosing the transport, deciding which tools, resources and prompts to expose, keeping reads separate from writes, handling auth and credentials, and defining what failure looks like to the model. Use when writing an MCP server, wrapping an internal system as one, or evaluating a third-party server before wiring it in. Not for designing the individual tool signatures inside it (tool-design), and not authorization to install, confi...

Decide what an agent should remember, which layer holds it, who it is scoped to, and how a stale or contradicted memory is detected and retired. Use when an agent forgets something across sessions, when a memory or persistent-context feature is being designed, or when stored memories have grown noisy, wrong, or are leaking between users. Not for retrieval over a document corpus, not for prompt or context-window packing, and not for conversation transcript storage.

Pick a model per job and degrade sensibly when one fails — a quality bar per call site, candidates compared on the same task set, a readable routing rule, and an explicit retry-versus-fallback path with pinned model ids. Use when cost or latency has become a problem, when adding a cheaper or larger model to an existing system, or when a fallback fires silently and quality drops without anyone noticing. Not for prompt authoring, not for retrieval tuning, and not for capacity or infrastructure ...

Write or revise a prompt so it holds up — output contract, instruction placement, examples that earn their place, an escape hatch for bad input — and measure the change against a saved set of cases instead of one good-looking run. Use when a prompt is being authored or patched, when output is inconsistent or the wrong shape, when a model or version changes, or when someone reports a prompt as fixed. Not for scoping an agent's job and tools, not for deciding what material to load into the wind...

Treat everything an agent reads but did not author as data rather than instructions — an explicit trust boundary, a tool set fixed before content is read, consequential calls gated on the user, and destinations that cannot be chosen by the content. Use when an agent reads web pages, retrieved documents, emails, tool results, file contents or another agent's output and can also take actions, when adding retrieval or new tools to an agent, or when reviewing an agent for injection exposure. Not ...

Build and fix retrieval that actually returns the right passage — structure-aware chunking, one pinned embedding model, lexical plus vector search fused, reranking, and a recall measurement that is run separately from the generator. Use when a RAG system answers wrong or vaguely, when an index is being designed or reindexed, or when someone proposes a prompt change to fix what is really a retrieval miss. Not for prompt or output-quality work once the right passage is already in context, not f...

Get parseable, trustworthy structured results out of a model — schema design, the enforcement mechanism the provider actually offers, validation at the boundary, bounded retry that feeds the error back, and recognising where a schema stops buying correctness. Use when a model's output feeds code rather than a human, when parsing keeps failing or fields come back plausible-but-wrong, or when designing an extraction, classification or grading step. Not for designing the tools an agent calls (to...

Design the tools a model calls — names, parameter shapes, what a result returns, and error text written as an instruction the model can act on. Use when adding or reshaping a tool or function an LLM invokes, when an agent keeps calling the wrong tool or passing malformed arguments, or when reviewing a tool surface someone else defined. Not for building the MCP server that hosts the tools (mcp-design), not for forcing a model's final answer into a schema (structured-output), and not for prompt...

Prove an API integration actually works by executing it — success path, documented failure paths, auth failure — and leave behind a contract test that catches the next break. Use before reporting any endpoint, client or third-party integration as working, when asked whether an integration is verified, or when checking someone else's integration work. Not for load or performance testing, not for rendered UI verification, and not a substitute for reading the provider's own documentation.

Design or change an HTTP API — resources, verbs, status codes, one error shape, pagination, versioning, and an OpenAPI description that cannot drift from the handlers. Use when adding or reshaping endpoints, when asked what a response should return, or when reviewing whether a change to a published API breaks its consumers. Not for choosing between REST, GraphQL and RPC, not for database schema design, and not for implementing the handler's business logic.

Establish who the caller is — session cookies, bearer tokens, refresh, and OAuth/OIDC flows — and put each where it belongs. Use when adding or changing login, logout, signup, session handling, token issuance or refresh, an identity-provider integration, or when a request arrives with a credential nobody validates. Not for deciding what an authenticated caller may then do (that is authorization), not for the login screen's design, and not for hand-rolling crypto.

Decide what an authenticated caller may do — pick the permission model, put the check at one enforcement point close to the data, and default to deny. Use when adding roles or permissions, scoping data per tenant or per owner, building an admin-only path, reviewing an endpoint that trusts a client-supplied id, or when someone reports seeing data that is not theirs. Not for establishing identity (that is authentication), and hiding a control in the UI is never the enforcement.

Design queued and scheduled work so it survives duplicates, retries, crashes and restarts — job contract, idempotency, transactional enqueue, backoff, dead letters, leases and the ordering guarantees you actually have. Use when moving work off a request path, adding a worker or cron, or debugging a job that ran twice, never ran, ran out of order, or is stuck retrying forever. Not for in-request async concurrency, and not for stream processing topology design.

Decide what to cache, at which layer, for how long, and how it gets invalidated — before any cache is added. Use when someone proposes caching to make a read path faster, when stale or cross-user data is suspected, when adding a TTL or a Redis/CDN layer, or when reviewing a change that introduces one. Not for fixing a slow query or an N+1 (do that first — a cache over a bad query hides it), and not for HTTP header tuning with no server-side store.

Make an operation safe to repeat — idempotency keys and their storage, what a replay returns, retry policy with backoff and jitter, and how to reconcile after a timeout whose outcome is unknown. Use when an operation has an external side effect (a charge, an email, a provisioning call), when a caller needs to retry safely, or when duplicates have already appeared in production. Not for webhook receipt mechanics, not for database transaction design, and not for choosing a queue.

Receive or send HTTP webhooks correctly — signature verification on the raw body, fast acknowledgement, deduplication, out-of-order handling, retry and dead-letter behaviour, and the delivery contract a consumer needs. Use when adding or debugging a webhook endpoint, when integrating a provider's events, or when your own service has to notify others of changes. Not for internal queue or event-bus messages that never cross an HTTP boundary, and not for general outbound API retry policy.

Keep data correct over time — write the invariants down, push each one to the lowest layer that can enforce it, cover the rest with reconciliation queries, and detect drift before a user reports it. Use when deciding where a rule should be enforced, auditing a schema whose rules live only in application code, building reconciliation or drift checks, or investigating data that looks wrong. Not for sequencing a schema change (migrations) or proving one migration's outcome (database-migration-ve...

Build and repair batch and streaming pipelines that can be run twice without lying — lineage, event-time windowing, late arrivals, re-runnable writes and bounded backfills. Use when writing or fixing a pipeline, scheduled transform or job that produces data someone reads, when a run dropped or duplicated rows, or when planning a backfill. Not for designing the destination schema or its migrations, not for the standing assertions that guard the data afterwards (data-quality), and not for inter...

Decide what must be true of a dataset and where that assertion belongs — freshness against event time, volume floors and bands, distribution and referential checks, source reconciliation, and whether it should be a schema constraint, a blocking publish gate or an alert. Use when adding or reviewing data checks, when a wrong number reached a consumer and nothing caught it, or when a check fires so often it is being ignored. Not for proving a specific migration did what it claimed (database-mig...

Prove a migration did what it claimed — before/after row counts, column checksums, constraint and index state, invariant queries, an exercised application read path, and a rehearsed rollback. Use after a migration has been applied to any environment and before anyone reports it as working, or when reviewing someone else's claim that a migration succeeded. Not for planning or sequencing the migration (that is migrations), and it does not treat a clean exit code, a green CI run, or a backup's e...

Change a live schema without breaking the application on it — expand/contract sequencing, lock-safe DDL, batched backfills, and a rollback that is actually reachable. Use when writing, reviewing or sequencing a migration that will run against a database holding real data with live readers. Not for designing a schema from scratch, not for proving afterwards that a migration did what it claimed (that is database-migration-verification), and it never runs the production step for you.

Postgres behaviour worth checking before relying on it — type choices, index kinds and their costs, reading EXPLAIN output, isolation levels and lock behaviour during DDL, and row-level security. Use when the project runs on Postgres (including Postgres-backed services) and a decision depends on what the engine actually does: picking a column type, adding an index, changing isolation, or writing and debugging an RLS policy. Not for engine-neutral modelling decisions, and not for the measure-f...

Make one slow query fast without guessing — capture the plan, find where the time actually goes, change one thing, and measure again on comparable data. Use when a query, endpoint or report is slow and the database is the suspect, when a plan needs reading, or when someone proposes an index with no evidence. Not for modelling decisions about tables and constraints, not an engine feature reference, and not for system-wide performance work where the database has not yet been shown to be the bot...

Turn what a system must guarantee into tables, keys and constraints — normalization judgement, nullability, foreign key behaviour, and naming that survives. Use when designing new tables, reviewing ORM models or a migration's DDL, or when a bug reduces to "the database allowed a row that should be impossible". Not for tuning a slow query, not for engine-specific syntax and features, and not for writing or running the migration that ships the change.

Prove an accessibility claim instead of asserting it — automated scan plus the keyboard, focus, zoom and screen-reader passes a scanner structurally cannot make. Fires before anyone says a screen is accessible or WCAG AA, when signing off UI work, or when an audit result needs checking. Not for making the fixes (accessibility), and it never upgrades a clean scan into a conformance claim.

Build and fix interfaces so they meet WCAG 2.2 AA in practice — native semantics, keyboard paths, focus order and visibility, accessible names, contrast, form errors, live regions, target size. Fires while writing or reviewing UI code, when a component is keyboard- or screen-reader-hostile, or when an audit finding has to be turned into a change. Not for proving the result (accessibility-verification), not for viewport layout work (responsive-design), and not a recital of the standard.

Build UI inside an existing design system — find its tokens and components, reuse before adding, decide between extending a component and introducing a new one, and preserve conventions you did not set. Use when a project already has design tokens, a component library, a theme or a shared Figma library and you are about to add or change UI inside it. Not for establishing a visual direction where no system exists, and not for reviewing an interface's usability.

Turn a design, mockup, Figma frame or screenshot into implementation that actually matches it — mapping values to the codebase's existing tokens and components, covering the states the design never drew, and listing what the design left ambiguous instead of guessing. Use when handed a design to build, when asked whether an implementation matches its source, or when a build has drifted from the design. Not for deciding what the design should be, and not by itself proof that the screen works.

Establish a visual direction for new or reshaped UI so it reads as designed for this product rather than assembled from defaults — hierarchy, typography, colour, spacing, density. Use when building a new surface, when something looks templated and needs a direction rather than a tweak, or when asked to make an interface feel considered. Prefer the official Anthropic frontend-design skill when it is installed; this is the local counterpart for when it is not. Not for critiquing an existing int...

Decide what an animation is communicating, then give it a duration, an easing curve, an interruption behaviour and a reduced-motion fallback. Use when adding or reviewing transitions, when a screen feels sluggish or jumpy, when implementing motion specified in a design, or when animation needs to survive users who ask for less of it. Not for static visual design, and not for general performance profiling of code that has no animation.

Make a layout hold from 320px to wide desktop — content-driven breakpoints, intrinsic layout before media queries, fluid type that still zooms, touch targets, reflow without hiding content, and what to check at each width. Fires when building or fixing layout, when something overflows or collapses at a size, or when a design only exists at one width. Not for proving it renders (browser-verification) and not for semantics or screen readers (accessibility).

Review an existing interface and return ranked, concrete findings — each with its location, the user consequence, and a specific fix — instead of taste notes. Use when asked to critique, audit or review a screen or flow, when someone's UI work needs judging, or when an interface "feels off" and the problem needs naming. Not for proving a change renders and functions, not for inventing a new visual direction, and not for an accessibility conformance audit, which is its own discipline.

Write or repair the words inside an interface — button labels, empty states, error messages, confirmation dialogs, form hints, success and loading text — so a reader knows what just happened and what to do next. Use when a screen's copy is being written or reviewed, when an error says something unhelpful, when a confirmation is vague about what it will do, or when users hesitate at a control. Not for marketing or landing-page copy, not for documentation, and not for deciding layout or visual ...

Design the shape of a delivery pipeline — what each stage actually proves, what gates what, where verification belongs, and how a run reports the truth instead of a green tick. Use when a pipeline is being designed or restructured, when a release got through a passing pipeline broken, when deciding what blocks a merge or a deploy, or when a stage claims more than it ran. Not for provider-specific workflow YAML (github-actions), image authoring (docker), writing the tests themselves (test-desi...

Prepare and run a release you can explain and undo — exact artifact identity, environment parity, config and secrets, a rollout strategy matched to blast radius, and a preflight that names the abort condition in advance. Use when planning or performing a deploy, building a release path, or when someone says "ship it" and the steps are not written down anywhere. Not for proving the deployed thing is healthy (release-verification) or for getting back out (rollback), and it never treats a green ...

Build container images that are reproducible, small, and safe to run — layer order and what actually caches, multi-stage builds, and what belongs in an image versus what must never be baked into one. Use when writing or reviewing a Dockerfile, when an image build is slow, bloated, or non-deterministic, or when deciding how configuration and secrets reach a container. Not for orchestration, cluster or compose topology, not for CI workflow authoring (github-actions), and not for pipeline stage ...

Write and review GitHub Actions workflows that fail honestly and finish fast enough to be trusted — least-privilege permissions, untrusted pull request input, caching keyed on the right thing, matrices that mean something, and secrets that never reach a fork. Use when adding or changing a workflow file, when CI is slow, flaky, or green when it should be red, or when reviewing someone's workflow YAML. Not for provider-neutral pipeline and gate design (ci-cd), image authoring (docker), or writi...

Stabilize a system that is failing right now — name the signal that flagged it, size the blast radius in numbers, keep a timestamped log written as you go, find the last known-good state, then propose the smallest reversible mitigation and confirm recovery against that same signal. Use when production is degraded or down and time to mitigation matters more than a complete explanation. Not for a defect that is not currently failing (systematic-debugging), not for the root-cause investigation o...

Instrument a service so the questions asked during an incident are answerable from data already being collected — rate, errors, latency distribution and saturation per route, structured events carrying a correlation id that survives process and queue boundaries, and alerts on symptoms users feel. Use before a service or a new critical path goes to production, after an incident that ended in "we had no data for that", or when adding a dependency, queue or job whose failure would be silent. Not...

Prove a deployment is healthy rather than merely finished — the revision actually serving asked of the running system, every instance moved, smoke paths walked against the real environment, error rate and latency compared to a pre-deploy baseline. Use after any deploy to a shared environment, before a release is called good, or when checking someone else's claim that it went fine. Not for planning the rollout (deployment) or executing a revert (rollback); it never accepts a green pipeline, a ...

Get back to a known-good state, and know in advance which parts of a release cannot come back — destructive migrations, data the old version cannot read, messages already sent, published artifacts, cache and CDN state. Use while writing a release plan, when a deploy is going wrong, or when someone asks whether a change can be undone. Not the health check that decides you should revert (release-verification), not incident coordination, and it never runs a production revert without explicit per...

Decide where a component's boundaries go, where state lives, what its props should be, and whether to split it — using composition instead of configuration flags. Fires when adding a component to an existing tree, when a component has grown props or responsibilities, or when a review asks whether a structure will hold. Not for visual design decisions, not for styling systems, and not a licence to restructure code the task did not ask you to touch.

Make a page measurably faster — pick the metric that is actually bad, measure it under stated conditions, find the real cause, apply the fix that moves that specific metric, re-measure the same way. Use when a page is called slow, when LCP, CLS, INP, TTFB, a Lighthouse score or bundle size is named, when a bundle has grown, or before claiming an optimization worked. Not for backend query or API latency, not for choosing a framework, and not a substitute for checking the page still works after...

Work with shadcn/ui components and the Radix primitives under them — components are copied into the repo and are your source, so customize them in place, know that re-running the generator overwrites local edits, and know which accessibility behaviour Radix gives you and which it does not. Fires when adding, customizing or debugging a component in a repo with components.json and a vendored UI directory. Not for choosing a component library, not for general component structure, and not an acce...