yellinzero
@yellinzero
Public Skills
aico-worktree
by yellinzero
Create isolated git worktree for feature development. Handles directory selection, gitignore verification, project setup, and baseline test verification. Use this skill when: - Starting feature work that needs isolation from current workspace - Before executing implementation plans on a new branch - Want to work on multiple branches/features simultaneously - User asks to "create worktree", "isolate this work", "separate branch" - Need clean baseline before starting major changes Safety: ALWAYS verify worktree directory is gitignored before creating. Process: Check directory → Verify ignored → Create worktree → Run setup → Verify baseline tests
aico-backend-task-breakdown
by yellinzero
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
aico-backend-implement
by yellinzero
Execute backend 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 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/backend/tasks/ (story- or standalone-) - Read constraints.md and design spec before coding Flow: Read Task → Read Constraints → Execute Steps → Verify → Test → Update Status
aico-pm-story-acceptance
by yellinzero
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]
aico-subagent-driven
by yellinzero
Execute implementation plan by dispatching fresh subagent per task. Each task gets: Implementer → Spec Review → Quality Review. Two-stage review ensures both correctness and quality. Use this skill when: - Have implementation plan with multiple independent tasks - Want automated execution with quality gates after each task - Tasks are mostly independent (not tightly coupled) - User asks to "execute the plan", "run the tasks", "auto implement" Prerequisites: Must have plan from aico-frontend-plan, aico-backend-plan, or aico-*-task-breakdown skill. Process: For each task: Dispatch Implementer → Spec Review (passes?) → Quality Review (passes?) → Next task Review order: ALWAYS spec compliance first, THEN code quality.
aico-backend-plan
by yellinzero
Create or enhance backend 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 /backend.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: Types → DB → Repository → Service → API → Tests 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
aico-frontend-plan
by 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
aico-frontend-implement
by yellinzero
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
aico-frontend-task-breakdown
by yellinzero
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
aico-pm-brainstorming
by yellinzero
Guide users through structured dialogue to transform vague ideas into clear, actionable product concepts. Uses one-question-at-a-time approach with multiple choice options. Use this skill when: - User says "I have an idea", "I want to build", "let me think about" - User mentions "brainstorm", "explore ideas", "think through" - Requirements are vague, incomplete, or user seems unsure what they want - Need to explore problem space before jumping to solutions - Running /pm.plan but requirements are unclear or missing context - User asks "what should I build?", "how should this work?" Process: Ask ONE question at a time, prefer multiple choice, explore 2-3 approaches before settling.
aico-frontend-design
by yellinzero
Transform PRD or story into complete page/component designs with ASCII layouts, component specs, interaction flows, and frontend implementation prompts. Use this skill when: - User asks to "design the page", "design component", "create page design" - User mentions "page design", "component design", "UI design", "layout design" - Running /frontend.design command - PRD or story is ready and need visual/interaction design before implementation - Need to create design spec that frontend developer can implement from Prerequisites: Design system must exist at docs/reference/frontend/design-system.md Output: ALWAYS write design files to docs/reference/frontend/designs/{name}.md
aico-pm-user-story-writing
by yellinzero
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
aico-pm-clarification
by yellinzero
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.
aico-pm-acceptance-criteria
by yellinzero
Define clear, testable acceptance criteria using Given/When/Then (Gherkin) format that can be directly used for testing. Use this skill when: - User asks for "acceptance criteria", "AC", "test criteria", "done criteria" - User asks "how do we know it's done?", "what counts as complete?" - User story needs testable success conditions - QA needs test scenarios or test cases - Running /pm.plan and need to add AC to stories - Reviewing story and AC is missing or vague Format: Always use Given [context], When [action], Then [expected result] structure.
aico-pm-prd-writing
by yellinzero
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
aico-backend-init
by yellinzero
Initialize backend environment by creating constraints document from template. Use this skill when: - Running /backend.init command - User asks to "initialize backend", "setup backend environment" - Starting backend work and need to establish tech stack and conventions - Need to create docs/reference/backend/constraints.md
aico-frontend-init
by yellinzero
Initialize frontend environment by creating design system and constraints documents from templates. Use this skill when: - Running /frontend.init command - User asks to "initialize frontend", "setup frontend environment" - Starting frontend work and need to establish design system and constraints - Need to create docs/reference/frontend/design-system.md or constraints.md
aico-pm-init
by yellinzero
Initialize PM environment by creating constitution document from template. Use this skill when: - Running /pm.init command - User asks to "initialize PM", "setup product management", "create constitution" - Starting a new project and need to establish product constraints and domain info - Need to create docs/reference/pm/constitution.md for a new project
aico-code-review
by yellinzero
Request structured code review to catch correctness, security, performance, and readability issues. Reviews should happen early and often. Use this skill when: - Completing a task and need quality check - After major feature implementation - Before merging to main branch - When stuck and need fresh perspective on code - User asks for "code review", "review my code", "check my code" - Subagent-driven workflow needs spec compliance or quality review Review categories: Correctness, Tests, Security, Performance, Readability, Error Handling Severity levels: Critical (fix now), Important (fix before proceeding), Minor (note for later)
aico-frontend-style-extraction
by yellinzero
Extract design tokens (colors, typography, spacing, effects) from reference website or screenshot to create project design system. UNIQUE VALUE: Creates standardized design-system.md file with all design tokens extracted systematically. Use this skill when: - User shares reference website URL and wants to extract its style - User provides screenshot or image and asks to "extract design", "extract style" - Running /frontend.init and need to create design system from reference - User asks to "create design system", "extract colors", "extract typography" - Need to establish consistent design tokens before starting frontend work Methods: URL (via Playwright MCP screenshot) or direct screenshot analysis Output: ALWAYS write to docs/reference/frontend/design-system.md
aico-pm-competitor-analysis
by yellinzero
Research and analyze competitors with STRUCTURED output: feature comparison matrix, strengths/weaknesses analysis, and actionable recommendations. UNIQUE VALUE: Creates standardized competitor analysis document with feature matrix and strategic recommendations. Use this skill when: - User asks "what do competitors do?", "who are our competitors?" - User mentions competitor names or asks for product comparison - User asks for "competitor analysis", "market research", "competitive landscape" - Entering new market, feature area, or evaluating product direction - Need to understand competitive landscape before making product decisions - Writing PRD and need market context or differentiation strategy Output format: Feature comparison matrix + Strengths/Weaknesses + Actionable recommendations