# Frontend Style Orchestrator

> Transform user-provided visual style prompts into frontend webpage design or redesign implementations through a repeatable pipeline (style extraction, design contract, token system, implementation, and QA). Use when the user asks to build a web page in a specific style, refactor an existing page to a new style, or iterate through multiple style directions across rounds.

- Skill: `citizenll/frontend-style-orchestrator` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add citizenll/frontend-style-orchestrator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/citizenll/frontend-style-orchestrator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: citizenll (https://skillmd.com/u/citizenll)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/citizenll/frontend-style-orchestrator

---


# Frontend Style Orchestrator

Deliver consistent, high-quality frontend styling outcomes from free-form style prompts.

## Use This Execution Model

1. Read the user prompt and classify the task mode:
   - `build-new`: create a new page/component with the requested style.
   - `restyle-existing`: keep existing structure/business logic and replace visual language.
2. Resolve hard constraints first:
   - Stack and framework.
   - Files that can or cannot be changed.
   - Responsiveness, accessibility, performance constraints.
3. Convert the style prompt into a compact design contract:
   - Mood and tone.
   - Color system.
   - Typography direction.
   - Layout rhythm.
   - Component treatment.
   - Motion behavior.
4. Select a style pack:
   - If a matching pack exists in `references/style-packs/`, adapt it.
   - Otherwise create a new pack using `scripts/new_style_pack.ps1` and fill it.
5. Implement with token-first architecture:
   - Define CSS variables/tokens before component-level styling.
   - Separate structure from skin (layout classes vs style classes).
   - Keep visual decisions centralized for easy iteration.
6. Validate against quality gates in `references/quality-gates.md`.
7. Return concise delivery notes:
   - What changed.
   - Which files were modified.
   - Any tradeoffs or remaining risks.

## Reference Loading Rules

- Read `references/workflow.md` for end-to-end execution order.
- Read `references/style-pack-schema.md` when creating or updating a style pack.
- Read `references/quality-gates.md` before finalizing changes.
- Read only the specific file in `references/style-packs/` that matches the target style.

## Output Contract Per Request

For each style request, produce:

1. `Style Contract` (short): 5-8 bullets describing core visual intent.
2. `Implementation` (code changes): update or create frontend files.
3. `Verification` (short): report responsiveness/accessibility checks completed.

## Iteration Rules

- Keep semantic HTML and behavior intact unless user explicitly asks for structural rewrite.
- Prefer incremental edits for restyling tasks; avoid unnecessary refactors.
- When user sends a new style prompt, create a new style pack or revise an existing one, then re-run the same pipeline.