slipstream

Use when several pieces of work are genuinely independent and can run at once, to fan them out across parallel agents instead of doing them in sequence. Cuts wall-clock time and keeps each strand in its own clean context.

Use when a written plan exists and you are about to build it in the current session, to work it task by task with a checkpoint after each. Keeps execution honest against the plan instead of drifting into a freehand build.

Use when work needs its own isolated checkout — parallel strands that would fight over files, or a risky change you want quarantined from the main tree. Gives each strand a real working directory on its own branch without re-cloning.

Use whenever the user says "use slipstream", "use superpowers", or starts any task in a project that has slipstream. A hard, always-on discipline that forces scoped reads over whole-file reads to save tokens, recalls memory before acting, and records what is durable every turn so memory grows constantly.

Use when a site needs to look designed rather than defaulted, before building sections: establish a cohesive design system of type scale, spacing, colour, radius and shadow tokens so every component shares one premium visual language.

Use when building the top of a landing page, to produce a high-impact hero with confident display type, a clear single call to action and balanced composition, the kind of opening a polished marketing site leads with.

Use when filling out a landing page below the hero, to build the polished marketing sections a premium site is made of: a feature grid, a logo or social-proof strip, a testimonial and a closing call to action.

Use when a site needs the smooth entrance and scroll-reveal animations that make a page feel alive and crafted, to add tasteful motion with a real animation library rather than ad-hoc transitions.

Use when implementation is complete and verified and the work needs to land, to choose how to integrate it. Walks the close-out from a clean green suite to a recorded memory of what changed, then merge, pull request or cleanup as the situation calls for.

Use when acting on code-review feedback, especially when a comment seems unclear or wrong. Requires verifying each point technically before changing anything, so you fix real issues and push back on mistaken ones instead of agreeing performatively.

Use when a feature or fix is complete and verified, before merging, to get a focused review. Prepares a tight diff and the context a reviewer needs so the review finds real problems instead of drowning in noise.

Use when executing a multi-step plan whose tasks are independent, to dispatch a fresh agent per task and review between tasks. Keeps each task in a clean context, parallelises independent work, and gates each result before the next begins.

Use before writing or changing any feature or bugfix code, to drive the change with a failing test first. Red, green, refactor. The discipline that proves the code does what was asked and keeps it proven as the project grows.

Use before claiming any work is done, fixed, passing or shipped, and before committing or opening a pull request. Requires running the real checks and quoting the real output, so a success claim is backed by evidence rather than hope.

Use when creating or editing a slipstream skill, to produce one that loads cleanly and earns its place. Covers the frontmatter contract, the trigger-shaped description, the required body sections and the verification gate, so the skill validator passes and the skill is actually useful.

Use at the start of a non-trivial feature or change, before planning or coding, to refine a vague request into a short written spec through focused questions. Turns "build me X" into an agreed scope, so the plan and the code that follow do not chase a moving target.

Use when a bug, test failure, or unexpected behaviour appears, to find the root cause before changing code instead of guessing fixes. A four-phase process that stops the hallucinated-fix loop and the token waste of trying patches at random.

Use before writing or changing code on any non-trivial task, to surface hidden assumptions, keep the change minimal and surgical, and define how you will verify success. The discipline that stops over-engineering and wasted tokens before they happen.

Use after a spec is agreed and before coding a multi-step change, to break the work into small, independently verifiable tasks with exact files and a check per task. A plan an agent can execute without re-deciding scope, and that survives compaction.

This skill has an invalid name, an invalid category, and no required sections.

This shipping skill omits the required verification gate and must be rejected.

A minimal but complete skill used to prove the loader accepts valid Claude Code SKILL.md input.

Use when you need product analytics: track the handful of events that actually matter, such as sign up and purchase.

Use when adding privacy-friendly site analytics: add a lightweight, cookieless analytics script that respects visitor privacy.

Use when you want to measure real-user performance (Core Web Vitals): measure and report Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.

Use when adding social or third-party sign in: add a third party OAuth provider such as GitHub or Google for social sign in.

Use when users need to reset a forgotten password: let users reset a forgotten password with a single use, time limited token sent by email.

Use when routes or actions must be gated by user role: gate routes and actions behind roles so only authorised users can perform them.

Use when issuing authenticated session cookies: issue HTTP only, secure, same site session cookies for authenticated requests.

Use when an API needs consistent error responses: catch unhandled errors centrally and return consistent JSON error envelopes.

Use when scaffolding an HTTP API that runs on Node and the edge: create a Hono based HTTP API that runs on both Node and edge runtimes.

Use when consumers need an OpenAPI spec for the API: generate an OpenAPI specification from the API routes and serve it for consumers.

Use when a public endpoint needs abuse protection: protect public endpoints with a token bucket rate limiter keyed by client identity.

Use when API input must be validated and rejected if malformed: add schema validation middleware so every endpoint rejects malformed input with a 400.

Use when the app needs a SQLite database on Cloudflare: create a Cloudflare D1 SQLite database and run an initial migration.

Use when you need a low-latency edge cache or key-value store: create a Workers KV namespace and use it as a low latency cache.

Use when deploying a static front end to Cloudflare Pages: publish a built static front end to Cloudflare Pages.

Use when the app needs object storage on Cloudflare: create an R2 object storage bucket and bind it to a Worker.

Use when a Worker needs secret values kept out of source: store sensitive values as Worker secrets rather than committing them.

Use when building an API or handler at the Cloudflare edge: create a Cloudflare Worker with Wrangler that serves an API at the edge.