name	prismatic-terminal-ui
description	Create self-contained single-page HTML in a prismatic monospace terminal style. Use when the user asks for an HTML plan, one-off demo site, concept page, dashboard, explainer, report, or quick visualization that should use this visual language. Produces responsive, accessible HTML with inline CSS and optional inline JavaScript, without external stylesheets, fonts, icon libraries, or build tools.

Prismatic Terminal UI

Turn the user's material into one polished HTML document using this skill's visual language. Preserve the style, not the sample content.

Workflow

Identify the page's job, primary audience, dominant artifact, and necessary interactions from the request. Do not invent product requirements or ask questions unless a missing decision blocks useful work.
Read assets/page-template.html in full. Treat its <style> block as the canonical implementation and start from that document rather than recreating the CSS from memory.
Read references/visual-language.md when selecting components, adapting the composition, or deciding how non-terminal content maps into the style.
Replace every example label, title, metric, chart, and action with task-specific content. Remove sample sections that do not serve the request.
Build a clear content hierarchy before adding decoration: context label, one decisive title, short explanation, then the dominant artifact. Make the artifact a plan, prototype, data view, report, or other structure the request actually needs.
Keep the atmospheric background, narrow shell, mono typography, borders, compact radii, restrained shadows, and semantic accent roles. Change composition and density to fit the content; do not clone the sample layout mechanically.
Add only interactions that improve the page. Use semantic HTML first and small inline JavaScript second. The bundled theme toggle is optional.
Open the result at desktop and mobile widths when browser tooling is available. Fix overflow, clipped content, unreadable contrast, missing focus states, and controls without accessible names before finishing.

Output Contract

Produce exactly one .html file unless the user explicitly requests another delivery format.
Put all CSS in a <style> element in the document <head>.
Never use CSS @import, external stylesheets, remote fonts, icon libraries, frameworks, or build steps.
Do not use url(...) for decorative CSS assets. Create atmosphere with gradients, borders, and CSS shapes.
Keep JavaScript inline and dependency-free. The page's core content must remain understandable if JavaScript fails.
Use inline SVG only when a real diagram or icon needs it. Give meaningful SVGs an accessible name and mark decorative SVGs aria-hidden="true".
External destinations may be ordinary links. User-provided content images are allowed, but do not introduce remote imagery merely as decoration.
Set the viewport meta tag, a useful document title, and a concise meta description.

Style Invariants

Use a mono-first type system. Large display text is heavy and compact; body text stays readable with generous line height.
Keep the content shell near 808px on wide screens and fluid on small screens.
Use one atmospheric magenta-red-violet field behind a subtle square grid. It is background atmosphere, not a card fill.
Build surfaces from translucent background color, a one-pixel semantic border, 8px to 10px radii, and a short downward shadow.
Default to readable cards, prose, tables, steps, charts, and diagrams. Use full terminal chrome only when the source content is genuinely command-line material such as a command, trace, REPL, or log; never use it to frame an ordinary recommendation or summary.
Use accent colors by role: yellow for prompts and active markers, green for commands and positive state, blue/lavender for links, pink for hints, red for destructive or failed state.
Prefer small status dots, text labels, and typographic symbols over decorative icon sets.
Keep animation sparse: a short reveal, cursor blink, or state transition. Honor prefers-reduced-motion.

Content Rules

Write content for the user's purpose. Do not mention this skill, the source blog, Stanley, or the template in the generated page.
Do not invent shell syntax for ordinary headings, decisions, plans, or takeaways. Prompt motifs belong only to real command-oriented content.
Do not use fake metrics, endorsements, activity feeds, or status claims unless clearly labeled as illustrative sample data.
For plans, expose sequence, owner or scope, dependencies, and completion state where relevant.
For demos, make the primary interaction functional and show its state visibly.
For visualizations, include units, labels, a legend when needed, and an accessible text summary. CSS bars are suitable for small categorical comparisons; use inline SVG for real axes or connected data.
For long-form explanations, use the .prose treatment and bordered heading rhythm instead of stacking many cards.

Final Check

Before returning the file, verify all of the following:

No sample content remains.
No external CSS, font, script, or icon dependency exists.
The page has one obvious primary artifact and action hierarchy.
Every interactive control works with keyboard focus and has an accessible name.
Light and dark themes remain legible if both are retained.
The page works at 390px and around 1440px without horizontal page scrolling.
Reduced-motion users do not receive essential information only through animation.

Prismatic Terminal UI

Turn the user's material into one polished HTML document using this skill's visual language. Preserve the style, not the sample content.

Workflow

Identify the page's job, primary audience, dominant artifact, and necessary interactions from the request. Do not invent product requirements or ask questions unless a missing decision blocks useful work.

Read assets/page-template.html in full. Treat its <style> block as the canonical implementation and start from that document rather than recreating the CSS from memory.

Read references/visual-language.md when selecting components, adapting the composition, or deciding how non-terminal content maps into the style.

Replace every example label, title, metric, chart, and action with task-specific content. Remove sample sections that do not serve the request.

Build a clear content hierarchy before adding decoration: context label, one decisive title, short explanation, then the dominant artifact. Make the artifact a plan, prototype, data view, report, or other structure the request actually needs.

Keep the atmospheric background, narrow shell, mono typography, borders, compact radii, restrained shadows, and semantic accent roles. Change composition and density to fit the content; do not clone the sample layout mechanically.

Add only interactions that improve the page. Use semantic HTML first and small inline JavaScript second. The bundled theme toggle is optional.

Open the result at desktop and mobile widths when browser tooling is available. Fix overflow, clipped content, unreadable contrast, missing focus states, and controls without accessible names before finishing.

Output Contract

Produce exactly one .html file unless the user explicitly requests another delivery format.

Put all CSS in a <style> element in the document <head>.

Never use CSS @import, external stylesheets, remote fonts, icon libraries, frameworks, or build steps.

Do not use url(...) for decorative CSS assets. Create atmosphere with gradients, borders, and CSS shapes.

Keep JavaScript inline and dependency-free. The page's core content must remain understandable if JavaScript fails.

Use inline SVG only when a real diagram or icon needs it. Give meaningful SVGs an accessible name and mark decorative SVGs aria-hidden="true".

External destinations may be ordinary links. User-provided content images are allowed, but do not introduce remote imagery merely as decoration.

Set the viewport meta tag, a useful document title, and a concise meta description.

Style Invariants

Use a mono-first type system. Large display text is heavy and compact; body text stays readable with generous line height.

Keep the content shell near 808px on wide screens and fluid on small screens.

Use one atmospheric magenta-red-violet field behind a subtle square grid. It is background atmosphere, not a card fill.

Build surfaces from translucent background color, a one-pixel semantic border, 8px to 10px radii, and a short downward shadow.

Default to readable cards, prose, tables, steps, charts, and diagrams. Use full terminal chrome only when the source content is genuinely command-line material such as a command, trace, REPL, or log; never use it to frame an ordinary recommendation or summary.

Use accent colors by role: yellow for prompts and active markers, green for commands and positive state, blue/lavender for links, pink for hints, red for destructive or failed state.

Prefer small status dots, text labels, and typographic symbols over decorative icon sets.

Keep animation sparse: a short reveal, cursor blink, or state transition. Honor prefers-reduced-motion.

Content Rules

Write content for the user's purpose. Do not mention this skill, the source blog, Stanley, or the template in the generated page.

Do not invent shell syntax for ordinary headings, decisions, plans, or takeaways. Prompt motifs belong only to real command-oriented content.

Do not use fake metrics, endorsements, activity feeds, or status claims unless clearly labeled as illustrative sample data.

For plans, expose sequence, owner or scope, dependencies, and completion state where relevant.

For demos, make the primary interaction functional and show its state visibly.

For visualizations, include units, labels, a legend when needed, and an accessible text summary. CSS bars are suitable for small categorical comparisons; use inline SVG for real axes or connected data.

For long-form explanations, use the .prose treatment and bordered heading rhythm instead of stacking many cards.

Final Check

Before returning the file, verify all of the following:

No sample content remains.

No external CSS, font, script, or icon dependency exists.

The page has one obvious primary artifact and action hierarchy.

Every interactive control works with keyboard focus and has an accessible name.

Light and dark themes remain legible if both are retained.

The page works at 390px and around 1440px without horizontal page scrolling.

Reduced-motion users do not receive essential information only through animation.

prismatic-terminal-ui