Luis85

building-canvas

Builds or expands an Obsidian canvas by reading vault structure and placing linked notes as nodes. Use when the user asks to create a canvas, build a visual map, or visualize note connections as a diagram.

brainstorming

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

building-evidence-based-personas

Use when creating personas, proto-personas, or empathy maps, deciding whether a persona is research-based or an assumption, separating user goals from tasks, or when tempted to generate a persona with AI. For UX designers and product managers modeling who the user is.

defining-jobs-to-be-done

Use when applying Jobs-to-be-Done, writing job stories or job statements, running a switch interview, mapping forces of progress, building a job map, or understanding why customers switch to or abandon a product. For product managers and UX designers modeling customer motivation and the progress users are trying to make.

dispatching-parallel-agents

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

executing-plans

Use when you have a written implementation plan to execute in a separate session with review checkpoints

finishing-a-development-branch

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

framing-the-opportunity

Use when starting discovery on a problem, writing a problem statement, defining the outcome to pursue, turning research into "How Might We" questions or point-of-view statements, or when a team is jumping to solutions before the problem is understood. For product managers, UX designers, and requirements engineers framing the problem space.

improve-codebase-architecture

Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.

mapping-customer-journeys

Use when creating a customer journey map, experience map, or service blueprint — visualizing a user's end-to-end experience across phases, plotting emotions and pain points, or mapping the frontstage/backstage processes behind touchpoints. For UX designers and product managers modeling the experience and finding opportunities.

mapping-discovery-assumptions

Use when an idea or solution rests on untested beliefs, when deciding what to research or test next, when prioritizing risks by importance and evidence, or when running an assumptions, desirability/feasibility/viability, or riskiest-assumption-test workshop. For product managers, UX designers, and requirements engineers de-risking before building.

mapping-impact-to-outcomes

Use when connecting features or deliverables to business goals, building an impact map, writing OKRs, creating an outcome-based roadmap, or cutting features that don't serve a measurable outcome. For product managers and requirements engineers linking work to results and avoiding the feature factory.

planning-discovery-interviews

Use when planning or writing a discovery interview guide, preparing to talk to users or customers, designing a contextual inquiry or field/diary study, deciding how many people to interview, or reviewing interview questions for bias. For UX designers and requirements engineers running generative research. Also covers when a survey is the wrong tool.

prioritizing-with-evidence

Use when prioritizing features, requirements, or a backlog/roadmap — applying MoSCoW, RICE, Kano, WSJF, or opportunity scoring, or choosing which prioritization method fits. For product managers and requirements engineers sequencing work by evidence and outcome rather than opinion.

receiving-code-review

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

requesting-code-review

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

running-product-discovery

Use when a product manager, requirements engineer, or UX designer is starting or running product discovery — understanding a problem space, deciding what to build, de-risking an idea, or kicking off research before committing to a solution, or when unsure which discovery skill to reach for. Start here to orient the team.

story-mapping-the-solution

Use when building a user story map, planning releases, finding a minimal viable release or walking skeleton, or turning a backlog into a visual end-to-end narrative. For the product trio shaping a solution into shippable slices after the problem is understood.

subagent-driven-development

Use when executing implementation plans with independent tasks in the current session

synthesizing-discovery-research

Use when turning raw interview notes, transcripts, or field observations into themes and insights — affinity mapping, thematic analysis, coding qualitative data, building a research repository, or using AI to help analyze research, especially when AI assistance risks fabricated quotes or synthetic findings. For UX designers and requirements engineers.

systematic-debugging

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Testing & QA Listed

tdd

Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.

Testing & QA Listed

test-driven-development

Use when implementing any feature or bugfix, before writing implementation code

using-git-worktrees

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

using-superpowers

Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

verification-before-completion

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

writing-plans

Use when you have a spec or requirements for a multi-step task, before touching code

writing-requirements

Use when writing user stories, acceptance criteria, or non-functional requirements — applying INVEST, splitting a large story, writing Given/When/Then scenarios, defining Definition of Ready/Done, or specifying measurable quality attributes. For requirements engineers and product owners turning validated discovery into buildable, testable specs.