frontend-harness-slides

Frontend Harness Slides

Build HTML slides that survive iteration. This skill does not provide a starter project or require React, Vite, Tailwind, Playwright, or any other stack. Its unit is the harness contract: stable frame address, registry, fixed stage, frozen mode, audit surface, visual checks, and verified handoff.

Pre-Build Alignment

Use explicit user requirements. An inferred or recommended default is a working plan, not an explicit user requirement. For a small edit with clear requirements to an existing deck, preserve the current stack, deck root, and visual system except where the user requests a change, and proceed.

Inspect discoverable facts first: source material, the existing deck, the repo, a deployed URL, and project files. Ask only unresolved decisions that materially affect the result or scope. Do not re-ask a path, style, stage, stack, density, navigation, or delivery target the user already gave.

When the brief is still vague, treat alignment as focused grilling: purpose and audience, content boundary and story, presentation format and density, then the remaining execution constraints. Keep each round on the next highest-impact unknown. Ask in normal chat text, with a recommended answer, rationale, and impact. Group related low-risk questions when that reduces back-and-forth. Do not call AskUserQuestion, AskQuestion, request_user_input, or any structured single-choice, multiple-choice, or form-style prompt. Candidate options may clarify a real directional choice, but they stay as plain text.

Cover these decisions at the level the task needs. This is a decision surface, not a confirmation ritual:

• Content plan: scope, non-goals, orientation, presentation format, duration, and content mix.
• Design plan: style, density, audit profile, motion direction, visual references, and whether a preview would reduce visual uncertainty.
• Project location plan: the deck root, whether it is new, existing, inside a parent repo, an independent repo, or temporary, and which files are expected there. Use a path the user already gave or the existing deck's root. A user home directory or other broad workspace is not a reliable long-term deck root. If a long-term deliverable has no reliable specified target, recommend one exact path and confirm before scaffolding. Do not scaffold into the current working directory just because the agent started there.
• Build plan: fixed stage, navigation/touch expectations, technology stack, source material, and delivery target. Do not publish or deploy without authorization.
• Testing plan: test runner, test command, and required coverage across render, frame addressing, navigation, interaction isolation, layout safety, runtime errors, assets/fonts, and build/export/deployment checks. Testing is required for created or modified HTML slide artifacts; do not present it as a preference to confirm.
• Context document plan: where the Context document will live, when it will be updated, and whether the user wants a different location.