Owns the SwiftUI view layer: declarative views, view modifiers, NavigationStack, the Observation framework, accessibility traits, and the UIKit/SwiftUI bridge. Engage when a view is over-rebuilding, navigation state is misbehaving, or when picking between SwiftUI-native patterns and a UIKit fallback.
Owns internal developer tooling: CLI scripts, codegen, Storybook / component sandboxes, design-token sync, env management, and one-off automation that saves the team from manual drudgery. Engage when a recurring manual task needs scripting or when developer experience is dragging on velocity.
Owns the TypeScript type system, strict-mode configuration, schema-driven validation (zod, valibot, io-ts), and shared types across mobile/server in monorepos. Engage for tsconfig design, branded types, generic API helpers, type-level refactors, or when runtime data shape mismatches the compile-time type.
The User Researcher plans and runs user research: interviews, usability tests, diary studies, surveys, and beta program analysis. Maintains personas and Jobs-To-Be-Done framings. Use this agent when a decision needs user evidence, when a flow needs validation before build, when personas need updating, or when a beta…
The UX Designer owns interaction design, information architecture, accessibility integration, onboarding flows, and navigation patterns. Use this agent for screen-level UX specs, navigation model decisions (tabs vs drawer vs stack), onboarding flow design, empty-state design, or any screen where 'how should this feel…
The Visual Design Director owns the visual identity of the app: design tokens (color, typography, spacing, elevation, radius, motion), the component spec library, and the visual quality bar. Use this agent for design-system token decisions, component spec authoring, visual consistency reviews, dark-mode design, and…
Brownfield onboarding for an existing mobile-app codebase. Audits PRDs, ADRs, stories, UX specs, and architecture docs for compatibility with this template's review skills, classifies gaps by impact, and produces a numbered migration plan. Use when joining a project mid-flight or upgrading from an older template…
Creates an Architecture Decision Record (ADR) documenting a significant technical decision — its context, alternatives, decision, consequences, and PRD requirements addressed. Every major mobile-architecture choice should have an ADR. Framework-version-aware: cross-references the framework reference docs to flag…
Validates the architecture against all PRDs. Builds a traceability matrix from PRD requirements to ADRs, identifies coverage gaps, detects cross-ADR conflicts, and produces a PASS/CONCERNS/FAIL verdict. Run after Required ADRs are written; rerun whenever PRDs change. Read-only — never edits files.
Audits app assets for naming conventions, file size budgets, format standards, app icon completeness, splash screens, and store-listing imagery. Identifies orphans (asset on disk but never referenced) and missing references (referenced but missing).
Generates per-asset visual specifications and AI-generation prompts from PRDs and the design bible. Produces structured spec files and updates a master asset manifest. Use after design bible is approved and a UX spec or PRD identifies assets to produce. Output: design/assets/ .md plus design/assets/manifest.md.
Analyze pricing tiers, paywall configs, A/B test variants, and feature-flag values for outliers, broken funnels, dominant variants, and monetization imbalance. Use after editing pricing, paywall copy, or any growth-experiment config.
Guided ideation for a mobile app — from a blank page (or a single hint) to a structured concept doc covering target user, core job-to-be-done, MVP scope, and primary metric. Use when starting a new app or when an existing pitch needs to be tightened into a concept.
Author a structured bug report from a description, OR analyze code/logs to derive likely bugs. Captures reproduction steps, severity, device matrix, expected vs actual, and attachments. Use after a manual QA failure or when the user describes a defect.
Read all open bugs, re-evaluate priority and severity, surface systemic trends, and assign each to a sprint or backlog. Run at sprint start or when the open bug count grows beyond comfort.
Auto-generate a changelog from git commits, sprint data, and design docs. Produces both internal (engineering-facing) and user-facing (release-notes) versions for a given release window.
Architectural and quality review of one or more files. Verifies coding standards, SOLID, testability, mobile anti-patterns, and ADR compliance. Use after /dev-story and before /story-done.
Read-only audit that scans all PRDs against the entity registry and detects cross-doc inconsistencies — same entity with different values, same configurable value with different defaults, same formula with different variables. Use when multiple PRDs are in flight to catch drift before /review-all-prds runs.
Audits PRD-specified content counts (screens, copy strings, images, supported locales, push categories, onboarding steps) against what is actually implemented. Identifies what is planned vs. what is built. Read-only.
Section-by-section authoring of the master architecture doc for the app. Reads all PRDs, systems index, existing ADRs, and the framework reference docs to produce a complete blueprint and a Required ADR list. Framework-version-aware: flags knowledge gaps and validates against the pinned framework. Run after…
Produces a flat, immediately-actionable rules sheet — do this, never do that, per system and per layer — extracted from accepted ADRs, technical preferences, and framework reference docs. More directly usable than ADRs for day-to-day implementation. Run after /architecture-review passes.
Translates approved PRDs and architecture into epics — one epic per architectural module or major system. Each epic captures scope, governing ADRs, framework risk, and untraced requirements. Run after /architecture-review passes; do NOT decompose into stories — run /create-stories per epic afterward.
Decomposes a single epic into implementable story files. Each story embeds its TR-ID, governing ADR, acceptance criteria, story type, and test-evidence path. Run after /create-epics for each epic, in dependency order. Stories are what developers pick up — epics are what architects define.
Prepare a day-one patch for launch. Scopes, prioritizes, implements, and QA-gates a focused patch addressing issues found between gold master and public launch. Treats the patch as a mini-sprint with its own QA gate and rollback plan.
★not rated 42▲
+1 5mo agoA56 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: