Claude Skills by nahid-sparktales

Establish what a frontend project actually uses — framework, router, package manager, styling, component layer, TypeScript posture — from package.json, lockfiles, config files and the source itself, before loading framework-specific guidance or writing a line of code. Fires at the start of any frontend task in an unfamiliar or half-remembered repo, and whenever you are about to assume a convention. Not for choosing a stack for a new project, and not a substitute for reading the code you are a...

Work inside an existing Tailwind codebase without degrading it — use the project's theme tokens instead of arbitrary values, extend the theme when a token is genuinely missing, extract repetition into components rather than @apply, resolve class conflicts with the project's merge helper, and make dark mode a token decision. Fires when writing or editing Tailwind classes in a repo that already uses it. Not for deciding whether to adopt Tailwind, not for visual design direction, and not a rende...

Prove a UI looks right across every state and viewport it has to survive — enumerate the state matrix, make captures deterministic, compare against a baseline captured the same way, and triage every diff. Use before calling a visual change, a style refactor or a redesign done, when running or trusting a screenshot-comparison suite, and when asked whether a screen still looks correct. Not for judging whether a design is good, not for proving controls actually work, and never on its own suffici...

Compare products, libraries or approaches on criteria derived from your own constraints rather than from anyone's feature list, and fill each cell with evidence you obtained — hands-on trial, primary docs, source, issue tracker — marking clearly what is only a vendor claim. Use when choosing between real alternatives, when asked how something stacks up against the competition, or when a decision is being made from a marketing comparison table. Not for general investigation method, not for jud...

Write persuasive copy that is also true — landing pages, product messaging, emails, ads, launch announcements — by fixing the reader, the objection, the offer and the voice, then auditing every claim against evidence before it ships. Use when copy needs writing or rewriting, when a page says nothing specific, or when a draft's claims need checking before publication. Not for interface strings inside a product, not for documentation, and never authorization to publish or send what it produces.

Get a defensible answer out of a dataset — grain and denominators pinned, missing data accounted for, aggregates checked against their segments, and every number reproducible from raw input by a script. Use when asked what a dataset shows, when a number needs explaining or two numbers disagree, or before any finding from data is reported to someone who will act on it. Not for defining product metrics or instrumentation, not for building the pipeline that produced the data, and not for designi...

Investigate an open question properly — frame it as a decision, work from primary sources, sweep from several angles including the disconfirming one, and stop on a rule rather than on fatigue. Use when a question's answer will change what gets built or bought, when the material is unfamiliar or contested, or when someone asks for a recommendation with evidence behind it. Not for looking up a single fact you can confirm in one place, not for mapping the local codebase, and not for judging one ...

Verify documentation against its promises: validate source-report citations and schemas, or execute runnable guide commands in the stated environment. Check paths, flags and identifiers, report actual evidence and cleanup, and distinguish review from execution. Not a prose-quality review or a replacement for project tests.

Say what a product is for, which alternative it beats, and why — in one segment's own words, with every claim tied to something the product actually does today. Use when a homepage or deck says what the product is, when "who is this for" or "how is this different" has no crisp answer, when entering a new segment, or when sales keeps losing to one competitor. Not for writing the final copy, not for pricing, and not for deciding what to build next.

Make a page findable for a real query — match the intent behind it, structure the page around that intent, and clear the technical floor that decides whether it can be crawled and indexed at all. Use when a page is written for search, when traffic drops or a page is missing from results, when someone asks "how do we rank for X", or before publishing content meant to be found. Not for writing the copy itself, not for page speed work, and not for paid search or social distribution.

Judge whether a source can carry the weight you are about to put on it — trace it upstream to something primary, check its date and version, name who benefits if you believe it, test whether corroboration is actually independent, and cite it so a reader can reopen exactly what you read. Use before relying on a claim that changes a decision, when two sources disagree, when a number arrives without its method, or when writing citations. Not for running the overall investigation, and not for dec...

Write or repair documentation that stays true to the system it describes — README, setup guide, how-to, API reference, architecture explanation, release notes, runbook — by fixing the reader and the task first, then grounding every factual claim in code you actually read. Use when documentation is being written, restructured or found to be stale, or when a reader cannot get from the docs to a working result. Not for interface strings inside a product, not for persuasive or marketing copy, and...

Design an A/B test that can answer its question — hypothesis, randomization unit, power, duration, pre-registered analysis — and read the result honestly, including a null. Use when someone proposes testing a change, asks how long a test must run or whether a result is real, when a test is about to be stopped early, or when a flat result is being read as "no difference". Not for defining the metric itself (product-analytics), not for a change too small or too rare to power, and not for author...

Write a scope someone else can build from without asking you what you meant — problem, users, the flow end to end including its unhappy states, acceptance criteria phrased as observable behaviour, and explicit non-goals. Use when turning a settled problem into a brief, spec, PRD, epic or set of stories, or when repairing a ticket that is too vague to estimate or to check. Not for deciding whether the problem is real (product-discovery), not for ranking work (prioritization), and not for choos...

Choose what not to do and make the tradeoff legible — the constraint being spent, each candidate's cost and value with the evidence behind it, what is reversible, and what would change the answer. Use when a list is longer than the capacity, when asked what to cut or what ships first, or when a decision was made and nobody can reconstruct why. Not for deciding whether a problem is real (product-discovery), not for writing the scope of what wins (prd-and-stories), and not for committing the te...

Define a product metric so it means one thing — event, denominator, population, window — and check the instrumentation exists before anyone reports a number. Use when asked "how do we measure this", when a funnel or activation/retention/conversion metric is being defined, when two dashboards disagree, or before adding tracking to a feature. Not for choosing what to build (prioritization), not for designing an A/B test (experimentation), and not for general data analysis of a dataset that is a...

Find the real problem behind a feature request before anyone scopes a solution — whose job is stuck, what evidence exists already, and what observation would prove the assumption wrong. Use when a request arrives phrased as a solution ("add a dashboard", "we need notifications"), when a team is about to build on a belief nobody has checked, or when asked whether something is worth building at all. Not for writing the spec once the problem is settled, not for ranking work that is already under...

Prove a UI change actually renders and works — desktop and mobile, controls operated, console clean. Use before reporting any change to rendered UI as done, when asked whether a screen actually functions, or when checking someone else's frontend work. Not for judging whether a design is good, and not a substitute for tests you intend to keep.

Build and keep end-to-end suites that are worth their runtime — which journeys belong at this level, selectors that survive refactors, waiting on state instead of sleeping, per-spec data isolation, and flake triage that finds the cause. Use when adding or repairing an e2e suite, when specs are slow or intermittently red, or when deciding whether a case belongs here at all. Not for one-off checking that a change renders, not for unit or integration tests, and not for load testing.

Find where the time actually goes before changing anything — define the metric and workload, build a repeatable baseline with its spread, profile on the right axis, confirm the suspected hotspot by removing its work, then re-measure under identical conditions. Use when something is slow, when an optimization is about to be written from a hunch, or when a speedup is being claimed without comparable numbers. Not for reading code to guess what is expensive, not for micro-tuning with no measured ...

Turn a fixed bug into a test that fails on the old code and passes on the new one. Assert behavior at the cheapest useful level and compare old behavior without reverting unrelated work or leaving scratch files. Use after a fix or when recurring defects lack coverage; not for a new feature's test strategy or an environmental/cosmetic failure.

Find the cause of a failure by evidence — reproduce it, read what the system actually did, form hypotheses that predict something you have not looked at yet, bisect to the smallest failing case, fix where all callers route through, then re-run the original reproduction. Use when something is broken and the cause is not yet known, when a previous fix did not hold, or when an edit is about to be made because the code "looks wrong". Not for an outage still burning (mitigate first), not for a cau...

Write unit and integration tests that fail for the right reason — behaviour-level assertions, boundary values, the smallest honest double, deterministic setup and teardown. Use when adding tests for new code, pinning a bug before fixing it, or repairing tests that stay green while the code is broken. Not for deciding what to test or at which level, not for browser journeys, and not a way to call a change verified.

Decide what to test and at which level before any tests get written — enumerate failure modes by consequence, give each one the cheapest level that can actually observe it, and name what is deliberately left uncovered. Use when starting testing on a feature or a codebase, when asked for a test plan or why coverage sits where it does, or when a suite is large and still missing bugs. Not for writing the tests themselves, and not for proving a finished change works.

Secure an agent system as a permission surface — what authority each tool call runs under, where the confused deputy sits, which controls are enforced outside the model and which are only prompt text, and how far one bad call reaches. Use when granting an agent tools or credentials, wiring in MCP servers or subagents, reviewing an agent that acted beyond what the requester could have done, or before letting an agent touch a shared or production system. Not for wording the ingestion trust boun...

Attack and harden an existing auth surface — session fixation and rotation, token verification, horizontal and vertical privilege escalation, password reset and account recovery, MFA bypass. Use when reviewing login, session, token, reset, invite, impersonation or role-elevation code, when someone reports seeing another user's data or an account takeover, or when auth changes are about to ship. Not for designing the login mechanism or permission model in the first place (authentication, autho...

Judge dependency risk instead of reciting it — resolve the advisory to a real path through the lockfile, decide whether the vulnerable code is reachable in this codebase, and pick upgrade, override, removal or a written acceptance. Use when an audit or advisory alert fires, before adding a new dependency, when a lockfile change needs reviewing, or when someone asks whether a named CVE actually affects this project. Not for finding vulnerabilities in code you wrote, not for secret scanning, an...

Hunt the web failure classes that actually recur — broken access control, injection, XSS by output context, SSRF, unsafe deserialization and mass assignment, session and token handling, secrets leakage, file handling — as patterns to find in this codebase. Use when writing or reviewing request handlers, queries, URL fetches, templates, uploads or auth code, or when asked to check a web app for the common vulnerability classes. Not for design-stage modeling (threat-modeling), not infrastructur...

Keep credentials out of code, logs, bundles and history — one supply path, scoped per environment, rotatable on demand — and run the rotate-first response when one has already leaked. Use when adding or moving a key, token, connection string or signing secret, when a scanner or reviewer finds one committed, when a credential appears in logs or a client bundle, or when rotation is due. Not for deciding what a credential may access, and not for vulnerability advisories in dependencies.

Review a change or a codebase for security defects with a deliberate reading order — where bugs cluster, trace source to sink, confirm reachability, and write a finding someone can actually fix. Use when asked to security-review a pull request, feature or repository, or before shipping anything touching auth, money, tenancy, uploads or secrets. Not a scanner run (its output is leads), not design-stage threat modeling, and not a penetration test — nothing here authorizes touching a running sys...

Work out what is actually worth defending in this system — the trust boundaries data crosses, the assets behind them, what an attacker can already do, and the small number of threats that justify a control. Use when designing or changing a system's shape, before building auth, payments, uploads, file sharing or multi-tenancy, when adding an integration that crosses a boundary, or when asked whether a design is safe. Not for finding bugs in code that already exists (that is secure-code-review)...