Design Synthesis

by bsamiee

design

>-

Skill Details

Repository Files

1 file in this skill directory


name: design-synthesis type: simple depth: extended description: >- Synthesizes research findings into design decisions via codebase investigation. Use when (1) translating research into implementation approaches, (2) selecting between design alternatives, (3) executing after /research or deep-research, or (4) preparing input for /plan phase.

[H1][DESIGN-SYNTHESIS]

Dictum: Design decisions require grounded context before implementation.

Synthesize research findings into design decisions via light codebase investigation.

Workflow:

  1. §INGEST — Load research artifact, parse original request
  2. §SCAN — Light codebase investigation via parallel-dispatch (3-4 agents)
  3. §EXPLORE — Generate 2-3 approaches with trade-offs
  4. §SELECT — Commit to best approach with rationale
  5. §OUTPUT — Structured design document

Dependencies:

  • parallel-dispatch — Agent orchestration for codebase scan
  • Research artifact — External findings from deep-research

Input:

  • Research: Path to research artifact (research_{slug}.md)
  • Request: Original user request/intent

[1][INGEST]

Dictum: Grounded context prevents speculative design.

Load and parse inputs:

[INDEX] Source Extract
[1] Research file Findings, confidence levels, key sources
[2] Request Intent, scope boundaries, success criteria

Parse research structure:

  • ## [1][FINDINGS] → Domain knowledge by category
  • ## [2][CONFIDENCE] → High/Medium/Low ratings
  • ## [3][SOURCES] → Attribution for decisions

[IMPORTANT]:

  • [ALWAYS] Extract high-confidence findings as primary input.
  • [ALWAYS] Note low-confidence areas as design risks.
  • [NEVER] Proceed without understanding request intent.

[2][SCAN]

Dictum: Pattern awareness prevents reinvention.

Dispatch 3-4 agents via parallel-dispatch for codebase context.

Agent Assignment:

[INDEX] [AGENT] [SCOPE] [RETURNS]
[1] Patterns Similar implementations in codebase Conventions, reusable patterns, prior art
[2] Constraints Project rules, architecture limits Hard boundaries, style requirements
[3] Interfaces Entry/exit points for feature area Touch points, consumers, integration surface

Agent Prompt Template:

Scope: [Specific investigation area]
Objective: Surface [patterns|constraints|interfaces] relevant to: [request summary]
Output: Bullet list of findings with file paths
Context: Research indicates: [key findings summary]
Exclusions: Do NOT analyze implementation details or specific file contents

[CRITICAL]:

  • [ALWAYS] Dispatch ALL agents in ONE message block.
  • [ALWAYS] Scope to patterns/constraints/interfaces—NOT implementation.
  • [NEVER] Deep-dive into file contents—that's plan's job.

[3][EXPLORE]

Dictum: Comparison reveals optimal trade-offs.

Generate 2-3 distinct approaches from research + scan findings.

Per Approach:

[INDEX] Aspect Content
[1] Strategy High-level implementation direction
[2] Alignment How it leverages research findings
[3] Patterns Which codebase conventions it follows
[4] Trade-offs Pros and cons

Approach Generation Criteria:

  • Approach A: Most aligned with existing patterns (conservative)
  • Approach B: Best leverage of research findings (optimal)
  • Approach C: Simplest implementation path (minimal) — optional

[IMPORTANT]:

  • [ALWAYS] Ground approaches in scan findings—no speculation.
  • [ALWAYS] Include trade-off analysis per approach.
  • [ALWAYS] Apply YAGNI—cut unnecessary scope from all approaches.
  • [NEVER] Generate approaches without codebase evidence.

[4][SELECT]

Dictum: Committed direction enables focused planning.

Select best approach via weighted criteria:

[INDEX] Criterion Weight Evaluation
[1] Pattern alignment High Matches existing codebase conventions
[2] Research support High Backed by high-confidence findings
[3] Simplicity Medium Minimal moving parts
[4] Risk profile Medium Low-confidence areas minimized

Selection Output:

  • Selected approach name
  • Primary rationale (1-2 sentences)
  • Key trade-off accepted

[CRITICAL]:

  • [ALWAYS] Commit to ONE approach—no hedging.
  • [ALWAYS] Document trade-off accepted.
  • [NEVER] Defer selection to downstream phases.

[5][OUTPUT]

Dictum: Downstream consumers require predictable structure.

Produce brainstorm.md with structure:

# [H1][DESIGN]: [Title]
>**Dictum:** *[Build target—refined from request]*

<br>

**Research Summary:** [Key findings relevant to design]

---
## [1][APPROACHES]

### [1.1][APPROACH_A]: [Name]

| [INDEX] | [ASPECT]  | [DETAIL]                        |
| :-----: | --------- | ------------------------------- |
|   [1]   | Strategy  | [High-level direction]          |
|   [2]   | Alignment | [Research findings leveraged]   |
|   [3]   | Patterns  | [Codebase conventions followed] |
|   [4]   | Pros      | [Benefits]                      |
|   [5]   | Cons      | [Drawbacks]                     |

---
### [1.2][APPROACH_B]: [Name]

| [INDEX] | [ASPECT]  | [DETAIL]                        |
| :-----: | --------- | ------------------------------- |
|   [1]   | Strategy  | [High-level direction]          |
|   [2]   | Alignment | [Research findings leveraged]   |
|   [3]   | Patterns  | [Codebase conventions followed] |
|   [4]   | Pros      | [Benefits]                      |
|   [5]   | Cons      | [Drawbacks]                     |

---
## [2][SELECTED_APPROACH]

| [INDEX] | [KEY]              | [VALUE]                |
| :-----: | ------------------ | ---------------------- |
|   [1]   | Choice             | [Approach name]        |
|   [2]   | Rationale          | [Why this approach]    |
|   [3]   | Trade-off Accepted | [What we're giving up] |

---
## [3][DESIGN_CONSTRAINTS]

| [INDEX] | [CONSTRAINT]    | [SOURCE]        |
| :-----: | --------------- | --------------- |
|   [1]   | [Hard boundary] | [Codebase scan] |
|   [2]   | ...             | ...             |

---
## [4][KEY_DECISIONS]

| [INDEX] | [DECISION]      | [CHOICE]          | [RATIONALE] |
| :-----: | --------------- | ----------------- | ----------- |
|   [1]   | [Design choice] | [Selected option] | [Why]       |
|   [2]   | [Design choice] | [Selected option] | [Why]       |

[CRITICAL]:

  • [ALWAYS] Include all sections—downstream depends on structure.
  • [ALWAYS] Table format for approaches and decisions.
  • [NEVER] Prose paragraphs—tables and lists only.

[6][VALIDATION]

Dictum: Incomplete synthesis cascades errors downstream.

[VERIFY]:

  • Ingest: Research parsed, request intent extracted
  • Scan: 3-4 agents dispatched in ONE message
  • Explore: 2-3 approaches with trade-offs generated
  • Select: ONE approach committed with rationale
  • Output: All sections present, table format used
  • YAGNI: Unnecessary scope cut from all approaches

Related Skills

Team Composition Analysis

This skill should be used when the user asks to "plan team structure", "determine hiring needs", "design org chart", "calculate compensation", "plan equity allocation", or requests organizational design and headcount planning for a startup.

artdesign

Kpi Dashboard Design

Design effective KPI dashboards with metrics selection, visualization best practices, and real-time monitoring patterns. Use when building business dashboards, selecting metrics, or designing data visualization layouts.

designdata

Sql Optimization Patterns

Master SQL query optimization, indexing strategies, and EXPLAIN analysis to dramatically improve database performance and eliminate slow queries. Use when debugging slow queries, designing database schemas, or optimizing application performance.

designdata

Senior Data Scientist

World-class data science skill for statistical modeling, experimentation, causal inference, and advanced analytics. Expertise in Python (NumPy, Pandas, Scikit-learn), R, SQL, statistical methods, A/B testing, time series, and business intelligence. Includes experiment design, feature engineering, model evaluation, and stakeholder communication. Use when designing experiments, building predictive models, performing causal analysis, or driving data-driven decisions.

designtestingdata

Mermaid Diagrams

Comprehensive guide for creating software diagrams using Mermaid syntax. Use when users need to create, visualize, or document software through diagrams including class diagrams (domain modeling, object-oriented design), sequence diagrams (application flows, API interactions, code execution), flowcharts (processes, algorithms, user journeys), entity relationship diagrams (database schemas), C4 architecture diagrams (system context, containers, components), state diagrams, git graphs, pie charts,

artdesigncode

Ux Researcher Designer

UX research and design toolkit for Senior UX Designer/Researcher including data-driven persona generation, journey mapping, usability testing frameworks, and research synthesis. Use for user research, persona creation, journey mapping, and design validation.

designtestingtool

Supabase Postgres Best Practices

Postgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.

designdata

Kpi Dashboard Design

Design effective KPI dashboards with metrics selection, visualization best practices, and real-time monitoring patterns. Use when building business dashboards, selecting metrics, or designing data visualization layouts.

designdata

Sql Optimization Patterns

Master SQL query optimization, indexing strategies, and EXPLAIN analysis to dramatically improve database performance and eliminate slow queries. Use when debugging slow queries, designing database schemas, or optimizing application performance.

designdata

Dashboard Design

USE THIS SKILL FIRST when user wants to create and design a dashboard, ESPECIALLY Vizro dashboards. This skill enforces a 3-step workflow (requirements, layout, visualization) that must be followed before implementation. For implementation and testing, use the dashboard-build skill after completing Steps 1-3.

designtestingworkflow

Skill Information

Category:Creative
Last Updated:12/25/2025