Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/gaelic-ghost/socket/swiftui-liquid-glassnpx skills add gaelic-ghost/socket --skill swiftui-liquid-glassgit clone --depth 1 https://github.com/gaelic-ghost/socketWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/gaelic-ghost/socket/swiftui-liquid-glass)<a href="https://agentmods.dev/skills/gaelic-ghost/socket/swiftui-liquid-glass"><img src="https://agentmods.dev/badge/skills/gaelic-ghost/socket/swiftui-liquid-glass.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00055 | $0.01064 |
| Opus 5 | $0.00028 | $0.00532 |
| Sonnet 5 | $0.00011 | $0.00213 |
| Haiku 4.5 | $0.00006 | $0.00106 |
Grade A, and why
swiftui-liquid-glass scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SwiftUI Liquid Glass
Purpose
Use the platform's native glass system deliberately rather than reproducing it with custom blur, opaque fills, or ad hoc material layers. Liquid Glass is a visual-system contract: this workflow owns where it belongs, how related surfaces group, and how earlier systems retain a clear fallback; it does not own a feature's state or navigation architecture.
When To Use
- Use for
glassEffect,GlassEffectContainer, glass button styles,glassEffectID, interactive glass, shape/tint consistency, and iOS/macOS availability handling. - Use when reviewing custom chrome, toolbar, sidebar, card, chip, or action surfaces that visually fight the current platform design.
- Hand off component ownership to
swiftui-app-architecture-workflow, animation mechanics toswiftui-animation-workflow, and desktop/AppKit ownership toappkit-app-architecture-workflow.
Single-Path Workflow
- Apply the Apple docs gate through
explore-apple-swift-docs. Confirm the current platform API, deployment target, and availability before selecting a glass treatment. - Inspect the existing hierarchy, materials, toolbars, controls, backgrounds, shapes, and interaction model. Identify the few semantic surfaces that need emphasis rather than applying glass to every container.
- Classify the work: system-chrome cleanup, one glass surface, a related group of glass controls, interactive action, morphing transition, or cross-version fallback.
- Read
references/glass-composition-and-fallbacks.mdfor composition and availability patterns andreferences/review-and-validation.mdfor visual, accessibility, and performance review. - Prefer native controls, system materials, and standard toolbars before adding custom glass. Apply glass after the layout and visual modifiers that define the surface.
- Use
GlassEffectContaineronly for genuinely related nearby glass elements. Keep shapes, spacing, and tint roles consistent; use interactive glass only for actual controls. - Use
glassEffectIDand a namespace only when the hierarchy changes and a morphing relationship makes the transition clearer. Do not introduce glass IDs as decorative animation noise. - Gate version-sensitive APIs and provide an intentional non-glass fallback that preserves hierarchy, affordance, contrast, and touch/keyboard access.
- Read
references/os26-os27-beta-availability.mdbefore treating an OS 27 beta toolbar feature as a Liquid Glass API change. Core custom-glass APIs remain the OS 26 baseline; OS 27 beta toolbar composition features need their own availability gates and visual validation. - Validate in Light and Dark appearance, compact and regular windows where relevant, reduced-motion and accessibility settings, keyboard/pointer interaction, the oldest supported OS fallback, and OS 27 beta toolbar overflow/visibility behavior when used.
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 66 lines · 55 tokens per session scan A 14f480071321
swiftui-liquid-glass is a skill published in the GitHub repository gaelic-ghost/socket (7 stars, last pushed 9d ago), licensed Apache-2.0. It adds 55 tokens to every session and 1,064 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
interface-craft
Raises the visual and interaction quality of an interface — layout, hierarchy, type, spacing, density, and the details that separate a considered product from a generic one. Use this when a screen works but looks unfinished or default, when a layout feels crowded or arbitrary, when a page has no clear focal point, or…
design-system
Builds and maintains the design system a product is assembled from — tokens for color, type, spacing and elevation, component contracts, and the rules that keep them coherent as the product grows. Use this when starting a new interface, when screens have drifted apart visually, when the same component exists three…
interface-redesign
Upgrades an existing interface to a higher standard without rebuilding it — auditing what is there, identifying what reads as generic or unfinished, and sequencing changes by impact. Use this when a product works but looks dated or default, when a redesign is being considered, when deciding whether to restyle or…
pipeline
Use when the user wants a feature idea taken end-to-end in one autonomous run — phrases like "run the whole pipeline", "take this feature from idea to finished branch", "brainstorm then build it autonomously", "do everything from idea to merged", "implement all phases without stopping". Triggers when they want…
craft
Use when a product idea is still vague and needs to become a clear definition of what to build — "let's craft an app like X", "help me define what I actually want", "clarify this idea before we plan it". Also use before planning or implementation when requirements, UX, domain behaviour, or technical preferences have…
design-system-specification
Design a production-ready Design System and UI/UX visual style guide. Covers design tokens (colors, typography, spacing, shadows, radius), components (buttons, inputs, cards, tables, modals, navigation), layouts, interaction/hover states, iconography, motion design, responsive behavior, accessibility (WCAG 2.2), and…