@yellinzero

Create or enhance frontend tasks with detailed implementation steps. Supports TWO modes: MODE A: Enhance existing task (add detailed steps to task in file) MODE B: Create new standalone task file (can contain single or multiple tasks) IMPORTANT: This skill creates MICRO-LEVEL atomic steps, NOT macro architecture plans. For architecture planning or feature scoping, use EnterPlanMode instead. Use this skill when: - Running /frontend.plan command - User asks for "atomic steps", "step-by-step plan with verification" - Have a specific task and need implementation steps - User wants to create a standalone task file (not from story) - Need granular steps: Setup (create files) → Implementation (write code) → Test (verify) DO NOT use for: - Architecture planning (use EnterPlanMode) - General development planning - Feature scoping or estimation Output: - MODE A: Update specific task section in file with Implementation Steps - MODE B: Create new standalone-{name}.md file with one or multiple tasks

Transform requirements into well-structured User Stories using "As a [user], I want [goal], So that [benefit]" format with Given/When/Then acceptance criteria. Use this skill when: - User asks to "write user story", "create story", "add story" - User mentions "user story", "backlog item", "story" - Running /pm.plan and need to break PRD into implementable stories - Creating backlog items for development team - Need to formalize a requirement into standard story format - Converting feature request into actionable story with acceptance criteria Output: ALWAYS write story files to docs/reference/pm/stories/{story-name}.md

Resolve requirement ambiguities through STRUCTURED questioning: one question at a time, with recommended options and reasoning. UNIQUE VALUE: Prevents overwhelming users with multiple questions. Provides expert recommendations for each decision. Use this skill when: - Running /pm.clarify command - User says "unclear", "not sure what this means", "confused about" - User asks "what does X mean?", "how should X work?", "can you clarify?" - Requirements have conflicting or inconsistent details - Stories are missing acceptance criteria or have gaps - Need to fill information gaps BEFORE development can proceed Process: Ask ONE question at a time (max 5 per session), provide recommended option with reasoning. DO NOT ask multiple questions at once - this overwhelms users.

Execute frontend task implementation with TDD. Read task file, execute steps, verify each, update status. Use this skill when: - User asks to "implement task/plan", "start implementation", "execute plan", or "start coding" - Have task file (story-* or standalone-*) ready to execute - User asks to "use TDD", "write test first", or "test-driven" - User asks to "write tests", "add tests", "create tests" - Fixing UI bugs (write failing test first) TDD Iron Law: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST TDD Cycle: RED (failing test) → Verify fails → GREEN (minimal code) → Verify passes → REFACTOR Prerequisites: - Task file in docs/reference/frontend/tasks/ (story-* or standalone-*) - Read design-system.md, constraints.md, design spec before coding Flow: Read Task → Read Constraints → Execute Steps → Verify → Test → Update Status

Verify and close stories after frontend/backend tasks are completed. Check ALL related task files, update story acceptance criteria checkboxes. UNIQUE VALUE: Ensures BOTH frontend AND backend tasks are verified before closing story. Prevents premature story closure. Use this skill when: - Frontend or backend notifies "task completed, please verify" - User asks to "verify story", "accept story", "close story", "mark story done" - Need to check if a story can be marked as complete - User asks "is story X done?", "can we close story X?" CRITICAL: Must check BOTH frontend tasks (docs/reference/frontend/tasks/) AND backend tasks (docs/reference/backend/tasks/) before closing. Output: Update story file checkboxes from `- [ ]` to `- [x]`

Break down PM story into organized tasks in a single file following LAYERED ARCHITECTURE order: Types → Database → Repository → Service → API → Tests. UNIQUE VALUE: Creates single task file (story-{name}.md) containing all tasks for a story. Tasks are ordered by backend architecture layers. Use this skill when: - Running /backend.tasks command - User asks to "break down story", "create backend tasks", "split into tasks" - Have story at docs/reference/pm/stories/ and need organized task breakdown - Need tasks ordered by backend architecture layers (not random order) - Starting backend work and want organized task list Task order is CRITICAL: Types → Database → Repository → Service → API → Tests Output: Create single file docs/reference/backend/tasks/story-{name}.md with all tasks

Break down PM story into organized tasks in a single file following UI DEVELOPMENT order: Setup → Static UI → Dynamic Logic → Interactions → Testing. UNIQUE VALUE: Creates single task file (story-{name}.md) containing all tasks for a story. Tasks are ordered by UI development layers. Use this skill when: - Running /frontend.tasks command - User asks to "break down story", "create frontend tasks", "split into tasks" - Have story at docs/reference/pm/stories/ and need organized task breakdown - Need tasks ordered by UI development layers (not random order) - Starting frontend work and want organized task list Task order is CRITICAL: Setup → Static UI → Dynamic → Interactions → Tests Output: Create single file docs/reference/frontend/tasks/story-{name}.md with all tasks

Create comprehensive Product Requirements Documents (PRD) that define what to build and why, focusing on goals, scope, user stories, and success criteria without implementation details. Use this skill when: - User asks to "write a PRD", "create PRD", "write requirements document" - User mentions "requirements document", "product requirements", "product spec" - Running /pm.plan command to create version planning document - Starting a new product, major feature, or initiative that needs formal requirements - Need to document goals, scope, user stories, functional requirements, and success criteria Output: ALWAYS write PRD files to docs/reference/pm/versions/{version-name}.md