presentation-discovery

name	presentation-discovery
description	Lock a fresh WebsitePresent brief before design or implementation. Use when starting a new HTML presentation task, major redesign, new version direction, or any work where audience, tone, delivery shape, or reference style is still open.

Presentation Discovery

Use this skill when a presentation task is fresh enough that the team does not yet have a locked brief.

This skill is the repository's equivalent of a turn-1 design brief lock. Its purpose is to prevent premature implementation and reduce expensive rework.

Hard gate

Do not begin substantial implementation, heavy redesign, or broad delegation until this skill has locked the brief.

Only skip this skill when all of the following are true:

• the task is a narrow tweak or fix,
• the task boundary is already known,
• the direction is already known,
• the user did not ask for new story, design, or motion thinking.

Read first

Before asking anything, read:

• references/brief-schema.md
• references/directions.md

If the user wants reference or brand matching, also read:

• references/brand-extraction.md

What this skill locks

This skill exists to lock the minimum viable brief for presentation production:

• artifact type
• audience
• delivery context
• tone or visual direction
• reference/brand intent
• scale and scope
• hard constraints

It does not replace source analysis, story design, or implementation. It simply creates the conditions for those later steps to work well.

Workflow

1. Confirm whether discovery is needed

If the task is a new task, major redesign, new version direction, or a substantial creative request, discovery is needed.

If the task is only a surgical change inside a stable direction, you may skip to downstream work.

2. Ask one compact structured batch

Use a structured question batch when available.

Keep it compact. Target roughly 5 to 7 items.

Do not re-ask what the user already made explicit. Do not expand the batch into a long interview unless ambiguity remains after the first round.

3. Branch on the direction/source answer

Branch A: user wants help choosing a direction

Use the curated direction library in references/directions.md.

Ask the user to choose one direction, or choose one for them only if they explicitly delegate the decision.

Do not let the implementation stage become the first time anyone realizes the visual language.

Branch B: user wants to match a brand, site, or screenshot

Run the extraction protocol from references/brand-extraction.md before visual design work.

The point is to convert vague “match this” instructions into a concrete, portable style summary.

Branch C: user already specified a clear direction

Summarize the direction back in working terms and proceed.

4. Produce a locked brief summary

Before handoff, summarize:

• what is being made
• who it is for
• what the tone/direction is
• whether the work follows a source/reference
• what scale is expected
• what the main hard constraints are
• what still remains intentionally open

This summary should be brief but operational.

5. Hand off to planning and downstream roles

Once the brief is locked, the next step is a visible plan.

That plan should be detailed enough for the user to redirect cheaply, but short enough to stay actionable.

Output contract

Your output should leave behind:

• a locked brief,
• a chosen direction or a confirmed reference-matching path,
• the main hard constraints,
• the next recommended role or step.

Principles

• Ask early, not after building the wrong thing.
• Choose a direction deliberately, not accidentally.
• Match real evidence, not memory.
• Minimize redirect cost.
• Keep the brief operational rather than ornamental.

What to avoid

• treating a long user request as fully specified when direction is still open,
• asking ten tiny follow-up questions instead of one compact batch,
• letting style choice happen implicitly during implementation,
• claiming to match a brand without extracting any real signal,
• turning discovery into a long design essay.