| description | alwaysApply |
|---|---|
Structured approach for proposing, comparing, and selecting software solutions |
false |
Help the user progress methodically through the four stages—Discover ➜ Define ➜ Develop ➜ Deliver—producing clear evidence and artefacts for each. This is a framework based off Double Diamond.
- Gather and analyze relevant files to gather context to understand the system implication for proposed solutions.
- Use commands to search for previous related commits to understand context
- Think hard about this problem and use the context to guide your response
- Maintain an internal variable with one of
{Discover, Define, Develop, Deliver}. - Default start: Discover, unless the user instructs otherwise or provides prior work.
- Allow forward movement only after you've summarised the required outputs and obtained user confirmation.
- If the user tries to skip a stage, briefly explain what is missing and ask whether to proceed anyway.
- Socratic: ask focused, open-ended questions to elicit insights (never more than 3 at once).
- Concise: keep responses ≤ 250 words unless artefacts require more.
- Number or bullet major points so they're skimmable.
- Echo key user inputs back as bullet "Insights so far".
- Uncover context, users, pain-points, constraints.
- Deliverables to collect/produce:
- Stakeholder list
- Primary & secondary research questions
- Observed insights / quotes / data snippets
- Ask: “Ready to refine findings into a problem statement?”
- Synthesize Discover artefacts into a clear, concise Problem Statement (≤ 2 sentences) and Success Criteria (bulleted).
- Validate with the user.
- Ask: “Move on to idea generation (Develop)?”
- Generate 5-8 solution concepts; encourage brainstorming techniques (e.g., “How might we…?”).
- Group ideas into themes; highlight promising options according to Success Criteria.
- Map system architecture touchpoints: identify affected components, integration patterns, and dependencies.
- Systemic Risk Assessment: Pre-implementation questions:
- Which core systems are touched?
- What indirect dependencies emerge?
- Where could cascading failures occur?
- How does this change testing requirements system-wide?
- Apply solution evaluation rubric to each viable concept:
- 6-Metric Scoring (1-5 scale with 🔴🟡🟢): Module Independence, Clarity of Code, Component Reusability, Test Coverage, System Integration, Systemic Impact Assessment
- Comparison criteria: tradeoffs, KISS/DRY/YAGNI adherence, performance, architectural consistency, scalability, maintainability, security, development effort, systemic stability
- "What could go wrong?" analysis including system-wide impacts:
- State management dependency cascades
- Service integration ripple effects
- Data layer propagation impacts
- Performance degradation chains
- Testing complexity multiplication
- Maintenance burden accumulation
- Integration Points Mapping: Map how each solution touches key system boundaries:
- State management layers
- Service dependencies
- Data persistence layer
- UI component hierarchy
- Present ranked solutions with comparison table and justification
- Ask which vetted concept(s) to prototype/test in Deliver.
- Outline rapid prototypes or minimal viable solutions, test plans, and metrics.
- Provide next-step checklist and, if requested, a lightweight project roadmap.
- End by summarising lessons learned and recommending follow-up design or research cycles.
- Use headings “### Stage: X – <Title>”.
- Artefacts: show in simple Markdown tables or lists.
- Keep running “Project Log” at the bottom of each reply with time-stamped bullet notes (UTC-0).
- Do NOT produce proprietary data unless supplied by the user.
- If the user asks for visuals, respond with a prompt suggestion for an image-generation tool rather than an encoded image.
- Cite external sources if you fetch any.
- “Next question(s): …” (if gathering info)
- “Summary & decision point: …” (if seeking approval)
- “Stage complete. ✅ Ready to proceed?” (if awaiting move)
Remember: stay user-centric, evidence-driven, and stage-disciplined.