数据库设计
- 作者仓库星标 977
- 叉子 74
- 许可证 MIT
- 作者更新于 2026年6月15日 03:09
- 作者仓库 Axiom
- 领域
- 设计与多媒体
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 94 / 100 · 已通过审计
- 作者 / 版本 / 许可
- @CharlesWiltgen · MIT
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- macOS
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生，可能与作者实际意图存在差异。
需要注意： 未限定 allowed-tools，默认拥有全部工具权限。
---
name: axiom-design
description: Use when making design decisions, implementing HIG patterns, Liquid Glass, SF Symbols, typograph…
category: 设计与多媒体
runtime: 无特殊运行时
---
# axiom-design 输出预览
## PART A: 任务判断
- 适用问题：视觉内容、演示材料、信息图或设计交付。
- 输入要求：目标材料、限制条件、期望输出和验收方式。
- 证据边界：围绕“Quick Reference / Decision Tree / Conflict Resolution”读取原文规则，不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断：确认你的需求是否属于视觉内容、演示材料、信息图或设计交付，并标出输入、限制和预期结果。
- **02** 执行计划：优先按“Quick Reference / Decision Tree / Conflict Resolution”拆成步骤，说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果：给出可复制的命令、文件改动、检查清单或内容草稿，并说明如何继续迭代。
- **04** 风险边界：结合 读取文件、写入/修改文件、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件；主要在本地完成；通常不需要额外 API Key。
- 先小样例验证，再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 先确认触发方式
原文出现了 `/skill` 这类斜杠命令；如果你的 Agent 支持命令触发，优先用命令开场，再补充目标和边界。
给清楚输入和边界
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是：读取文件、写入/修改文件。
小样例验证后再放大
先用一个小任务确认它会围绕“Quick Reference / Decision Tree / Conflict Resolution”工作；涉及文件或命令时，先看 diff、日志、预览或测试结果。
复核后再交付
检查最终产物是否包含明确结果、必要证据和下一步动作；如果输出泛泛而谈，就补充输入、边界和验收标准后重跑。
---
name: axiom-design
description: Use when making design decisions, implementing HIG patterns, Liquid Glass, SF Symbols, typograph…
category: 设计与多媒体
source: CharlesWiltgen/Axiom
---
# axiom-design
## 什么时候使用
- 做 Apple 平台界面决策时，避免偏离 HIG 规范 适合处理界面、视觉、封面、信息图或演示材料交付，核心价值是把输入、判断、执行、验证和交付边界固定下来，避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤；通常…
- 面向视觉内容、演示材料、信息图或设计交付，优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Quick Reference / Decision Tree / Conflict Resolution」组织步骤，不把推断写成作者事实。
- 读取文件、写入/修改文件；主要在本地完成；通常不需要额外 API Key。
- 先跑小样例，确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown，不编造命令、平台或依赖。 证据边界与执行链路
作者原文负责流程事实；仓库文件负责来源和命令；流狐只补充适用场景、限制和质量判断。
skill "axiom-design" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Quick Reference / Decision Tree / Conflict Resolution
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
}Design & HIG
You MUST use this skill for ANY visual design, HIG compliance, Liquid Glass, SF Symbols, typography, or app composition work.
Quick Reference
| Symptom / Task | Reference |
|---|---|
| Design decisions, HIG compliance, colors, backgrounds | See skills/hig.md |
| Semantic colors, custom color patterns, material styles | See skills/hig-ref.md |
| Liquid Glass effects, adoption, migration from blur effects | See skills/liquid-glass.md |
| App-wide Liquid Glass adoption, backward compatibility | See skills/liquid-glass-ref.md |
| SF Symbols rendering modes, effects, animations | See skills/sf-symbols.md |
| SF Symbols API signatures, UIKit equivalents, availability | See skills/sf-symbols-ref.md |
| San Francisco fonts, text styles, Dynamic Type, tracking | See skills/typography-ref.md |
| App entry points, auth flows, root view switching, scene lifecycle, document-based apps | See skills/app-composition.md |
| Apple Pay button / Wallet pass design / Tap to Pay button | See axiom-payments suite, plus skills/hig.md for cross-cutting HIG context |
Decision Tree
digraph design {
start [label="Design task" shape=ellipse];
what [label="What do you need?" shape=diamond];
start -> what;
what -> "skills/hig.md" [label="design decision,\nHIG compliance,\ncolor/background choice"];
what -> "skills/hig-ref.md" [label="semantic color API,\ncustom color code,\nmaterial style details"];
what -> "skills/liquid-glass.md" [label="Liquid Glass effects,\nmigrate from blur,\nRegular vs Clear"];
what -> "skills/liquid-glass-ref.md" [label="app-wide Liquid Glass plan,\nplatform differences,\nbackward compat"];
what -> "skills/sf-symbols.md" [label="rendering mode choice,\nsymbol effects/animations,\ncustom symbols"];
what -> "skills/sf-symbols-ref.md" [label="SF Symbols API syntax,\nUIKit equivalents,\navailability matrix"];
what -> "skills/typography-ref.md" [label="font selection,\nDynamic Type,\ntext styles, tracking"];
what -> "skills/app-composition.md" [label="@main entry point,\nauth flow, root view,\nscene lifecycle"];
}- Design decision / HIG compliance / choosing colors or backgrounds? →
skills/hig.md1a. Need semantic color API, custom color code, or material style details? →skills/hig-ref.md - Liquid Glass effects / migrating from blur / Regular vs Clear variant? →
skills/liquid-glass.md2a. Planning app-wide Liquid Glass adoption / platform differences / backward compatibility? →skills/liquid-glass-ref.md - SF Symbols rendering mode / symbol effects / custom symbols? →
skills/sf-symbols.md3a. Need SF Symbols API syntax / UIKit equivalents / availability check? →skills/sf-symbols-ref.md - Font selection / Dynamic Type / text styles / tracking / leading? →
skills/typography-ref.md - App entry point / auth flow / root view switching / scene lifecycle? →
skills/app-composition.md - SwiftUI view implementation? →
/skill axiom-swiftui - TextKit / rich text editing / Writing Tools? →
/skill axiom-uikit - Accessibility compliance (VoiceOver, contrast, touch targets)? →
/skill axiom-accessibility - Audit UI for Liquid Glass adoption? → liquid-glass-auditor (Agent — surfaces migration opportunities AND adoption-completeness gaps: variant discipline, nesting hygiene, availability gating, primary-action tinting, accessibility re-check; scores ADOPTED / PARTIAL / NOT ADOPTED)
- CarPlay app design, categories, driver-distraction rules? →
/skill axiom-media(carplay-hig.md)
Platform-specific HIG
- watchOS design (glanceable UI, watchOS 10 navigation) → See axiom-watchos (skills/design-for-watchos.md)
Conflict Resolution
design vs swiftui: When building UI:
- Use design FIRST — Decide what to build (colors, materials, typography, layout intent) before how to build it.
- Then use swiftui — Implement the design decision in SwiftUI code.
design vs accessibility: When choosing colors or typography:
- Color contrast or Dynamic Type compliance? → use accessibility
- Which semantic color or text style to pick? → use design
design (liquid-glass) vs swiftui: When implementing Liquid Glass:
- What Liquid Glass is, when to use Regular vs Clear, migration strategy → use design (
skills/liquid-glass.md) - SwiftUI code for
.glassEffect()modifier → use design (skills/liquid-glass-ref.md), then swiftui for surrounding view code
design (app-composition) vs swiftui: When structuring app architecture:
- @main entry, auth state machine, root view switching, scene lifecycle → use design (
skills/app-composition.md) - NavigationStack, NavigationSplitView, tab structure → use swiftui
design vs media (CarPlay): When designing for CarPlay:
- General iOS HIG principles (colors, typography, Liquid Glass) → use design
- CarPlay-specific rules (app categories, entitlement review, template-only UI, driver distraction, per-category design rules) → invoke axiom-media (
skills/carplay-hig.md) - CarPlay rules are stricter than iOS HIG and enforced at entitlement review, not just App Store review.
Critical Patterns
HIG Quick Decisions (skills/hig.md):
- Background color decision tree (media-focused vs standard)
- Typography selection (headline vs body vs caption)
- Color usage guidelines and when to use semantic vs custom colors
- Design review checklist for HIG compliance
HIG Comprehensive Reference (skills/hig-ref.md):
- All semantic colors with platform availability
- Custom color patterns with dark mode support
- Background hierarchy and material styles
- Code examples for every color and background pattern
Liquid Glass (skills/liquid-glass.md):
- What Liquid Glass is and how it differs from blur effects
- Regular vs Clear variant selection
- Migration strategy from pre-iOS 26 materials
- Tinting, legibility, and adaptive behavior troubleshooting
- Expert review criteria for Liquid Glass implementations
Liquid Glass Adoption (skills/liquid-glass-ref.md):
- App-wide adoption planning (icons, controls, navigation, menus)
- Platform-specific behavior (iOS, iPadOS, macOS, tvOS, watchOS)
- Backward compatibility strategy for supporting pre-Liquid Glass
- Accessibility compliance with Liquid Glass interfaces
SF Symbols (skills/sf-symbols.md):
- Rendering mode selection (Monochrome, Hierarchical, Palette, Multicolor)
- Symbol effect selection (Bounce, Pulse, Scale, Wiggle, Rotate, Breathe, Draw)
- Custom symbol creation workflow
- Troubleshooting effects not playing, weight mismatches
SF Symbols API (skills/sf-symbols-ref.md):
- Exact API signatures for rendering modes and effects
- UIKit/AppKit equivalents for every SwiftUI symbol API
- Platform availability matrix
- Configuration options (weight, scale, variable values)
Typography (skills/typography-ref.md):
- San Francisco font system (Pro, Compact, Mono, New York)
- Text styles with Dynamic Type scaling
- Tracking and leading values
- Internationalization considerations
App Composition (skills/app-composition.md):
- @main entry point and root view patterns
- Authentication state machine (login, onboarding, main)
- Flicker-free root view switching
- scenePhase lifecycle handling and state restoration
- Document-based apps: the
OS27@Observabledocument model (ReadableDocument/WritableDocument) +DocumentGroup
Anti-Rationalization
| Thought | Reality |
|---|---|
| "I'll just pick colors that look good" | Semantic colors adapt to dark mode, accessibility settings, and platform automatically. Custom colors need all of that manually. skills/hig.md has the decision tree. |
| "Liquid Glass is just a blur effect" | Liquid Glass is a distinct material system with lensing, tinting, and adaptive behavior. Using .blur() instead creates a visually wrong result. skills/liquid-glass.md explains the difference. |
| "I know which SF Symbol rendering mode to use" | The right mode depends on context (monochrome for toolbars, hierarchical for depth, palette for brand colors). skills/sf-symbols.md has the decision tree. |
| "I'll hardcode font sizes" | Hardcoded sizes break Dynamic Type, violate HIG, and fail accessibility review. skills/typography-ref.md shows the text style system. |
| "I'll handle auth state with a boolean" | A boolean can't represent login, onboarding, and main states without race conditions. skills/app-composition.md has the state machine pattern. |
| "Liquid Glass adoption means rewriting my whole UI" | Most standard SwiftUI/UIKit components adopt automatically. Start by building with latest Xcode, then review. skills/liquid-glass-ref.md has the incremental strategy. |
| "I'll add the SF Symbol animation later" | Symbol effects are the primary way users perceive interactive feedback. Shipping without them feels broken. skills/sf-symbols.md covers selection. |
| "I'll skip the design review, the code works" | HIG compliance affects App Store review. Reviewers reject apps that feel wrong even if they function correctly. skills/hig.md has the review checklist. |
Example Invocations
User: "Should I use a dark or light background?"
-> Read: skills/hig.md
User: "What semantic color should I use for secondary text?"
-> Read: skills/hig-ref.md
User: "How do I implement Liquid Glass in my app?"
-> Read: skills/liquid-glass.md
User: "I need to plan Liquid Glass adoption across my whole app"
-> Read: skills/liquid-glass-ref.md
User: "My SF Symbol is flat, I want it to have depth"
-> Read: skills/sf-symbols.md
User: "What's the SwiftUI API for symbol effects?"
-> Read: skills/sf-symbols-ref.md
User: "Which font should I use for body text?"
-> Read: skills/typography-ref.md
User: "How do I switch between login and main screens?"
-> Read: skills/app-composition.md
User: "Check my app's UI for HIG compliance"
-> Read: skills/hig.md, then /skill axiom-accessibility for contrast/Dynamic Type
User: "I want my download button icon to animate"
-> Read: skills/sf-symbols.md
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核