Repository navigation
explore-directions: HTML mockups of an existing app's feature should keep the app's look #8429
Description
Problem
/prototype:explore-directions on its HTML mockup substrate forces every variant to look like a different app, even when the variants are changes to an existing app. Its rules say the mockup "has no project styling system to inherit" and require each variant to declare its own background, accent and typeface (plugins/prototype/skills/explore-directions/SKILL.md, "Each variant declares its visual direction"), and the step 2 table says the visual direction must differ "always on the HTML mockup substrate".
That assumption fails when a self-contained mockup is needed for an existing app, for example when the variants must be standalone files another page frames (the shared interview page's prototype questions serve each variant as a sandboxed HTML asset). In a live session the owner asked for three layouts of one existing feature (the host's Inbox); the skill produced three variants in three unrelated palettes and typefaces, which the owner rejected: "These look like wildly different apps ... This is just the existing app, but change to the inbox feature and add a new page."
Expected
When the variants change part of an existing app, every variant keeps that app's look (its CSS, components, header and surrounding page) and differs only in the structure under question. A divergent visual direction applies only when the person asks to change the app's design, or when no app exists yet.
Suggested change
- In the mockup substrate, branch on whether an app exists: with one, build each variant from the app's own styling and markup (inline its CSS; capture the real surrounding page), and vary only the subtree under test; without one, keep today's per-variant visual directions.
- Make the step 2 "Visual direction" row say "must differ only when no app exists or a redesign was asked", and add the failure ("three variants of one app's feature in three different looks") to the failure-modes table.
- Add an eval: an existing app plus a request for layout options of one feature, delivered as standalone files; pass when all variants share the app's styling and differ structurally.
Context
The orchestrating session's brief also chose the mockup substrate and dropped the switcher; that part was the caller's choice, not the skill's. The gap reported here is the forced divergent look once the mockup substrate is in use for an existing app.
Activity
github-actions commentedon Oct 19, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; a maintainer confirms or changes it.
Size: Small
Complexity: Low
Uncertainty: Known
Flags: none
Blocked by: none
#8429 (comment)
The decision settles the open questions: the mockup branches on whether an app exists, and inlining the app's CSS does not conflict with the no-remote-fetch rule.
What I understood: explore-directions' HTML mockup should keep an existing app's look across variants and vary only the structure under test. The work is a SKILL.md edit (mockup constraint, the step 2 row, the failure-modes table) plus a new eval case. Related, possibly overlapping: #8776, #8773, #8777, #9783.
Automated triage. A maintainer reviews it.
github-actions commentedon Oct 26, 2026
The triage sweep dispatched intake triage for this issue (attempt 1 of 2).
melodic-automation-lanes commentedon Oct 26, 2026
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed
- [ ]criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Oct 26, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.kyle-sexton commentedon Oct 26, 2026
Decision recorded. The owner answered in the Refinement and Issue Triage sessions (2026-10-25), deciding the open items below on the facts:
No owner ledger (
.work/*/interview-checklist.md,.work/gh-monitor-owner-decisions/) names this issue. The issue was held only because no trusted-human criteria existed (#8429 (comment)). The body's "Suggested change" list is the spec; the criteria below convert it, wording kept close.Decided: Yes. The mockup constraint still says "The mockup has no project styling system to inherit" and requires each variant to "differ from its siblings on that axis as well as structurally" (
plugins/prototype/skills/explore-directions/SKILL.md:134-138, origin/main 68d3f2b). The step 2 "Visual direction" row still says "Must differ ... and always on the HTML mockup substrate" (SKILL.md:195). The failure-modes table (SKILL.md:363-368) has no row for one app's feature drawn in several looks.Decided: The body's: branch on whether an app exists. With an app, every variant inlines the app's own CSS and surrounding page and varies only the subtree under test; without one, today's per-variant visual directions stay. This matches the table's own "Component library and styling system | Identical" row (
SKILL.md:197), so the mockup and the real-stack hosts follow one rule.Decided: No. The rule forbids remote origins only; "Inline
<style>and inline<script>stay allowed" (SKILL.md:114-119). App CSS is inlined, never linked.Acceptance criteria:
SKILL.md's HTML mockup substrate section branches on whether an app exists: with one, each variant is built from the app's own styling and markup (its CSS inlined, the real surrounding page captured) and only the subtree under test varies; without one, each variant keeps its declared visual direction.plugins/prototype/skills/explore-directions/evals/evals.jsonhas a case: an existing app plus a request for layout options of one feature, delivered as standalone files; it passes when all variants share the app's styling and differ structurally.melodic-automation-lanes commentedon Oct 26, 2026
Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.
Intended outcome: explore-directions' HTML mockup substrate keeps an existing app's look across variants and varies only the structure under test, using per-variant visual directions only when no app exists or a redesign is asked.
Acceptance criteria
Related work
Sources read
Automated refinement by the lanes App. Intake triages the issue again with it.