"You're not sure what you want yet. Ask the agent to fan out across several directions and lay them next to each other so you can point at one."
When to use
| User says | Which paradigm to use | Template |
|---|---|---|
| "Show me several implementation approaches / which is better" | Three-approach comparison | ../templates/compare.html |
| "compare X vs Y vs Z" | Same as above | Same as above |
| "I want a UI but can't articulate the style / show me a few directions" | Visual design direction | Build your own (see below) |
| "Make an implementation plan / RFC / how to ship it" | Implementation plan | ../templates/plan.html |
| "How to schedule shipping in 2 weeks" | Same as above | Same as above |
Paradigm 1.1 · Three-approach comparison
Spatial shape: each approach = one complete code block + one Pro/Con table + one line of metrics (bundle / testability / SSR / reuse). The three approaches must beside by sideto compare; markdown can only stack them vertically.
Minimum elements:
- At least 2, no more than 4 columns (more and the user can't remember them)
- Each column has a minimal runnable piece of code (5-15 lines)
- 3 Pro and 3 Con items each,specific(not "easy to read", but "Single import reused across filter, command bar, and board search")
- The metrics line uses the same set of dimensions for side-by-side comparison
- A closing paragraph with the agent's recommendation(don't make the user judge everything themselves)
HTML skeleton:
<div class="approaches">
<article class="approach">
<header><span class="tag">Approach 1</span><h2>Inline useEffect</h2></header>
<pre><code>...实际可运行代码...</code></pre>
<table class="proscons">
<thead><tr><th>Pro</th><th>Con</th></tr></thead>
<tbody><tr><td>...</td><td>...</td></tr></tbody>
</table>
<footer class="metrics">
<span>Bundle <b>+0 kb</b></span>
<span>Test <b>medium</b></span>
<span>Reuse <b>low</b></span>
<span>SSR <b>yes</b></span>
</footer>
</article>
<!-- 重复 2-3 次 -->
</div>
<aside class="recommendation"><strong>建议:</strong>...</aside>
Key CSS:
.approaches { display: grid; grid-template-columns: repeat(3, 1fr); gap: 24px; }
.approach { display: flex; flex-direction: column; gap: 16px;
padding: 20px; border: 1px solid var(--gray-300);
border-radius: 12px; background: var(--white); }
.approach pre { flex: 1; max-height: 360px; overflow: auto; }
.proscons td:first-child { color: var(--success); }
.proscons td:last-child { color: var(--danger); }
.metrics { display: flex; gap: 16px; flex-wrap: wrap;
font-size: 13px; color: var(--gray-700); }
Ready-to-use template:../../templates/compare.html
Paradigm 1.2 · Visual design direction
Spatial shape: 4 cards ofreal rendering(not descriptions!) + one line of style notes per card + a top-bar light/dark toggle.
Typical 4 directions(covering most scenarios):
- A — Minimal · pure typography, single action
- B — Illustrated · add a small SVG illustration
- C — Playful · micro-animations / playful
- D — Instructional · treat the empty state as onboarding
Key CSS / JS:
.directions { display: grid; grid-template-columns: repeat(2, 1fr); gap: 32px; }
.directions[data-theme="dark"] { background: var(--slate); color: var(--ivory); }
.render { aspect-ratio: 4/3; padding: 32px; border-radius: 12px;
background: var(--ivory); display: flex; align-items: center;
justify-content: center; flex-direction: column; }
document.querySelectorAll('.theme-toggle button').forEach(b => b.onclick = () => {
document.querySelectorAll('.directions').forEach(d => d.dataset.theme = b.dataset.theme);
});
No standalone template (generate as needed; you can refer to the two-column structure of ../../templates/compare.html and adapt it).
Paradigm 1.3 · Implementation plan (plan)
Spatial shape: 6 fixed regions:
- Meta info bar:Effort / Surfaces / New tables / Feature flag
- Milestones: 4-phase timeline (slices 1-4, each independently reviewable)
- Data flow: SVG block diagram (solid lines = request/response, dashed lines = realtime fan-out)
- Mockups: UI sketch rendered directly in HTML (no image placeholders)
- Key code: 1-2 pieces of code most likely to be done wrong (migration, optimistic mutation)
- Risks & mitigations: table (Risk, Sev, Mitigation)
- Open questions: each entry with "with whom, decided when"
HTML skeleton:
<header class="meta">
<h1>Implementation plan — [Feature]</h1>
<dl class="meta-grid">
<div><dt>Effort</dt><dd>~2 weeks</dd></div>
<div><dt>Surfaces touched</dt><dd>3 packages</dd></div>
<div><dt>New tables</dt><dd>2</dd></div>
<div><dt>Feature flag</dt><dd><code>flag_v1</code></dd></div>
</dl>
</header>
<section class="step"><span class="step-no">01</span>
<h2>Milestones</h2>
<ol class="timeline">...</ol>
</section>
<section class="step"><span class="step-no">02</span>
<h2>Data flow</h2>
<svg viewBox="0 0 800 320">...</svg>
</section>
<!-- 03 Mockups · 04 Key code · 05 Risks · 06 Open questions -->
SVG data flow key points:
- Nodes
<rect>use 8px rounded corners - Solid line (request path) uses
--slate, dashed line (fan-out) uses--clay+stroke-dasharray="4 4" - Arrow reuse
<defs><marker id="arr">(see../shared/components.htmlSection 1)
Ready-to-use template:../../templates/plan.html
Common principles
- Do not write a winner, make all 3 options look credible, then give a recommendation
- Metrics must be comparable—don't write "fast" in the first column and "200ms" in the second
- 3 Pros/Cons each—fewer is not credible, more is too much to read
- Real name placeholder:
Mira Okafor,Devon Park, do not writeUser A - The data flow diagram must have a legend—clearly state the meaning of solid vs dashed lines