Section-by-section authoring of the Design Bible — the visual identity spec that gates all visual production. Defines tokens for color, type, space, radius, elevation, motion, plus app icon and splash spec. Run after /brainstorm and before /map-systems or any UX work.
Reviews any design document — concept doc, design bible, flow spec, or other architecture-adjacent design artefact — for completeness, internal consistency, and implementability. Detects PRDs and routes them to /prd-review. Use this when the doc is NOT a PRD; for PRD validation, use /prd-review directly.
Section-by-section authoring of a Product Requirements Doc for a single mobile-app system. Reads concept, systems index, dependencies, and registry; walks the user through each PRD section collaboratively; writes incrementally to file. Use when starting a new PRD or filling gaps in an existing one.
Read a story file and implement it end-to-end. Loads PRD requirement, governing ADR, control manifest, and routes to the right framework specialist (RN/Flutter/iOS/Android). Use when a story has passed /story-readiness and is ready to be built.
Estimates effort for a story, batch of stories, or epic by analyzing complexity, dependencies, historical velocity, and risk factors. Produces a structured estimate with confidence levels. Use before sprint planning or when sizing a new request.
Extracts patterns from existing source code into a structured system.md file — naming, state shape, navigation pattern, error handling, and component composition. Used as the first step inside /reverse-document and on its own when the team wants to capture undocumented conventions in a brownfield project.
Validate readiness to advance between development phases. Synthesizes QA, perf, security, asset, balance, and localization verdicts into a single PASS/CONCERNS/FAIL with specific blockers and required artifacts. Use when asking 'are we ready to advance?'.
Analyzes the project's current state and the user's question, then recommends the single best next skill or step. Use when the user says 'what should I do next', 'I'm stuck', or 'I don't know where to go'.
Emergency fix workflow that bypasses normal sprint process while keeping a full audit trail. Creates the hotfix branch, tracks approvals, ensures backport to main, and produces release-store-ready notes. Use only for production-impacting S1 bugs or critical store-rejection issues.
Full launch readiness across departments: code, content, store listings, marketing, community, infra, legal, privacy (ATT, Data Safety), accessibility, and sign-offs. Run before every public launch.
Decomposes the app concept into discrete systems, maps dependencies, prioritizes design order by upstream-first, and writes the systems index. Use after /brainstorm and /setup-framework, before authoring any individual PRD.
Comprehensive milestone progress review — feature completeness, quality metrics, risk assessment, and go/no-go recommendation. Use at milestone checkpoints (alpha, beta, RC) or when evaluating readiness for a milestone deadline.
Generates a contextual onboarding doc for a new contributor based on their role (engineer, designer, PM, QA, etc.). Summarizes app concept, architecture, conventions, current sprint, and the contributor's likely first tasks. Use when bringing someone new onto the project or when a contributor switches roles.
Generate user-facing patch notes from git history, sprint data, and the internal changelog. Translates engineering language into clear, store-appropriate user communication. Respects App Store / Play Store character limits.
Structured performance profiling: cold/warm start, frame time, memory, network, app size, battery. Identifies bottlenecks against budgets, recommends optimizations with priority. Use during Polish or before a release.
PRD-specific validation gate: checks required PRD sections, TR-ID requirement IDs, GIVEN-WHEN-THEN acceptance criteria, dependency-graph bidirectionality, and traceability readiness for engineering hand-off. Use ONLY for PRDs (design/prd/.md); for any other design doc, use /design-review. Run in a fresh session …
Read-only audit that classifies the project's current stage (concept / design / architecture / sprint / beta / live-ops), identifies missing artifacts, and recommends the next sensible skill. Use when the user asks 'where are we', 'what stage are we in', or after pulling an unfamiliar branch.
When a PRD is changed, scans all ADRs, dependent PRDs, stories, and the traceability index to identify what is now potentially stale. Produces a change-impact report and walks the user through resolving each downstream artifact. Use immediately after editing a PRD that other artifacts reference.
Rapid prototyping workflow that deliberately skips standards to validate a risky concept fast. Produces throwaway code and a structured prototype report. Use to retire the riskiest assumption from /brainstorm before committing to architecture, or to validate a novel mechanic before adding to the sprint.
Generate a QA test plan for a sprint or feature. Reads PRDs and stories, classifies stories by test type (Logic/Integration/Visual/UI/Config), and produces a plan covering automated tests, manual cases, smoke scope, device matrix, and sign-off rules. Run before sprint kickoff or when starting a major feature.
Lightweight design spec for small changes — copy tweaks, single-screen polish, parameter adjustments — when a full PRD is overkill. Produces a Quick Design Spec that embeds directly into a story file. Use when a change is too small to justify a new PRD section but still needs a written spec for traceability.
Map test coverage to PRD critical paths, identify fixed bugs without regression tests, flag coverage drift from new features, and maintain tests/regression-suite.md. Run after a bug fix or before a release gate.
Pre-release validation: build verification, certification (App Store / Play Console), store metadata, screenshots, privacy nutrition labels, Play Data Safety, version numbering. Narrower than /launch-checklist — focused on the build and store submission.
★not rated 42▲
+1 5mo agoA51 tokens
originalMIT
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: