Founder Mode
Take a product opportunity from first principles through a scoped build, independent validation, launch, and learning.
Steps
- 1
Clarify the Opportunity
Start with the customer problem, not a solution. State the target user, their context, the current alternative, why the problem matters now, and the desired outcome. Separate facts from assumptions; do not proceed until the problem statement and success hypothesis can be tested.
- 2
CEO Review
Decide whether this deserves investment now. Challenge the expected impact, strategic fit, differentiation, opportunity cost, and downside; explicitly identify what will not be built. Choose proceed, stop, or learn more. Proceed only when the scope, non-goals, and decision owner are clear.
- 3
Engineering Review
Translate the approved scope into an implementation approach. Examine the architecture, data model, interfaces, dependencies, migrations, failure modes, security implications, and test strategy. Record material trade-offs and risks. Do not begin the build with an unresolved technical blocker.
- 4
Build
Implement only the approved scope and follow the engineering plan. Keep behavior changes covered by tests and record deviations, discoveries, or new requests for a later decision instead of silently expanding scope. Finish with a working change, its tests, and a concise summary of modified files.
- 5
Independent Review
Review the change independently from its implementation. Check correctness, security, maintainability, test coverage, operational impact, and alignment with the approved scope. Classify findings by severity, return blockers with actionable fixes, and verify that every blocker is resolved.
- 6
Product QA
Validate the real user journey in the browser or relevant client. Exercise the primary path, important permissions and error states, and the edge cases identified in planning. Capture reproducible evidence for failures. Pass QA only when the intended experience works without a release-blocking defect.
- 7
Ship
Confirm the latest tests, review, and QA evidence before preparing the release. Summarize user-facing changes, deployment steps, rollback considerations, and ownership after launch. Do not ship with an unresolved blocker or an unknown deployment prerequisite.
- 8
Retro
Review the outcome against the original hypothesis. Record what worked, what was surprising, what created delay or risk, and the smallest changes that will improve the next cycle. Convert durable learnings into owned follow-up actions.
Content Digest
sha256:sha256:0df5814d9ed4c79a1b0927c09da741990824f422b163a60744ca82dc26324a48{"category":"operations","description":"Take a product opportunity from first principles through a scoped build, independent validation, launch, and learning.","inputSchema":{"properties":{"constraints":{"description":"Time, budget, team, and technical constraints.","type":"string"},"context":{"description":"Relevant customer, business, and technical context.","type":"string"},"opportunity":{"description":"The problem, opportunity, or idea to explore.","type":"string"}},"required":["opportunity"],"type":"object"},"schemaVersion":1,"steps":[{"expectedOutputs":[{"name":"problem-statement","type":"artifact"},{"name":"target-user","type":"artifact"},{"name":"key-assumptions","type":"list"},{"name":"success-hypothesis","type":"decision"}],"id":"ZXC8","instructions":"Start with the customer problem, not a solution. State the target user, their context, the current alternative, why the problem matters now, and the desired outcome. Separate facts from assumptions; do not proceed until the problem statement and success hypothesis can be tested.","resourceHints":[{"kind":"skill","ref":"github:garrytan/gstack","selector":"office-hours"}],"title":"Clarify the Opportunity"},{"expectedOutputs":[{"name":"product-decision","type":"decision"},{"name":"scope","type":"artifact"},{"name":"non-goals","type":"list"},{"name":"key-risks","type":"list"}],"id":"VM4N","instructions":"Decide whether this deserves investment now. Challenge the expected impact, strategic fit, differentiation, opportunity cost, and downside; explicitly identify what will not be built. Choose proceed, stop, or learn more. Proceed only when the scope, non-goals, and decision owner are clear.","resourceHints":[{"kind":"skill","ref":"github:garrytan/gstack","selector":"plan-ceo-review"}],"title":"CEO Review"},{"expectedOutputs":[{"name":"implementation-plan","type":"artifact"},{"name":"architecture-decisions","type":"decision-log"},{"name":"test-plan","type":"artifact"},{"name":"technical-risks","type":"list"}],"id":"WK3N","instructions":"Translate the approved scope into an implementation approach. Examine the architecture, data model, interfaces, dependencies, migrations, failure modes, security implications, and test strategy. Record material trade-offs and risks. Do not begin the build with an unresolved technical blocker.","resourceHints":[{"kind":"skill","ref":"github:garrytan/gstack","selector":"plan-eng-review"}],"title":"Engineering Review"},{"expectedOutputs":[{"name":"working-implementation","type":"artifact"},{"name":"tests","type":"artifact"},{"name":"changed-files","type":"summary"}],"id":"19KK","instructions":"Implement only the approved scope and follow the engineering plan. Keep behavior changes covered by tests and record deviations, discoveries, or new requests for a later decision instead of silently expanding scope. Finish with a working change, its tests, and a concise summary of modified files.","resourceHints":[{"kind":"agent","ref":"github:openai/codex","selector":"coding-agent"}],"title":"Build"},{"expectedOutputs":[{"name":"review-findings","type":"report"},{"name":"blockers","type":"list"},{"name":"required-fixes","type":"list"}],"id":"66IX","instructions":"Review the change independently from its implementation. Check correctness, security, maintainability, test coverage, operational impact, and alignment with the approved scope. Classify findings by severity, return blockers with actionable fixes, and verify that every blocker is resolved.","resourceHints":[{"kind":"skill","ref":"github:garrytan/gstack","selector":"review"}],"title":"Independent Review"},{"expectedOutputs":[{"name":"qa-checklist","type":"checklist"},{"name":"qa-evidence","type":"evidence"},{"name":"bugs","type":"list"},{"name":"qa-decision","type":"decision"}],"id":"LTUW","instructions":"Validate the real user journey in the browser or relevant client. Exercise the primary path, important permissions and error states, and the edge cases identified in planning. Capture reproducible evidence for failures. Pass QA only when the intended experience works without a release-blocking defect.","resourceHints":[{"kind":"skill","ref":"github:garrytan/gstack","selector":"qa"}],"title":"Product QA"},{"expectedOutputs":[{"name":"release-ready-pr","type":"artifact"},{"name":"release-notes","type":"artifact"},{"name":"deployment-checklist","type":"checklist"}],"id":"7K7J","instructions":"Confirm the latest tests, review, and QA evidence before preparing the release. Summarize user-facing changes, deployment steps, rollback considerations, and ownership after launch. Do not ship with an unresolved blocker or an unknown deployment prerequisite.","resourceHints":[{"kind":"skill","ref":"github:garrytan/gstack","selector":"ship"}],"title":"Ship"},{"expectedOutputs":[{"name":"learnings","type":"list"},{"name":"follow-up-actions","type":"list"}],"id":"MFYZ","instructions":"Review the outcome against the original hypothesis. Record what worked, what was surprising, what created delay or risk, and the smallest changes that will improve the next cycle. Convert durable learnings into owned follow-up actions.","resourceHints":[{"kind":"skill","ref":"github:garrytan/gstack","selector":"retro"}],"title":"Retro"}],"title":"Founder Mode"}