diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 571335c..c1ecb2b 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -6,22 +6,17 @@ uv run python scripts/init_skill.py my-new-skill ``` -Edit `skills/figma-agent/my-new-skill/SKILL.md`. The directory name and frontmatter `name` must match and use kebab-case. Then generate the Figma upload document: - -```bash -uv run python scripts/sync_figma_documents.py -``` +Edit `skills/figma-agent/my-new-skill/SKILL.md`. The directory name and frontmatter `name` must match and use kebab-case. ## Validate ```bash -uv run python scripts/sync_figma_documents.py --check uv run python scripts/validate_skills.py uv run python tests/test_skills_catalog.py uv run ruff check . uv run ruff format --check . ``` -`SKILL.md` is the skills.sh source of truth. `SKILLS.md` is generated for Figma Design Agents and must remain byte-identical. +Each installable skill is a single `SKILL.md`. Do not add a `SKILLS.md` duplicate. Archived material belongs in `archive/` and must not include a `SKILL.md` file. diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 2c28af5..f37af9d 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,25 +1,20 @@ ## Description - + ## Type of change - - -- [ ] Bug fix (non-breaking change which fixes an issue) -- [ ] New feature (non-breaking change which adds functionality) -- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) +- [ ] Bug fix +- [ ] New feature +- [ ] Breaking change - [ ] Documentation update -- [ ] New Skill - -## Checklist: +- [ ] New skill - +## Checklist -- [ ] My code follows the style guidelines of this project (run `uv run ruff check .`) -- [ ] I have performed a self-review of my own code -- [ ] I have commented my code, particularly in hard-to-understand areas -- [ ] I have made corresponding changes to the documentation (e.g. `SKILLS.md` / `SKILL.md`) -- [ ] My changes generate no new warnings -- [ ] Any dependent changes have been merged and published in downstream modules -- [ ] If this PR adds a new skill, it successfully packages via `uv run python scripts/package_skill.py figma-agent/` \ No newline at end of file +- [ ] Ran `uv run ruff check .` and `uv run ruff format --check .` +- [ ] Ran `uv run python scripts/validate_skills.py` +- [ ] Ran `uv run python tests/test_skills_catalog.py` +- [ ] New or updated skills use kebab-case names matching frontmatter `name` +- [ ] No `SKILLS.md` duplicates were added +- [ ] Docs updated if behaviour or catalogue layout changed diff --git a/.github/workflows/python-ci.yml b/.github/workflows/python-ci.yml index c6e7f6b..9d3a117 100644 --- a/.github/workflows/python-ci.yml +++ b/.github/workflows/python-ci.yml @@ -35,6 +35,5 @@ jobs: - name: Validate skills catalogue run: | - uv run python scripts/sync_figma_documents.py --check uv run python scripts/validate_skills.py uv run python tests/test_skills_catalog.py diff --git a/AGENTS.md b/AGENTS.md index bb77aa8..1e590b8 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -2,18 +2,17 @@ ## Active catalogue -Active skills live under `skills/figma-agent//`. +Installable skills live under `skills/figma-agent//`. -- `SKILL.md` is canonical and is installed by `skills.sh`. -- `SKILLS.md` is generated from `SKILL.md` for direct Figma uploads. -- `archive/` is documentation only; it must never contain `SKILL.md`. +- `SKILL.md` is the only skill document. It is installed by `skills.sh`. +- `archive/` is documentation only. It must never contain `SKILL.md`. +- Do not add duplicate upload documents (`SKILLS.md`) or plugin-manager stubs. ## Create or update a skill ```bash uv run python scripts/init_skill.py my-new-skill # edit skills/figma-agent/my-new-skill/SKILL.md -uv run python scripts/sync_figma_documents.py ``` Use kebab-case names. Keep `name` and `description` in YAML frontmatter; `name` must match the directory name. @@ -21,7 +20,6 @@ Use kebab-case names. Keep `name` and `description` in YAML frontmatter; `name` ## Validation ```bash -uv run python scripts/sync_figma_documents.py --check uv run python scripts/validate_skills.py uv run python tests/test_skills_catalog.py uv run ruff check . diff --git a/README.md b/README.md index 8cce581..8872fb7 100644 --- a/README.md +++ b/README.md @@ -2,41 +2,193 @@ Practical Figma design and product skills for AI agents. -## Quickstart (30 seconds) +This repository is a curated catalogue you can install with [`skills.sh`](https://www.skills.sh/docs). Each skill is a single `SKILL.md` with a clear trigger description and an evidence-backed workflow agents can follow inside Figma. -Install the skills you want with [`skills.sh`](https://www.skills.sh/docs): +--- + +## Quickstart ```bash npx skills@latest add qredence/skills ``` -Choose skills from the Figma catalogue, then choose the agents where you want them installed. - -## Browse the catalogue +1. Choose skills from the Figma catalogue. +2. Choose the agents where you want them installed. +3. Invoke a skill by name or by describing the task it covers. -The active collection lives in [`skills/figma-agent/`](skills/figma-agent/). It includes skills for accessibility, design systems, components, prototyping, research, content, and developer handoff. +List discoverable skills from a clean directory: -Start with: +```bash +npx skills@latest add qredence/skills --list +``` -- [`accessibility-audit`](skills/figma-agent/accessibility-audit/) -- [`component-audit`](skills/figma-agent/component-audit/) -- [`design-tokens-sync`](skills/figma-agent/design-tokens-sync/) -- [`figma-to-code-component`](skills/figma-agent/figma-to-code-component/) -- [`prototype-from-flow`](skills/figma-agent/prototype-from-flow/) -- [`dev-handoff-prep`](skills/figma-agent/dev-handoff-prep/) +Only packages under [`skills/figma-agent/`](skills/figma-agent/) should appear. -## Use a skill in Figma +--- + +## How skills work + +| Piece | Role | +| --- | --- | +| `skills/figma-agent//SKILL.md` | Canonical, installable skill document | +| YAML frontmatter (`name`, `description`) | Discovery and routing for agents | +| Workflow sections | Concrete steps, limits, and output shape | + +There is no duplicate upload document. `SKILL.md` is the only skill file. + +Skills are scoped for Figma design work: selection-first by default, evidence tied to layers/frames/variables, and clear limits when code or admin context is unavailable. + +--- + +## Catalogue + +**56 skills** in [`skills/figma-agent/`](skills/figma-agent/). Grouped by job below; open a folder for the full `SKILL.md`. + +### Accessibility & usability + +| Skill | Use when | +| --- | --- | +| [`accessibility-audit`](skills/figma-agent/accessibility-audit/) | Checking WCAG-oriented issues visible in Figma before handoff | +| [`heuristic-evaluation`](skills/figma-agent/heuristic-evaluation/) | Running a Nielsen-heuristics usability pass on a flow | +| [`localization-readiness`](skills/figma-agent/localization-readiness/) | Catching clipping, RTL, and translation risks before localization | +| [`states-completeness-check`](skills/figma-agent/states-completeness-check/) | Verifying empty, loading, error, and interaction states exist | +| [`visual-consistency-check`](skills/figma-agent/visual-consistency-check/) | Unifying spacing, alignment, and style across a multi-screen flow | + +### Design system & tokens + +| Skill | Use when | +| --- | --- | +| [`apply-color-variables`](skills/figma-agent/apply-color-variables/) | Binding hard-coded colors to existing Color variables | +| [`component-audit`](skills/figma-agent/component-audit/) | Health-checking a component set before publish | +| [`design-tokens-sync`](skills/figma-agent/design-tokens-sync/) | Reconciling Figma variables with code tokens | +| [`follow-ds-guidelines`](skills/figma-agent/follow-ds-guidelines/) | Auditing a frame against the published design system | +| [`legacy-styles-to-variables`](skills/figma-agent/legacy-styles-to-variables/) | Migrating hard-coded styles onto shared variables | +| [`library-health-report`](skills/figma-agent/library-health-report/) | Cleaning unused, duplicate, or undocumented library assets | +| [`naming-convention-enforcer`](skills/figma-agent/naming-convention-enforcer/) | Renaming layers and components to a stated convention | +| [`rename-layers-batch`](skills/figma-agent/rename-layers-batch/) | Bulk renaming with a simple rule or find/replace | +| [`semantic-color-audit`](skills/figma-agent/semantic-color-audit/) | Catching raw palette usage where semantic tokens belong | +| [`spacing-scale-enforcer`](skills/figma-agent/spacing-scale-enforcer/) | Mapping arbitrary spacing onto the project scale | + +### Components & code mapping + +| Skill | Use when | +| --- | --- | +| [`base-ui-primitive-composition`](skills/figma-agent/base-ui-primitive-composition/) | Composing overlays from Base UI / Radix-style primitives | +| [`code-connect-mapper`](skills/figma-agent/code-connect-mapper/) | Planning Figma ↔ code mappings for Code Connect | +| [`component-naming-sync`](skills/figma-agent/component-naming-sync/) | Aligning Figma and code component/prop naming | +| [`cva-variant-generator`](skills/figma-agent/cva-variant-generator/) | Generating `cva` configs from Figma variants | +| [`figma-to-code-component`](skills/figma-agent/figma-to-code-component/) | Translating a selected frame into a first-pass implementation | +| [`screenshot-to-component`](skills/figma-agent/screenshot-to-component/) | Recreating a UI screenshot as a structured Figma component | +| [`shadcn-component-structure`](skills/figma-agent/shadcn-component-structure/) | Matching shadcn/ui component conventions in generated code | +| [`tailwind-class-order-check`](skills/figma-agent/tailwind-class-order-check/) | Cleaning Tailwind class order and conflicts | +| [`token-tailwind-theme-sync`](skills/figma-agent/token-tailwind-theme-sync/) | Syncing Figma variables into a Tailwind/shadcn theme | + +### Layout & responsive + +| Skill | Use when | +| --- | --- | +| [`container-layout-normalizer`](skills/figma-agent/container-layout-normalizer/) | Normalizing container widths, max-width, and padding | +| [`responsive-breakpoint-check`](skills/figma-agent/responsive-breakpoint-check/) | Verifying auto layout and constraints across breakpoints | +| [`site-launch-checklist`](skills/figma-agent/site-launch-checklist/) | Pre-publish review for a Figma Sites project | + +### Prototyping & motion + +| Skill | Use when | +| --- | --- | +| [`animation-consistency-check`](skills/figma-agent/animation-consistency-check/) | Auditing easing, duration, and motion character across a file | +| [`motion-spec-generator`](skills/figma-agent/motion-spec-generator/) | Documenting duration/easing specs for engineering | +| [`prototype-from-flow`](skills/figma-agent/prototype-from-flow/) | Wiring screens into an end-to-end clickable prototype | +| [`prototype-qa`](skills/figma-agent/prototype-qa/) | Walking every prototype link for dead ends and broken paths | +| [`variable-driven-prototype`](skills/figma-agent/variable-driven-prototype/) | Building stateful prototypes with variables and conditions | +| [`wire-up-interactions`](skills/figma-agent/wire-up-interactions/) | Adding or fixing specific prototype interactions | + +### Research, workshops & strategy + +| Skill | Use when | +| --- | --- | +| [`affinity-mapping`](skills/figma-agent/affinity-mapping/) | Clustering open-ended qualitative data into themes | +| [`competitive-teardown`](skills/figma-agent/competitive-teardown/) | Extracting actionable insights from a competitor flow | +| [`design-brief-generator`](skills/figma-agent/design-brief-generator/) | Turning a vague ask into a structured design brief | +| [`journey-map-builder`](skills/figma-agent/journey-map-builder/) | Building a journey map from research or a described experience | +| [`persona-builder`](skills/figma-agent/persona-builder/) | Creating an evidence-grounded persona from research | +| [`sticky-synthesis`](skills/figma-agent/sticky-synthesis/) | Clustering FigJam stickies into themes and takeaways | +| [`workshop-facilitator`](skills/figma-agent/workshop-facilitator/) | Structuring a FigJam board for a workshop format | + +### Content + +| Skill | Use when | +| --- | --- | +| [`content-inventory`](skills/figma-agent/content-inventory/) | Exporting every user-facing string for review or translation | +| [`content-tone-review`](skills/figma-agent/content-tone-review/) | Checking copy against voice-and-tone guidelines | +| [`microcopy-generator`](skills/figma-agent/microcopy-generator/) | Drafting buttons, empty states, errors, and tooltips | + +### Delivery & collaboration + +| Skill | Use when | +| --- | --- | +| [`figma-skill-router`](skills/figma-agent/figma-skill-router/) | Choosing the right installed Figma skill for a request | +| [`branch-review-summary`](skills/figma-agent/branch-review-summary/) | Summarizing a design branch for reviewers | +| [`build-from-prd`](skills/figma-agent/build-from-prd/) | Turning a PRD into screens, states, and flows | +| [`comment-triage`](skills/figma-agent/comment-triage/) | Sorting open comments into actionable buckets | +| [`deck-from-outline`](skills/figma-agent/deck-from-outline/) | Building a Figma Slides deck from an outline | +| [`design-change-diff`](skills/figma-agent/design-change-diff/) | Explaining what changed between two design versions | +| [`design-crit`](skills/figma-agent/design-crit/) | Getting a structured critique before a wider review | +| [`dev-handoff-prep`](skills/figma-agent/dev-handoff-prep/) | Final Dev Mode readiness pass before engineering | +| [`file-cleanup`](skills/figma-agent/file-cleanup/) | Reorganizing pages and archiving stale exploration | +| [`handoff-summary`](skills/figma-agent/handoff-summary/) | Writing a concise context handoff for a teammate | +| [`brand-kit-asset-generator`](skills/figma-agent/brand-kit-asset-generator/) | Generating on-brand marketing/social asset variants | +| [`plugin-widget-recommender`](skills/figma-agent/plugin-widget-recommender/) | Recommending plugins/widgets for a workflow need | +| [`color-token-format-normalizer`](skills/figma-agent/color-token-format-normalizer/) | Aligning colors to shadcn CSS-variable / HSL format | + +--- + +## Suggested starting set + +If you are installing for the first time, these cover the most common loops: + +| Skill | Why | +| --- | --- | +| [`accessibility-audit`](skills/figma-agent/accessibility-audit/) | Catch checkable a11y issues early | +| [`component-audit`](skills/figma-agent/component-audit/) | Keep shared components healthy | +| [`design-tokens-sync`](skills/figma-agent/design-tokens-sync/) | Keep design and code tokens aligned | +| [`figma-to-code-component`](skills/figma-agent/figma-to-code-component/) | Bridge a selected design into code | +| [`prototype-from-flow`](skills/figma-agent/prototype-from-flow/) | Make flows testable quickly | +| [`dev-handoff-prep`](skills/figma-agent/dev-handoff-prep/) | Close the loop before engineering | + +--- + +## Repository layout + +```text +skills/figma-agent//SKILL.md # installable catalogue (source of truth) +archive/ # historical material (not installable) +scripts/ # init + validate helpers +tests/ # catalogue integrity checks +AGENTS.md # maintainer workflow +``` -Each package exposes the same skill in two formats: +| Path | Audience | +| --- | --- | +| [`skills/figma-agent/`](skills/figma-agent/) | Users and agents — active skills | +| [`archive/`](archive/) | Maintainers — historical packages as `README.md` only | +| [`AGENTS.md`](AGENTS.md) | Contributors — create, validate, release | +| [`SECURITY.md`](SECURITY.md) | Vulnerability reporting | -- `SKILL.md` is the canonical document installed by `skills.sh`. -- `SKILLS.md` is the byte-identical Figma upload document. In Figma Design Agents, use **Add skill** and upload it directly. +--- ## Contributing -See [AGENTS.md](AGENTS.md) and [the contribution guide](.github/CONTRIBUTING.md) for the creation and validation workflow. +New skills belong under `skills/figma-agent/` as a kebab-case directory with a matching frontmatter `name`. + +```bash +uv run python scripts/init_skill.py my-new-skill +# edit skills/figma-agent/my-new-skill/SKILL.md +uv run python scripts/validate_skills.py +``` + +Full workflow: [AGENTS.md](AGENTS.md) and [CONTRIBUTING](.github/CONTRIBUTING.md). -Historical, non-installable material is retained in [`archive/`](archive/). +--- ## License diff --git a/pyproject.toml b/pyproject.toml index f709820..388717d 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,7 +1,7 @@ [project] name = "skills" version = "0.1.0" -description = "Qredence Figma agent skills" +description = "Curated Figma design and product skills for AI agents" readme = "README.md" requires-python = ">=3.13" dependencies = [] diff --git a/scripts/init_skill.py b/scripts/init_skill.py index 76bf106..16dac49 100644 --- a/scripts/init_skill.py +++ b/scripts/init_skill.py @@ -1,18 +1,37 @@ +"""Initialize a new Figma agent skill directory.""" + +from __future__ import annotations + import argparse +import re +import sys import textwrap from pathlib import Path -def init_skill(name: str, path: str) -> bool: - skill_dir = Path(path) / name - if skill_dir.exists(): - print(f"Error: Skill directory '{skill_dir}' already exists.") - return False +REPO_ROOT = Path(__file__).resolve().parents[1] +DEFAULT_SKILLS_ROOT = REPO_ROOT / "skills" / "figma-agent" +KEBAB = re.compile(r"^[a-z0-9]+(-[a-z0-9]+)*$") + - (skill_dir / "scripts").mkdir(parents=True) - (skill_dir / "references").mkdir() - (skill_dir / "assets").mkdir() +def init_skill(name: str, path: Path) -> int: + if not KEBAB.match(name): + print( + f"Error: Skill name must be kebab-case (got '{name}').", + file=sys.stderr, + ) + return 1 + + if path.exists() and not path.is_dir(): + print(f"Error: Path '{path}' is not a directory.", file=sys.stderr) + return 1 + + skill_dir = path / name + if skill_dir.exists(): + print(f"Error: Skill directory '{skill_dir}' already exists.", file=sys.stderr) + return 1 + skill_dir.mkdir(parents=True) skill_md_content = textwrap.dedent(f"""\ --- name: {name} @@ -30,26 +49,23 @@ def init_skill(name: str, path: str) -> bool: 3. Report findings or deliverables clearly. """) - canonical_document = skill_dir / "SKILL.md" - canonical_document.write_text(skill_md_content, encoding="utf-8") - - path_norm = Path(path).as_posix().rstrip("/") - if path_norm == "skills/figma-agent" or path_norm.endswith("/skills/figma-agent"): - (skill_dir / "SKILLS.md").write_text(skill_md_content, encoding="utf-8") - + (skill_dir / "SKILL.md").write_text(skill_md_content, encoding="utf-8") print(f"Successfully initialized skill '{name}' in '{skill_dir}'") - - return True + return 0 -if __name__ == "__main__": - parser = argparse.ArgumentParser(description="Initialize a new skill.") - parser.add_argument("name", help="Name of the skill to create") +def main() -> int: + parser = argparse.ArgumentParser(description=__doc__) + parser.add_argument("name", help="Kebab-case name of the skill to create") parser.add_argument( "--path", - default="skills/figma-agent/", - help="Path where the skill directory will be created (default: skills/figma-agent/)", + type=Path, + default=DEFAULT_SKILLS_ROOT, + help=f"Directory for the new skill (default: {DEFAULT_SKILLS_ROOT})", ) args = parser.parse_args() + return init_skill(args.name, args.path.resolve()) + - init_skill(args.name, args.path) +if __name__ == "__main__": + raise SystemExit(main()) diff --git a/scripts/sync_figma_documents.py b/scripts/sync_figma_documents.py deleted file mode 100644 index d947d90..0000000 --- a/scripts/sync_figma_documents.py +++ /dev/null @@ -1,69 +0,0 @@ -"""Keep Figma upload documents synchronized with canonical skill documents.""" - -from __future__ import annotations - -import argparse -import sys -from pathlib import Path - - -REPO_ROOT = Path(__file__).resolve().parents[1] -FIGMA_SKILLS_ROOT = REPO_ROOT / "skills" / "figma-agent" - - -def iter_skill_directories() -> list[Path]: - if not FIGMA_SKILLS_ROOT.is_dir(): - return [] - return sorted(path for path in FIGMA_SKILLS_ROOT.iterdir() if path.is_dir()) - - -def synchronize(*, check: bool) -> int: - errors: list[str] = [] - changed = 0 - - for skill_dir in iter_skill_directories(): - canonical = skill_dir / "SKILL.md" - figma_upload = skill_dir / "SKILLS.md" - if not canonical.is_file(): - errors.append( - f"Missing canonical document: {canonical.relative_to(REPO_ROOT)}" - ) - continue - - expected = canonical.read_bytes() - if figma_upload.is_file() and figma_upload.read_bytes() == expected: - continue - - if check: - errors.append( - f"Out-of-sync Figma document: {figma_upload.relative_to(REPO_ROOT)}" - ) - continue - - figma_upload.write_bytes(expected) - changed += 1 - - if errors: - print("\n".join(errors), file=sys.stderr) - return 1 - - action = "Checked" if check else "Synchronized" - print( - f"{action} {len(iter_skill_directories())} Figma skill documents ({changed} changed)." - ) - return 0 - - -def main() -> int: - parser = argparse.ArgumentParser(description=__doc__) - parser.add_argument( - "--check", - action="store_true", - help="Fail when SKILLS.md does not match the canonical SKILL.md.", - ) - args = parser.parse_args() - return synchronize(check=args.check) - - -if __name__ == "__main__": - raise SystemExit(main()) diff --git a/scripts/validate_skills.py b/scripts/validate_skills.py index a5f8402..733202c 100644 --- a/scripts/validate_skills.py +++ b/scripts/validate_skills.py @@ -13,6 +13,7 @@ FRONTMATTER = re.compile(r"\A---\s*\n(?P.*?)\n---\s*\n", re.DOTALL) NAME = re.compile(r"^name:\s*[\"']?(?P[a-z0-9-]+)[\"']?\s*$", re.MULTILINE) DESCRIPTION = re.compile(r"^description:\s*.+$", re.MULTILINE) +KEBAB = re.compile(r"^[a-z0-9]+(-[a-z0-9]+)*$") def validate() -> list[str]: @@ -27,15 +28,20 @@ def validate() -> list[str]: errors.append("No active skills found under skills/figma-agent") for skill_dir in skill_dirs: - canonical = skill_dir / "SKILL.md" - figma_upload = skill_dir / "SKILLS.md" relative_dir = skill_dir.relative_to(REPO_ROOT) + if not KEBAB.match(skill_dir.name): + errors.append(f"Skill directory must be kebab-case: {relative_dir}") + + canonical = skill_dir / "SKILL.md" if not canonical.is_file(): errors.append(f"Missing canonical document: {relative_dir}/SKILL.md") continue - if not figma_upload.is_file(): - errors.append(f"Missing Figma document: {relative_dir}/SKILLS.md") - continue + + legacy_upload = skill_dir / "SKILLS.md" + if legacy_upload.exists(): + errors.append( + f"Legacy Figma duplicate must not exist: {relative_dir}/SKILLS.md" + ) content = canonical.read_text(encoding="utf-8") match = FRONTMATTER.match(content) @@ -51,8 +57,6 @@ def validate() -> list[str]: ) if not DESCRIPTION.search(match.group("body")): errors.append(f"Missing frontmatter description: {relative_dir}/SKILL.md") - if canonical.read_bytes() != figma_upload.read_bytes(): - errors.append(f"Figma document differs from canonical: {relative_dir}") for archived_document in (REPO_ROOT / "archive").rglob("SKILL.md"): errors.append( diff --git a/skills/figma-agent/README.md b/skills/figma-agent/README.md index 2aa0b65..4b47810 100644 --- a/skills/figma-agent/README.md +++ b/skills/figma-agent/README.md @@ -1,16 +1,9 @@ # Figma Agent Skills -This is Qredence’s active catalogue of Figma design and product skills. - -Install skills with: +Qredence’s active catalogue of Figma design and product skills for AI agents. ```bash npx skills@latest add qredence/skills ``` -Each directory is one skill. Its documents serve two surfaces: - -- `SKILL.md` is the canonical document used by `skills.sh`. -- `SKILLS.md` is the identical document for direct upload through **Add skill** in Figma Design Agents. - -Browse the directories to find skills for accessibility, design systems, components, prototyping, research, content, and handoff. +Each directory is one skill. The installable document is `SKILL.md` (YAML frontmatter + workflow). Browse the folders for accessibility, design systems, components, prototyping, research, content, and handoff. diff --git a/skills/figma-agent/accessibility-audit/SKILLS.md b/skills/figma-agent/accessibility-audit/SKILLS.md deleted file mode 100644 index 33d0ba5..0000000 --- a/skills/figma-agent/accessibility-audit/SKILLS.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -name: accessibility-audit -description: "Audits a design against WCAG 2.2 AA basics that are checkable in Figma: color contrast, text sizing, tap/click target size, focus order implied by layer order, and presence of alt-text-equivalent labels for meaningful images/icons. Use before a design is considered done, or when accessibility compliance is a requirement." ---- - -# Accessibility Audit - -## Purpose -Catch the accessibility issues that are visible and checkable directly in a Figma design, before a design is built. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before marking a screen or flow "ready for dev" -- When a product has explicit accessibility/compliance requirements - -## Required Inputs -- The frame(s) to audit -- Platform (web, iOS, Android) since target sizes and conventions differ slightly -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Inspect the selected frame visually first, then drill into text, icons, controls, order, and motion. -- Report Figma-checkable issues only; put implementation-only concerns in a separate "Needs implementation validation" section. - -## Workflow -1. Contrast: for every text layer and meaningful icon, compare its color against its background and flag anything below 4.5:1 for normal text or 3:1 for large text (18pt+/14pt+ bold) and UI components/graphical objects. -2. Text sizing and scaling: flag body text below ~14-16px and check that text containers can grow (not fixed-height, clipped) to support user font-size scaling. -3. Target size: flag interactive elements (buttons, icons, links, form controls) smaller than roughly 24x24px (44x44px is the safer, commonly recommended minimum for primary touch targets), and check adequate spacing between adjacent targets. -4. Reading and focus order: check that layer order (top-to-bottom, left-to-right in the layers panel, or explicit tab order if annotated) matches the logical reading/interaction order a screen reader or keyboard user would follow. -5. Non-text content: flag meaningful icons/images with no adjacent label or annotation indicating what alt text they should have in code; purely decorative images should be flagged as "should be marked decorative" in a handoff annotation. -6. Color-only meaning: flag any place where color alone conveys information (e.g. red text with no icon/label meaning "error") and suggest adding an icon or text cue. -7. Motion: note any auto-animate/prototype transitions that rely on large, fast motion without an implied reduced-motion alternative. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. -- Do not certify WCAG compliance from a Figma review; separate visual findings from implementation checks. - -## Guardrails -- Report exact contrast ratios and target sizes, not just pass/fail, so findings can be verified. -- Do not assume a component is accessible just because it is from the design system -- spot-check anyway, since the underlying colors may have changed. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A checklist grouped by WCAG concern (Contrast, Text sizing, Target size, Order, Non-text content, Color-only meaning, Motion) with pass/fail and the specific fix needed. diff --git a/skills/figma-agent/affinity-mapping/SKILLS.md b/skills/figma-agent/affinity-mapping/SKILLS.md deleted file mode 100644 index ccfaef9..0000000 --- a/skills/figma-agent/affinity-mapping/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: affinity-mapping -description: "Groups raw qualitative data (research notes, survey verbatims, support tickets, interview quotes) into a bottom-up affinity map -- clustering related observations before naming themes, rather than sorting into pre-defined buckets. Use for open-ended research synthesis where categories aren't known in advance." ---- - -# Affinity Mapping - -## Purpose -Synthesize raw qualitative data bottom-up: group related individual observations first, then name the themes that emerge -- rather than sorting into categories decided in advance. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Synthesizing open-ended research (interview notes, support tickets, survey verbatims) where the right categories aren't known yet - -## Required Inputs -- The raw data source (pasted notes, a connected doc/spreadsheet, or existing loose stickies) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Use existing sticky positions or colors as weak signals, not hard categories. Cluster by meaning first, then name themes. -- Create 3-8 actionable themes unless the evidence strongly requires more. - -## Workflow -1. Convert each discrete observation/quote into its own individual note if not already atomized -- one idea per note, not paragraphs. -2. Do a first pass grouping notes that feel directly related, without naming groups yet -- resist jumping to categories too early. -3. Once initial small clusters form, look for clusters that are really the same underlying idea and merge them; split any cluster that's actually two different ideas. -4. Only after clustering is stable, name each cluster with a theme label that captures the shared idea, written from the user's point of view where possible (e.g. "Users do not trust the price until checkout", not "Pricing"). -5. Note the frequency (how many observations) per theme, since this is often useful signal for prioritization, while flagging that frequency in qualitative data is not the same as prevalence in the full user base. -6. Surface tensions or contradictions between themes explicitly (e.g. "some users want more automation, others want more control") rather than smoothing them over. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Keep source traceability -- each theme should be able to point back to the specific observations that formed it. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: Clusters laid out spatially with theme labels, plus a written summary: theme -> frequency -> representative quote/observation. diff --git a/skills/figma-agent/animation-consistency-check/SKILLS.md b/skills/figma-agent/animation-consistency-check/SKILLS.md deleted file mode 100644 index 3d9c7ee..0000000 --- a/skills/figma-agent/animation-consistency-check/SKILLS.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -name: animation-consistency-check -description: "Audits animated components and prototype transitions across a file for consistent easing, duration, and motion character, flagging transitions that feel out of step with the rest of the product's motion language. Use when multiple people or sessions have added animation and it needs to feel cohesive." ---- - -# Animation Consistency Check - -## Purpose -Make sure animated transitions across a file share one coherent motion language, rather than each feeling separately tuned. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Multiple animated components/transitions exist and need a consistency pass -- Before finalizing motion for a release - -## Required Inputs -- The scope of transitions/animated components to review -- Any established motion principle or reference transition to treat as the baseline, if one exists -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Inventory transitions by role before judging values. Compare like with like: navigation, overlay, component state, and micro-interaction. - -## Workflow -1. Inventory every prototype transition (trigger -> animation type -> duration/easing) and every animated component (interactive component transitions, Motion-file animations) in scope. -2. Group transitions by role (entrances, exits, in-place state changes, navigational transitions, micro-interactions) since each role should share consistent timing/easing within itself. -3. Compare durations within each role group and flag outliers (e.g. one modal opens in 150ms while every other modal opens in 300ms). -4. Compare easing curves within each role group and flag inconsistency (e.g. most exits use ease-in, but one uses a bouncy spring that feels tonally different). -5. Check that semantically identical interactions (e.g. every primary button's hover state) use identical timing, not just similar-looking timing. -6. Propose a single consistent value per role group when outliers are found, defaulting to whichever value is most prevalent unless there's a clear reason another value is more correct. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Distinguish an intentional, meaningful difference (e.g. a celebratory moment deliberately animated more expressively) from an accidental inconsistency -- ask if unsure. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A table grouped by transition role: Role | Transitions compared | Outlier(s) found | Recommended consistent value. diff --git a/skills/figma-agent/apply-color-variables/SKILLS.md b/skills/figma-agent/apply-color-variables/SKILLS.md deleted file mode 100644 index fba8872..0000000 --- a/skills/figma-agent/apply-color-variables/SKILLS.md +++ /dev/null @@ -1,142 +0,0 @@ ---- -name: apply-color-variables -description: Apply existing Figma Color variables from a specified Variables collection to hard-coded colors in the current selection, page, or file. Use when colors are not bound to collection variables and should be standardized to the design system. -compatibility: Figma Agent / Figma Design; single-file skill intended for upload as Markdown. ---- - -# Apply existing Color variables - -## Purpose -Use this skill to replace hard-coded colors in a Figma file with **existing Color variables** from the chosen Variables collection. The goal is to make fills, strokes, text colors, and effect colors use the design system’s variable collection instead of raw color values. - -## When to use -Use this skill when the user asks to: -- apply existing Color variables to colors that are not using variables -- convert raw hex/RGB colors to variables -- clean up a Figma file so colors use the team’s Variables collection -- audit a design for unbound colors and bind them to existing variables - -Do **not** use this skill to create, rename, delete, or change variables. - -## Default behavior -If the user does not specify details, use these defaults: -- **Scope:** current selection; if nothing is selected, use the current page -- **Variable source:** any available collection that clearly contains Color variables, prioritizing a collection named `Colors`, `Colour`, `Primitives`, `Semantic`, `Theme`, or similar -- **Matching rule:** exact color matches only -- **Variable creation:** never create new variables -- **Unmatched colors:** report them instead of changing them - -## Clarify only when necessary -Ask a short question before editing if any of these are unclear and materially affect the result: -1. Which Variables collection should be used? -2. Should the work apply to the selection, current page, or entire file? -3. Should matching be exact only, or may near matches be used? -4. If the file uses modes such as Light and Dark, which mode should be used for matching? - -If the likely answer is obvious from the file context, proceed and state the assumption in the final summary. - -## Operating rules -- Use only **existing Color variables**. -- Bind colors to variables; do not simply copy variable values as raw colors. -- Preserve layout, layer structure, names, constraints, variants, component relationships, and non-color styling. -- Leave any color that is already bound to a variable unchanged unless it is bound to the wrong collection and the user explicitly asked to normalize collections. -- Do not replace variables with paint styles unless the user explicitly asks for styles. -- Do not approximate colors unless the user explicitly allows near-match replacement. -- Do not change opacity, blend mode, stroke width, effect blur, or any non-color property. - -## Step-by-step process - -### 1. Identify the target scope -Determine whether to scan: -- the current selection -- the current page -- the entire file -- a specific frame, section, component, or page named by the user - -If scanning the entire file could be large or risky, tell the user what scope you are using before applying changes. - -### 2. Build the Color variable map -From the target Variables collection or collections: -1. List all variables of type **Color**. -2. Resolve their values for the relevant mode or modes. -3. Normalize each variable value into comparable RGBA values. -4. Record each variable’s name, collection, mode, and resolved color. - -Prefer semantic variables when there are duplicates. For example, prefer `Semantic / Background / Primary` over `Primitive / Blue / 500` when both match and the semantic variable appears intended for UI usage. - -### 3. Scan for unbound color properties -Within the target scope, inspect color-bearing properties, including where supported: -- fills -- strokes -- text fills -- effect colors, such as shadows -- component and instance properties that expose color values - -For each property, classify it as: -- **Already variable-bound** — leave unchanged -- **Hard-coded and matchable** — candidate for variable binding -- **Hard-coded and unmatched** — report only -- **Unsupported or ambiguous** — report only - -### 4. Match hard-coded colors to variables -For every hard-coded color: -1. Normalize the color and opacity to RGBA. -2. Compare it against the Color variable map. -3. Use exact RGBA matching by default. -4. If multiple variables match, choose the best candidate using this priority: - 1. variable from the user-specified collection - 2. semantic token over primitive/raw token - 3. token name that matches the layer/property context - 4. shorter, cleaner, more current-looking token name - 5. if still ambiguous, do not guess; report the ambiguity - -### 5. Apply bindings -For every confident match: -1. Bind the color property to the matched existing Color variable. -2. Preserve the property’s non-color settings. -3. Keep the visual appearance unchanged after binding. -4. If a variable has modes, bind the variable itself rather than hard-coding a mode value. - -### 6. Validate the result -After applying changes: -1. Re-scan the same scope. -2. Confirm that matched hard-coded colors are now variable-bound. -3. Confirm unmatched colors were not changed. -4. Confirm visible appearance is unchanged except for variable binding. -5. Check representative examples: fill, stroke, text, and effect color if present. - -## Final response format -Return a concise summary with these sections: - -### Updated -- Number of layers or nodes checked -- Number of color properties changed from hard-coded values to Color variables -- Number of properties already using variables - -### Unmatched colors -List hard-coded colors that could not be mapped to an existing variable. Group by color value and include where they appear. - -Example: -- `#F24E1E` at 80% opacity — 3 uses: `Button / Icon`, `Alert / Border`, `Badge / Fill` - -### Ambiguities -List cases where multiple variables matched and no confident choice was possible, or state that there were none. - -### Assumptions -State any assumptions made, such as scope, collection, or mode. - -## Edge cases -- **Gradients:** bind variable-supported gradient stops only if Figma supports variable binding for that property. Otherwise report them. -- **Images:** do not attempt to alter bitmap/image colors. -- **Remote libraries:** use available library variables if they are enabled and accessible. If not accessible, report that the variable source is unavailable. -- **Detached or legacy components:** update only the eligible color properties; do not restructure components. -- **Different opacity:** treat opacity as part of the color match. `#000000` at 40% is not the same as `#000000` at 100%. -- **Near matches:** only use near matches when explicitly allowed by the user. When allowed, report every near match separately from exact matches. - -## Hard stop conditions -Stop and ask the user before editing if: -- no Color variable collection is available -- multiple likely collections exist and choosing the wrong one would be risky -- the user requested near matching but gave no tolerance or rule -- the requested change would require creating or modifying variables -- applying the change would affect a very large scope and the user did not explicitly request that scope diff --git a/skills/figma-agent/base-ui-primitive-composition/SKILLS.md b/skills/figma-agent/base-ui-primitive-composition/SKILLS.md deleted file mode 100644 index 133588d..0000000 --- a/skills/figma-agent/base-ui-primitive-composition/SKILLS.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -name: base-ui-primitive-composition -description: "Composes interactive components (dialogs, popovers, tooltips, menus, tabs, accordions) from Base UI's unstyled primitive parts (Root/Trigger/Portal/Content/etc.) instead of hand-rolled behavior, preserving built-in accessibility and state management. Use when building any interactive/overlay component that has a Base UI or Radix equivalent primitive." ---- - -# Base UI Primitive Composition - -## Purpose -Build interactive components on top of accessible, tested primitives instead of reimplementing focus trapping, positioning, and ARIA wiring by hand. - -## Operating Role -Act as a design-to-code bridge for this specific skill. Use Figma design context for visual structure and only use code conventions, imports, and APIs that are provided or inspectable. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. -- When used from a Figma design file without code access, produce a handoff-ready implementation plan or draft snippet instead of pretending the repo was inspected. - -## Activation Boundary -- Building dialogs, popovers, dropdown/select menus, tooltips, tabs, accordions, or toggle groups -- Any component with keyboard/focus management complexity that has an existing Base UI (or equivalent Radix) primitive - -## Required Inputs -- Which interactive pattern is being built -- Whether the project already has this primitive installed (check for an existing `components/ui/.tsx` wrapper before adding a new dependency) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Start from the existing design anatomy in the selected Figma component, then choose the closest primitive family. -- Return component structure and code only after naming the primitive family and the accessibility behavior it supplies. - -## Workflow -1. Identify the closest matching Base UI primitive family for the pattern requested (e.g. Dialog, Popover, Menu, Tooltip, Tabs, Accordion, Select). -2. Compose using the primitive's part structure (commonly Root, Trigger, Portal, Backdrop/Overlay, Content/Positioner) rather than building custom open-state/focus logic from scratch. -3. Apply shadcn-style styling to each part via `className` with `cn()`, keeping the underlying primitive's behavior/ARIA attributes untouched -- style, do not override, functional attributes like `role`, `aria-*`, or `data-state`. -4. Preserve the primitive's `data-state` / `data-*` attributes as Tailwind state selectors (e.g. `data-[state=open]:animate-in`) for enter/exit animation instead of managing animation state manually. -5. Confirm keyboard interaction (Escape to close, arrow-key navigation, focus return to trigger on close) works via the primitive defaults rather than being reimplemented. -6. If no primitive exists for the exact pattern requested, say so explicitly rather than silently hand-rolling equivalent behavior, and propose the closest primitive to adapt. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. -- Do not invent packages, imports, component APIs, token names, or Code Connect mappings. -- Use design tokens and existing component names only when they are visible or provided. - -## Guardrails -- Never strip or override `aria-*` / `role` attributes supplied by the primitive to "simplify" markup. -- Do not reimplement focus-trap/portal logic that the primitive already provides. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return code or mapping output only when enough context exists. Otherwise return a design-to-code plan with required missing code context, proposed props, token mappings, and unresolved assumptions. -- Skill-specific format: Composed component code using primitive parts, followed by a note on which primitive family was used and why. diff --git a/skills/figma-agent/branch-review-summary/SKILLS.md b/skills/figma-agent/branch-review-summary/SKILLS.md deleted file mode 100644 index bf07133..0000000 --- a/skills/figma-agent/branch-review-summary/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: branch-review-summary -description: "Summarizes a design branch's changes relative to its main file for a branch reviewer, highlighting what changed, why (if known), and what specifically needs review attention. Use when requesting or performing a branch review." ---- - -# Branch Review Summary - -## Purpose -Give a branch reviewer a clear, fast way to understand what changed and what needs their attention, instead of asking them to diff everything manually. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Requesting a branch review -- Performing a branch review and needing a structured starting summary - -## Required Inputs -- The branch and its main file -- Any known context for why the branch was created (linked ticket/requirement, if available via connector) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Focus reviewer attention on risky or judgment-heavy changes first; do not bury them under minor visual diffs. - -## Workflow -1. Run design-change-diff logic between the branch and main to establish what actually changed. -2. Organize changes by what needs reviewer judgment (new patterns, structural changes, anything ambiguous or a judgment call was made) versus what's low-risk (copy fixes, minor spacing polish) so the reviewer can focus attention. -3. State explicitly what kind of review is being requested (visual QA, design system compliance, content review, final sign-off) so the reviewer knows what lens to apply. -4. Flag anything in the branch that deviates from the design system (cross-reference follow-ds-guidelines) so the reviewer can decide if it is an intentional new pattern or needs fixing before merge. -5. List any open questions the branch author has for the reviewer specifically. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not understate genuinely risky/structural changes as minor to make the branch look more merge-ready than it is. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: "What kind of review this needs" (1 line) -> "Needs your judgment" (list) -> "Low-risk changes" (list) -> "Open questions for you" (list). diff --git a/skills/figma-agent/brand-kit-asset-generator/SKILLS.md b/skills/figma-agent/brand-kit-asset-generator/SKILLS.md deleted file mode 100644 index 1c4f5d6..0000000 --- a/skills/figma-agent/brand-kit-asset-generator/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: brand-kit-asset-generator -description: "Generates a set of on-brand marketing/social assets (e.g. social post variants, banner sizes, a simple one-pager) from a project's brand kit (colors, fonts, logo, existing templates), for use in Figma Buzz or general marketing asset production. Use when a brand kit exists and multiple sized/format variants of an asset are needed quickly." ---- - -# Brand Kit Asset Generator - -## Purpose -Produce multiple on-brand marketing asset variants quickly and consistently from an existing brand kit. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Multiple sizes/formats of the same core asset are needed (e.g. a social campaign across several platforms) -- A brand kit (colors, type, logo, templates) already exists to pull from - -## Required Inputs -- The brand kit source (existing library/styles/variables, logo assets, and any existing templates to match) -- The exact set of sizes/formats needed (ask for the list if not given -- common social sizes vary significantly by platform and shouldn't be guessed silently) -- The core message/content that should appear across variants -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Keep the same message hierarchy across sizes. Recompose layouts per aspect ratio instead of scaling one frame blindly. - -## Workflow -1. Identify the brand's core visual system from the kit: primary/secondary colors as variables or styles, approved fonts and their hierarchy, logo lockup(s) and their minimum clear space/size rules, and any existing template layouts to follow. -2. For each required size/format, adapt the core layout to fit -- this usually means re-flowing, not just scaling, since aspect ratio changes need different compositional choices (e.g. a square post vs. a tall story format). -3. Keep messaging hierarchy consistent across variants (the same primary message should be the most prominent element in every size) even as the layout adapts. -4. Apply brand colors/fonts/logo exactly from the kit -- no ad hoc substitutions, even for a size where the exact brand color combination feels visually awkward; flag that tension instead of quietly deviating. -5. Name and organize each variant clearly (by platform/size) for easy export. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not alter the logo (recoloring, stretching, cropping) beyond what the brand kit is usage guidelines explicitly allow. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: The generated variants, organized and named by size/platform, plus a note on any brand-kit ambiguity encountered. diff --git a/skills/figma-agent/build-from-prd/SKILLS.md b/skills/figma-agent/build-from-prd/SKILLS.md deleted file mode 100644 index b73d873..0000000 --- a/skills/figma-agent/build-from-prd/SKILLS.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -name: build-from-prd -description: "Reads a product requirements document (PRD) and produces the corresponding Figma design -- screens, states, and flow -- reusing existing design system components wherever possible and flagging any requirement that has no corresponding pattern yet. Use when a PRD or spec exists and needs to become an actual design, especially when paired with a connector to the requirements source." ---- - -# Build From PRD - -## Purpose -Turn a written product requirement into a structured Figma design that reuses the existing design system. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- A PRD, spec, or detailed ticket exists and needs a first-pass design -- Pair with a connector to the requirements source so the agent can read the live requirements - -## Required Inputs -- The PRD/spec content (via connector or pasted text) -- The target file/page to build in, and which library is canonical for components -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Extract screens, states, data needs, and acceptance criteria before creating or changing frames. -- Use existing components and patterns in the file before drawing new UI. - -## Workflow -1. Read the PRD and extract: user goal, explicit requirements (must-haves), open questions/edge cases mentioned, and any explicit UI direction given. -2. Break the requirement into discrete screens/states needed to satisfy it end to end, including non-happy-path states called out or implied (errors, empty, permissions-denied, etc.) -- cross-check against states-completeness-check once a first draft exists. -3. For each screen, build using existing components and variables from the canonical library first; only introduce new/custom elements where no existing pattern satisfies the requirement, and call those out explicitly as new patterns needing design system review. -4. Reflect every explicit requirement in the design directly, and note in a callout or comment any requirement that's ambiguous or that you made an assumption about, so it can be confirmed rather than silently guessed. -5. Assemble the discrete screens into a connected flow (invoke prototype-from-flow logic) matching the order of operations implied by the PRD. -6. List every requirement from the PRD next to the screen/element that satisfies it, and separately list anything in the PRD that could not be confidently translated into UI (e.g. a backend-only requirement, or a requirement too vague to design against). - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not silently drop a requirement that's hard to design for -- surface it instead of omitting it. -- Do not invent product decisions the PRD leaves open; flag them as open questions. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: A traceability list (Requirement -> Screen/element it is addressed by) plus an "Open questions / assumptions" list. diff --git a/skills/figma-agent/code-connect-mapper/SKILLS.md b/skills/figma-agent/code-connect-mapper/SKILLS.md deleted file mode 100644 index a6fe641..0000000 --- a/skills/figma-agent/code-connect-mapper/SKILLS.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -name: code-connect-mapper -description: "Plans and drafts the mapping between Figma components/variants and their corresponding code components and props for Code Connect, so Dev Mode can show real production code snippets instead of generic markup. Use when setting up or expanding Code Connect coverage for a design system library." ---- - -# Code Connect Mapper - -## Purpose -Map Figma components and their variant/instance properties to the equivalent code components and props, for Code Connect. - -## Operating Role -Act as a design-to-code bridge for this specific skill. Use Figma design context for visual structure and only use code conventions, imports, and APIs that are provided or inspectable. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. -- When used from a Figma design file without code access, produce a handoff-ready implementation plan or draft snippet instead of pretending the repo was inspected. - -## Activation Boundary -- Setting up Code Connect for a library for the first time -- Expanding coverage to newly published components -- A component's Code Connect snippet looks wrong or outdated after a component or code change - -## Required Inputs -- The Figma component(s)/variant set(s) in scope -- Access to (or a description of) the corresponding code component(s): file location, prop names/types, and any variant-to-prop mapping already established elsewhere in the codebase -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Treat selected Figma components as candidates and code components as source of truth for actual props. -- If code is unavailable, produce a mapping worksheet, not a claimed mapping. - -## Workflow -1. List every Figma variant property (e.g. `Size`, `State`, `Has icon`) and every exposed component property (boolean/text/instance-swap) on the component. -2. List every prop on the corresponding code component, with its type and accepted values. -3. Map each Figma property to the code prop it corresponds to, including value translation where names differ (e.g. Figma `Size=Large` -> code `size="lg"`). -4. Flag any Figma property with no code equivalent (dead prop in the mapping, or a design-only variant that does not exist in code) and any code prop with no Figma equivalent (a prop a designer cannot currently express in the file). -5. Draft the Code Connect configuration (component mapping + prop mapping) in the format the codebase's Code Connect setup expects, using existing mapped components in the repo as the style reference if available. -6. Note any nested/composed components (e.g. a Card that contains a Button) and confirm whether the child should also resolve via its own Code Connect mapping. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. -- Do not invent packages, imports, component APIs, token names, or Code Connect mappings. -- Use design tokens and existing component names only when they are visible or provided. - -## Guardrails -- Do not guess a prop mapping when variant/prop names are ambiguous -- list the ambiguity and ask, since an incorrect mapping actively misleads developers using Dev Mode. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return code or mapping output only when enough context exists. Otherwise return a design-to-code plan with required missing code context, proposed props, token mappings, and unresolved assumptions. -- Skill-specific format: A per-component mapping table (Figma property/value -> code prop/value) plus a list of unmapped items on either side. diff --git a/skills/figma-agent/color-token-format-normalizer/SKILLS.md b/skills/figma-agent/color-token-format-normalizer/SKILLS.md deleted file mode 100644 index 7e19e61..0000000 --- a/skills/figma-agent/color-token-format-normalizer/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: color-token-format-normalizer -description: "Converts colors to the CSS-variable/HSL token format used by shadcn's theming convention (--background, --primary, etc.), flags hardcoded hex/rgb values that should reference a token, and keeps light/dark pairs aligned. Use when generating or auditing color usage in a shadcn-based codebase." ---- - -# Color Token Format Normalizer - -## Purpose -Keep color usage consistent with shadcn's CSS-variable theming convention instead of scattered hardcoded color values. - -## Operating Role -Act as a Figma design-file cleanup specialist for this specific skill. Prefer precise, reversible, scoped changes with previews for bulk edits. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Generating new component code that uses color -- Auditing an existing codebase for hardcoded colors that bypass the token system - -## Required Inputs -- The project's existing theme token set (commonly defined in a global CSS file as HSL CSS variables like `--background`, `--foreground`, `--primary`, `--primary-foreground`, `--muted`, `--accent`, `--destructive`, `--border`, `--ring`, plus a `.dark` override block) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Preserve visual values while improving naming, grouping, and aliases. Do not change color intent during format cleanup. - -## Workflow -1. Read the project's existing token definitions first; do not invent a new token naming scheme if one already exists. -2. For any color used in new or reviewed code, map it to the closest matching semantic token (`bg-background`, `text-foreground`, `bg-primary`, `text-primary-foreground`, `border-border`, etc.) rather than a raw Tailwind palette class (`bg-blue-600`) or hardcoded hex. -3. If a genuinely new semantic color is needed that has no existing token, propose adding a new token (both light and dark values) following the existing naming and format convention (HSL triplet, e.g. `222.2 47.4% 11.2%`), rather than inlining a one-off value. -4. Verify every new/changed color token has both a light and a dark value defined, and that paired tokens (e.g. primary / primary-foreground) maintain sufficient contrast in both modes. -5. Flag any hardcoded hex/rgb/named color found in reviewed code that has an equivalent existing token, with the suggested token replacement. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Never introduce a raw hex value into component code when a semantic token exists for that purpose. -- Always provide both light and dark values for any new token. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return a preview or change log with before/after values, skipped ambiguous items, and any breaking-change risk. Keep the report short enough to act on immediately. -- Skill-specific format: List of colors reviewed -> current usage -> suggested token, plus any newly proposed tokens with light/dark HSL values. diff --git a/skills/figma-agent/comment-triage/SKILLS.md b/skills/figma-agent/comment-triage/SKILLS.md deleted file mode 100644 index 5d4325f..0000000 --- a/skills/figma-agent/comment-triage/SKILLS.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -name: comment-triage -description: "Reads all open comments on a file and triages them into categories (needs a design change, needs a decision/answer, already resolved but not marked, out of scope) so a designer can work through feedback efficiently. Use when a file has accumulated many comments and it's unclear what still needs action." ---- - -# Comment Triage - -## Purpose -Turn a pile of open file comments into a clear, prioritized action list. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- A file has many open comments and it is unclear which still need action -- Before starting a revision pass, to plan the work from feedback received - -## Required Inputs -- The file (and page/frame scope, if the whole file is too broad) to triage -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Group comments by action needed, not by chronology. Identify duplicates and blocked questions. - -## Workflow -1. Read every open (unresolved) comment along with the specific layer/area it is attached to. -2. Classify each comment: "Needs a design change" (a concrete change is being requested), "Needs a decision/answer" (a question that needs a reply, not necessarily a design change), "Appears already addressed" (the design has since changed in a way that seems to resolve the comment -- flag for the commenter to confirm rather than resolving it unilaterally), or "Out of scope / won't do" (a reasonable request that's out of scope for this piece of work, to be explicitly acknowledged rather than silently ignored). -3. For "Needs a design change" comments, group related ones together (multiple comments about the same underlying issue) so they can be addressed in one pass. -4. Note comment age/thread length as a signal for what might need more urgent attention (a long back-and-forth thread often signals unresolved disagreement worth resolving directly rather than in comments). -5. Draft a brief reply for "Appears already addressed" and "Out of scope" comments explaining the status, ready for the designer to review and post rather than posting automatically. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Never resolve/close another person's comment automatically -- only draft the reply and flag it as ready to post. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: Four sections (Needs design change [grouped], Needs a decision, Appears already addressed, Out of scope) each listing the comment, its author, and the location. diff --git a/skills/figma-agent/competitive-teardown/SKILLS.md b/skills/figma-agent/competitive-teardown/SKILLS.md deleted file mode 100644 index eb1abdf..0000000 --- a/skills/figma-agent/competitive-teardown/SKILLS.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -name: competitive-teardown -description: "Tears down a competitor's product, flow, or specific feature -- analyzing structure, patterns, strengths, and weaknesses -- and extracts concrete, actionable insights for the current project. Use when researching competitors before or during a design phase." ---- - -# Competitive Teardown - -## Purpose -Analyze a competitor's product or feature systematically and extract concrete insights relevant to the current project. - -## Operating Role -Act as a Figma workflow advisor for this specific skill. Base recommendations on the stated task, visible file context, and explicit policy or connector context. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Researching how competitors solve a problem before designing a solution -- Benchmarking a specific flow (e.g. checkout, onboarding) against competitors - -## Required Inputs -- The competitor(s) and specific product area/flow to tear down -- The specific question(s) the teardown should answer (e.g. "how do they handle empty states", not just "look at their app") -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Use supplied competitor material only. Separate observed pattern, likely user effect, and recommendation for this file. - -## Workflow -1. Use web research to gather the competitor's actual flow/screens for the area in question (screenshots, walkthroughs, app store listings, or public design write-ups), citing sources. -2. Describe the flow structurally: steps involved, information architecture, and where it diverges from or matches common patterns. -3. Identify what the competitor does well relative to the specific question being asked, with concrete detail (not just "good UX"). -4. Identify weaknesses or apparent trade-offs the competitor made, and speculate (clearly labeled as speculation) on why they might have made that choice. -5. Extract 3-5 concrete, actionable takeaways for the current project -- patterns worth adapting, pitfalls worth avoiding -- rather than a general summary of "what they do". -6. Note anything observed that's likely protected by patent/trademark or is a very brand-specific choice that shouldn't be directly copied. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. -- Do not infer competitor strategy or performance from screenshots; separate observation from interpretation. - -## Guardrails -- Cite sources for factual claims about the competitor's product; label speculation about their reasoning clearly as speculation. -- Never suggest copying distinctive branded visual identity -- extract the underlying pattern/principle instead. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return recommendations as a short ranked list with rationale, fit, risk, and what must be verified before adoption. -- Skill-specific format: Structure summary -> Strengths -> Weaknesses -> 3-5 actionable takeaways, with sources cited. diff --git a/skills/figma-agent/component-audit/SKILLS.md b/skills/figma-agent/component-audit/SKILLS.md deleted file mode 100644 index e8c6f63..0000000 --- a/skills/figma-agent/component-audit/SKILLS.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -name: component-audit -description: "Reviews a component set (all variants of one component) for structural consistency: naming, variant properties, layer structure, auto layout settings, and exposed component properties. Use when publishing or updating a component to a shared library, or when a component has grown organically and needs a health check before others build on it." ---- - -# Component Audit - -## Purpose -Verify a component or component set is well-structured, consistently named, and safe to publish or reuse. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before publishing a new or updated component to a library -- When a component set has many variants added over time by different people -- When an instance is behaving unexpectedly (e.g. resizing oddly, missing a property) - -## Required Inputs -- The component or component set to audit -- Whether it is going into a shared library (stricter bar) or staying local to this file -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Audit the component set as a system: names, variants, layer parity, component properties, tokens, states, and resizing. - -## Workflow -1. Check naming: the component set name is the base name (no variant values in it); each variant's variant properties follow a consistent, documented value set (e.g. `Size=Small/Medium/Large`, not `Size=sm` in one variant and `Size=Large` in another). -2. Check layer structure: equivalent layers across variants share the same name and nesting order, so swapping variants does not reflow unexpectedly and component properties bind cleanly. -3. Check auto layout: padding, gap, and resizing behavior (hug/fill/fixed) are consistent and intentional across variants; nothing is pinned with fixed dimensions that should hug or fill. -4. Check exposed component properties: boolean/instance-swap/text properties are named clearly from a consumer's point of view (e.g. `Show icon`, not `Layer 4 visible`), and instance-swap properties are scoped to appropriate types. -5. Check tokens: variants use shared color/text/effect styles and variables, not hardcoded values (cross-reference with follow-ds-guidelines for a deeper token audit). -6. Check accessibility basics: sufficient contrast in the default state, and if the component is interactive, that a focus/hover/pressed/disabled state variant exists. -7. Summarize findings and, if asked, fix straightforward issues (renaming, aligning padding) directly. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not change variant property names in a component that's already published and in wide use without flagging the breaking-change risk to every file consuming it. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A findings list organized by: Naming, Structure, Properties, Tokens, States -- each with pass/fail and a fix suggestion. diff --git a/skills/figma-agent/component-naming-sync/SKILLS.md b/skills/figma-agent/component-naming-sync/SKILLS.md deleted file mode 100644 index 816ae14..0000000 --- a/skills/figma-agent/component-naming-sync/SKILLS.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -name: component-naming-sync -description: "Keeps naming consistent across Figma component names, variant/prop names, and their code equivalents -- PascalCase components, camelCase props, kebab-case files and CSS classes -- so design and code stay traceable to each other. Use when component or variant names drift between Figma and code." ---- - -# Component Naming Sync - -## Purpose -Keep a single, consistent naming scheme for components and their variants across Figma and code so the two stay traceable to each other. - -## Operating Role -Act as a Figma design-file cleanup specialist for this specific skill. Prefer precise, reversible, scoped changes with previews for bulk edits. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Naming a new component or variant in Figma before it is built in code -- Auditing where Figma and code component/variant names have diverged - -## Required Inputs -- The existing naming conventions already in use in both the Figma file (component/variant naming) and the codebase (file/component/prop naming) -- do not assume a scheme; check for one first -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Normalize component, property, and variant names together; changing only one layer of naming usually leaves drift behind. - -## Workflow -1. Establish (or confirm existing) per-context conventions: component names in PascalCase (`Button`, `DropdownMenu`) matching between the Figma layer name and the code export name; file names in kebab-case (`dropdown-menu.tsx`) matching shadcn convention; props/variant keys in camelCase (`isDisabled`, `size`); variant option values in lowercase-kebab where they map to CSS data attributes (`data-state="open"`). -2. Cross-check Figma component variant properties (e.g. Size=Small/Medium/Large, State=Default/Hover/Disabled) against the code's variant prop names and values, flagging any mismatch (e.g. Figma "Size" vs. code prop "variant" being used for the same concept). -3. Flag inconsistent pluralization, abbreviation, or synonym drift (e.g. "btn" in one place vs. "Button" in another; "Icon" vs. "Ic") across the two surfaces. -4. When a new component/variant is being named for the first time, propose the name in all three forms (Figma layer name, code component name, file name) at once so they're set consistently from the start. -5. Suggest a lightweight naming glossary (or an addition to the design system guidelines) if drift is recurring across many components, rather than fixing names one at a time indefinitely. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not rename an existing widely-referenced component/prop without flagging it as a breaking change that needs coordinated updates across design and code. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return a preview or change log with before/after values, skipped ambiguous items, and any breaking-change risk. Keep the report short enough to act on immediately. -- Skill-specific format: Table of concept -> Figma name -> code name -> flagged mismatch (if any) -> proposed consistent name. diff --git a/skills/figma-agent/container-layout-normalizer/SKILLS.md b/skills/figma-agent/container-layout-normalizer/SKILLS.md deleted file mode 100644 index e4e6ea9..0000000 --- a/skills/figma-agent/container-layout-normalizer/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: container-layout-normalizer -description: "Sets consistent container widths, max-width, centering, and responsive padding across breakpoints, matching standard Tailwind/shadcn container conventions instead of ad hoc per-page values. Use when a layout's outer container sizing looks inconsistent or arbitrary." ---- - -# Container Layout Normalizer - -## Purpose -Keep the outer page/section container consistent (max-width, centering, gutter padding) across a project instead of every page defining its own ad hoc wrapper. - -## Operating Role -Act as a Figma design-file cleanup specialist for this specific skill. Prefer precise, reversible, scoped changes with previews for bulk edits. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Reviewing a layout where container width/padding looks inconsistent across pages or components -- Setting up a new page/section shell - -## Required Inputs -- The project's existing container convention if one exists (a shared `Container`/`Shell` component, or a `container` key in `tailwind.config`) -- Target breakpoints in use -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Preserve visual appearance while replacing fragile manual positioning with auto layout, constraints, and predictable resizing. - -## Workflow -1. Check whether the project already defines a container convention (custom `Container` component, or the `container` key in `tailwind.config` with `center`/`padding`/`screens` settings). If one exists, use it rather than inventing a new wrapper pattern. -2. If none exists, propose a standard set: a max-width scale (breakpoints mapped to explicit max-width values), `mx-auto` centering, and consistent horizontal padding that increases at wider breakpoints (e.g. `px-4` on mobile, `px-6` md, `px-8` lg). -3. Distinguish "outer page container" (sets max-width and gutters) from "inner content width" (may be narrower for readable text, e.g. prose content capped near 65-75ch) -- do not conflate the two. -4. Audit existing pages/components for one-off container overrides that drift from the established convention, and flag each with its specific deviation. -5. Ensure nested containers do not double up horizontal padding (a section inside an already-padded container shouldn't add its own matching padding, causing excess gutter). - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not introduce a second competing container pattern alongside an existing one -- consolidate to one. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return a preview or change log with before/after values, skipped ambiguous items, and any breaking-change risk. Keep the report short enough to act on immediately. -- Skill-specific format: Current convention (or proposed one) stated first, then a list of specific deviations found with corrected values. diff --git a/skills/figma-agent/content-inventory/SKILLS.md b/skills/figma-agent/content-inventory/SKILLS.md deleted file mode 100644 index 6199128..0000000 --- a/skills/figma-agent/content-inventory/SKILLS.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -name: content-inventory -description: "Extracts every piece of user-facing text in a file or flow into a structured, exportable table (screen, element, current text, character count) for copy review, translation hand-off, or content audits. Use when copy needs to be reviewed, translated, or tracked outside of Figma." ---- - -# Content Inventory - -## Purpose -Pull every user-facing string out of a design into one structured list for review, translation, or tracking. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before sending copy for translation -- Before a copy/content review pass -- When auditing a flow for tone or terminology consistency - -## Required Inputs -- The scope (file, page, or specific flow) -- Whether to include placeholder/lorem ipsum text as a flag or exclude it entirely -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Capture visible copy exactly first, then classify it. Do not rewrite content during inventory unless separately asked. - -## Workflow -1. Walk every screen in scope and extract every text layer's current content, noting the screen it is on and a short description of its role (e.g. "primary CTA", "error message", "empty state body"). -2. Record the character count for each string, useful for translation length-checking and truncation risk. -3. Flag placeholder-looking content (lorem ipsum, "Text goes here", obviously non-final names/numbers) as needing real copy before this can be finalized. -4. Group repeated strings (e.g. the same button label appearing on many screens) together, since these usually need a single decision applied consistently. -5. Note any string that appears to be dynamically generated (contains an obvious variable-like pattern, e.g. "Welcome, [Name]") separately, since these need special handling in translation. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Preserve exact current text verbatim in the inventory -- this is an extraction step, not a rewrite (see microcopy-generator or content-tone-review for rewriting). - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A table: Screen | Element/role | Text | Character count | Notes (placeholder/repeated/dynamic flags). diff --git a/skills/figma-agent/content-tone-review/SKILLS.md b/skills/figma-agent/content-tone-review/SKILLS.md deleted file mode 100644 index 49db653..0000000 --- a/skills/figma-agent/content-tone-review/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: content-tone-review -description: "Reviews existing copy in a design against a stated voice-and-tone guideline (or against the file's own established voice if no separate guideline exists) and flags lines that are inconsistent, too formal/casual, jargon-heavy, or unclear. Use as a copy QA pass distinct from drafting new copy." ---- - -# Content Tone Review - -## Purpose -Check existing copy for consistency with the intended voice and tone, and for basic clarity. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before final review, as a copy QA pass on already-drafted content -- When copy was written by multiple people/at different times and needs to feel like one voice - -## Required Inputs -- The voice/tone guideline to check against, if one exists (e.g. a brand voice doc via connector); otherwise, establish the file's own dominant voice from its most-used, most-considered copy first -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Review copy in context: user moment, severity, product surface, and nearby UI. Suggest replacement copy only where tone or clarity is actually weak. - -## Workflow -1. Run content-inventory logic first to get every string in scope in one place. -2. For each string, check: does it match the established formality level (contractions, sentence structure)? Is it using terminology consistent with the rest of the product (see visual-consistency-check for the parallel visual check)? Is it free of unexplained jargon or internal team language? -3. Check clarity independent of tone: is the sentence understandable on first read, is the most important information first, and is it as short as it can be without losing necessary nuance? -4. Check for tone mismatches given context (e.g. an overly cheerful tone on a data-loss warning, or an overly formal tone on a casual social feature). -5. Flag every inconsistency with the specific string, why it is inconsistent, and a suggested rewrite. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Flag, do not silently rewrite, unless explicitly asked to apply fixes -- tone calls often need a human sign-off. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A table: Screen/element | Current text | Issue | Suggested rewrite. diff --git a/skills/figma-agent/cva-variant-generator/SKILLS.md b/skills/figma-agent/cva-variant-generator/SKILLS.md deleted file mode 100644 index 76055c5..0000000 --- a/skills/figma-agent/cva-variant-generator/SKILLS.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -name: cva-variant-generator -description: "Generates a class-variance-authority (cva) variant configuration from a Figma component's variant properties, mapping each Figma variant option to its corresponding Tailwind class set. Use when turning a Figma component with multiple variants into styled, type-safe code variants." ---- - -# CVA Variant Generator - -## Purpose -Turn a Figma component's variant properties directly into a type-safe `cva` configuration instead of manual conditional class logic. - -## Operating Role -Act as a design-to-code bridge for this specific skill. Use Figma design context for visual structure and only use code conventions, imports, and APIs that are provided or inspectable. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. -- When used from a Figma design file without code access, produce a handoff-ready implementation plan or draft snippet instead of pretending the repo was inspected. - -## Activation Boundary -- Building code for a Figma component that has multiple variant properties (size, variant/intent, state) defined as Figma component properties - -## Required Inputs -- The Figma component's full list of variant properties and their options -- The visual difference (padding, font-size, color, border) that each option should produce, read directly from the corresponding Figma variant frames rather than guessed -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Map Figma variant properties to CVA axes before writing config. Keep compound variants only for true cross-axis exceptions. - -## Workflow -1. List every Figma variant property (e.g. Size: sm/md/lg; Variant: primary/secondary/outline/ghost/destructive; State: default/disabled) and its full option set. -2. For each option, extract the actual visual properties that differ (padding, height, font-size/weight, background/text/border color using existing tokens, radius) by comparing that variant frame against the base/default frame. -3. Build the `cva` config with a base class string (shared across all variants), a `variants` object keyed by each Figma property name (camelCased), and `defaultVariants` matching the Figma component's default variant combination. -4. Use semantic color tokens (per the color-token-format-normalizer skill) rather than raw palette classes inside each variant's class string. -5. Handle compound cases explicitly (e.g. a specific combination of size+variant that is not just the union of each individual variant's classes) using `cva`'s `compoundVariants` rather than forcing them into the simple per-property model. -6. Verify every Figma variant option has a corresponding entry in the generated config -- flag any Figma option with no generated mapping, and any generated option with no Figma source. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. -- Do not invent packages, imports, component APIs, token names, or Code Connect mappings. -- Use design tokens and existing component names only when they are visible or provided. - -## Guardrails -- Do not invent visual differences between variant options that aren't actually present in the Figma variants -- only encode what's visually specified. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return code or mapping output only when enough context exists. Otherwise return a design-to-code plan with required missing code context, proposed props, token mappings, and unresolved assumptions. -- Skill-specific format: Full `cva` config code block, followed by a coverage check list (Figma option -> mapped pass / missing fail). diff --git a/skills/figma-agent/deck-from-outline/SKILLS.md b/skills/figma-agent/deck-from-outline/SKILLS.md deleted file mode 100644 index 7a23ef3..0000000 --- a/skills/figma-agent/deck-from-outline/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: deck-from-outline -description: "Turns a text outline, bullet list, or document into a structured Figma Slides deck -- one slide per section, using consistent layout patterns and the file's existing slide template/theme. Use when the content already exists (as an outline or doc) and needs to become a presentable deck." ---- - -# Deck From Outline - -## Purpose -Convert an existing outline or document into a structured, presentable Figma Slides deck. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Content already exists as an outline, doc, or bullet list and needs to become slides - -## Required Inputs -- The source outline/document (pasted or via connector) -- The existing deck template/theme to use, if one exists in the file; otherwise ask about the intended audience/purpose to pick an appropriate structure (pitch, update, training, etc.) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Turn each outline section into one slide or a small slide group; preserve narrative pacing rather than dumping bullets. - -## Workflow -1. Read the outline and identify natural slide breaks: typically one slide per top-level section or major point, not one slide per sentence. -2. For each slide, choose a layout appropriate to its content type: title/section-divider layout for section breaks, a single-strong-statement layout for key takeaways, a list/comparison layout for enumerated points, a data/chart layout for anything quantitative mentioned in the source. -3. Reduce each slide's text to presentation-appropriate density -- headlines and short supporting points, not paragraphs copied verbatim from the source document; note any place where meaningful nuance from the source was cut so it can be added as speaker notes instead of on-slide text. -4. Apply the deck's existing template/theme (fonts, colors, logo placement) consistently across every slide rather than reinventing layout per slide. -5. Add a clear opening slide (title, presenter/date if relevant) and a closing slide (summary or call to action) even if the source outline didn't explicitly include them. -6. Where the source had supporting detail that shouldn't be cut but also does not belong on-slide, add it as speaker notes on the relevant slide. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Never fabricate data or claims not present in the source outline to "fill out" a slide -- a shorter, accurate slide is better than a padded, inaccurate one. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: The built deck, plus a slide-by-slide map back to the source outline section it came from. diff --git a/skills/figma-agent/design-brief-generator/SKILLS.md b/skills/figma-agent/design-brief-generator/SKILLS.md deleted file mode 100644 index fcde07a..0000000 --- a/skills/figma-agent/design-brief-generator/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: design-brief-generator -description: "Turns a rough, informal ask (a Slack message, a one-line ticket, a verbal request) into a structured design brief -- problem statement, goals, constraints, success criteria, and open questions -- ready to scope work against. Use at the start of a project when the ask is underspecified." ---- - -# Design Brief Generator - -## Purpose -Turn a rough or underspecified ask into a structured brief that makes the actual scope of work clear. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- A project starts from a vague or informal request and needs to be scoped before design work begins - -## Required Inputs -- The raw ask (pasted message, ticket, or description) -- Any related context available via connectors (related tickets, prior discussion, existing research) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Extract the brief from evidence first. Keep goals, non-goals, audience, constraints, and success criteria separate. - -## Workflow -1. Restate the problem being solved in one or two sentences, distinguishing the underlying user/business problem from any specific solution that may have been mentioned in the raw ask (a stated solution is not necessarily the right one). -2. State the goal(s): what should be true after this is shipped, ideally in terms that could be measured or at least clearly observed. -3. List known constraints: technical, timeline, platform, brand, or scope constraints mentioned or reasonably inferable -- mark inferred constraints as such. -4. List explicit non-goals: what this project is deliberately not trying to solve, to prevent scope creep (infer reasonable non-goals if none were stated, and flag them as suggested rather than confirmed). -5. Propose success criteria: how it will be evident this worked (metric, qualitative signal, or explicit stakeholder sign-off criteria). -6. List every open question the raw ask leaves unanswered, so these can be resolved before design work starts rather than discovered midway. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not invent scope, deadlines, or success metrics as if they were given -- clearly separate "stated", "inferred", and "open question". - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: Problem statement -> Goals -> Constraints -> Non-goals -> Success criteria -> Open questions, each section labeled by confidence (stated/inferred). diff --git a/skills/figma-agent/design-change-diff/SKILLS.md b/skills/figma-agent/design-change-diff/SKILLS.md deleted file mode 100644 index 278f950..0000000 --- a/skills/figma-agent/design-change-diff/SKILLS.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -name: design-change-diff -description: "Summarizes what changed in a design between two points in time (e.g. two branches, two versions, or before/after a review round) in plain language useful to engineers and PMs, rather than a generic 'design updated' note. Use when communicating design changes to a broader team, especially after a branch merge or a revision round." ---- - -# Design Change Diff - -## Purpose -Turn a design's version/branch history into a clear, plain-language summary of what actually changed and why it matters. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- After merging a branch back into a main file -- After a revision round, to tell stakeholders/engineers what changed since they last looked - -## Required Inputs -- The two points to compare (e.g. branch vs main, or two named versions) -- use version history if available -- The intended audience (engineers need implementation-relevant detail; PMs/stakeholders need product-relevant detail) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Compare frames structurally before summarizing: layout, content, components, tokens, interactions, and annotations. - -## Workflow -1. Identify every screen/component that differs between the two points. -2. For each change, classify it: new screen/flow added, existing screen restructured, visual-only tweak (spacing/color/copy), content/copy change, new or removed state, or interaction/prototype change. -3. Write each change as a plain-language statement of what's different and, where relevant, why (e.g. "Checkout now shows a shipping cost estimate before payment -- addresses the surprise-cost complaint from the last round of feedback" rather than just "added text layer to Checkout"). -4. Flag changes that affect implementation specifically for an engineering audience: new states, changed component props/variants, new interactions, or changed content rules. -5. Flag changes that affect scope/timeline for a PM audience: new screens, new flows, or anything that looks like scope growth relative to the original requirement. -6. Order the summary by impact (structural/flow changes first, then visual/content polish) rather than by the order changes happened to be made. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not just restate layer-level diffs (e.g. "moved layer X 4px") -- synthesize into what a reader actually needs to know; mention pure micro-adjustments only in a brief "minor polish" line at the end. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: "What changed" grouped by impact level, with a one-line "why it matters" per item, plus a short "minor polish" catch-all line. diff --git a/skills/figma-agent/design-crit/SKILLS.md b/skills/figma-agent/design-crit/SKILLS.md deleted file mode 100644 index f7ee7c2..0000000 --- a/skills/figma-agent/design-crit/SKILLS.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -name: design-crit -description: "Gives a structured, actionable design critique of a selected frame or flow, covering visual hierarchy, layout, consistency, content, and usability -- modeled on how a senior design lead would review work in a critique session. Use when a designer wants fast, honest feedback before sharing work more broadly." ---- - -# Design Crit - -## Purpose -Give a focused, senior-level critique of a design, organized so it is easy to act on. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before sharing work in a design review or with stakeholders -- As a first pass before requesting critique from teammates - -## Required Inputs -- The frame(s) or flow to critique -- Any known constraints (brand guidelines, platform, target audience) that should inform the critique -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Critique against the stated goal and user task. If no goal is supplied, infer a tentative goal and label it as an assumption. - -## Workflow -1. State what the design is trying to do in one sentence, to confirm the goal before critiquing execution. -2. Review visual hierarchy: is the primary action/content obviously primary? Does eye movement follow the intended order? -3. Review layout and spacing: alignment to grid, consistent spacing rhythm, appropriate whitespace, and information density for the context. -4. Review consistency: does this match patterns used elsewhere in the product (components, terminology, iconography)? Call out anything that reinvents an existing pattern without a clear reason. -5. Review content: clarity, tone, length of copy, and whether labels are specific and honest (e.g. avoid vague CTAs like "Submit"). -6. Review usability signals: obvious tap/click targets, clear affordances, error/empty/loading states considered, and destructive actions appropriately guarded. -7. Close with the 2-3 highest-leverage changes -- not an exhaustive nitpick list -- plus any smaller polish notes as a secondary list. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Separate subjective taste from objective usability/consistency issues, and label which is which. -- Be specific: point to the exact layer/area, not general statements like "spacing feels off". - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: "What this is trying to do" (1 line) -> "Top fixes" (2-3 items, each with why it matters) -> "Also worth polishing" (bulleted, shorter). diff --git a/skills/figma-agent/design-tokens-sync/SKILLS.md b/skills/figma-agent/design-tokens-sync/SKILLS.md deleted file mode 100644 index f691408..0000000 --- a/skills/figma-agent/design-tokens-sync/SKILLS.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -name: design-tokens-sync -description: "Compares Figma variables (colors, spacing, typography, radii) against a codebase's design tokens (CSS custom properties, JSON, or a tokens package) and reports mismatches, missing tokens, and naming drift in both directions. Use when design and engineering tokens need to be reconciled, e.g. before a release or after either side changes independently." ---- - -# Design Tokens Sync - -## Purpose -Reconcile Figma variables with the design tokens defined in code so both sides stay a single source of truth. - -## Operating Role -Act as a design-to-code bridge for this specific skill. Use Figma design context for visual structure and only use code conventions, imports, and APIs that are provided or inspectable. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. -- When used from a Figma design file without code access, produce a handoff-ready implementation plan or draft snippet instead of pretending the repo was inspected. - -## Activation Boundary -- Before a release, to catch drift between Figma and the codebase -- After a rebrand or token restructuring on either side -- When setting up token sync for the first time - -## Required Inputs -- The Figma variable collections and modes to compare (ask which collections are canonical, e.g. "Primitives", "Semantic", "Component") -- The code-side token source: a connected repo, an attached tokens JSON/YAML file, or pasted CSS custom properties -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Compare names, values, modes, aliases, and source-of-truth direction separately. Do not collapse them into one generic mismatch list. - -## Workflow -1. Enumerate every Figma variable in scope: name, type (color/number/string/boolean), value per mode, and collection/group path. -2. Enumerate every code-side token: name, value, and any theme/mode variants. -3. Match tokens by best-guess name normalization (e.g. `color/text/primary` vs `--color-text-primary` vs `color.text.primary`). Flag any pair whose values disagree even if names match. -4. List tokens that exist only in Figma (need to be added to code) and tokens that exist only in code (need to be added to Figma as variables). -5. Note mode/theme mismatches (e.g. Figma has a "Dark" mode with no code equivalent, or vice versa). -6. If asked to fix rather than just report, create the missing Figma variables in the correct collection/mode, matching the code values exactly. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. -- Do not invent packages, imports, component APIs, token names, or Code Connect mappings. -- Use design tokens and existing component names only when they are visible or provided. - -## Guardrails -- Treat the direction of truth as whichever the user specifies; default to flagging both directions without assuming which side is "right". -- Preserve existing variable aliasing (semantic tokens referencing primitives) -- do not flatten aliases into raw values. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return code or mapping output only when enough context exists. Otherwise return a design-to-code plan with required missing code context, proposed props, token mappings, and unresolved assumptions. -- Skill-specific format: A three-part table: "Matched but different value", "Figma-only", "Code-only", each row showing name, Figma value, and code value. diff --git a/skills/figma-agent/dev-handoff-prep/SKILLS.md b/skills/figma-agent/dev-handoff-prep/SKILLS.md deleted file mode 100644 index 710601d..0000000 --- a/skills/figma-agent/dev-handoff-prep/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: dev-handoff-prep -description: "Prepares a finished design for developer handoff in Dev Mode: verifies naming, checks for stray unstyled elements, adds redline/behavior annotations for anything code can't infer from static layers, and confirms components are ready to inspect. Use as the last step before marking a design 'ready for development'." ---- - -# Dev Handoff Prep - -## Purpose -Get a design genuinely ready for a developer to inspect and build from, not just visually finished. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Right before marking a design "ready for dev" or moving it to a dev-ready status - -## Required Inputs -- The frame(s)/flow being handed off -- The target platform/framework if it affects what needs annotating (e.g. web vs native conventions) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Check what a developer needs to build without guessing: states, specs, assets, tokens, responsive behavior, interactions, and open decisions. - -## Workflow -1. Run naming-convention-enforcer logic first -- Dev Mode inspection and generated code both inherit layer names directly. -2. Confirm every screen uses shared components/styles/variables where available (cross-check with follow-ds-guidelines), since Dev Mode's code suggestions and design system references depend on this. -3. Add explicit annotations for anything a developer cannot infer from the static layers: exact interaction behavior (if not already in the prototype), conditional logic, responsive behavior at breakpoints not shown, animation timing/easing not visible statically, and content rules (e.g. max character counts, truncation behavior, pluralization). -4. Verify states-completeness-check items are all present as real frames/variants, not just described, since developers need to see them to build them. -5. Double check spacing and sizing are built with auto layout/constraints rather than manual pixel placement, so Dev Mode's inspected values (padding, gap) are meaningful rather than incidental. -6. Confirm image/icon assets are export-ready (correctly named, appropriate format flagged: SVG for icons/vectors, PNG/WebP for photos) and mark anything that's a placeholder and not final asset. -7. Note any measurements or values that were intentionally approximate ("about") versus exact, so developers know where precision matters. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not add annotations restating what's already visually obvious from Dev Mode's inspect panel -- only annotate what code cannot otherwise infer. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A "Ready for dev" checklist with pass/fail per item, plus the list of annotations added and where. diff --git a/skills/figma-agent/figma-skill-router/SKILLS.md b/skills/figma-agent/figma-skill-router/SKILLS.md deleted file mode 100644 index 1e243f0..0000000 --- a/skills/figma-agent/figma-skill-router/SKILLS.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -name: figma-skill-router -description: "Use when a Figma Design agent must choose among installed Figma skills for a request or design-file context." ---- - -# Figma Skill Router - -Select and hand off to one installed Figma skill. Skip it when a narrower matching skill is already invoked. - -## Route - -1. Read the goal and strongest context: selection, page, library, comments, branch, PRD, code, or none. -2. Choose the narrowest index entry. Use check skills for “audit”, “review”, or “find”; use apply skills for “fix”, “apply”, “migrate”, or “standardize”. -3. Return one primary skill and only one dependent next skill. Ask once only for missing required input. - -## Capability Gate - -Treat prototype or interaction work as a plan unless interaction editing is supported. State limits for exports, vector editing, or diagrams/data visualizations; use external context only when supplied. - -## Catalogue Index - -Use the request noun and verb to choose within the relevant group. - -| Area | Installed skills | -| --- | --- | -| Discover and define | `design-brief-generator`, `build-from-prd`, `persona-builder`, `journey-map-builder`, `workshop-facilitator`, `affinity-mapping`, `sticky-synthesis`, `competitive-teardown`, `deck-from-outline` | -| Content and brand | `content-inventory`, `content-tone-review`, `microcopy-generator`, `localization-readiness`, `brand-kit-asset-generator` | -| Layout and construction | `container-layout-normalizer`, `responsive-breakpoint-check`, `spacing-scale-enforcer`, `figma-to-code-component`, `base-ui-primitive-composition`, `shadcn-component-structure`, `cva-variant-generator` | -| Components and libraries | `component-audit`, `component-naming-sync`, `library-health-report`, `follow-ds-guidelines`, `design-tokens-sync`, `legacy-styles-to-variables`, `apply-color-variables`, `color-token-format-normalizer`, `semantic-color-audit` | -| Review and quality | `accessibility-audit`, `heuristic-evaluation`, `design-crit`, `visual-consistency-check`, `states-completeness-check`, `site-launch-checklist`, `prototype-qa`, `animation-consistency-check` | -| Prototypes and motion | `prototype-from-flow`, `wire-up-interactions`, `variable-driven-prototype`, `motion-spec-generator` | -| Code, changes, and handoff | `code-connect-mapper`, `dev-handoff-prep`, `handoff-summary`, `token-tailwind-theme-sync`, `tailwind-class-order-check`, `design-change-diff`, `branch-review-summary` | -| File operations | `file-cleanup`, `rename-layers-batch`, `naming-convention-enforcer` | -| Collaboration and utilities | `comment-triage`, `plugin-widget-recommender` | - -## Tie-Breakers - -Use `component-audit` for one set, `library-health-report` library-wide; `microcopy-generator` writes, `content-inventory` enumerates. `design-crit` is broad feedback, `heuristic-evaluation` usability, `accessibility-audit` access; `journey-map-builder` maps experience, `prototype-from-flow` plans screens. For unmatched requests: `design-brief-generator` (new) or `design-crit` (improve). - -## Handoff - -Return only: - -```markdown -Primary skill: `` -Why: -Scope: -Next skill: `` — -Capability note: -``` - -Do not list alternatives, perform the work, or send two skills to the same artifact. diff --git a/skills/figma-agent/figma-to-code-component/SKILLS.md b/skills/figma-agent/figma-to-code-component/SKILLS.md deleted file mode 100644 index d2f9dac..0000000 --- a/skills/figma-agent/figma-to-code-component/SKILLS.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -name: figma-to-code-component -description: "Translates a selected Figma frame or component into idiomatic code for a specified target (e.g. React + Tailwind, React + CSS Modules, SwiftUI, Jetpack Compose), mapping Figma variables to design tokens and Figma auto layout to the target's layout system. Use for a first-pass implementation of a specific design element, not a full application build." ---- - -# Figma To Code Component - -## Purpose -Produce a first-pass, idiomatic code implementation of a specific Figma frame or component for a stated target stack. - -## Operating Role -Act as a design-to-code bridge for this specific skill. Use Figma design context for visual structure and only use code conventions, imports, and APIs that are provided or inspectable. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. -- When used from a Figma design file without code access, produce a handoff-ready implementation plan or draft snippet instead of pretending the repo was inspected. - -## Activation Boundary -- A specific component or screen needs an initial code implementation -- Specify the target explicitly (framework, styling approach) since output differs significantly by stack - -## Required Inputs -- The frame/component to translate -- Target framework and styling approach (e.g. "React + Tailwind", "SwiftUI", "Vue + CSS Modules") -- Whether an existing Code Connect mapping or component library in code should be reused instead of generating new markup (check code-connect-mapper first if unsure) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Translate the selected component anatomy, not the whole page. Use Figma design context for structure and code context for imports/components when available. - -## Workflow -1. Read the layer structure, auto layout settings (direction, gap, padding, alignment, resizing), and applied variables/styles from the design. -2. If a Code Connect mapping exists for this component, use the mapped code component and its props instead of generating raw markup -- only generate new markup for elements without a mapping. -3. Translate auto layout to the target's native layout system: flex direction/gap/padding for CSS/React, HStack/VStack/spacing for SwiftUI, Row/Column/Arrangement for Compose -- preserving hug/fill/fixed sizing semantics precisely. -4. Map Figma variables to the target's design tokens (CSS custom properties, a theme object, or platform-native token references) rather than hardcoding resolved values, so the code stays themeable. -5. Reproduce text styles (font, size, weight, line-height, letter-spacing) using the target's typography system/tokens, not inline magic numbers. -6. Implement interactive/variant states (hover, focus, pressed, disabled) using the target's idiomatic mechanism (CSS pseudo-classes, SwiftUI modifiers, Compose state), matching exactly what the Figma variants show. -7. Note any part of the design that couldn't be translated cleanly (e.g. a very custom vector shape, an unusual blend mode) and suggest the closest reasonable code equivalent. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. -- Do not invent packages, imports, component APIs, token names, or Code Connect mappings. -- Use design tokens and existing component names only when they are visible or provided. - -## Guardrails -- Prefer semantic, accessible markup/components (correct heading levels, button vs div, labeled form controls) over pixel-matching with generic elements. -- Do not fabricate a Code Connect mapping that does not exist -- only use ones that are actually present. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return code or mapping output only when enough context exists. Otherwise return a design-to-code plan with required missing code context, proposed props, token mappings, and unresolved assumptions. -- Skill-specific format: The generated code, plus a short list of any design details that required a judgment call during translation. diff --git a/skills/figma-agent/file-cleanup/SKILLS.md b/skills/figma-agent/file-cleanup/SKILLS.md deleted file mode 100644 index 99e14f0..0000000 --- a/skills/figma-agent/file-cleanup/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: file-cleanup -description: "Reorganizes a messy, sprawling file into clearly named, logically ordered pages and sections, archiving or clearly marking stale exploration work, without altering any final designs. Use when a working file has become hard to navigate after a lot of exploration." ---- - -# File Cleanup - -## Purpose -Make a sprawling working file navigable again by organizing it into clear pages/sections, without touching the actual design content that matters. - -## Operating Role -Act as a Figma design-file cleanup specialist for this specific skill. Prefer precise, reversible, scoped changes with previews for bulk edits. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- A file has accumulated a lot of exploration, dead ends, and loosely organized content and is hard to navigate -- Before sharing a file more broadly or archiving a project - -## Required Inputs -- Which content is final/current vs. exploratory/stale -- ask if it is not obvious from context (e.g. naming, position, or comments) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Separate final, archive, exploration, and trash candidates. Never delete uncertain work; move or label it for review. - -## Workflow -1. Inventory existing pages and top-level sections/frames and what each currently contains. -2. Propose a clear structure: typically something like "Final / Current", "In progress", "Explorations", "Archive", "Handoff-ready" -- adapt names to the team's convention if one already exists. -3. Move content into the proposed structure, keeping exploratory work intact (not deleted) but clearly separated from current/final work so it does not get mistaken for the source of truth. -4. Rename pages/sections descriptively (pairs with naming-convention-enforcer) so the file's structure is understandable from the pages panel alone. -5. Add a short README-style frame or section at the top of the file (if none exists) explaining the file's structure and where to find current work. -6. Flag genuinely obsolete content (e.g. an abandoned direction with no relevance to current work) as a candidate to archive out of the file entirely, rather than deleting it outright. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Never delete design content as part of cleanup -- only reorganize, rename, and flag; deletion should be a separate, explicit, human-confirmed step. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return a preview or change log with before/after values, skipped ambiguous items, and any breaking-change risk. Keep the report short enough to act on immediately. -- Skill-specific format: A before -> after structure map, plus a short list of anything flagged as a candidate for archiving/deletion. diff --git a/skills/figma-agent/follow-ds-guidelines/SKILLS.md b/skills/figma-agent/follow-ds-guidelines/SKILLS.md deleted file mode 100644 index f92da12..0000000 --- a/skills/figma-agent/follow-ds-guidelines/SKILLS.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -name: follow-ds-guidelines -description: "Audits a selected frame, screen, or file against the team's published design system (components, styles, and variables) and flags every deviation with a suggested fix. Use when a design needs to conform to existing design system rules before review or handoff. Does not create new components -- use component-audit or legacy-styles-to-variables for that." ---- - -# Follow DS Guidelines - -## Purpose -Check a design against the team's design system and flag anything that does not use approved components, styles, or variables. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before sending a file for design review -- Before dev handoff -- After a large exploration pass full of ad hoc shapes and colors - -## Required Inputs -- Which library/libraries are the source of truth (ask if more than one is enabled) -- The specific frame(s), page, or selection to audit -- default to the current selection, or the current page if nothing is selected -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Prioritize actual system violations over cosmetic preferences. Use the current library names and variables exactly as they exist. - -## Workflow -1. Identify the enabled libraries for the file and note their published components, color/text/effect styles, and variable collections. -2. Walk every layer in the selected scope. For each layer, check: - - Colors: is the fill/stroke a bound variable or shared style, or a raw hex/RGBA value? - - Typography: is text using a shared text style, or manually set font/size/line-height? - - Spacing: does auto layout padding/gap use spacing variables, or hardcoded pixel values? - - Components: could this group of layers be replaced by an existing component or variant instead of custom-drawn layers? - - Corner radius / effects: do they match a published style/variable, or a one-off value? -3. Group findings by severity: "Must fix" (visibly off-brand or inconsistent), "Should fix" (raw value that happens to match a token), "Consider" (an existing component could simplify this pattern). -4. Propose the fix for each finding: which style, variable, or component instance to swap in. -5. Ask before applying destructive changes (detaching instances, deleting layers). Apply straightforward token/style swaps directly if asked to fix; otherwise just report. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Never invent a new style or variable name that does not exist in the library -- flag the gap instead and suggest it be added to the library. -- Do not flag intentional one-offs called out in a layer's name or a nearby annotation (e.g. "custom - marketing exception"). - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A grouped checklist (Must fix / Should fix / Consider) with a one-line description and suggested fix per item, plus a short summary count at the top. diff --git a/skills/figma-agent/handoff-summary/SKILLS.md b/skills/figma-agent/handoff-summary/SKILLS.md deleted file mode 100644 index 6ec4369..0000000 --- a/skills/figma-agent/handoff-summary/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: handoff-summary -description: "Writes a concise handoff summary of a file's current state -- what's finished, what's in progress, key decisions made and why, and open questions -- for a teammate picking up the work, a new team member, or a stakeholder update. Use whenever context needs to transfer cleanly to someone else." ---- - -# Handoff Summary - -## Purpose -Give someone picking up a file everything they need to get oriented quickly, without having to reconstruct history themselves. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Handing work off to another designer, a new team member, engineering, or a stakeholder -- Before going out of office on an active project - -## Required Inputs -- The file/project and the audience for the summary (a teammate continuing the work needs different detail than a stakeholder getting a status update) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Write for the receiving developer or reviewer. Summarize what matters to build, verify, or decide. - -## Workflow -1. State current status plainly: what's finished and considered final, what's in progress, and what hasn't been started yet. -2. Summarize key decisions made so far and briefly why, especially any non-obvious ones a newcomer might otherwise second-guess or accidentally re-litigate. -3. List explicit open questions and known unresolved issues, distinguishing "blocked on someone else" from "not yet decided by this team". -4. Point to exactly where in the file to find current/final work versus exploration (pairs with file-cleanup if the file itself is not yet organized enough to point to clearly). -5. For a teammate-continuation audience, include practical next steps: what the most logical next task is and any context needed to start it immediately. -6. For a stakeholder audience, keep decision rationale and next steps but drop file-navigation detail that is not relevant to them. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Keep the summary honest about what's actually unresolved -- do not smooth over open risks to make status look more complete than it is. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: Status (Finished / In progress / Not started) -> Key decisions + why -> Open questions -> Where to look in the file -> Next steps, tailored to the stated audience. diff --git a/skills/figma-agent/heuristic-evaluation/SKILLS.md b/skills/figma-agent/heuristic-evaluation/SKILLS.md deleted file mode 100644 index 0b5aa11..0000000 --- a/skills/figma-agent/heuristic-evaluation/SKILLS.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -name: heuristic-evaluation -description: "Evaluates a flow or screen against Jakob Nielsen's 10 usability heuristics (visibility of system status, match with the real world, user control, consistency, error prevention, recognition over recall, flexibility, minimalist design, error recovery, help and documentation) and reports concrete violations. Use for a fast, structured usability pass independent of visual polish." ---- - -# Heuristic Evaluation - -## Purpose -Run a structured usability evaluation of a flow using Nielsen's 10 usability heuristics, independent of visual style. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- When usability, not visual polish, is the concern -- Before user testing, to catch obvious issues cheaply first - -## Required Inputs -- The flow (ordered set of screens) to evaluate, or a single screen if that's the scope -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Use heuristics as lenses, not as a generic checklist. Report only issues visible in the selected flow. - -## Workflow -Walk the flow once per heuristic and record concrete violations, referencing the specific screen/element: -1. Visibility of system status -- does the user always know what's happening (loading, progress, confirmation)? -2. Match between system and the real world -- does language and iconography match user mental models, not internal jargon? -3. User control and freedom -- is there an obvious way to undo, cancel, or go back at every step? -4. Consistency and standards -- do similar actions look and behave the same way throughout the flow? -5. Error prevention -- are destructive or hard-to-reverse actions confirmed or made hard to trigger by accident? -6. Recognition rather than recall -- are options visible when needed, rather than requiring the user to remember something from an earlier screen? -7. Flexibility and efficiency of use -- are there reasonable shortcuts for repeat/expert users without cluttering the default path? -8. Aesthetic and minimalist design -- is every element earning its place, or is there competing/irrelevant information? -9. Help users recognize, diagnose, and recover from errors -- are error messages specific, in plain language, and paired with a way to fix the problem? -10. Help and documentation -- for complex actions, is contextual help available where it is needed, not just in a separate help center? - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Only report a violation if it is concretely observable in the flow -- do not pad the report with heuristics that have nothing to flag. -- Rate severity (Critical / Moderate / Minor) per Nielsen's standard severity scale so findings can be triaged. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: One section per heuristic with violations found (or "No issues observed"), each violation rated by severity. diff --git a/skills/figma-agent/journey-map-builder/SKILLS.md b/skills/figma-agent/journey-map-builder/SKILLS.md deleted file mode 100644 index fc87bee..0000000 --- a/skills/figma-agent/journey-map-builder/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: journey-map-builder -description: "Builds a user journey map on a FigJam (or design) canvas from research notes, transcripts, or a described experience -- stages, actions, thoughts/feelings, pain points, and opportunities per stage. Use when synthesizing research into a shareable journey artifact." ---- - -# Journey Map Builder - -## Purpose -Turn research notes or a described user experience into a structured journey map. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- After user research (interviews, surveys, session recordings) needs to be synthesized into a shared artifact -- When scoping a project and a clear before/during/after picture of the user's experience would help - -## Required Inputs -- The source material: research notes, meeting transcripts (via connector), or a described experience -- The persona/user type the journey is for, if more than one is relevant -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Build the map from evidence-backed stages, touchpoints, user actions, emotions, pain points, and opportunities. Mark guessed stages. - -## Workflow -1. Identify the journey's scope (start and end point) and break it into a small number of clear stages (typically 4-7) that represent meaningful phases, not every micro-step. -2. For each stage, extract: the user's actions, their thoughts/feelings (quote directly from research where possible), touchpoints/channels involved, pain points, and any positive moments worth preserving. -3. Identify opportunities per stage -- a specific, actionable idea suggested by the pain point or positive moment, not a vague "improve this". -4. Lay the map out as a grid: stages as columns, the rows above (actions, thoughts/feelings, touchpoints) and pain points/opportunities as the bottom rows, so it reads left-to-right as the experience unfolds. -5. Include a visual emotion indicator per stage (e.g. a simple line or icon showing relative highs/lows) to make the emotional arc scannable at a glance. -6. Cite the source for major claims (e.g. which interview a quote came from) so the map remains traceable to real research. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not fabricate quotes or data points not present in the source material -- mark any inferred (not directly sourced) content as an assumption. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: The journey map structure (stages x rows) built directly on the canvas, plus a short list of the top 3 opportunities surfaced. diff --git a/skills/figma-agent/legacy-styles-to-variables/SKILLS.md b/skills/figma-agent/legacy-styles-to-variables/SKILLS.md deleted file mode 100644 index 091de47..0000000 --- a/skills/figma-agent/legacy-styles-to-variables/SKILLS.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -name: legacy-styles-to-variables -description: "Finds hardcoded fill, stroke, and effect colors, hardcoded spacing values, or old-style color/text styles in a file and migrates them to the equivalent shared variables or styles from an enabled library. Use when adopting variables in a file that predates them, or migrating a file onto a newer design system version." ---- - -# Legacy Styles To Variables - -## Purpose -Move a file from hardcoded values (and/or old-style shared styles) onto the current variable-based design system. - -## Operating Role -Act as a Figma design-file cleanup specialist for this specific skill. Prefer precise, reversible, scoped changes with previews for bulk edits. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- A file was built before the team adopted variables -- A library moved from styles to variables and old files need to catch up - -## Required Inputs -- The target variable collection(s)/library to migrate onto -- Scope: whole file, a page, or a selection -- Whether old styles should be kept for backward compatibility or deleted after migration -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Inventory current styles and raw values before creating variables. Preserve semantic aliases and modes. - -## Workflow -1. Scan the scope for: raw hex/RGBA fills and strokes, raw pixel spacing/radius values in auto layout frames, and any old-format color/text/effect styles. -2. For each raw value, find the closest matching variable by value (exact match first, then nearest by contrast/lightness for colors or nearest scale step for spacing). -3. Where an exact semantic match is not obvious (e.g. a gray that could be `border/subtle` or `border/default`), list the candidates and ask, rather than guessing silently. -4. Apply the variable bindings, preserving any interactive/mode-specific behavior (e.g. bind to a variable that already has both Light and Dark mode values, do not just set a flat value). -5. Re-check contrast and visual appearance after binding, since the nearest-match variable may render at a very slightly different value than the original. -6. Report anything left unmigrated (e.g. a color with no reasonable variable match) so it can be added to the library deliberately instead of forced into the wrong token. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Never delete an old style that's still referenced elsewhere in the file without flagging it first. -- Prefer semantic variables (e.g. `text/primary`) over primitive variables (e.g. `gray/900`) when both exist and the semantic one fits. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return a preview or change log with before/after values, skipped ambiguous items, and any breaking-change risk. Keep the report short enough to act on immediately. -- Skill-specific format: A migration log: original value -> variable bound, grouped by Fills, Strokes, Spacing, Effects, plus an "unmigrated" list at the end. diff --git a/skills/figma-agent/library-health-report/SKILLS.md b/skills/figma-agent/library-health-report/SKILLS.md deleted file mode 100644 index 4fbf7bc..0000000 --- a/skills/figma-agent/library-health-report/SKILLS.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -name: library-health-report -description: "Audits a published component/style/variable library for unused assets, undocumented components, duplicate or near-duplicate styles, and inconsistent naming across the whole library, producing a prioritized cleanup report. Use periodically to keep a shared design system library healthy as it grows." ---- - -# Library Health Report - -## Purpose -Produce a prioritized health report for a published library so it can be kept clean and trustworthy as it grows. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Periodic design system maintenance -- Before a major library version bump, to clean up debt first - -## Required Inputs -- The library/libraries to audit -- Any usage/analytics data available (e.g. library analytics on adoption/insertions) to inform what's actually used -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Evaluate the library as infrastructure: reuse, duplication, naming, variants, variables, docs, deprecated patterns, and publishing risk. - -## Workflow -1. List every component, style, and variable in the library along with its description status (documented or not) and, if available, usage/insertion data. -2. Flag likely-unused assets (no or very low usage per analytics, or an old component clearly superseded by a newer one) as candidates for deprecation -- never delete outright without flagging first, since removal can break consuming files. -3. Flag duplicate or near-duplicate styles/variables (e.g. two near-identical grays, two color styles with the same value but different names) that should be consolidated. -4. Flag components/variants missing descriptions, since these are harder for consumers to use correctly (pairs with component-audit for structural issues on a specific component). -5. Flag naming inconsistencies across the library as a whole (e.g. inconsistent capitalization or grouping conventions across otherwise-similar components) -- pairs with naming-convention-enforcer for applying fixes. -6. Prioritize the report: correctness issues (things that will visibly cause bugs, like duplicate conflicting tokens) first, then consistency issues, then documentation gaps. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Never unpublish or delete a library asset directly as part of this skill -- always report and let a human confirm deprecations, since other files may depend on it. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A prioritized report: Critical (fix soon) / Consolidate / Document, each item naming the specific asset and the issue. diff --git a/skills/figma-agent/localization-readiness/SKILLS.md b/skills/figma-agent/localization-readiness/SKILLS.md deleted file mode 100644 index 698f582..0000000 --- a/skills/figma-agent/localization-readiness/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: localization-readiness -description: "Checks a design for issues that will surface once text is translated: fixed-width containers that will clip longer languages, RTL layout assumptions, concatenated/hardcoded sentence fragments, and untranslatable content baked into images. Use before sending a design or file for localization." ---- - -# Localization Readiness - -## Purpose -Catch layout and content patterns that break once text is translated, before that translation actually happens. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before sending a file or flow for translation/localization -- When a product is expanding into new languages, especially RTL (Arabic, Hebrew) or long-average-length languages (German, Finnish) or CJK languages - -## Required Inputs -- The target languages/locales, if known -- this changes which checks matter most (RTL vs length-expansion vs CJK line-breaking) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Stress-test layouts for text expansion, format changes, bidirectionality, and ambiguous visuals. Separate design risks from engineering i18n risks. - -## Workflow -1. Check every text container's resizing: fixed-width/fixed-height text layers should be flagged, since most languages run 20-35% longer than English and German/Finnish can run even longer; containers should hug or allow wrapping. -2. Check for hardcoded concatenation patterns (e.g. a sentence assembled from separate text layers like "You have " + [3] + " items") since word order varies by language -- flag these as needing to become a single translatable string with placeholders. -3. Check for text baked into images (e.g. a screenshot with UI text, an illustration with a label) and flag it as needing a real text layer or a per-locale asset instead. -4. If RTL locales are in scope, check that layout is built with auto layout/constraints that can mirror (rather than assets or layouts that assume strict left-to-right), and flag icons that imply direction (e.g. arrows, "back" chevrons) as needing mirrored variants. -5. If CJK locales are in scope, check line-height and font choices accommodate taller/denser glyphs, and that text is not relying on letter-spacing tricks that do not apply to CJK scripts. -6. Check date, number, and currency formats aren't hardcoded to one locale's convention in a way the code cannot override per locale. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Report each issue with the specific screen/layer, not general localization advice. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A checklist grouped by risk type (Fixed-width containers, Concatenation, Text-in-images, RTL, CJK, Formats) with pass/fail and fix per item. diff --git a/skills/figma-agent/microcopy-generator/SKILLS.md b/skills/figma-agent/microcopy-generator/SKILLS.md deleted file mode 100644 index 8143b7e..0000000 --- a/skills/figma-agent/microcopy-generator/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: microcopy-generator -description: "Drafts microcopy -- button labels, empty states, error messages, tooltips, confirmation dialogs, form hints -- for a specific screen or component, matching a stated (or inferred from existing content) voice and tone. Use when placeholder text needs to become real, ship-ready copy." ---- - -# Microcopy Generator - -## Purpose -Draft real, ship-ready microcopy for specific UI moments, matching the product's existing voice. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- A screen has placeholder copy that needs to become final -- A new state (error, empty, confirmation) needs copy drafted from scratch - -## Required Inputs -- The specific element(s) needing copy and their exact context (what triggered this state, what the user should do next) -- The voice/tone to match -- infer it from existing finished copy elsewhere in the file if not explicitly given, and state the inferred voice before proceeding -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Generate copy in sets of 2-3 high-quality options only when alternatives are useful. Prefer precise UI copy over clever copy. - -## Workflow -1. Read existing finished copy in the file (not placeholders) to infer voice: formality, use of contractions, humor level, sentence length, and terminology choices already established. -2. For each element needing copy, write to the specific pattern's best practice: buttons as a specific verb + object ("Save changes", not "Submit"), error messages that state what happened and how to fix it (not just "Something went wrong"), empty states that explain what will appear and how to get there, tooltips that add information not already visible, confirmation dialogs that state the specific consequence of the action. -3. Respect any known length constraints (character counts from content-inventory, container width) and note if the best copy does not fit and a container change would be better than truncation. -4. Keep terminology consistent with what's used elsewhere in the file (e.g. do not introduce "delete" in one place and "remove" in another for the same action). -5. Provide one primary option per element; offer 1-2 alternates only where tone is genuinely ambiguous or the user asked for options. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Never invent copy that implies a feature, policy, or promise not otherwise confirmed (e.g. do not write "your data is never shared" unless that's an established, accurate claim). - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: A list of element -> drafted copy (plus alternates where relevant), with the inferred voice stated up front. diff --git a/skills/figma-agent/motion-spec-generator/SKILLS.md b/skills/figma-agent/motion-spec-generator/SKILLS.md deleted file mode 100644 index 8d35522..0000000 --- a/skills/figma-agent/motion-spec-generator/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: motion-spec-generator -description: "Defines and documents a precise motion spec (duration, easing curve, delay, properties animated) for key transitions in a flow, so the intended motion feel is captured explicitly rather than left to be reverse-engineered from a prototype. Use when documenting motion decisions for engineering handoff or design system consistency." ---- - -# Motion Spec Generator - -## Purpose -Turn intended motion for key transitions into a precise, documented spec that can be implemented consistently. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Documenting motion for developer handoff -- Establishing/updating a design system's motion guidelines - -## Required Inputs -- The specific transitions/animations to spec (e.g. modal open/close, page transition, a component's micro-interaction) -- Any existing motion principles for the product (e.g. "quick and snappy" vs. "smooth and considered") to keep new specs consistent with -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Describe trigger, affected layers, properties, duration, easing, direction, and reduced-motion expectation for each motion moment. - -## Workflow -1. For each transition, identify exactly which properties animate (position, opacity, scale, color, size) and their start and end values. -2. Choose duration deliberately based on the distance/size of the change and the transition's role: micro-interactions (hover, toggle) typically feel best fast (roughly 100-200ms), standard navigational transitions moderate (roughly 200-400ms), and larger/attention-drawing transitions slightly longer -- state the exact chosen value, not a vague range, and keep it consistent with any existing product-wide motion principle. -3. Choose an easing curve matching the motion's character: ease-out for elements entering/appearing (fast start, gentle stop feels responsive), ease-in for elements exiting, ease-in-out for elements moving between two on-screen states, and spring/bounce easing (with specific stiffness/damping or bounce/duration values) for anything meant to feel tactile or playful -- state exact curve parameters, not just a name, if the target platform needs them (e.g. cubic-bezier values for CSS). -4. Note any delay/stagger, especially for multi-element transitions (e.g. list items staggering in), including the exact per-item delay. -5. Note reduced-motion behavior: what should happen instead when a user has motion-reduction preferences enabled (usually: keep the state change, remove or shorten the animated transition). -6. Where the Figma prototype's Smart Animate or spring settings already exist, extract their actual values as the source of truth for the spec rather than re-guessing. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Give implementable exact values (ms, curve parameters) rather than only qualitative descriptions like "smooth" or "quick". - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: A per-transition spec table: Transition | Properties animated | Duration | Easing | Delay/stagger | Reduced-motion behavior. diff --git a/skills/figma-agent/naming-convention-enforcer/SKILLS.md b/skills/figma-agent/naming-convention-enforcer/SKILLS.md deleted file mode 100644 index 3388c69..0000000 --- a/skills/figma-agent/naming-convention-enforcer/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: naming-convention-enforcer -description: "Renames layers, frames, components, and pages to follow a specified naming convention (e.g. PascalCase components, sentence-case screens, prefix-based icon names). Use for cleaning up messy layer names before handoff, publishing, or Dev Mode inspection." ---- - -# Naming Convention Enforcer - -## Purpose -Bring layer, frame, and component names in line with a consistent, documented naming convention. - -## Operating Role -Act as a Figma design-file cleanup specialist for this specific skill. Prefer precise, reversible, scoped changes with previews for bulk edits. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before Dev Mode handoff, when generated code would otherwise inherit names like "Frame 482" or "Rectangle 12" -- Before publishing a library -- Periodically, as file hygiene - -## Required Inputs -- The naming convention to apply (ask for one if none is specified -- a reasonable default is: screens in Sentence case describing the screen, components in PascalCase describing the element, icons prefixed `icon/`, and no default Figma names like "Frame", "Group", or "Rectangle" left unnamed) -- Scope: page, selection, or whole file -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Apply the provided convention exactly. If no convention exists, propose a simple one and ask before mass renaming. - -## Workflow -1. List every layer in scope still using a Figma default name (Frame N, Group N, Rectangle N, Ellipse N, Vector, Component N, etc.) or an inconsistent name relative to its siblings. -2. Infer a meaningful name from the layer's content (text contents, icon shape, its role in the parent's auto layout) and the target convention. -3. For structural containers (sections, frames representing screens), name them for what they represent in the product (e.g. "Checkout / Payment step"), not their visual properties. -4. For components and variants, ensure names match the base + variant-property convention from component-audit. -5. Present the full rename list for confirmation before applying at scale; apply directly only for small, obviously-safe batches if asked to "just do it". - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Never rename a layer referenced by an existing Code Connect mapping, prototype interaction target, or component property binding without noting that the mapping/binding may need to be updated too. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return a preview or change log with before/after values, skipped ambiguous items, and any breaking-change risk. Keep the report short enough to act on immediately. -- Skill-specific format: A before -> after rename table grouped by layer type (Pages, Frames/Screens, Components, Icons, Other). diff --git a/skills/figma-agent/persona-builder/SKILLS.md b/skills/figma-agent/persona-builder/SKILLS.md deleted file mode 100644 index 536f7e4..0000000 --- a/skills/figma-agent/persona-builder/SKILLS.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -name: persona-builder -description: "Builds a lightweight, evidence-grounded persona (or refreshes an existing one) from available research notes, interview data, or survey results for a specific project -- avoiding invented demographic detail not supported by the source data. Use when a project needs a shared reference point for who it's designing for." ---- - -# Persona Builder - -## Purpose -Build a lightweight persona grounded in actual available research, for use as a shared reference point on a project. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- A project needs an agreed reference point for who it is designing for -- Refreshing an existing persona against newer research - -## Required Inputs -- The available research source (interview notes, survey data, support tickets, existing user research repository) -- this skill should not proceed from pure assumption; if no research exists, say so and suggest what minimal research would ground a real persona -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Ground personas in provided evidence. Do not invent demographics unless they are relevant and supported. - -## Workflow -1. Extract from the source data: goals, common pain points, typical context of use (when/where/how the product is used), and any notable behavioral patterns that recur across multiple sources (not a single outlier data point). -2. Build the persona around behaviors and goals relevant to the project, not incidental demographic detail (age, name, stock photo) unless that detail is actually relevant to the design problem and supported by the data. -3. Include representative quotes from the source material where they exist, to keep the persona connected to real voices rather than reading as invented. -4. Note confidence level per major claim (well-supported across many sources vs. a single data point) so the team knows where the persona is on solid ground versus thin. -5. If multiple distinct user types emerge from the data, propose splitting into multiple personas rather than averaging into one that represents no one well. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Never invent a name, photo, or biographical detail presented as if it were real data -- if illustrative detail is added for readability, label it clearly as illustrative, not sourced. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: Persona name (role-based, e.g. "The time-pressed approver") -> Goals -> Pain points -> Context of use -> Representative quotes -> Confidence notes. diff --git a/skills/figma-agent/plugin-widget-recommender/SKILLS.md b/skills/figma-agent/plugin-widget-recommender/SKILLS.md deleted file mode 100644 index 6300223..0000000 --- a/skills/figma-agent/plugin-widget-recommender/SKILLS.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -name: plugin-widget-recommender -description: "Recommends specific, well-regarded plugins or widgets for a stated workflow need (e.g. content population, accessibility checking, data visualization), and separately audits which plugins/widgets are already used in a file against an organization's approved list if one is provided. Use when looking for the right tool for a task, or auditing plugin usage against policy." ---- - -# Plugin Widget Recommender - -**Category:** Organization & Governance -**Slash Command:** `/plugin-widget-recommender` -**Surface:** Figma Design (Agent) -> Use to find the right plugin for a task, or to audit plugin usage against org policy. - -## Purpose -Recommend the right plugin/widget for a specific workflow need, or audit existing plugin/widget usage against an organization's policy. - -## Operating Role -Act as a Figma workflow advisor for this specific skill. Base recommendations on the stated task, visible file context, and explicit policy or connector context. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Looking for a tool to solve a specific, recurring manual task (e.g. renaming layers in bulk, checking contrast, generating placeholder content, syncing data into the file) -- Auditing a file's or team's plugin usage against an approved/allowed list - -## Required Inputs -- The specific workflow problem to solve, described concretely (not just "any useful plugins") -- If auditing: the organization's approved plugin/widget list, if one is provided -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Recommend by workflow fit, current verification status, and organization approval risk. Avoid generic plugin lists. - -## Workflow -1. For a recommendation request, restate the underlying workflow problem precisely, then suggest plugin/widget categories or well-known, broadly-used specific options that address it, favoring plugins from Figma's verified/highly-rated set where relevant, and being explicit that plugin ecosystems change and availability/approval should be verified in the organization's own plugin management settings before install. -2. For an audit request, list plugins/widgets currently used in the file (as visible from plugin data/traces in the file, or as reported by the user) against the approved list, flagging anything not on it. -3. For unapproved plugins found, note what workflow they appear to serve so a reviewer can decide whether to request approval or find an approved alternative that does the same job. -4. Where relevant, note that private plugins/widgets can be created for organization-specific needs that public options do not cover well. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. -- Do not install, approve, disable, or configure plugins/widgets. Verify current availability and organization approval before recommending adoption. - -## Guardrails -- This skill cannot install, approve, or configure plugins/widgets on your behalf -- organization plugin management is an admin action outside what a design/dev file skill can do; recommend and audit only. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return recommendations as a short ranked list with rationale, fit, risk, and what must be verified before adoption. -- Skill-specific format: For recommendations: a short list of options with what each is best for. For audits: a table of Plugin/widget | Approved? | Apparent purpose. diff --git a/skills/figma-agent/prototype-from-flow/SKILLS.md b/skills/figma-agent/prototype-from-flow/SKILLS.md deleted file mode 100644 index 3e9aab1..0000000 --- a/skills/figma-agent/prototype-from-flow/SKILLS.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -name: prototype-from-flow -description: "Builds a clickable, connected prototype from a described user flow, a flow diagram, or a set of already-designed screens -- wiring up prototype connections, triggers, and actions end to end. Use when screens exist (or a flow is described) but aren't yet linked into a testable prototype." ---- - -# Prototype From Flow - -## Purpose -Turn a described or diagrammed user flow, or a set of unconnected screens, into a fully wired, clickable prototype. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Screens are designed but not yet connected -- A flow diagram (from FigJam, a PRD, or a description) needs to become a testable prototype - -## Required Inputs -- The flow definition: an ordered description of screens and the decisions/actions that move between them, or a reference to a FigJam flow/diagram -- The starting frame for the prototype -- Any states that should be reflected in the flow (e.g. logged in vs out, empty cart vs full cart) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Map the full flow as nodes and decision points before wiring interactions. -- Use one canonical happy path plus explicit branches; avoid adding speculative routes. - -## Workflow -1. Map every step in the flow to an existing frame; if a needed screen does not exist yet, flag it rather than inventing new UI, unless asked to also design the missing screens. -2. For each transition, pick the trigger that matches the interaction (On click/tap for buttons and links, On drag for swipe/scroll interactions, After delay for auto-advancing content, key/gamepad triggers only if explicitly relevant). -3. Choose the action that matches the intent: Navigate to for standard transitions, Open overlay for modals/menus/tooltips, Swap state for interactive component state changes, Scroll to for in-page jumps, Back for return navigation. -4. Choose an animation (Instant, Dissolve, Smart animate, Move in/out, Push, Slide) that matches the platform convention and the weight of the transition -- Smart animate for element continuity between similar frames, Push/Slide for standard mobile navigation. -5. Set overlay behavior (position, background, close-on-click-outside) explicitly for every overlay rather than leaving defaults unconsidered. -6. Wire every branch described in the flow, including error/cancel/back paths, not just the primary happy path. -7. Set the prototype's starting frame and device frame/background to match the intended viewing context. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not silently skip a described branch because the destination screen does not exist -- flag it explicitly so it is not mistaken for "done". - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: A confirmation list of every connection made (from -> trigger -> action -> to) plus a list of any flow steps that couldn't be wired and why. diff --git a/skills/figma-agent/prototype-qa/SKILLS.md b/skills/figma-agent/prototype-qa/SKILLS.md deleted file mode 100644 index d1c4263..0000000 --- a/skills/figma-agent/prototype-qa/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: prototype-qa -description: "Walks every connection in a prototype end to end, testing that each leads where intended, has no dead ends, and that overlays/back actions behave correctly, then reports every broken or missing link. Use before sharing a prototype for testing, review, or a stakeholder demo." ---- - -# Prototype QA - -## Purpose -Catch every broken, missing, or misbehaving connection in a prototype before it is shared or demoed. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before sending a prototype link to stakeholders, researchers, or reviewers -- After a round of screen additions/edits that could have silently broken existing connections - -## Required Inputs -- The prototype's starting frame (or all starting frames, if there are multiple flows in one file) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Test paths as a user would: start frame, happy path, branch paths, overlays, back behavior, dead ends, and state resets. - -## Workflow -1. Enumerate every frame in the prototype and every outgoing connection from it (trigger, action, destination). -2. From the starting frame, walk each path exhaustively, following every button/link/interactive element, including overlays, nested overlays, and back actions. -3. Flag dead ends: interactive-looking elements (buttons, links, list items) with no connection at all. -4. Flag broken destinations: connections pointing to a frame that's been deleted, renamed out of the flow, or clearly the wrong target for the label (e.g. a "Cancel" button that navigates forward instead of back). -5. Flag overlay issues: overlays with no close action, or an "outside click closes" setting that conflicts with the intended behavior (e.g. a confirmation dialog that should require an explicit choice but can be dismissed by clicking outside). -6. Flag orphaned frames: frames that exist in the file but are never reached by any connection from the starting frame. -7. Check state-driven logic (variables/conditionals) actually branches into every intended state at least once during the walk. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Report the exact frame and element for every issue so it can be found and fixed quickly, not just "some links are broken". - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A findings list grouped as: Dead ends, Broken destinations, Overlay issues, Orphaned frames, State-logic gaps -- each with frame/element names. diff --git a/skills/figma-agent/rename-layers-batch/SKILLS.md b/skills/figma-agent/rename-layers-batch/SKILLS.md deleted file mode 100644 index 1559734..0000000 --- a/skills/figma-agent/rename-layers-batch/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: rename-layers-batch -description: "Batch-renames a large set of layers according to a rule (pattern, content-based inference, or find/replace) in one pass, reporting every change made. Use for quick, mechanical bulk renaming, as a lighter-weight companion to the more comprehensive naming-convention-enforcer." ---- - -# Rename Layers Batch - -## Purpose -Apply a mechanical bulk rename across many layers in one pass, based on a clear rule. - -## Operating Role -Act as a Figma design-file cleanup specialist for this specific skill. Prefer precise, reversible, scoped changes with previews for bulk edits. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- A large number of layers need the same kind of rename (e.g. all "Rectangle N" icons renamed by content, or a consistent find/replace across many names) -- For a deeper structural naming pass (conventions across types of layers), use naming-convention-enforcer instead - -## Required Inputs -- The exact rule: a find/replace pattern, a content-based rule ("name each icon after what it depicts"), or a prefix/suffix pattern to apply -- The scope (selection, page, or file) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Default to selection scope. If nothing is selected, ask before touching the whole page. -- Use preview mode for large batches; apply only clearly mechanical renames. - -## Workflow -1. Identify every layer in scope matching the rule's trigger condition (e.g. still has a default name, or matches the find pattern). -2. Apply the rule mechanically and consistently: same find/replace logic, same inference logic, or same prefix/suffix pattern for every matched layer. -3. Skip (and report) any layer where the rule is ambiguous (e.g. content-based naming for an icon that's unclear what it depicts) rather than guessing. -4. Present the full before -> after list for confirmation before applying at large scale (more than roughly 20 renames); apply directly for small batches. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not rename layers outside the specified scope, even if they also match the rule, without confirming scope expansion first. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return a preview or change log with before/after values, skipped ambiguous items, and any breaking-change risk. Keep the report short enough to act on immediately. -- Skill-specific format: A before -> after table of every rename made, plus a separate list of layers skipped due to ambiguity. diff --git a/skills/figma-agent/responsive-breakpoint-check/SKILLS.md b/skills/figma-agent/responsive-breakpoint-check/SKILLS.md deleted file mode 100644 index 0cff018..0000000 --- a/skills/figma-agent/responsive-breakpoint-check/SKILLS.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -name: responsive-breakpoint-check -description: "Reviews a layout's auto layout, constraints, and resizing settings to verify it will adapt correctly across specified breakpoints (e.g. mobile, tablet, desktop) rather than just checking how it looks at one frame size. Use when a design needs to work responsively, especially for Figma Sites or handoff to a responsive web build." ---- - -# Responsive Breakpoint Check - -## Purpose -Verify a layout is actually built to resize well across breakpoints, not just designed once at a single canvas size. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before handoff for a responsive web build or Figma Sites publish -- When a design only exists at one breakpoint and needs to be validated (or extended) for others - -## Required Inputs -- The breakpoints in scope (e.g. 375px mobile, 768px tablet, 1440px desktop) -- ask if not specified -- Whether frames already exist per breakpoint, or only one exists and needs review for how it should adapt -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Compare equivalent content across breakpoints and flag where layout behavior, not just visual position, fails. - -## Workflow -1. For each top-level frame, check that auto layout is used for the overall structure (rather than fixed absolute positioning), since that's what allows content to reflow. -2. Check resizing settings on key containers: do they hug, fill, or have a fixed size -- and is that the correct choice for how the container should behave at other widths (e.g. a sidebar that should stay fixed-width while content fills the rest)? -3. Check text containers can grow vertically (auto-height) so translated or wrapped text does not get clipped at narrower widths. -4. Check images/media have consistent scaling behavior (fill vs fit) so they do not distort or overflow at different widths. -5. Check constraints on any layers not in auto layout (e.g. decorative background elements) so they stay positioned correctly when their parent frame resizes. -6. If multiple breakpoint frames exist, compare them for structural consistency: is the same content present, just rearranged, or is content unexpectedly missing/duplicated at one breakpoint? -7. If only one breakpoint exists, propose how the layout should adapt at each other breakpoint in scope (what stacks, what hides, what resizes) before building it out. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Flag any layer that will visibly break (clip, overlap, overflow) at a breakpoint; do not just describe general best practice. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A per-breakpoint findings list: breakpoint -> issues found -> fix, plus a short note on what's working well already. diff --git a/skills/figma-agent/screenshot-to-component/SKILLS.md b/skills/figma-agent/screenshot-to-component/SKILLS.md deleted file mode 100644 index e44f491..0000000 --- a/skills/figma-agent/screenshot-to-component/SKILLS.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -name: screenshot-to-component -description: Use when the user provides a screenshot or crop of a UI component, panel, sidebar, modal, menu, card, toolbar, form, or dense app surface and wants it recreated as a structured Figma Design component. Focuses on editable hierarchy, auto layout, semantic nesting, reusable subcomponents, component properties, variants, and maintainable layer naming instead of flat screenshot tracing. ---- - -# Screenshot To Component - -## Purpose -Recreate a UI screenshot as a clean, editable Figma component with meaningful nesting, reusable subcomponents, sensible properties, and design-system-ready structure. Prioritize component architecture over pixel-perfect tracing while keeping the visual match close. - -## When To Use - -Use for screenshots of panels, sidebars, modals, drawers, menus, popovers, cards, toolbars, forms, table rows, lists, or dense app surfaces; or when a visible component should become reusable in Figma. - -Do not use for full-page website generation, production code generation, broad design-system creation, pure visual critique, or illustration/icon design as the main task. - -## Ask Only If Needed - -Proceed from the screenshot unless missing context materially changes the structure. Ask only about target platform when sizing depends on it, an existing design system the user references, whether to create one component or a component set, or which visible state to prioritize when states conflict. Infer spacing, colors, labels, and icons from the screenshot. - -## Core Rules - -1. Build editable Figma layers, not a flattened screenshot replica. -2. Use auto layout for every structured container. -3. Group by semantic region before visual appearance. -4. Create subcomponents for repeated rows, controls, chips, counters, icons, and section headers. -5. Use variants only for real likely states or repeated types. -6. Use component properties for text, visibility toggles, icons, badges, counters, and nested row states. -7. Preserve hierarchy, spacing rhythm, alignment, typography, and interaction cues. -8. Do not invent hidden behavior. Report uncertain values as assumptions. - -## Screenshot Reading Pass - -Before building, identify the root type; outer bounds, radius, shadow, border, background, and padding; major regions and dividers; repeated row patterns; icon meanings; text hierarchy; status values; interactive affordances; and visible states such as selected, active, disabled, expanded, positive, or negative. Mentally convert the screenshot into a hierarchy tree before creating layers. - -## Recommended Architecture - -Name the root by function, such as `Panel / Environment`, `Sidebar / Project Browser`, `Menu / Branch Actions`, or `Card / Status Summary`. For dense panels, use: - -- `Panel / [Name]` - - `Header` - - `Section / [Name]` - - `Section Header` - - `Row / [Type]` - - `Divider` - - `Footer` when present - -Use nested components such as `Panel Header`, `Panel Section`, `Panel Row`, `Status Counter`, `Icon Button`, `Disclosure Row`, `External Link Row`, and `Source Link Row`. Do not leave every element as a direct child of the root. - -## Container, Row, and Section Rules - -The root must have a named outer frame, intentional width, main-axis auto layout, screenshot-matched padding and gaps, approximated surface styling, and clipping only when implied by the screenshot. Keep compact dark panels tight, with muted section labels and dividers only where visible. - -Rows should use auto layout with leading icon, main label, optional metadata, status counter, trailing action, and chevron/external-link slots. Expose `label`, `metadata`, `showLeadingIcon`, `leadingIcon`, `showTrailingIcon`, `trailingIcon`, `showStatus`, `statusValue`, `state`, and `tone`. Use variants for row `Type` (default, disclosure, link, source, status, action), `State` (default, hover, selected, disabled, muted), and `Tone` (neutral, positive, negative, warning) when useful. - -Sections should contain an optional title, rows, optional divider, and optional action. Expose `title`, `showTitle`, `showDivider`, `showAction`, and `actionIcon`. Keep one-off content nested without over-abstracting it. - -## Icons, Text, and Status - -Use editable vectors or icon instances where possible. Name icons by meaning, e.g. `Icon / Changes`, `Icon / Branch`, `Icon / Commit`, `Icon / External`, `Icon / Plus`, and `Icon / More`. If exact details are unclear, use a close placeholder named by intended meaning. - -Use real text layers and separate roles such as `Panel Title`, `Section Label`, `Row Label`, `Metadata`, `Status Positive`, `Status Negative`, and `Muted Action`. Group related counts into a `Status Counter` subcomponent and expose count text when possible. - -## Variants, Properties, and Naming - -Create variants only when they improve reuse: row type/state, status tone, button state, or density when the screenshot implies multiple modes. Expose labels, optional icons/metadata/status, dividers, section titles, trailing actions, and nested row state; do not expose internal layout details. If the Figma Agent cannot create a property directly, still build the correct structure and report the intended property. - -Use semantic names rather than generated names: `Panel / Environment`, `Header`, `Section / Changes`, `Row / Branch`, `Row / Source Link`, `Status Counter`, `Icon Button / More`, and `Text / Row Label`. - -## Completion Criteria - -The result is a reusable, editable Figma component that closely matches the screenshot, preserves its hierarchy and interaction cues, uses maintainable layer names and auto layout, and makes assumptions or unsupported properties explicit. Keep the final report concise: component structure, assumptions, and any intended-but-unavailable properties. - -## Workflow -1. Clarify scope from the current selection or user request. -2. Apply the skill with concrete, evidence-backed steps. -3. Report findings or deliverables clearly. diff --git a/skills/figma-agent/semantic-color-audit/SKILLS.md b/skills/figma-agent/semantic-color-audit/SKILLS.md deleted file mode 100644 index 3e4eb85..0000000 --- a/skills/figma-agent/semantic-color-audit/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: semantic-color-audit -description: "Audits code for raw Tailwind palette color classes or hardcoded colors used where a semantic design-system token should be used instead, catching drift between the token system and actual usage. Use periodically or before a release to catch semantic color drift." ---- - -# Semantic Color Audit - -## Purpose -Catch places where code uses a raw palette color (e.g. `bg-blue-600`) or a hardcoded value instead of the project's semantic design tokens, which silently breaks theming/dark-mode consistency. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Periodic codebase hygiene check -- Before a release -- After a theming/rebrand change, to find code that didn't pick up the new tokens because it never used them in the first place - -## Required Inputs -- The project's full semantic token list (see the color-token-format-normalizer skill) to know what "correct" usage looks like -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Judge color by semantic role and mode behavior, not just matching hex values. - -## Workflow -1. Scan component code for raw Tailwind palette color utility classes (`bg-*`, `text-*`, `border-*` using palette names like slate/blue/red/zinc rather than semantic names like background/primary/destructive). -2. For each raw usage found, determine the closest semantic token that represents the same design intent (e.g. `bg-red-600` used for a delete button is very likely meant to be `bg-destructive`). -3. Distinguish legitimate raw palette usage (e.g. a data-visualization chart intentionally using a fixed categorical palette unrelated to theme) from drift (a UI element that should react to theme/dark-mode but currently does not) -- flag the former as "intentional, confirm" rather than auto-flagging as an error. -4. Check that flagged components actually look wrong or break in dark mode as supporting evidence the raw color is a real bug, not just a style preference. -5. Produce a prioritized list: highest priority = raw colors on interactive/semantic elements (buttons, alerts, form validation states) where theme/dark-mode breakage is most visible to users. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not blanket-flag every raw palette class as wrong -- data visualization, illustrations, and marketing-only sections often legitimately use fixed palette colors. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: Prioritized list of file/component -> raw color found -> suggested semantic token -> confidence (likely drift vs. possibly intentional). diff --git a/skills/figma-agent/shadcn-component-structure/SKILLS.md b/skills/figma-agent/shadcn-component-structure/SKILLS.md deleted file mode 100644 index e7aee18..0000000 --- a/skills/figma-agent/shadcn-component-structure/SKILLS.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -name: shadcn-component-structure -description: "Ensures generated React components follow shadcn/ui structural conventions -- forwardRef/ref handling, cn() className merging, cva-based variants, proper prop interfaces extending native element types, and correct file placement. Use when generating or reviewing component code meant to fit into a shadcn/ui-based codebase." ---- - -# Shadcn Component Structure - -## Purpose -Make generated component code structurally consistent with shadcn/ui conventions so it fits naturally into a shadcn-based codebase. - -## Operating Role -Act as a design-to-code bridge for this specific skill. Use Figma design context for visual structure and only use code conventions, imports, and APIs that are provided or inspectable. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. -- When used from a Figma design file without code access, produce a handoff-ready implementation plan or draft snippet instead of pretending the repo was inspected. - -## Activation Boundary -- Generating a new UI component for a shadcn/ui project -- Reviewing or refactoring existing component code for structural consistency - -## Required Inputs -- The component to generate/review -- Whether the project uses the React.forwardRef pattern or plain function components with ref as a prop (React 19+) -- The project's existing `cn` utility import path (commonly `lib/utils`) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Map Figma states and variants to a clean component API before writing or revising files. - -## Workflow -1. Confirm the component signature matches convention: a typed props interface extending the appropriate native element props (e.g. `React.ComponentProps<"button">`), with ref handled per the project's React version convention. -2. Use `cn()` (clsx + tailwind-merge) to merge internal base classes with a consumer-supplied `className` prop, so consumer overrides win over base styles without breaking structurally required classes. -3. If the component has visual variants (size, variant, state), define them with `cva` (class-variance-authority) rather than manual conditional string building, with `defaultVariants` set. -4. Export both the component and its variant config (e.g. `buttonVariants`) when other components may need to reuse the same visual variant styling (e.g. a `Link` styled like a `Button`). -5. Place the file under the project's UI components directory (commonly `components/ui/.tsx`) using kebab-case filenames matching shadcn's own convention, unless the project structure differs -- confirm before assuming. -6. Verify `displayName` is set for components wrapped in `forwardRef`, for clean DevTools/debugging output. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. -- Do not invent packages, imports, component APIs, token names, or Code Connect mappings. -- Use design tokens and existing component names only when they are visible or provided. - -## Guardrails -- Do not introduce a new className-merging utility if the project already has one; reuse it. -- Do not hardcode variant class strings inline once a `cva` config exists elsewhere for the same variant. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return code or mapping output only when enough context exists. Otherwise return a design-to-code plan with required missing code context, proposed props, token mappings, and unresolved assumptions. -- Skill-specific format: Corrected/generated component code block, followed by a short list of structural conventions applied. diff --git a/skills/figma-agent/site-launch-checklist/SKILLS.md b/skills/figma-agent/site-launch-checklist/SKILLS.md deleted file mode 100644 index 8e3f3b7..0000000 --- a/skills/figma-agent/site-launch-checklist/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: site-launch-checklist -description: "Reviews a Figma Sites project against a pre-launch checklist: responsive behavior across breakpoints, working links/navigation, page titles and meta content, image alt text, and load-affecting asset sizes. Use before publishing a Figma Sites project." ---- - -# Site Launch Checklist - -## Purpose -Catch the issues that specifically block or hurt a Figma Sites launch, beyond general visual design QA. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Right before publishing a Figma Sites project - -## Required Inputs -- The site's pages and the breakpoints it should support -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Separate launch blockers from polish. Do not call anything launch-ready if critical content, links, responsiveness, or accessibility checks are unresolved. - -## Workflow -1. Run responsive-breakpoint-check logic across every page of the site, not just the homepage. -2. Verify every navigation link and button resolves to a real, correct destination (internal page, correct anchor, or external URL) -- flag any placeholder `#` links or links to a since-renamed page. -3. Check each page has a distinct, descriptive page title and meta description set (not a default/placeholder), since these matter for SEO and link previews. -4. Check every meaningful image has alt text set, and decorative images are marked as such (cross-reference accessibility-audit for the broader accessibility pass). -5. Check for oversized image/media assets that will slow page load, and flag any that should be compressed or resized before publish. -6. Check forms (if any) have clear success/error states and that required fields are marked. -7. Check custom domain, favicon, and any site-wide settings (if applicable) are configured, not left as defaults. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Distinguish must-fix launch blockers from nice-to-have polish in the output so launch is not held up on non-blockers. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A checklist split into "Must fix before launch" and "Recommended follow-up", each item naming the specific page/element. diff --git a/skills/figma-agent/spacing-scale-enforcer/SKILLS.md b/skills/figma-agent/spacing-scale-enforcer/SKILLS.md deleted file mode 100644 index da87e09..0000000 --- a/skills/figma-agent/spacing-scale-enforcer/SKILLS.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -name: spacing-scale-enforcer -description: "Maps arbitrary spacing values to the nearest step on the project's spacing scale (typically Tailwind's 4px-based scale) and flags off-scale spacing in designs or code. Use when spacing looks inconsistent or when translating Figma spacing values into Tailwind utility classes." ---- - -# Spacing Scale Enforcer - -## Purpose -Keep spacing values (padding, margin, gap) on a consistent scale instead of arbitrary pixel values scattered throughout a design or codebase. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Translating Figma auto-layout spacing into Tailwind classes -- Auditing a page/component for inconsistent spacing - -## Required Inputs -- The project's spacing scale if customized (check `tailwind.config` `theme.spacing`/`extend.spacing`); otherwise assume Tailwind's default 4px-increment scale (1 = 4px, 2 = 8px, 3 = 12px, 4 = 16px, 6 = 24px, 8 = 32px, etc.) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Identify spacing relationships before changing values. Align equivalent relationships to the same token or scale step. - -## Workflow -1. For each spacing value encountered (Figma auto-layout gap/padding, or a CSS/Tailwind value), find the nearest valid step on the active spacing scale. -2. If a value is already on-scale, keep it as-is; if off-scale (e.g. 15px, 22px), flag it and propose the nearest valid step, noting the delta. -3. Distinguish intentional custom spacing (rare, deliberate exceptions like a specific icon offset) from unintentional drift (most off-scale values in real designs are drift, not intent) -- when unsure, ask rather than assume intent. -4. When generating Tailwind classes, always use the scale's utility classes (`p-4`, `gap-2`, etc.) rather than arbitrary value syntax (`p-[15px]`) unless the exact value is a deliberate, documented exception. -5. Check that spacing is applied consistently for the same semantic purpose across similar components (e.g. all card padding should use the same step, not vary between 12px and 16px arbitrarily across similar cards). - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not silently "round" a value that turns out to be intentional (e.g. matching an external embed's fixed size) -- flag for confirmation instead of overriding automatically when the source of the value is unclear. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: Table of value -> nearest scale step -> suggested class, plus flagged inconsistencies across similar components. diff --git a/skills/figma-agent/states-completeness-check/SKILLS.md b/skills/figma-agent/states-completeness-check/SKILLS.md deleted file mode 100644 index e2ade66..0000000 --- a/skills/figma-agent/states-completeness-check/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: states-completeness-check -description: "Checks that every screen and key component in a flow has the full set of states it needs -- empty, loading, populated, error, partial/edge-case data, and (for components) hover/focus/pressed/disabled -- and lists which are missing. Use before a flow is considered complete for handoff." ---- - -# States Completeness Check - -## Purpose -Make sure no screen or component is missing a state it will need in production. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before marking a flow complete or handing it to engineering -- After a flow was designed quickly and only shows the "happy path" - -## Required Inputs -- The flow or set of screens to check -- Any known data edge cases specific to this product (e.g. very long names, zero results, offline) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Check each interactive component or flow for required states in context; do not demand irrelevant states. - -## Workflow -1. For every screen that displays data, confirm the following states exist somewhere in the file (as separate frames/variants, not just described in a comment): loading, empty (zero data, first-time use), populated/happy-path, error (e.g. failed to load, no connection), and at least one edge case (very long content, maximum items, partial data). -2. For every interactive component used in the flow, confirm default, hover, focus, pressed/active, and disabled states exist, plus a loading/pending state if the action is asynchronous (e.g. a submit button). -3. For forms specifically, confirm inline validation states (untouched, valid, invalid with message) exist for each field type used. -4. List every missing state found, grouped by screen/component, with a short note on why it matters (e.g. "no empty state for search results -- first-time users will see a blank screen with no guidance"). -5. If asked to fill gaps, draft the missing states matching the existing visual language, and flag which ones need a copy decision (e.g. exact error message wording) rather than guessing final copy. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not mark a state as "present" if it only exists as a rough sketch inconsistent with the rest of the flow's fidelity -- note the fidelity gap. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A table: Screen/Component | States present | States missing | Why it matters. diff --git a/skills/figma-agent/sticky-synthesis/SKILLS.md b/skills/figma-agent/sticky-synthesis/SKILLS.md deleted file mode 100644 index 78addc3..0000000 --- a/skills/figma-agent/sticky-synthesis/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: sticky-synthesis -description: "Clusters and summarizes stickies on a FigJam board into themes, counts, and a synthesized takeaway for each theme. Use after a brainstorm, retro, or research session has generated a lot of loose stickies that need to become an actionable summary." ---- - -# Sticky Synthesis - -## Purpose -Turn a pile of loose FigJam stickies into a small number of clear, named themes with a synthesized takeaway each. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- After a brainstorm, retro, workshop, or research synthesis session on a FigJam board - -## Required Inputs -- The board or section of the board to synthesize -- Whether there's already a rough clustering (color-coding, spatial grouping) to respect, or whether to cluster from scratch -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Respect existing clusters when they are clearly intentional, but recluster when spatial grouping is accidental or noisy. - -## Workflow -1. Read every sticky's text (and note author/color if meaningfully used, e.g. color = category). -2. Group stickies into themes by underlying meaning, not just keyword overlap -- two stickies with different words can be the same theme, and two with similar words can be different themes. -3. Name each theme clearly and concisely (a short phrase, not a single word), and count how many stickies fall into it. -4. Write a one- or two-sentence synthesized takeaway per theme -- what the group of stickies is collectively saying, not just a list of what's in it. -5. Call out any strong outliers that do not fit a theme but seem important enough to preserve rather than discard. -6. Order themes by sticky count (most-represented first) unless another ordering is more meaningful (e.g. chronological for a retro's "went well / didn't go well / actions"). -7. If asked to update the board directly, visually group the stickies to match the clustering and add a theme-label sticky/section header per group. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not over-cluster into one giant theme or under-cluster into as many themes as stickies -- aim for a number of themes a team could realistically act on (typically 3-8). - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: A theme list: Theme name (sticky count) -> synthesized takeaway, followed by an "outliers" list if any. diff --git a/skills/figma-agent/tailwind-class-order-check/SKILLS.md b/skills/figma-agent/tailwind-class-order-check/SKILLS.md deleted file mode 100644 index 86358f5..0000000 --- a/skills/figma-agent/tailwind-class-order-check/SKILLS.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -name: tailwind-class-order-check -description: "Audits className strings for consistent ordering, duplicate or conflicting utility classes, and alignment with the project's class-sorting convention. Use when reviewing generated or hand-written component code for Tailwind class hygiene." ---- - -# Tailwind Class Order Check - -## Purpose -Keep Tailwind class strings readable, non-conflicting, and consistently ordered across a codebase. - -## Operating Role -Act as a design-to-code bridge for this specific skill. Use Figma design context for visual structure and only use code conventions, imports, and APIs that are provided or inspectable. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. -- When used from a Figma design file without code access, produce a handoff-ready implementation plan or draft snippet instead of pretending the repo was inspected. - -## Activation Boundary -- Reviewing generated component code -- Cleaning up a component whose className strings have grown unwieldy - -## Required Inputs -- Whether the project uses an automatic class sorter (commonly `prettier-plugin-tailwindcss`) -- if so, defer to its ordering rather than proposing a competing manual order -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Focus on conflicts and maintainability before ordering. If a sorter exists, defer ordering to tooling. - -## Workflow -1. Scan each `className` string for duplicate utilities (e.g. two conflicting padding classes) and directly conflicting utilities that cancel or override each other unpredictably (e.g. both `flex` and `hidden` without a responsive qualifier distinguishing when each applies). -2. If the project has an automatic sorter configured, note that formatting will be handled by tooling and focus review on correctness/conflicts rather than manual ordering. -3. If no automatic sorter exists, apply a conventional grouping order: layout (display/position) -> box model (sizing/spacing) -> flex/grid alignment -> typography -> color/background -> borders/effects -> state variants (`hover:`/`focus:`/`dark:`) last. -4. Flag arbitrary-value classes (e.g. `top-[13px]`) that could be replaced with a scale-based utility, per the spacing-scale-enforcer skill. -5. Flag very long inline `className` strings on complex components as candidates for extraction into a `cva` variant config for readability and reuse. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. -- Do not invent packages, imports, component APIs, token names, or Code Connect mappings. -- Use design tokens and existing component names only when they are visible or provided. - -## Guardrails -- Do not fight an existing automatic class sorter's output by hand-reordering classes it already normalizes. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Return code or mapping output only when enough context exists. Otherwise return a design-to-code plan with required missing code context, proposed props, token mappings, and unresolved assumptions. -- Skill-specific format: Per-component list of issues found (duplicates/conflicts/arbitrary values/extraction candidates) with corrected class strings. diff --git a/skills/figma-agent/token-tailwind-theme-sync/SKILLS.md b/skills/figma-agent/token-tailwind-theme-sync/SKILLS.md deleted file mode 100644 index 3f377fc..0000000 --- a/skills/figma-agent/token-tailwind-theme-sync/SKILLS.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -name: token-tailwind-theme-sync -description: "Syncs Figma variables (color, spacing, radius, typography) into a tailwind.config theme extension and CSS custom properties, following shadcn's theming file structure. Use when Figma variables have changed and the Tailwind/CSS theme needs to catch up, specifically for shadcn-based projects." ---- - -# Token Tailwind Theme Sync - -## Purpose -Keep a shadcn-based project's Tailwind theme and CSS variables in sync with the Figma variables that define the design system, specifically following shadcn's theming file conventions (distinct from a generic token sync, which is not shadcn-specific). - -## Operating Role -Act as a design-to-code bridge for this specific skill. Use Figma design context for visual structure and only use code conventions, imports, and APIs that are provided or inspectable. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. -- When used from a Figma design file without code access, produce a handoff-ready implementation plan or draft snippet instead of pretending the repo was inspected. - -## Activation Boundary -- Figma variables (color, spacing, radius, font) have changed and corresponding theme files need updating in a shadcn/Tailwind project - -## Required Inputs -- Current Figma variable collections and values -- The project's existing global CSS file defining `:root`/`.dark` CSS variables and its `tailwind.config` `theme.extend` mapping those variables into Tailwind tokens -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Map Figma variable modes to Tailwind theme/dark-mode strategy explicitly before generating config. - -## Workflow -1. Read the current Figma variable collections (color, spacing, radius, typography) including any light/dark mode value pairs. -2. Read the project's existing CSS variable definitions and `tailwind.config` extend mapping to understand the current token structure before changing anything. -3. For color, express new/changed values as HSL triplets in the CSS variable block (both `:root` and `.dark`, if the Figma variable has mode-specific values), and confirm each has a corresponding Tailwind color mapping (`colors: { primary: "hsl(var(--primary))", ... }`). -4. For spacing and radius, map Figma variable values onto the existing scale conventions (see the spacing-scale-enforcer skill) rather than introducing new arbitrary scale steps. -5. For typography, map Figma text style variables (family, size, weight, line-height) into the `tailwind.config` `theme.extend.fontSize`/`fontFamily`/`fontWeight` entries, preserving any existing custom type scale naming. -6. Produce a diff-style summary: which tokens are new, which changed value, which are unchanged, so the change is easy to review rather than a full file dump every time. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. -- Do not invent packages, imports, component APIs, token names, or Code Connect mappings. -- Use design tokens and existing component names only when they are visible or provided. - -## Guardrails -- Never restructure the project's existing theming file organization (e.g. switching from CSS-variable-based theming to a different system) as a side effect of a routine sync -- only update values unless a structural change was explicitly requested. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return code or mapping output only when enough context exists. Otherwise return a design-to-code plan with required missing code context, proposed props, token mappings, and unresolved assumptions. -- Skill-specific format: Diff-style summary of token changes, followed by the updated CSS variable block and `tailwind.config` excerpt. diff --git a/skills/figma-agent/variable-driven-prototype/SKILLS.md b/skills/figma-agent/variable-driven-prototype/SKILLS.md deleted file mode 100644 index ec3f796..0000000 --- a/skills/figma-agent/variable-driven-prototype/SKILLS.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: variable-driven-prototype -description: "Sets up Figma variables and conditional prototype logic to make a prototype genuinely stateful -- e.g. a login flow that remembers auth state, a cart that updates a count and total, or a settings toggle that persists across screens. Use when a prototype needs to demonstrate real interactive logic, not just static screen-to-screen navigation." ---- - -# Variable Driven Prototype - -## Purpose -Make a prototype behave statefully using Figma variables, conditionals, and expressions, instead of only linear screen jumps. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- The prototype needs to reflect state that persists or changes across screens (login status, form input echoed later, a running total, a toggle setting) -- A demo needs to show branching logic driven by user choices, not a fixed path - -## Required Inputs -- What state needs to be tracked (name, type -- boolean/number/string/color -- and its possible values) -- Where the state changes (which interactions set it) and where it is read (which screens/conditions depend on it) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Model state as a small variable table before wiring. Test every branch and reset condition. - -## Workflow -1. Create a variable for each piece of state needed, using a clear name and the correct type, in a collection scoped appropriately (local to the prototype unless it should be a shared design variable too). -2. Wire "Set variable" actions on the interactions that change state (e.g. a toggle's On click sets a boolean, quantity stepper's clicks increment/decrement a number). -3. Bind variables to visible properties where state should be reflected directly (e.g. binding a text layer to a number variable for a live count, or a variable-bound instance-swap for a toggle's visual state). -4. Add conditional actions where the destination or displayed content depends on a variable's value (e.g. "if isLoggedIn is true, navigate to Dashboard, else navigate to Sign in"), using expressions for any calculated logic (e.g. totals, formatted strings). -5. Verify initial variable values are set sensibly for the prototype's starting frame so the first view is correct before any interaction happens. -6. Test every branch of every conditional to confirm it resolves to the intended destination/state. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Keep variable names and structure simple enough that a teammate could understand the logic by reading the variables panel alone; avoid deeply nested conditionals where a simpler structure would do. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: A variable table (name, type, purpose) plus a logic summary of every conditional/set-variable action added and what triggers it. diff --git a/skills/figma-agent/visual-consistency-check/SKILLS.md b/skills/figma-agent/visual-consistency-check/SKILLS.md deleted file mode 100644 index b79ed00..0000000 --- a/skills/figma-agent/visual-consistency-check/SKILLS.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -name: visual-consistency-check -description: "Scans a flow for inconsistent spacing, alignment, corner radii, icon styles, and grid usage across screens that should feel like one cohesive product. Use when multiple screens were designed at different times or by different people and need to feel unified." ---- - -# Visual Consistency Check - -## Purpose -Catch the small inconsistencies that make a multi-screen flow feel disjointed, even when each screen looks fine on its own. - -## Operating Role -Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Before shipping a flow that was designed over multiple sessions or by more than one person -- When a file "feels off" but it is hard to pinpoint why - -## Required Inputs -- The set of screens to compare (at least two, ideally the whole flow) -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Compare repeated relationships and roles across screens. Do not flatten intentional hierarchy or brand moments. - -## Workflow -1. Compare grid and margin usage across screens: are outer margins, column counts, and gutters the same wherever the layout context is the same? -2. Compare spacing rhythm: do similar relationships (label-to-input, section-to-section, card padding) use the same spacing value across screens, or does it drift (e.g. 16px in one screen, 20px in another for the same relationship)? -3. Compare corner radii and stroke weights across similar elements (cards, buttons, inputs, modals). -4. Compare icon style: line weight, corner treatment, and size consistency across icons used together. -5. Compare typography usage: are headings/body/labels using the same text styles for the same semantic role across screens? -6. Compare color usage: are semantically equivalent elements (e.g. all primary buttons) using the exact same color/style, not visually-close-but-different values? -7. List every drift found with the specific screens compared and the exact values that differ. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Distinguish an intentional variation (e.g. a marketing page that's deliberately more expressive) from an accidental drift -- ask if unsure rather than flattening everything to identical. - -## Finding Quality Rules -- Lead with the highest-impact issues, not the order discovered. -- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source. -- Include severity only when it changes priority: Blocker, High, Medium, or Low. -- Pair every finding with an exact fix, replacement, or next decision. -- Separate confirmed findings from assumptions, recommendations, and unverified areas. - -## Output Contract -Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. -- Skill-specific format: A drift list grouped by category (Grid/Margins, Spacing, Radii/Strokes, Icons, Typography, Color), each row naming the screens compared and the differing values. diff --git a/skills/figma-agent/wire-up-interactions/SKILLS.md b/skills/figma-agent/wire-up-interactions/SKILLS.md deleted file mode 100644 index 6c6dc41..0000000 --- a/skills/figma-agent/wire-up-interactions/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: wire-up-interactions -description: "Adds or fixes specific prototype interactions (triggers, actions, animations, overlay settings) on an already-largely-connected prototype, based on a precise spec of what should happen. Use for targeted interaction work, as opposed to prototype-from-flow which builds an entire flow from scratch." ---- - -# Wire Up Interactions - -## Purpose -Add or correct specific prototype interactions against a precise spec, without rebuilding the whole flow. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- A prototype mostly works but a specific interaction is missing, wrong, or needs refinement -- Adding a new one-off interaction (e.g. a new overlay, a new hover state) to an existing prototype - -## Required Inputs -- The exact interaction(s) needed: source element, trigger, destination, and desired feel -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Change only the named interaction unless the user asks for broader prototype QA. Verify trigger, action, destination, and transition. - -## Workflow -1. Locate the source element and check for any existing conflicting interaction on the same trigger; decide whether to replace or add as an additional interaction. -2. Set the trigger precisely (On click, On hover, While hovering, On drag, While pressing, Mouse enter/leave, Key/gamepad, After delay, Mouse down/up) -- the most common source of "prototype does not feel right" bugs is the wrong trigger type. -3. Set the action (Navigate to, Open/close/swap overlay, Swap state, Change to, Scroll to, Back, Open link, Open node, Set variable, Conditional) matching the intent exactly, including any variable or condition logic required for state-driven behavior. -4. Configure animation curve and duration deliberately: prefer spring easing with tuned bounce/duration for natural motion, or ease-in-out with an explicit duration for precise, repeatable timing -- avoid leaving default "instant" when a transition is meant to feel considered. -5. If the interaction is on a component with variants/interactive-component states, confirm it swaps to the correct variant rather than a visually similar but semantically wrong one. -6. Test the specific interaction after wiring, describing exactly what happens on trigger. - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Do not remove or alter unrelated existing interactions on the same frame while fixing the requested one. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: A short list: what was added/changed, the exact trigger -> action configuration, and how to verify it. diff --git a/skills/figma-agent/workshop-facilitator/SKILLS.md b/skills/figma-agent/workshop-facilitator/SKILLS.md deleted file mode 100644 index 21af1d3..0000000 --- a/skills/figma-agent/workshop-facilitator/SKILLS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: workshop-facilitator -description: "Structures a FigJam board for a specific workshop format (brainstorm, retrospective, kickoff, design studio) with sections, prompts, and suggested timing, ready for a team to fill in live or async. Use when setting up a workshop board from scratch." ---- - -# Workshop Facilitator - -## Purpose -Set up a well-structured FigJam board for a specific workshop format, with clear sections and prompts, so participants can jump straight into contributing. - -## Operating Role -Act as a Figma design-file producer for this specific skill. Create or structure the requested artifact in the file when enough context exists; otherwise return the smallest useful plan and ask only for blocking inputs. - -## Supported Context -- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. -- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. -- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. -- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. - -## Activation Boundary -- Setting up a board ahead of a brainstorm, retro, kickoff, or design studio session - -## Required Inputs -- The workshop type and goal (ask if not specified -- common types: brainstorm, sprint retro, project kickoff, design studio/crazy-8s, pre-mortem) -- Expected group size and whether the session is live/synchronous or async -- If an input is missing but can be inferred safely from the selection, proceed and label the assumption. - -## Fast Defaults -- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. -- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. -- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. -- Build a board that can be explained in under a minute: goal, sections, prompts, timing, and synthesis space. - -## Workflow -1. Choose a structure matching the workshop type: e.g. retro -> "What went well / What didn't / Action items" columns; kickoff -> "Goals / Non-goals / Risks / Open questions / Timeline" sections; brainstorm -> a central problem statement with radiating idea zones or "How Might We" prompts; design studio -> individual sketch zones followed by a share-and-critique zone. -2. Write a clear, specific prompt at the top of each section -- avoid vague prompts like "thoughts?" in favor of a concrete question that's easy to respond to. -3. Add a section for the session goal/objective at the top of the board so contributors know what "done" looks like. -4. If the session is timed, add a suggested agenda with rough time allocations per section as a sticky or text block. -5. For live sessions, add a few starter stickies or an icebreaker prompt to reduce blank-canvas hesitation. -6. Reserve a clearly labeled space for synthesis/next steps at the end of the board, to be filled in after the session (pairs well with sticky-synthesis and affinity-mapping once the session has content). - -## Figma Execution Limits -- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. -- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. -- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. -- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. -- Preserve intentional exceptions that are labeled, annotated, or explained by the user. - -## Guardrails -- Keep the structure simple enough to explain in one sentence per section -- an overly elaborate board structure suppresses participation more than it helps. - -## Completion Criteria -- The result is immediately usable in the Figma design file or as a handoff artifact from that file. -- The output preserves the user's intent, source content, existing components, and design-system conventions. -- Assumptions, skipped items, and tradeoffs are visible and short. -- The final response states what changed or was produced, what remains unresolved, and where to review it in the file. - -## Output Contract -Return the created or proposed Figma structure first, then list assumptions, variants/states covered, and follow-up decisions. If changes were applied, include exactly what changed. -- Skill-specific format: The board structure (sections + prompts + optional timing) ready to build directly on the canvas. diff --git a/tests/test_skills_catalog.py b/tests/test_skills_catalog.py index 9b68d16..4dafef1 100644 --- a/tests/test_skills_catalog.py +++ b/tests/test_skills_catalog.py @@ -1,8 +1,7 @@ -"""Structural checks for the public skills catalogue.""" +"""Catalogue integrity checks for the active Figma skills collection.""" from __future__ import annotations -import subprocess import sys import tempfile import unittest @@ -11,39 +10,41 @@ REPO_ROOT = Path(__file__).resolve().parents[1] sys.path.insert(0, str(REPO_ROOT / "scripts")) + from init_skill import init_skill # noqa: E402 +from validate_skills import FIGMA_SKILLS_ROOT, validate # noqa: E402 class SkillsCatalogTests(unittest.TestCase): - def test_active_figma_skills_are_published_from_standard_root(self) -> None: - active_skills = sorted((REPO_ROOT / "skills" / "figma-agent").glob("*/SKILL.md")) - - self.assertEqual(len(active_skills), 56) + def test_catalogue_validates(self) -> None: + errors = validate() + self.assertEqual(errors, [], msg="\n".join(errors)) + + def test_every_skill_dir_has_skill_md_only(self) -> None: + self.assertTrue(FIGMA_SKILLS_ROOT.is_dir(), msg=f"Active skills root directory '{FIGMA_SKILLS_ROOT}' does not exist.") + skill_dirs = sorted(p for p in FIGMA_SKILLS_ROOT.iterdir() if p.is_dir()) + self.assertGreater(len(skill_dirs), 0) self.assertFalse((REPO_ROOT / "figma-agent").exists()) + for skill_dir in skill_dirs: + self.assertTrue( + (skill_dir / "SKILL.md").is_file(), + msg=f"Missing SKILL.md in {skill_dir.name}", + ) + self.assertFalse( + (skill_dir / "SKILLS.md").exists(), + msg=f"Legacy SKILLS.md must not exist in {skill_dir.name}", + ) - def test_validator_accepts_the_catalogue(self) -> None: - result = subprocess.run( - [sys.executable, "scripts/validate_skills.py"], - cwd=REPO_ROOT, - capture_output=True, - text=True, - check=False, - ) - - self.assertEqual(result.returncode, 0, result.stderr or result.stdout) - - def test_initializer_creates_matching_canonical_and_figma_documents(self) -> None: + def test_initializer_creates_skill_md_only(self) -> None: with tempfile.TemporaryDirectory() as temporary_directory: skill_root = Path(temporary_directory) / "skills" / "figma-agent" skill_root.mkdir(parents=True) - self.assertTrue(init_skill("example-skill", str(skill_root))) + self.assertEqual(init_skill("example-skill", skill_root), 0) skill_dir = skill_root / "example-skill" - self.assertEqual( - (skill_dir / "SKILL.md").read_bytes(), - (skill_dir / "SKILLS.md").read_bytes(), - ) + self.assertTrue((skill_dir / "SKILL.md").is_file()) + self.assertFalse((skill_dir / "SKILLS.md").exists()) if __name__ == "__main__":