Skip to content
skillsafebeta
← Report library
Purpose / Data analysis

Interface Design Skill Security Audit

What the author says it does (original text)

Craft-first interface design for dashboards, admin panels, SaaS apps, tools, settings pages, data interfaces, and interactive products. Use when designing, building, reviewing, auditing, or refining product UI where visual craft, layout hierarchy, tokens, states, visual direction, or design-system consistency matter. Not for marketing pages, landing pages, campaigns, or brand-only work.

Independent security check

Security risks found

Files checked
2
Risks found
3
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.Risks found: 1
Medium risk

Build and test steps can execute arbitrary repository-defined scripts

Source references: 1
What we found

The Skill tells the agent to run available build, typecheck, and test commands after editing, without first requiring inspection of what those commands execute. Project manifests or test configuration can map ordinary command names to arbitrary local programs.

Why this matters

In an untrusted repository, a script could read credentials or files available to the agent, alter data outside the intended changes, or make network requests. The actual impact depends on the execution environment's permissions.

What this evidence establishes

The Skill does instruct the agent to run relevant build, type-check, and test commands after edits; in some repositories these may invoke project-defined scripts. However, no command, manifest, or test configuration is provided, so arbitrary execution is not established. This is also normal post-change verification. A user can require the exact commands and script definitions to be reviewed first, or permit only pre-approved checks.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:270In the instructionsOpen original file
3. For greenfield screens, major redesigns, or vague direction, consider a visual reference pass *if an image-generation tool is available* (skip otherwise — it's a companion, never the deliverable). Four modes: **direction board** (2–3 abstract mood/material/color explorations before code — no real UI), **UI reference** (medium-fidelity composition for a chosen direction), **paintover** (a stronger version of an existing screenshot), **raster asset** (empty-state art, textures — never icons/logos/charts). Always reject generic SaaS, illegible text, off-domain palettes; extract palette/density/proportions/signature, then build it in real code and verify in the browser.4. Patch the implementation, then run the relevant build/typecheck/tests when available.5. Verify visually for non-trivial UI. Use the inline render tool, a local browser, or screenshots at desktop and mobile widths; fix overlap, broken spacing, blank states, unreadable text, missing assets, and generic composition before presenting.
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 1
Medium risk

Image-reference and paintover workflows may disclose sensitive UI data to an image tool

Source references: 2
What we found

The Skill recommends using an image-generation tool, when available, for UI references or a paintover of an existing screenshot. A screenshot from a real admin panel, customer interface, or internal tool may contain names, account details, business metrics, tokens, or other sensitive content.

Why this matters

Sensitive interface content could leave the local project for processing by an image service and become subject to that service's storage, logging, and data-use policies.

The Skill explicitly suggests using an existing screenshot for a paintover when an image tool is available and also permits screenshots for visual verification. If the screenshot comes from a real admin or internal product, it may contain personal, account, or business data that the image tool would then process. The step is conditional, and there is no evidence that any screenshot was uploaded. A user can require sanitized or synthetic screenshots and prohibit sending real customer or credential data to image tools.

SKILL.md:269In the instructionsOpen original file
2. Make the domain exploration concrete before choosing layout, color, type, density, and navigation.3. For greenfield screens, major redesigns, or vague direction, consider a visual reference pass *if an image-generation tool is available* (skip otherwise — it's a companion, never the deliverable). Four modes: **direction board** (2–3 abstract mood/material/color explorations before code — no real UI), **UI reference** (medium-fidelity composition for a chosen direction), **paintover** (a stronger version of an existing screenshot), **raster asset** (empty-state art, textures — never icons/logos/charts). Always reject generic SaaS, illegible text, off-domain palettes; extract palette/density/proportions/signature, then build it in real code and verify in the browser.4. Patch the implementation, then run the relevant build/typecheck/tests when available.
Show 1 other places
SKILL.md:271In the instructionsOpen original file
4. Patch the implementation, then run the relevant build/typecheck/tests when available.5. Verify visually for non-trivial UI. Use the inline render tool, a local browser, or screenshots at desktop and mobile widths; fix overlap, broken spacing, blank states, unreadable text, missing assets, and generic composition before presenting.6. Keep user-facing updates short. Don't expose long private design monologues — surface the useful recommendation or decision.
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.No risks found
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.Risks found: 1
Medium risk

Treating project-local system.md as settled instructions creates a prompt-injection entry point

Source references: 4
What we found

The Skill directs the agent to read and apply `.interface-design/system.md`, declaring that its decisions are already made, without requiring the file to be treated strictly as untrusted design data or limiting which content may influence behavior.

Why this matters

A repository author or compromised dependency could place unrelated agent instructions in that file and attempt to induce broader file access, command execution, or divergence from the user's request. Success still depends on whether the host agent enforces higher-priority rules.

What this evidence establishes

The Skill treats repository-local `.interface-design/system.md` content as settled design decisions and requires applying it, so out-of-scope text there could influence the agent. In context, however, the file is described as design data such as palette, spacing, hierarchy, and component patterns; its contents are absent, and the Skill does not explicitly say to execute commands from it. This creates a trust-boundary concern, but the security impact is not established. A user can require it to be treated only as design data and reject commands, credential requests, or out-of-scope instructions.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:267In the instructionsOpen original file
1. Inspect the existing app, design tokens, component patterns, and `.interface-design/system.md` if present.2. Make the domain exploration concrete before choosing layout, color, type, density, and navigation.
Show 3 other places
SKILL.md:287In the instructionsOpen original file
## Build flow- **If `.interface-design/system.md` exists:** read it and apply — decisions are made.- **If not:** explore domain (all four outputs) → propose (reference all four) → confirm when the direction is ambiguous or costly to change → build → run the checks below → offer to save.
SKILL.md:288In the instructionsOpen original file
## Build flow- **If `.interface-design/system.md` exists:** read it and apply — decisions are made.- **If not:** explore domain (all four outputs) → propose (reference all four) → confirm when the direction is ambiguous or costly to change → build → run the checks below → offer to save.
SKILL.md:305In the instructionsOpen original file
- Direction and feel- Depth strategy (borders/shadows/layered) and spacing base unit- Hierarchy decisions (type scale ratio, density values, focal pattern)- Key component patterns — add when a component is used 2+ times, is reusable, or has measurements worth remembering (not one-offs or prop variations). Record the values, e.g. `Button primary — 36px h · 12px 16px pad · 6px radius · 14px/500`.- Visual direction notes and selected references when an image pass shaped the design
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

8 instruction sections

This Skill targets product-interface design and refinement. It directs the agent to inspect the existing app, design tokens, and component patterns before patching the implementation and visually verifying it.

View source
SKILL.md:267In the instructionsOpen original file
1. Inspect the existing app, design tokens, component patterns, and `.interface-design/system.md` if present.2. Make the domain exploration concrete before choosing layout, color, type, density, and navigation.3. For greenfield screens, major redesigns, or vague direction, consider a visual reference pass *if an image-generation tool is available* (skip otherwise — it's a companion, never the deliverable). Four modes: **direction board** (2–3 abstract mood/material/color explorations before code — no real UI), **UI reference** (medium-fidelity composition for a chosen direction), **paintover** (a stronger version of an existing screenshot), **raster asset** (empty-state art, textures — never icons/logos/charts). Always reject generic SaaS, illegible text, off-domain palettes; extract palette/density/proportions/signature, then build it in real code and verify in the browser.4. Patch the implementation, then run the relevant build/typecheck/tests when available.5. Verify visually for non-trivial UI. Use the inline render tool, a local browser, or screenshots at desktop and mobile widths; fix overlap, broken spacing, blank states, unreadable text, missing assets, and generic composition before presenting.6. Keep user-facing updates short. Don't expose long private design monologues — surface the useful recommendation or decision.

It prioritizes existing native controls, component libraries, design systems, and semantic tokens, discouraging custom controls that lack accessibility behavior.

View source
SKILL.md:180In the instructionsOpen original file
1. **Native HTML first** where it works. A `<button>` is a button; an `<a>` is a link; `<input type="text">`, `<dialog>`, `<details>` exist. Never `<div onClick>` something the platform already provides — you lose focus, keyboard, and semantics for free.2. **A battle-tested headless primitive** for anything stateful and hard to get right — select, combobox, dialog, popover, tooltip, dropdown menu, tabs, date picker. These ship keyboard navigation, focus management, ARIA, and collision/positioning that take days to reproduce correctly. Reach for what the ecosystem already trusts (e.g. Radix UI, React Aria, Ark, Headless UI, Vaul, `cmdk` in React; the equivalent accessible primitive in other frameworks), then style it to your direction. "Build custom" means *compose and style a primitive*, not write the behavior from scratch.3. **Hand-roll only as a genuine last resort** — no primitive fits, or there's no dependency budget. Then you owe the complete behavior contract: keyboard nav (arrow keys, Enter, Escape), focus trap/return, full ARIA roles and state, click-outside, and scroll-lock for overlays. A styled control missing these is broken, however good it looks.

Persisting design conventions is not automatic: the Skill says to ask the user first and write `.interface-design/system.md` only if the user agrees.

View source
SKILL.md:301In the instructionsOpen original file
# After Completing a TaskAlways offer to save: "Want me to save these patterns for future sessions?" If yes, write to `.interface-design/system.md`:- Direction and feel- Depth strategy (borders/shadows/layered) and spacing base unit- Hierarchy decisions (type scale ratio, density values, focal pattern)- Key component patterns — add when a component is used 2+ times, is reusable, or has measurements worth remembering (not one-offs or prop variations). Record the values, e.g. `Button primary — 36px h · 12px 16px pad · 6px radius · 14px/500`.- Visual direction notes and selected references when an image pass shaped the design
Start here · InstructionsSKILL.md
interface-design
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 7 more sections are available in the original file.
Files and check records2 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • agents/openai.yamlFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
  • agents/openai.yamlSupporting file
Lines read
328
File checksum (to compare versions)
095caf4408fa17512dabf80a273fd5ba1b186bc6159d75dae7542e126a29d668