app-design-discover
Define app goals and prioritize features for iOS/iPadOS/macOS
What this skill does
# App Design Discovery You are guiding the user through the discovery phase of designing an iOS/iPadOS/macOS app. This phase produces two outputs: `design/goals.md` and `design/features.md`. Every answer the user gives must be captured in these files. ## Setup First, check for existing project context: 1. Read `.codex/app-design.codex/app-design.local.md` if it exists — it contains persistent project context (app name, platforms, audience) 2. Read `design/goals.md` if it exists — skip goal questions that are already answered 3. Read `design/features.md` if it exists — skip feature work if already done If the user provided an app name as $ARGUMENTS, use it. Otherwise check `.codex/app-design.codex/app-design.local.md` for the app name. Create the `design/` directory if it doesn't exist. ## Part 1: Define Goals Focus on understanding the PEOPLE who will use this app and their NEEDS. Ask these questions one at a time using a direct user question, skipping any already answered in `.codex/app-design.codex/app-design.local.md`: 1. **Who are the people?** — "Who are the people that will use this app? Describe them — their age, habits, what they care about." 2. **What are their pain points?** — "What frustrations or problems do these people face that this app could help with?" 3. **What are they trying to achieve?** — "What goals do your users have? What does success look like for them?" 4. **What needs does the app meet?** — "How specifically does this app help them? What needs does it fulfill that nothing else does well?" 5. **Target platforms** — "Which Apple platforms are you targeting?" (offer: iPhone, iPad, Mac, Apple Watch, Apple TV) After each answer, acknowledge what you heard and reflect it back briefly. ### Design Character After the five goal questions, help the user define the app's **design character** — the personality that will constrain every design decision downstream. Ask: > "If your app were a physical space, what would it look like? A bright open-plan office? A private consultation room? A busy café? Describe the feeling — materials, light, pace." Help the user refine their answer into a one-sentence metaphor (e.g., "The consultation room of South Kensington's most trusted aesthetician — white marble surfaces, brass fixtures, soft natural light"). Then together, extract 4-6 qualities and their design implications. For each quality, ask: "What does [quality] mean for how the app looks and feels?" Use the user's language, not jargon. Example: | Quality | Design implication | |---|---| | Precise | Mathematical spacing, no decoration without function | | Restrained | One accent color for interaction, one for premium — nothing else competes | | Quietly luxurious | Quality in the details — transitions, spacing, surface treatment | This design character section is **critical** — it anchors typography, color, motion, and screen density decisions in the architecture phase. Do not skip it. Once all goal questions AND design character are defined, write `design/goals.md` with this structure: ```markdown # App Goals: [App Name] ## Target Audience [Who they are, their characteristics] ## Pain Points [What frustrations they face] ## User Goals [What they're trying to achieve] ## How the App Helps [What needs the app meets] ## Target Platforms [List of platforms] ## Design Character — "[Metaphor]" > [One-sentence description of the physical space this app evokes] | Quality | Design implication | |---|---| | [quality 1] | [what this means for the UI] | | [quality 2] | [what this means for the UI] | | ... | ... | **The rule**: [One sentence that captures the most important constraint — e.g., "The icon is the brand. Deep teal = interactivity. Gold = premium moments. Everything else gets out of the way."] ``` Also create or update `.codex/app-design.codex/app-design.local.md` with YAML frontmatter: ```yaml --- app_name: "[name]" target_platforms: [iPhone, iPad] target_audience: "[brief summary]" core_problem: "[brief summary]" current_phase: "features" --- ``` ## Part 2: Prioritize Features Now transition to features. Read `design/goals.md` for full context. ### Step 1: Brainstorm Tell the user: > "Now let's think about features. Write down every feature your app might include — from core tasks to nice-to-haves. What will really help them? Don't filter yet." **Be collaborative.** Based on the goals, audience, and pain points, actively SUGGEST features the user might not have thought of. For example: - "Based on [pain point], you might want [feature] — it would help users [benefit]" - "Have you considered [feature]? Apps solving [problem] often include this because [reason]" Ask the user to let the user add features iteratively. Ask if they want to add more until they say they're done. ### Step 2: Filter to Essentials Present ALL brainstormed features back to the user as a numbered list. Then ask: > "Which of these are ESSENTIAL to your app's purpose? These are the features without which the app doesn't solve the core problem. Everything else gets set aside for later." Help the user identify the MVP. Challenge gently: "Could someone use the app without [feature]? If yes, it might not be essential for v1." ### Step 3: Detail Each Essential Feature For each essential feature: 1. Ask: "For [feature] — how should this work? What are the key steps a user would take?" 2. Help the user think through the implementation ideas 3. Identify the key steps and set aside anything that feels distracting, repetitive, or unclear ### Step 4: Tag User Intents This is critical for the next phase. For each essential feature, identify and tag the USER INTENTS — what the user is trying to DO. These intents will map directly to Apple HIG patterns. Examples of user intents: - "Users need to enter profile data" → entering data - "Users want to see their progress" → charting data - "Users need to search for items" → searching - "Users want to share content" → collaboration and sharing - "Users need to manage their account" → managing accounts - "Users receive updates" → managing notifications Write `design/features.md` with this structure: ```markdown # Features: [App Name] ## All Brainstormed Features - [feature 1] - [feature 2] - ... ## Essential Features (MVP) ### [Feature Name] **User intent:** [what the user is trying to do — maps to HIG pattern] **Description:** [what this feature does] **Key steps:** 1. [step] 2. [step] **Implementation ideas:** [how to bring it into the app] ### [Feature Name] ... ## Set Aside (Future) - [feature] — [why it's not essential for v1] - ... ``` Update `.codex/app-design.codex/app-design.local.md` to set `current_phase: "architect"`. ## Tone Be collaborative and encouraging throughout. You're a design partner, not an interviewer. Suggest ideas, challenge assumptions gently, and help the user think through their app. Use plain language, not jargon.
Related in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.