agent-toolkit-cli 1.11.0__py3-none-win_amd64.whl

agent_toolkit/data/skills/design/figma-create-design-system-rules/SKILL.md

@@ -0,0 +1,554 @@
+---
+name: figma-create-design-system-rules
+description: Generates custom design system rules for the user's codebase. Use when user says "create
+  design system rules", "generate rules for my project", "set up design rules", "customize design system
+  guidelines", or wants to establish project-specific conventions for Figma-to-code workflows. Requires
+  Figma MCP server connection.
+origin:
+  type: first-party
+---
+# Create Design System Rules
+
+## Overview
+
+This skill helps you generate custom design system rules tailored to your project's specific needs. These rules guide AI coding agents to produce consistent, high-quality code when implementing Figma designs, ensuring that your team's conventions, component patterns, and architectural decisions are followed automatically.
+
+### Supported Rule Files
+
+| Agent | Rule File |
+|-------|-----------|
+| Claude Code | `AGENTS.md` (or `CLAUDE.md` symlink) |
+| opencode | `AGENTS.md` (or `CLAUDE.md` symlink) |
+| Cursor | `.cursor/rules/figma-design-system.mdc` |
+| Gemini CLI | `GEMINI.md` (or symlink to `AGENTS.md`) |
+| GitHub Copilot | `.github/copilot-instructions.md` (or symlink to `AGENTS.md`) |
+| Windsurf | `.windsurfrules` |
+
+> agent-toolkit convention: prefer a single `AGENTS.md` and symlink the tool-specific
+> files to it. See the workstation `AGENTS.md` portability table for details.
+
+## What Are Design System Rules?
+
+Design system rules are project-level instructions that encode the "unwritten knowledge" of your codebase - the kind of expertise that experienced developers know and would pass on to new team members:
+
+- Which layout primitives and components to use
+- Where component files should be located
+- How components should be named and structured
+- What should never be hardcoded
+- How to handle design tokens and styling
+- Project-specific architectural patterns
+
+Once defined, these rules dramatically reduce repetitive prompting and ensure consistent output across all Figma implementation tasks.
+
+## Prerequisites
+
+- Figma MCP server must be connected and accessible
+- Access to the project codebase for analysis
+- Understanding of your team's component conventions (or willingness to establish them)
+
+## When to Use This Skill
+
+Use this skill when:
+
+- Starting a new project that will use Figma designs
+- Onboarding an AI coding agent to an existing project with established patterns
+- Standardizing Figma-to-code workflows across your team
+- Updating or refining existing design system conventions
+- Users explicitly request: "create design system rules", "set up Figma guidelines", "customize rules for my project"
+
+## Required Workflow
+
+**Follow these steps in order. Do not skip steps.**
+
+### Step 1: Run the Create Design System Rules Tool
+
+Call the Figma MCP server's `create_design_system_rules` tool to get the foundational prompt and template.
+
+**Parameters:**
+
+- `clientLanguages`: Comma-separated list of languages used in the project (e.g., "typescript,javascript", "python", "javascript")
+- `clientFrameworks`: Framework being used (e.g., "react", "vue", "svelte", "angular", "unknown")
+
+This tool returns guidance and a template for creating design system rules.
+
+Structure your design system rules following the template format provided in the tool's response.
+
+### Step 2: Analyze the Codebase
+
+Before finalizing rules, analyze the project to understand existing patterns:
+
+**Component Organization:**
+
+- Where are UI components located? (e.g., `src/components/`, `app/ui/`, `lib/components/`)
+- Is there a dedicated design system directory?
+- How are components organized? (by feature, by type, flat structure)
+
+**Styling Approach:**
+
+- What CSS framework or approach is used? (Tailwind, CSS Modules, styled-components, etc.)
+- Where are design tokens defined? (CSS variables, theme files, config files)
+- Are there existing color, typography, or spacing tokens?
+
+**Component Patterns:**
+
+- What naming conventions are used? (PascalCase, kebab-case, prefixes)
+- How are component props typically structured?
+- Are there common composition patterns?
+
+**Architecture Decisions:**
+
+- How is state management handled?
+- What routing system is used?
+- Are there specific import patterns or path aliases?
+
+### Step 3: Generate Project-Specific Rules
+
+Based on your codebase analysis, create a comprehensive set of rules. Include:
+
+#### General Component Rules
+
+```markdown
+- IMPORTANT: Always use components from `[YOUR_PATH]` when possible
+- Place new UI components in `[COMPONENT_DIRECTORY]`
+- Follow `[NAMING_CONVENTION]` for component names
+- Components must export as `[EXPORT_PATTERN]`
+```
+
+#### Styling Rules
+
+```markdown
+- Use `[CSS_FRAMEWORK/APPROACH]` for styling
+- Design tokens are defined in `[TOKEN_LOCATION]`
+- IMPORTANT: Never hardcode colors - always use tokens from `[TOKEN_FILE]`
+- Spacing values must use the `[SPACING_SYSTEM]` scale
+- Typography follows the scale defined in `[TYPOGRAPHY_LOCATION]`
+```
+
+#### Figma MCP Integration Rules
+
+```markdown
+## Figma MCP Integration Rules
+
+These rules define how to translate Figma inputs into code for this project and must be followed for every Figma-driven change.
+
+### Required Flow (do not skip)
+
+1. Run get_design_context first to fetch the structured representation for the exact node(s)
+2. If the response is too large or truncated, run get_metadata to get the high-level node map, then re-fetch only the required node(s) with get_design_context
+3. Run get_screenshot for a visual reference of the node variant being implemented
+4. Only after you have both get_design_context and get_screenshot, download any assets needed and start implementation
+5. Translate the output (usually React + Tailwind) into this project's conventions, styles, and framework
+6. Validate against Figma for 1:1 look and behavior before marking complete
+
+### Implementation Rules
+
+- Treat the Figma MCP output (React + Tailwind) as a representation of design and behavior, not as final code style
+- Replace Tailwind utility classes with `[YOUR_STYLING_APPROACH]` when applicable
+- Reuse existing components from `[COMPONENT_PATH]` instead of duplicating functionality
+- Use the project's color system, typography scale, and spacing tokens consistently
+- Respect existing routing, state management, and data-fetch patterns
+- Strive for 1:1 visual parity with the Figma design
+- Validate the final UI against the Figma screenshot for both look and behavior
+```
+
+#### Asset Handling Rules
+
+```markdown
+## Asset Handling
+
+- The Figma MCP server provides an assets endpoint which can serve image and SVG assets
+- IMPORTANT: If the Figma MCP server returns a localhost source for an image or SVG, use that source directly
+- IMPORTANT: DO NOT import/add new icon packages - all assets should be in the Figma payload
+- IMPORTANT: DO NOT use or create placeholders if a localhost source is provided
+- Store downloaded assets in `[ASSET_DIRECTORY]`
+```
+
+#### Project-Specific Conventions
+
+```markdown
+## Project-Specific Conventions
+
+- [Add any unique architectural patterns]
+- [Add any special import requirements]
+- [Add any testing requirements]
+- [Add any accessibility standards]
+- [Add any performance considerations]
+```
+
+### Step 4: Save Rules to the Appropriate Rule File
+
+Detect which AI coding agent the user is working with and save the generated rules to the corresponding file:
+
+| Agent | Rule File | Notes |
+|-------|-----------|-------|
+| Claude Code | `AGENTS.md` in project root (or `CLAUDE.md` symlinked) | Markdown format. Can also use `.claude/rules/figma-design-system.md` for modular organization. Append as a new section if the file already exists. |
+| opencode | `AGENTS.md` in project root (or `CLAUDE.md` symlinked) | Markdown format. Append as a new section if the file already exists. |
+| Cursor | `.cursor/rules/figma-design-system.mdc` | Markdown with YAML frontmatter (`description`, `globs`, `alwaysApply`). |
+| Gemini CLI | `GEMINI.md` in project root (or symlinked to `AGENTS.md`) | Markdown format. |
+| GitHub Copilot | `.github/copilot-instructions.md` (or symlinked to `AGENTS.md`) | Markdown format. |
+| Windsurf | `.windsurfrules` | Plain text or markdown. |
+
+agent-toolkit convention: prefer a single `AGENTS.md` and symlink the tool-specific
+files to it. See the workstation `AGENTS.md` portability table for details.
+
+If unsure which agent the user is working with, check for existing rule files
+in the project or ask the user.
+
+For Cursor, wrap the rules with YAML frontmatter:
+
+```markdown
+---
+description: Rules for implementing Figma designs using the Figma MCP server. Covers component organization, styling conventions, design tokens, asset handling, and the required Figma-to-code workflow.
+globs: "src/components/**"
+alwaysApply: false
+---
+
+[Generated rules here]
+```
+
+Customize the `globs` pattern to match the directories where Figma-derived code will live in the project (e.g., `"src/**/*.tsx"` or `["src/components/**", "src/pages/**"]`).
+
+After saving, the rules will be automatically loaded by the agent and applied to all Figma implementation tasks.
+
+### Step 5: Validate and Iterate
+
+After creating rules:
+
+1. Test with a simple Figma component implementation
+2. Verify the agent follows the rules correctly
+3. Refine any rules that aren't working as expected
+4. Share with team members for feedback
+5. Update rules as the project evolves
+
+## Rule Categories and Examples
+
+### Essential Rules (Always Include)
+
+**Component Discovery:**
+
+```markdown
+- UI components are located in `src/components/ui/`
+- Feature components are in `src/components/features/`
+- Layout primitives are in `src/components/layout/`
+```
+
+**Design Token Usage:**
+
+```markdown
+- Colors are defined as CSS variables in `src/styles/tokens.css`
+- Never hardcode hex colors - use `var(--color-*)` tokens
+- Spacing uses the 4px base scale: `--space-1` (4px), `--space-2` (8px), etc.
+```
+
+**Styling Approach:**
+
+```markdown
+- Use Tailwind utility classes for styling
+- Custom styles go in component-level CSS modules
+- Theme customization is in `tailwind.config.js`
+```
+
+### Recommended Rules (Highly Valuable)
+
+**Component Patterns:**
+
+```markdown
+- All components must accept a `className` prop for composition
+- Variant props should use union types: `variant: 'primary' | 'secondary'`
+- Icon components should accept `size` and `color` props
+```
+
+**Import Conventions:**
+
+```markdown
+- Use path aliases: `@/components`, `@/styles`, `@/utils`
+- Group imports: React, third-party, internal, types
+- No relative imports beyond parent directory
+```
+
+**Code Quality:**
+
+```markdown
+- Add JSDoc comments for exported components
+- Include PropTypes or TypeScript types for all props
+- Extract magic numbers to named constants
+```
+
+### Optional Rules (Project-Specific)
+
+**Accessibility:**
+
+```markdown
+- All interactive elements must have aria-labels
+- Color contrast must meet WCAG AA standards
+- Keyboard navigation required for all interactions
+```
+
+**Performance:**
+
+```markdown
+- Lazy load images with the `Image` component from `@/components/Image`
+- Use React.memo for components that receive complex props
+- Icons should be SVG components, not icon fonts
+```
+
+**Testing:**
+
+```markdown
+- Include unit tests for new components in `__tests__/` directory
+- Use Testing Library queries (getByRole, getByLabelText)
+- Test all interactive states and variants
+```
+
+## Examples
+
+### Example 1: React + Tailwind Project
+
+User says: "Create design system rules for my React project"
+
+**Actions:**
+
+1. Run `create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="react")`
+2. Analyze codebase structure
+3. Generate rules:
+
+```markdown
+# Figma MCP Integration Rules
+
+## Component Organization
+
+- UI components are in `src/components/ui/`
+- Page components are in `src/app/`
+- Use Tailwind for styling
+
+## Figma Implementation Flow
+
+1. Run get_design_context for the node
+2. Run get_screenshot for visual reference
+3. Map Figma colors to Tailwind colors defined in `tailwind.config.js`
+4. Reuse components from `src/components/ui/` when possible
+5. Validate against screenshot before completing
+
+## Styling Rules
+
+- IMPORTANT: Use Tailwind utility classes, not inline styles
+- Colors are defined in `tailwind.config.js` theme.colors
+- Spacing uses Tailwind's default scale
+- Custom components go in `src/components/ui/`
+
+## Asset Rules
+
+- IMPORTANT: Use localhost sources from Figma MCP server directly
+- Store static assets in `public/assets/`
+- DO NOT install new icon libraries
+```
+
+4. Save to the appropriate rule file for the user's agent
+5. Test with a simple button implementation
+
+**Result:** The agent now consistently follows the project's conventions when implementing Figma designs.
+
+### Example 2: Vue + Custom CSS Project
+
+User says: "Set up Figma rules for my Vue app"
+
+**Actions:**
+
+1. Run `create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="vue")`
+2. Discover that project uses CSS modules and a custom design token system
+3. Generate rules:
+
+```markdown
+# Figma MCP Integration Rules
+
+## Component Organization
+
+- Components are in `src/components/`
+- Composables are in `src/composables/`
+- Vue SFC structure: <script setup>, <template>, <style scoped>
+
+## Design Tokens
+
+- IMPORTANT: All colors defined in `src/styles/tokens.css` as CSS variables
+- Use `var(--color-primary)`, `var(--color-secondary)`, etc.
+- Spacing: `var(--space-xs)` through `var(--space-xl)`
+- Typography: `var(--text-sm)` through `var(--text-2xl)`
+
+## Figma Implementation Flow
+
+1. Run get_design_context and get_screenshot
+2. Translate React output to Vue 3 Composition API
+3. Map Figma colors to CSS variables in `src/styles/tokens.css`
+4. Use CSS Modules for component styles
+5. Check for existing components in `src/components/` before creating new ones
+
+## Styling Rules
+
+- Use CSS Modules (`.module.css` files)
+- IMPORTANT: Reference design tokens, never hardcode values
+- Scoped styles with CSS modules
+```
+
+4. Save to the appropriate rule file for the user's agent
+5. Validate with a card component
+
+**Result:** The agent now correctly translates Figma designs to Vue components using the project's design token system.
+
+### Example 3: Design System Team
+
+User says: "Generate rules for our design system library"
+
+**Actions:**
+
+1. Run `create_design_system_rules(clientLanguages="typescript", clientFrameworks="react")`
+2. Analyze the monorepo structure with design system package
+3. Generate comprehensive rules:
+
+```markdown
+# Design System Rules
+
+## Repository Structure
+
+- Design system components: `packages/design-system/src/components/`
+- Documentation: `packages/docs/`
+- Design tokens: `packages/tokens/src/`
+
+## Component Development
+
+- IMPORTANT: All components must be in `packages/design-system/src/components/`
+- Component file structure: `ComponentName/index.tsx`, `ComponentName.stories.tsx`, `ComponentName.test.tsx`
+- Export all components from `packages/design-system/src/index.ts`
+
+## Design Tokens
+
+- Colors: `packages/tokens/src/colors.ts`
+- Typography: `packages/tokens/src/typography.ts`
+- Spacing: `packages/tokens/src/spacing.ts`
+- IMPORTANT: Never hardcode values - import from tokens package
+
+## Documentation Requirements
+
+- Add Storybook story for every component
+- Include JSDoc with @example
+- Document all props with descriptions
+- Add accessibility notes
+
+## Figma Integration
+
+1. Get design context and screenshot from Figma
+2. Map Figma tokens to design system tokens
+3. Create or extend component in design system package
+4. Add Storybook stories showing all variants
+5. Validate against Figma screenshot
+6. Update documentation
+```
+
+4. Save to the appropriate rule file and share with team
+5. Add to team documentation
+
+**Result:** Entire team follows consistent patterns when adding components from Figma to the design system.
+
+## Best Practices
+
+### Start Simple, Iterate
+
+Don't try to capture every rule upfront. Start with the most important conventions and add rules as you encounter inconsistencies.
+
+### Be Specific
+
+Instead of: "Use the design system"
+Write: "Always use Button components from `src/components/ui/Button.tsx` with variant prop ('primary' | 'secondary' | 'ghost')"
+
+### Make Rules Actionable
+
+Each rule should tell the agent exactly what to do, not just what to avoid.
+
+Good: "Colors are defined in `src/theme/colors.ts` - import and use these constants"
+Bad: "Don't hardcode colors"
+
+### Use IMPORTANT for Critical Rules
+
+Prefix rules that must never be violated with "IMPORTANT:" to ensure the agent prioritizes them.
+
+```markdown
+- IMPORTANT: Never expose API keys in client-side code
+- IMPORTANT: Always sanitize user input before rendering
+```
+
+### Document the Why
+
+When rules seem arbitrary, explain the reasoning:
+
+```markdown
+- Place all data-fetching in server components (reduces client bundle size and improves performance)
+- Use absolute imports with `@/` alias (makes refactoring easier and prevents broken relative paths)
+```
+
+## Common Issues and Solutions
+
+### Issue: The agent isn't following the rules
+
+**Cause:** Rules may be too vague or not properly loaded by the agent.
+**Solution:**
+
+- Make rules more specific and actionable
+- Verify rules are saved in the correct configuration file
+- Restart your agent or IDE to reload rules
+- Add "IMPORTANT:" prefix to critical rules
+
+### Issue: Rules conflict with each other
+
+**Cause:** Contradictory or overlapping rules.
+**Solution:**
+
+- Review all rules for conflicts
+- Establish a clear priority hierarchy
+- Remove redundant rules
+- Consolidate related rules into single, clear statements
+
+### Issue: Too many rules increase latency
+
+**Cause:** Excessive rules increase context size and processing time.
+**Solution:**
+
+- Focus on the 20% of rules that solve 80% of consistency issues
+- Remove overly specific rules that rarely apply
+- Combine related rules
+- Use progressive disclosure (basic rules first, advanced rules in linked files)
+
+### Issue: Rules become outdated as project evolves
+
+**Cause:** Codebase changes but rules don't.
+**Solution:**
+
+- Schedule periodic rule reviews (monthly or quarterly)
+- Update rules when architectural decisions change
+- Version control your rule files
+- Document rule changes in commit messages
+
+## Understanding Design System Rules
+
+Design system rules transform how AI coding agents work with your Figma designs:
+
+**Before rules:**
+
+- The agent makes assumptions about component structure
+- Inconsistent styling approaches across implementations
+- Hardcoded values that don't match design tokens
+- Components created in random locations
+- Repetitive explanations of project conventions
+
+**After rules:**
+
+- The agent automatically follows your conventions
+- Consistent component structure and styling
+- Proper use of design tokens from the start
+- Components organized correctly
+- Zero repetitive prompting
+
+The time invested in creating good rules pays off exponentially across every Figma implementation task.
+
+## Additional Resources
+
+- [Figma MCP Server Documentation](https://developers.figma.com/docs/figma-mcp-server/)
+- [Figma Variables and Design Tokens](https://help.figma.com/hc/en-us/articles/15339657135383-Guide-to-variables-in-Figma)

agent_toolkit/data/skills/design/figma-create-design-system-rules/references/rule-template.md

@@ -0,0 +1,15 @@
+# Rule Template Skeleton
+
+## Figma MCP Integration Rules
+
+- Required flow (`get_design_context` -> `get_screenshot`)
+- Implementation conventions for this repo
+- Asset handling
+- Validation requirements
+
+## Project-Specific Conventions
+
+- Components path(s)
+- Token source(s)
+- Styling system
+- Testing and accessibility expectations

agent_toolkit/data/skills/design/figma-create-design-system-rules/scripts/check_agents_md.sh

@@ -0,0 +1,9 @@
+#!/usr/bin/env bash
+# Draft helper: report whether AGENTS.md exists at repo root.
+set -euo pipefail
+
+if [[ -f AGENTS.md ]]; then
+  echo "AGENTS.md found"
+else
+  echo "AGENTS.md not found"
+fi

agent_toolkit/data/skills/design/figma-create-new-file/LICENSE.txt

@@ -0,0 +1,2 @@
+Use of these Figma skills and related files ("Materials") is governed by the Figma Developer Terms (available at https://www.figma.com/legal/developer-terms/). By accessing, downloading, or using these Materials — including through automated systems or AI agents — you agree to the Figma Developer Terms.
+These Materials are currently offered as a Beta feature. Figma may modify, suspend, or discontinue them at any time without notice.

agent_toolkit/data/skills/design/figma-create-new-file/NOTICE.txt

@@ -0,0 +1,17 @@
+figma-create-new-file (agent-toolkit distribution)
+============================================
+
+This skill is derived from the OpenAI "skills" repository, originally licensed
+under the Apache License 2.0:
+
+  https://github.com/openai/skills (skills/.curated/figma-create-new-file)
+
+Modifications by agent-toolkit S.A. for distribution via agent-toolkit:
+
+- Removed the `agents/openai.yaml` manifest and `maintainers.yml` in favor of
+  the agent-toolkit `skill.json` schema.
+- Updated cross-references to point to the opt-in `figma-use` pack (see
+  `docs/SKILLS.md`) since it is not bundled by default.
+- Dropped vendor logo assets (`assets/figma*`).
+
+Original LICENSE.txt is preserved in this directory.

agent_toolkit/data/skills/design/figma-create-new-file/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: figma-create-new-file
+description: Create a new blank Figma file. Use when the user wants to create a new Figma design or FigJam
+  file, or when you need a new file before calling use_figma. Handles plan resolution via whoami if needed.
+  Usage — /figma-create-new-file [editorType] [fileName] (e.g. /figma-create-new-file figjam My Whiteboard)
+origin:
+  type: first-party
+---
+# create_new_file — Create a New Figma File
+
+Use the `create_new_file` MCP tool to create a new blank Figma file in the user's drafts folder. This is typically used before `use_figma` when you need a fresh file to work with.
+
+## Skill Arguments
+
+This skill accepts optional arguments: `/figma-create-new-file [editorType] [fileName]`
+
+- **editorType**: `design` (default) or `figjam`
+- **fileName**: Name for the new file (defaults to "Untitled")
+
+Examples:
+- `/figma-create-new-file` — creates a design file named "Untitled"
+- `/figma-create-new-file figjam My Whiteboard` — creates a FigJam file named "My Whiteboard"
+- `/figma-create-new-file design My New Design` — creates a design file named "My New Design"
+
+Parse the arguments from the skill invocation. If editorType is not provided, default to `"design"`. If fileName is not provided, default to `"Untitled"`.
+
+## Workflow
+
+### Step 1: Resolve the planKey
+
+The `create_new_file` tool requires a `planKey` parameter. Follow this decision tree:
+
+1. **User already provided a planKey** (e.g. from a previous `whoami` call or in their prompt) → use it directly, skip to Step 2.
+
+2. **No planKey available** → call the `whoami` tool. The response contains a `plans` array. Each plan has a `key`, `name`, `seat`, and `tier`.
+
+   - **Single plan**: use its `key` field automatically.
+   - **Multiple plans**: ask the user which team or organization they want to create the file in, then use the corresponding plan's `key`.
+
+### Step 2: Call create_new_file
+
+Call the `create_new_file` tool with:
+
+| Parameter    | Required | Description |
+|-------------|----------|-------------|
+| `planKey`   | Yes      | The plan key from Step 1 |
+| `fileName`  | Yes      | Name for the new file |
+| `editorType`| Yes      | `"design"` or `"figjam"` |
+
+Example:
+```json
+{
+  "planKey": "team:123456",
+  "fileName": "My New Design",
+  "editorType": "design"
+}
+```
+
+### Step 3: Use the result
+
+The tool returns:
+- `file_key` — the key of the newly created file
+- `file_url` — a direct URL to open the file in Figma
+
+Use the `file_key` for subsequent tool calls like `use_figma`.
+
+## Important Notes
+
+- The file is created in the user's **drafts folder** for the selected plan.
+- Only `"design"` and `"figjam"` editor types are supported.
+- If `use_figma` is your next step, install and load the opt-in `figma-use`
+  pack first (see `docs/SKILLS.md`).

agent_toolkit/data/skills/design/figma-implement-design/LICENSE.txt

@@ -0,0 +1,2 @@
+Use of these Figma skills and related files ("Materials") is governed by the Figma Developer Terms (available at https://www.figma.com/legal/developer-terms/). By accessing, downloading, or using these Materials — including through automated systems or AI agents — you agree to the Figma Developer Terms.
+These Materials are currently offered as a Beta feature. Figma may modify, suspend, or discontinue them at any time without notice.

agent_toolkit/data/skills/design/figma-implement-design/NOTICE.txt

@@ -0,0 +1,19 @@
+figma-implement-design (agent-toolkit distribution)
+=============================================
+
+This skill is derived from the OpenAI "skills" repository, originally licensed
+under the Apache License 2.0:
+
+  https://github.com/openai/skills (skills/.curated/figma-implement-design)
+
+Modifications by agent-toolkit S.A. for distribution via agent-toolkit:
+
+- Removed the `agents/openai.yaml` manifest in favor of the agent-toolkit
+  `skill.json` schema.
+- Rewrote cross-references to mark `figma-use` and `figma-generate-design` as
+  opt-in packs (see `docs/SKILLS.md`) since they are not bundled by default.
+- Reordered the agent rule guidance to mention `AGENTS.md` first (agent-toolkit
+  convention).
+- Dropped vendor logo assets (`assets/figma*`).
+
+Original LICENSE.txt is preserved in this directory.