sarmakska

systematic-debugging

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.

think-before-coding

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.

brainstorm-spec

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.

compact-and-offload

Use when the context budget is near full (level compact) or before a planned compaction, to summarise the session and offload durable facts to slipstream memory so nothing important is lost when context is trimmed.

context-budget

Use periodically during a long session to check the approximate context budget and decide whether to keep going, switch to scoped reads, or compact, so you rarely hit the context limit.

finishing-a-branch

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.

receiving-code-review

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.

requesting-code-review

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.

scoped-read

Use before opening any source file in a project that has a slipstream map, to read the compact index and pull a single symbol or line range instead of the whole file, protecting the context budget.

subagent-driven-development

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.

test-driven-development

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.

using-slipstream

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.

verification-before-completion

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.

write-plan

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.

writing-skills

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.

frontend-design-system

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.

frontend-hero-section

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.

frontend-marketing-sections

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.

frontend-motion

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.

analytics-events

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

analytics-plausible

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

analytics-web-vitals

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.

auth-oauth

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

Data & Documents Listed

auth-password-reset

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.

auth-rbac

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

auth-session

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

backend-error-handling

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

backend-hono-api

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.

backend-openapi

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

backend-rate-limit

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

backend-zod-validation

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

cloudflare-d1

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

cloudflare-kv

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.

cloudflare-pages

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

cloudflare-r2

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

cloudflare-secrets

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

cloudflare-worker

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

frontend-component-library

Use when starting a UI and you want reusable accessible primitives: create a small set of reusable, accessible UI primitives the rest of the site composes from.

frontend-dark-mode

Use when adding a light/dark theme toggle: add a persisted light and dark theme toggle driven by a CSS class on the root element.

frontend-forms

Use when building forms that need validation and accessible errors: build forms with client side validation and accessible error messaging.

frontend-responsive-layout

Use when laying out a marketing or landing page that must work on mobile and desktop: compose a responsive hero, features and footer layout that holds up from mobile to desktop.

frontend-router

Use when a front end needs multiple pages and routing: install a router and define the page routes for a multi page front end.

frontend-tailwind

Use when adding Tailwind CSS to a Vite project: wire Tailwind CSS into a Vite project for utility first styling.

frontend-vite-react

Use when starting a new React single-page front end: create a Vite single page app with React and TypeScript as the front end foundation.

git-conventional-commit

Use when committing work and you want a clean, changelog-shaped history: record work as small conventional commits so history reads as a changelog.

git-feature-branch

Use when starting a new unit of work that should not land on the default branch: create a focused feature branch off the default branch for each unit of work.

git-init-repo

Use when starting version control in a new project: initialise a Git repository with a sensible default branch and ignore file.