Update to FreakUI

{
  "name": "build-dashboard",
  "description": "Design and implement a distinctive, adaptive SwiftUI dashboard with FreakUI charts and data-display components. Use for overview, metrics, progress, balance, nutrition, finance, or workout dashboards in an existing FreakUI project.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 323
    },
    {
      "relative_path": "assets/freakui-icon.svg",
      "size_in_bytes": 20384
    },
    {
      "relative_path": "references/dashboard-system.md",
      "size_in_bytes": 3024
    }
  ],
  "skill_md_contents": "---\nname: build-dashboard\ndescription: Design and implement a distinctive, adaptive SwiftUI dashboard with FreakUI charts and data-display components. Use for overview, metrics, progress, balance, nutrition, finance, or workout dashboards in an existing FreakUI project.\n---\n\n# Build a FreakUI dashboard\n\nTurn real product data and actions into one clear dashboard hierarchy. This skill works locally in an existing project and does not call the FreakUI generation service.\n\nRead [dashboard-system.md](references/dashboard-system.md) before proposing or implementing the dashboard.\n\n## Workflow\n\n1. Read the active workspace instructions, then inspect the project's architecture, current dashboard or destination screen, data model, state flow, navigation, theme, supported platforms, and installed FreakUI version.\n2. Determine whether the user wants a layout proposal or implementation. For a proposal, provide the hierarchy and component choices without editing. For implementation, preserve the project's existing architecture and authorization boundaries.\n3. Identify the smallest useful information hierarchy: summary, progress, trend, breakdown, recent activity, and primary action. Include only sections supported by real data or explicitly requested placeholders.\n4. Map each section to the narrowest FreakUI component in the reference. Inspect the exact public API in the installed FreakUI source or Xcode interface before coding; do not guess initializers or copy product-specific code from another app.\n5. Build one semantic dashboard that adapts across the project's supported platforms. Prefer shared data and section composition with deliberate layout adaptation over duplicated product logic.\n6. Keep formatting, aggregation, loading, empty, and error behavior explicit. Preserve accessibility labels, Dynamic Type, keyboard behavior, and the project's existing interaction model.\n7. Run only verification authorized by the active workspace. Never claim a platform build succeeded when it was skipped or failed.\n\n## Quality bar\n\n- Establish one dominant summary before secondary metrics.\n- Use charts only when they reveal a comparison, distribution, progress, or trend more clearly than text.\n- Use FreakUI theme colors, typography, spacing, radius, component sizes, and surface appearances instead of recreating a parallel design system.\n- Avoid a uniform card grid. Vary hierarchy through component role, size, span, and composition while keeping a coherent rhythm.\n- Keep business rules and data mutations outside presentation views.\n\n## Handoff\n\nReport the dashboard structure, exact files changed, supported platform behavior, and verification performed. Keep technical output concise and name one concrete remaining action when verification is incomplete.\n"
}