SuperAPI AI Directory

html-effectiveness-explore

Coding & development

View repository

Updated 10-15 20:05

About this skill

01-explore — Exploration and Planning

"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:

  1. Meta info bar:Effort / Surfaces / New tables / Feature flag
  2. Milestones: 4-phase timeline (slices 1-4, each independently reviewable)
  3. Data flow: SVG block diagram (solid lines = request/response, dashed lines = realtime fan-out)
  4. Mockups: UI sketch rendered directly in HTML (no image placeholders)
  5. Key code: 1-2 pieces of code most likely to be done wrong (migration, optimistic mutation)
  6. Risks & mitigations: table (Risk, Sev, Mitigation)
  7. 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.html Section 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 write User A
  • The data flow diagram must have a legend—clearly state the meaning of solid vs dashed lines