agentleFS
Sign inStart free
thoitiettxl-cyberthoitiettxl-cyber/Claw-II/skills/frontend-design/SKILL.md

frontend-design

Skill2 starsChanged 7 months agoMITView on GitHub

Canonical OpenClaw frontend skill for UI/UX direction, review, component guidance, and direct frontend implementation. Use when tasks involve choosing design direction, reviewing interface quality, or building/refactoring production-grade HTML/CSS/JS UI within Android OpenClaw runtime constraints.

187 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use instantly-campaign, albert-dm and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • yawningwhaleAISkill

    instantly-campaign

    Create a new Instantly cold-email campaign in the proven 5-email structure of the user's top-performing campaign (~16% reply rate). Use when the user wants to launch a new outbound campaign, write a cold email sequence, create an Instantly campaign, draft outreach for a new service or niche, or set up a sales sequence.

    Also in 6 projects that use this

  • yawningwhaleAISkill

    albert-dm

    Reply to DMs and messages the way Albert would. Use when the user asks "how would Albert reply to this", pastes a conversation and wants an Albert-style response, or asks you to draft/write a DM in Albert's voice. Albert sells AI voice agents / automations to local service businesses (Go High Level, lead follow-up, bookings).

    Also in 5 projects that use this

  • naman10parikhSkill

    ecosystem-reference

    Quick-access directory of Claude Code ecosystem repos, skills, plugins, MCPs, and patterns. Use when improving the harness.

    Also in 5 projects that use this

  • naman10parikhSkill

    fractal-delegation

    Also in 5 projects that use this

  • julianoczkowskiSkill

    brief-to-tasks

    Break a design brief into an ordered checklist of independently buildable tasks using vertical slices. Saves as a markdown checklist. Use when user wants to break down work, create tasks from a brief, plan implementation order, or mentions "tasks" or "breakdown".

    Also in 7 projects that use this

  • SeifBenayedSkill

    file-reading

    Use this skill when a file has been uploaded but its content is NOT in your context — only its path at /mnt/user-data/uploads/ is listed in an uploaded_files block. This skill is a router: it tells you which tool to use for each file type (pdf, docx, xlsx, csv, json, images, archives, ebooks) so you read the right amount the right way instead of blindly running cat on a binary. Triggers: any mention of /mnt/user-data/uploads/, an uploaded_files section, a file_path tag, or a user asking about an uploaded file you have not yet read. Do NOT use this skill if the file content is already visible in your context inside a documents block — you already have it.

    Also in 6 projects that use this

  • +6 more from naman10parikh

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 13 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 181 edited versions we read keep these.

  • 13

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If a task spans multiple modes, sequence them explicitly instead of mixing them silently.

    line 80
  2. Distinctive:

    Read only the minimum references needed for that mode.

    line 101
  3. Distinctive:

    If implementing UI, keep runtime behavior truthful:

    line 109
  4. Very specific:

    keep webroot split predictable (index.html, styles.css, scripts.js) unless a different file shape is explicitly required

    line 111
  5. Distinctive:

    no external assets/network by default

    line 116
  6. Distinctive:

    no lifecycle/backend contract drift unless explicitly requested

    line 117
  7. Distinctive:

    Call out anti-patterns, unknowns, and trade-offs explicitly.

    line 118
  8. Distinctive:

    If cutting artifacts/config, keep rollback path and report verification evidence.

    line 119
  9. Distinctive:

    Do not hardcode secrets/tokens in frontend artifacts.

    line 128
  10. Distinctive:

    Do not use hover-only critical actions.

    line 129
  11. Distinctive:

    Do not let decorative styling reduce readability or state clarity.

    line 130
  12. Distinctive:

    Do not use external assets/network by default.

    line 131
  13. Distinctive:

    Do not claim production-ready/done without verification evidence.

    line 132
  14. Very specific:

    Do not convert the skill into installer/bootstrap/devops workflow.

    line 133
  15. Distinctive:

    Do not silently mix multiple primary style languages in one flow unless bounded and intentional.

    line 134

“Common” is measured: kept by at least 6 in 10 of the 181 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Frontend Design (Canonical Merged Skill)

Indexed Reference Map

  • @[SKILL.md#L12-L176] Frontmatter + merged scope + mode taxonomy + SOP + output contract
  • @[references/INDEX.md#L1-L40] Reading order + doc-purpose map
  • @[references/PORTING_MAP.md#L1-L37] Original-source preservation / transformation / omission rationale
  • @[references/QUICK_REFERENCE.md#L1-L33] Cross-mode decision priority and fast checks
  • @[references/BREADTH_APPENDIX.md#L1-L78] Source-breadth signals preserved from the original design-intelligence corpus
  • @[references/PRODUCT_TYPE_MATRIX.md#L1-L35] Product/page classification guidance
  • @[references/STYLE_MATRIX.md#L1-L32] Style fit / constraints / rejection criteria
  • @[references/COLOR_DIRECTION.md#L1-L25] Palette direction and semantic color rules
  • @[references/TYPOGRAPHY_PAIRING.md#L1-L24] Typography pairing guidance
  • @[references/LANDING_PATTERNS.md#L1-L24] Landing/page structure and CTA rules
  • @[references/CHART_SELECTION.md#L1-L23] Chart-choice guidance with a11y constraints
  • @[references/STACK_GUIDANCE.md#L1-L28] Stack-aware UI guidance without install/bootstrap drift
  • @[references/UI_REVIEW_CHECKLIST.md#L1-L39] Structured UI review rubric
  • @[references/ANTI_PATTERNS.md#L1-L21] Explicit rejection patterns and OpenClaw-specific no-go rules
  • @[references/openclaw-module-checklist.md#L1-L7] Android/OpenClaw runtime integration constraints
  • @[references/agent-context-snippets.md#L1-L5] Status/action/error-flow snippets for implementation work
  • @[references/EXAMPLES.md#L1-L24] Example output shapes by mode
  • @[references/AI_WORKFLOW.md#L1-L12] Bounded AI workflow discipline

Scope

  • In-scope:
    • design-direction: choose product-fit style, palette, typography, layout, interaction tone
    • ui-review: review screenshots/code/UI artifacts for hierarchy, readability, accessibility, consistency, and UX risk
    • component-guidance: advise on one component/screen section with visual + interaction + responsive rules
    • frontend-implementation: directly build or refactor production-grade frontend artifacts (index.html, styles.css, scripts.js) for OpenClaw/module/webroot contexts
    • chart choice, landing structure, stack-aware UI guidance, and design-system-style recommendations bounded to workspace/runtime constraints
  • Out-of-scope:
    • backend/API/database work
    • infra/devops/service lifecycle mutation unless explicitly requested outside this skill
    • package installation/bootstrap/marketplace publishing
    • ungated external fetch/research
    • arbitrary persistence outside assigned workspace paths

Purpose

This is the canonical merged frontend skill. It unifies:

  • the design-intelligence breadth from the advisor port,
  • the direct implementation contract from the original frontend-design,
  • and the Android/OpenClaw runtime discipline required for production module UI work.

Reading Order

  1. references/INDEX.md
  2. references/PORTING_MAP.md
  3. references/QUICK_REFERENCE.md
  4. references/BREADTH_APPENDIX.md
  5. Then read only the docs needed for the selected mode:
    • direction -> product/style/color/typography/landing
    • review -> review checklist + anti-patterns + quick reference
    • component guidance -> quick reference + stack guidance + examples
    • implementation -> OpenClaw module checklist + agent context snippets + any relevant design docs above
  6. references/EXAMPLES.md
  7. references/AI_WORKFLOW.md

Mode Taxonomy

Choose exactly one primary mode per task:

  1. design-direction
    • user lacks a clear visual/product direction
    • output is recommendation, not code-first
  2. ui-review
    • user provides screenshot/UI/code and wants critique or improvement direction
  3. component-guidance
    • user asks about one component/section/pattern
  4. frontend-implementation
    • user wants runnable UI artifacts, refactor, or an observable web demo/server

If a task spans multiple modes, sequence them explicitly instead of mixing them silently. Typical sequence:

  • design-direction -> frontend-implementation
  • ui-review -> frontend-implementation

Coverage Matrix

  • Product/page direction -> PRODUCT_TYPE_MATRIX.md, LANDING_PATTERNS.md, COLOR_DIRECTION.md, TYPOGRAPHY_PAIRING.md, BREADTH_APPENDIX.md
  • Style selection -> STYLE_MATRIX.md, ANTI_PATTERNS.md, BREADTH_APPENDIX.md
  • UI review -> UI_REVIEW_CHECKLIST.md, ANTI_PATTERNS.md, QUICK_REFERENCE.md
  • Component guidance -> QUICK_REFERENCE.md, STACK_GUIDANCE.md, EXAMPLES.md
  • Chart/data-display guidance -> CHART_SELECTION.md, BREADTH_APPENDIX.md
  • Runtime/webroot implementation -> openclaw-module-checklist.md, agent-context-snippets.md, this SKILL.md
  • Source fidelity / port boundary -> PORTING_MAP.md, BREADTH_APPENDIX.md

Trigger Rules

  • Positive: use when the user asks to design/refactor/review frontend UI, choose style/palette/layout/typography, critique usability/accessibility, shape landing/dashboard direction, advise on component UX, or directly build a frontend demo/webroot UI.
  • Negative: do not use for backend bugs, service operations, package setup, generic coding unrelated to UI decisions, or current-event/external research tasks.
  • Escalation: if the requested action needs external assets/docs, install flows, large-scale product mutations, or writing outside approved workspace paths, pause and get approval first.

SOP

  1. Classify into one primary mode.
  2. Read only the minimum references needed for that mode.
  3. Ground decisions in this priority order:
    • usability
    • accessibility
    • clarity/hierarchy
    • consistency
    • performance-aware interaction
    • visual polish
  4. If implementing UI, keep runtime behavior truthful:
    • reflect real service/runtime state from verifiable sources
    • keep webroot split predictable (index.html, styles.css, scripts.js) unless a different file shape is explicitly required
    • distinguish transport error, runtime error, and UI validation error
  5. Preserve OpenClaw boundaries:
    • workspace-first
    • no secret hardcoding
    • no external assets/network by default
    • no lifecycle/backend contract drift unless explicitly requested
  6. Call out anti-patterns, unknowns, and trade-offs explicitly.
  7. If cutting artifacts/config, keep rollback path and report verification evidence.

Error Handling

  • Missing visual/context evidence -> ask for screenshot/code/path or state assumptions explicitly; do not invent exact defects.
  • Conflicting goals (e.g. more flashy vs more accessible) -> prioritize usability/accessibility and state the trade-off.
  • Scope drift into tooling/install/network -> stop at UI reasoning/build boundary and redirect or request approval.
  • Runtime uncertainty in implementation mode -> present degraded state instead of fake status.

Guardrails

  • Do not hardcode secrets/tokens in frontend artifacts.
  • Do not use hover-only critical actions.
  • Do not let decorative styling reduce readability or state clarity.
  • Do not use external assets/network by default.
  • Do not claim production-ready/done without verification evidence.
  • Do not convert the skill into installer/bootstrap/devops workflow.
  • Do not silently mix multiple primary style languages in one flow unless bounded and intentional.

Output Contract

Return exactly one bounded result matching the selected mode:

Design Direction

  • product/page classification
  • recommended style direction
  • palette direction
  • typography direction
  • layout/landing pattern
  • interaction tone
  • anti-patterns to avoid
  • implementation notes if relevant

UI Review

  • findings
  • severity
  • evidence/symptom
  • why it matters
  • fix direction
  • quick wins
  • deeper refactor notes if needed

Component Guidance

  • goal and usage context
  • visual rules
  • interaction rules
  • accessibility checks
  • responsive constraints
  • stack-aware notes if relevant
  • anti-patterns

Frontend Implementation

  • Design Intent
  • file tree / architecture
  • full source for key files (index.html, styles.css, scripts.js or explicitly justified equivalent)
  • verification report
  • risk notes / fallback / rollback path

Verification / Compliance Verdict

  • PASS when the result stays within frontend/UI scope, respects OpenClaw runtime boundaries, and is traceable to the relevant references.
  • FAIL when the response drifts into backend/tooling/install/runtime-fabrication or skips required evidence for implementation claims.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free