Google stitch frontend brief enhancer
Skill host452b/polish/skills/google-stitch-frontend-brief-enhancer
Claude Code skill/plugin that rewrites a raw question into a high-performing LLM prompt by auto-selecting research-backed prompt-engineering strategies.
npx -y skills add host452b/polish --skill google-stitch-frontend-brief-enhancerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when a frontend request is too vague to implement without inventing visual, structural, interaction, responsive, accessibility, content, or acceptance-criteria decisions.
SKILL.md
3.0 KB, as published. Nobody here has run it
Frontend Brief Enhancer
Overview
Turn vague UI language into a bounded, implementation-ready brief. Increase specificity without converting guesses into requirements or starting implementation.
Workflow
- Preserve the request. Quote the user's goal and non-negotiable wording. Inspect
DESIGN.md, existing components, screenshots, or product copy when available. - Classify every decision. Separate Confirmed requirements, Reversible assumptions, and Unresolved decisions. Never invent features, workflows, data, metrics, customers, brand assets, or business rules.
- Translate vague language. Convert words such as “premium,” “modern,” or “clean” into observable hierarchy, spacing, typography, color roles, composition, and interaction behavior. Use ui-ux-keywords.md for precise terms, not decoration by thesaurus.
- Specify the experience. Cover purpose, audience, platform, page structure, content hierarchy, components, relevant states, responsiveness, accessibility, motion, content constraints, and boundaries. State when a category is not applicable or unknown.
- Write acceptance criteria. Make each criterion observable: named viewport behavior, keyboard path, focus treatment, state coverage, token reuse, content integrity, and preserved behavior. Avoid “looks polished” or “works well.”
- Stop at the brief. Use brief-template.md. Do not write code, install packages, or silently resolve decisions that would materially change scope.
Decision Rules
| Situation | Response |
|---|---|
Existing DESIGN.md is present | Treat it as the visual contract and cite relevant sections |
| Missing detail is reversible | Recommend one assumption and label it |
| Missing detail changes product behavior | List it as unresolved; do not guess |
| User supplied exact copy or tokens | Preserve them verbatim unless asked to revise |
| Request asks for implementation too | Finish the brief first, then hand it to the implementation workflow |
Example
Vague: “Make settings feel premium.”
Actionable: “Preserve existing settings and behavior. Use the current token system; strengthen title/section/row hierarchy; define focus, disabled, validation, saving, error, and success treatments where those states exist; specify mobile row collapse and measurable keyboard, contrast, and viewport checks. Brand typography remains unresolved.”
Common Mistakes
- Smuggling assumptions into imperative requirements.
- Adding imaginary sections to make the brief look complete.
- Describing style without component states or responsive behavior.
- Writing acceptance criteria that cannot be tested.
- Continuing into code before the brief boundary is accepted.