d0whc3r

Use when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, testing accessibility (axe-core), file uploads/downloads, date/time mocking, WebSockets, geolocation, permissions, multi-tab/popup flows, mobile/responsive layouts, touch gestures, GraphQL, error handling, offline mode, multi-user collaboration, third-party services (payments, email verification), console error monitoring, global setup/teardown, test annotations (skip, fixme, slow), test tags (@smoke, @fast, @critical, filtering with --grep), project dependencies, security testing (XSS, CSRF, auth), performance budgets (Web Vitals, Lighthouse), iframes, component testing, canvas/WebGL, service workers/PWA, test coverage, i18n/localization, Electron apps, or browser extension testing. Covers E2E, component, API, visual, accessibility, security, Electron, and extension testing.

Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.

Generate a custom checklist for the current feature based on user requirements.

Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.

Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.

Execute the implementation planning workflow using the plan template to generate design artifacts.

Create or update the feature specification from a natural language feature description.

Convert existing tasks into actionable, dependency-ordered GitHub issues for the feature based on available design artifacts.

Execute the implementation plan by processing and executing all tasks defined in tasks.md

Create or update the feature specification from a natural language feature description.

Convert existing tasks into actionable, dependency-ordered GitHub issues for the feature based on available design artifacts.

Make the product documents that `/speckit.product.*` commands generate read like a person wrote them, not a model. Use this skill whenever a generated `product/00-info.md`, `10-spec.md`, `20-plan.md`, or `30-design.md` reads robotic, formulaic, or "AI-generated"; whenever the user asks to humanize, naturalize, de-slop, soften, or polish product prose; right after running a `/speckit.product.*` command when the output feels stiff; and when authoring the product commands or the humanization guide. The practices themselves live in the shipped `templates/humanization-guide.md`; this skill is the contributor-side tool that applies and maintains them. Reach for it even when the user does not say the word "humanize" but clearly wants the product docs to sound human.

Keep the user-facing extension docs (the wiki under docs/, the public website under web/, plus the root README and CHANGELOG) in sync with what the extension actually does. Invoke whenever someone asks to update the docs, sync the wiki, refresh the website, audit docs for drift, document a new command, or after any change under commands/, templates/, extension.yml, or catalog.json. Use it before merging structural changes, even if the user only said 'update the docs' in passing. It writes for the person who USES the extension: what each command does, how to run it, what it produces, and how the pieces fit together. It never documents how the repo is built or released; that lives in CONTRIBUTING.md.

Keep the user-facing extension docs (the wiki under docs/, the public website under web/, plus the root README and CHANGELOG) in sync with what the extension actually does. Invoke whenever someone asks to update the docs, sync the wiki, refresh the website, audit docs for drift, document a new command, or after any change under commands/, templates/, extension.yml, or catalog.json. Use it before merging structural changes, even if the user only said 'update the docs' in passing. It writes for the person who USES the extension: what each command does, how to run it, what it produces, and how the pieces fit together. It never documents how the repo is built or released; that lives in CONTRIBUTING.md.

Add a community extension to the Spec Kit catalog from a GitHub issue submission. USE FOR: processing extension submission issues, validating catalog entries, updating catalog.community.json and docs/community/extensions.md, creating PRs. DO NOT USE FOR: creating new extensions from scratch, or first-party extension work.

How to add and maintain shadcn/ui components in web-review (Astro + Tailwind v4) WITHOUT React. Components are vanilla .astro files using cva + cn; interactive ones use small delegated vanilla JS instead of Radix. shadcn tokens are mapped onto the existing axi theme, so dark mode is automatic (no `dark:` variants). Use when adding a shadcn component to web-review, porting a component from ui.shadcn.com, editing src/components/ui/, touching the theme tokens in src/styles/global.css, or whenever the shadcn CLI wants to emit .tsx files.