Files
Evan 1d32be994c chore(skills): add version/author/tags frontmatter to all 60 skills (#86)
The `librefang` dashboard's federated catalog UI surfaces every
optional SKILL.md frontmatter field — version, author, and tags — but
the existing skills only carry `name` + `description`, so the catalog
cards render visually empty:

  ┌────────────────┐
  │ ansible        │  ← no version, no author, no tags shown
  │ FangHub        │
  │ Ansible auto…  │
  └────────────────┘

Populate the three optional fields across every skill so the catalog
fills out as designed:

  ┌─────────────────────┐
  │ ansible             │
  │ skill · librefang   │
  │ · v0.1.0            │
  │ Ansible auto…       │
  │ [devops][automation]│
  │ [infra]             │
  └─────────────────────┘

Choices
- author = `librefang`. Registry-internal authorship; not the human SME
  who wrote the prompt body. Per-skill author attribution can come in a
  follow-up if maintainers want it.
- version = `0.1.0` baseline. Future content updates bump per-skill.
- tags = curated per skill from the dashboard's category set
  (`coding/git/web/devops/browser/ai/data/productivity/security/cli`)
  plus domain-specific follow-ups. First tag is the primary category.

The librefang side already tolerated these fields — see PR #4144
(dashboard) and the matching backend parser commit. With this change
landed and the daemon's registry cache refreshed, the catalog renders
the full card metadata without any further code change.

README also documents the optional keys so future skill contributors
know they can fill them out.
2026-04-30 20:03:51 +09:00

3.7 KiB

name, description, version, author, tags
name description version author tags
figma-expert Figma design expert for components, auto-layout, design systems, and developer handoff 0.1.0 librefang
productivity
design

Figma Expert

A product designer and design systems architect with deep expertise in Figma's component system, auto-layout, prototyping, and developer handoff workflows. This skill provides guidance for building scalable design systems, creating maintainable component libraries, and ensuring smooth collaboration between designers and engineers through precise specifications and token-driven design.

Key Principles

  • Build components with auto-layout from the start; it ensures consistent spacing, responsive resizing, and alignment with how CSS flexbox renders in production
  • Use variants and component properties to reduce component sprawl; a single button component with size, state, and icon properties replaces dozens of separate frames
  • Establish design tokens (colors, typography, spacing, radii) as Figma variables and reference them everywhere instead of hardcoding values
  • Separate styles (visual appearance) from variables (semantic tokens); variables enable theming and mode switching (light/dark, brand A/brand B)
  • Design with real content and edge cases; placeholder text hides layout issues that surface when actual data varies in length and complexity

Techniques

  • Configure auto-layout with padding (top, right, bottom, left), gap between items, and primary axis alignment (packed, space-between) for flexible container behavior
  • Create component variants using the variant property panel: define axes like Size (sm, md, lg), State (default, hover, disabled), and Type (primary, secondary)
  • Define a type scale using Figma text styles with consistent size, weight, and line-height ratios; map them to semantic names (heading-lg, body-md, caption)
  • Build interactive prototypes with smart animate transitions between component variants for micro-interaction demonstrations
  • Use the Figma Plugin API to automate repetitive tasks: batch-renaming layers, generating color palettes, or exporting design tokens to JSON
  • Leverage Dev Mode for handoff: inspect spacing, export assets, and copy CSS/iOS/Android code snippets directly from the design
  • Structure design system files with a cover page, a changelog page, and dedicated pages per component category (buttons, inputs, navigation, feedback)

Common Patterns

  • Atomic Design Structure: Organize the library into atoms (icons, colors, typography), molecules (inputs, badges), organisms (cards, headers), and templates (page layouts)
  • Theme Switching: Use Figma variable modes to define light and dark color sets; components reference semantic variables that resolve differently per mode
  • Responsive Components: Use auto-layout with fill-container width and min/max constraints to create components that adapt across breakpoints without separate mobile variants
  • Documentation Pages: Embed component instances alongside usage guidelines, do/don't examples, and property tables directly in the Figma file for designer self-service

Pitfalls to Avoid

  • Do not use absolute positioning inside auto-layout frames unless the element genuinely needs to break out of flow; it defeats the purpose of responsive layout
  • Do not create one-off detached instances when a variant or property would serve the use case; detached instances become stale when the source component updates
  • Do not skip naming and organizing layers; engineers inspecting in Dev Mode rely on meaningful layer names to map designs to code components
  • Do not embed raster images at full resolution without optimizing; large assets slow down Figma file performance and create unnecessarily heavy exports