idea2product-agent-kit

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

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

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

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

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

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

Guide a user through the full idea-to-product pipeline from initial idea through strategy, product, architecture, delivery, and outcome review; choose the next step from state, invoke the matching P1-P10 skill, request gates when needed, and keep the user oriented.

Capture a real product or business idea as a falsifiable hypothesis, clarify the user, frequency, quantified loss, workaround, urgency, do-nothing cost, risks, and stop conditions, then initialize assumptions and risks for downstream strategy work. Use when the user explicitly asks for idea2product-P1-idea-expansion, P1, phase 1, or this step of the idea-to-product pipeline.

Review real outcomes after release, distinguish product-market-fit signal from launch noise, decide continue, scale, iterate, pivot, pause, or retire, and update assumptions, risks, decision log, PRD, or ADRs rather than only writing a retrospective. Use when the user explicitly asks for idea2product-P10-outcome-review, P10, phase 10, or this step of the idea-to-product pipeline.

Translate an approved strategy into product discovery: target user, problem statement, JTBD, value proposition, business model, boundaries, product hypotheses, customer-discovery interview plan, and stop conditions. Use when the user explicitly asks for idea2product-P4-product-discovery, P4, phase 4, or this step of the idea-to-product pipeline.

Turn product discovery into delivery-ready product artifacts: PRD, user stories, acceptance criteria, edge cases, instrumentation, non-goals, evidence-gated scope, and PM critique before Product Gate. Use when the user explicitly asks for idea2product-P5-product-definition, P5, phase 5, or this step of the idea-to-product pipeline.

Drive engineering execution, verification, acceptance results, launch or GTM checklist, release decision, pre-release security review, and Release Gate preparation using disciplined build and review practices. Use when the user explicitly asks for idea2product-P9-build-release, P9, phase 9, or this step of the idea-to-product pipeline.

Run the idea-to-product pipeline health check from the current workspace, report whether pipeline state and required artifacts are coherent, surface any confirmation-bias warnings about assumption evidence, and never change pipeline state. Use also when the user asks whether they are fooling themselves or whether their evidence is solid.

Creates an Architecture Decision Record following the Nygard format to document significant technical decisions, their context, and consequences. Use when making technical choices that affect system architecture, technology selection, or development patterns.

Roll the idea-to-product pipeline back to an earlier completed phase using the reopen command — only after confirming the target phase, the affected reports, and the reason with the user; never reopen without explicit confirmation.

Analyze the approved idea as a strategy problem, starting with an existing-solutions scan so the user can use, buy, partner, retire, or deliberately build a differentiated product before deeper strategy work. Use when the user explicitly asks for idea2product-P2-strategy-analysis, P2, phase 2, or this step of the idea-to-product pipeline.

Validate the single core interaction with a throwaway prototype tested on ~5 target users before committing to architecture and full build; the conversations are the evidence, not the prototype. Use when the user explicitly asks for idea2product-P6-validation-prototype, P6, phase 6, or this step of the idea-to-product pipeline.

Bridge product definition into technical direction by creating feature maps, traceability, architecture options, spikes, design rationale, and ADRs before Architecture Gate. Use when the user explicitly asks for idea2product-P7-architecture-handoff, P7, phase 7, or this step of the idea-to-product pipeline.

Specify one MVP feature at a time from approved PRD and ADR context, producing Spec Kit-ready packets and implementation planning without reopening product-level decisions. Use when the user explicitly asks for idea2product-P8-feature-specification, P8, phase 8, or this step of the idea-to-product pipeline.

Synthesizes user research interviews into actionable insights, patterns, and recommendations. Use after conducting user interviews, customer calls, or usability sessions to extract and communicate findings across participants. Distinct from foundation-meeting-recap, which summarizes one internal meeting for its attendees; this skill aggregates research conversations into evidence-backed findings.

Creates a structured lessons learned entry for organizational memory. Use after an incident, a completed project, or a significant learning to record knowledge for future teams and initiatives. Distinct from iterate-retrospective, which facilitates the team ceremony; this skill writes the durable lessons entry that outlives it.

Use when stress-testing the assumptions behind an idea or strategy before committing resources — classify desirability/viability/feasibility/usability assumptions, score them by risk and certainty, and plan the cheapest tests to de-risk the riskiest ones. Also covers opportunity framing and problem/solution validation.

Convert strategy analysis into a decision memo comparing build, buy, partner, capability-only, internal improvement, wait, and do-nothing options, then red-team the recommendation and request Strategy Gate. Use when the user explicitly asks for idea2product-P3-strategy-decision, P3, phase 3, or this step of the idea-to-product pipeline.

Retire or abandon the current idea-to-product project only after showing the current handoff, collecting explicit confirmation, and recording a non-empty reason.

Resume the idea-to-product pipeline from saved state by reporting current status, identifying the next ready phase or blocker, and continuing only when the user asked to proceed.

Report the current state of the idea-to-product pipeline, including active phase, pilot validation state, gate states, and blockers, without changing pipeline files.

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

Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.

Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.

Creates an opportunity solution tree mapping desired outcomes to opportunities and potential solutions. Use for outcome-driven product discovery, prioritization, or communicating product strategy.

Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.

Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.

Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.

Documents edge cases, error states, boundary conditions, and recovery paths for a feature. Use during specification to ensure comprehensive failure coverage, or during QA planning to identify test scenarios. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the systematic edge-case catalog for the whole feature.

Creates a comprehensive pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness. Use before releasing features, products, or major updates to ensure nothing is missed.

Creates a comprehensive Product Requirements Document that aligns stakeholders on what to build, why, and how success will be measured. Use when specifying features, epics, or product initiatives for engineering handoff.

Generates user stories in the standard persona, action, benefit story format from product requirements or feature descriptions. Use when breaking a feature into stories for sprint planning, writing tickets, or communicating scope to engineering. For testable Given/When/Then acceptance criteria on a story, use deliver-acceptance-criteria; for boundary and failure scenarios, use deliver-edge-cases.

Documents the reasoning behind design decisions including alternatives considered, trade-offs evaluated, and principles applied. Use when making significant UX decisions, aligning with stakeholders on design direction, or preserving design context for future reference.

Creates a concise one-page solution overview that communicates the proposed approach, key decisions, and trade-offs. Use when pitching solutions to stakeholders, aligning teams on approach, or documenting solution intent before detailed specification.

Documents the results of a time-boxed technical or design exploration (spike). Use after completing a spike to capture learnings, findings, and recommendations for the team.