What installing a skill changes
Installing a skill makes a procedure available to an agent host that supports its format and discovery mechanism. It does not automatically connect external tools, grant access to a Figma file, or prove that the procedure fits your product. Treat installation, tool access, and task validation as separate steps.
TDP’s agent-skills article describes skills for repeatable tasks such as token auditing, component metadata, and moving between Figma and code. The public repository contains the current installation instructions and individual skill descriptions.
Begin with one task you can judge, rather than installing a large bundle and assuming every skill will be useful. A small first run makes it easier to tell whether the host loaded the right instructions and whether the output is worth keeping.
Step 1. Choose a task before choosing a skill
Start with the outcome: organize product context, audit accessibility, or document component metadata. Read the skill’s description and instructions in the public repository. Confirm its supported host and dependencies. A skill that relies on a Figma integration needs that connection separately; instructions do not provide credentials or service access.
Step 2. Inspect the resource
Read the files and identify what the skill may change. Prefer a small first task that you can inspect. If the skill’s instructions do not match your project’s conventions, adapt the configuration or select a more suitable resource. Keep product-specific rules explicit so a generic example does not become your production requirement.
Step 3. Install one selected skill
The TDP repository documents the following installation pattern. Run it in the intended project, confirm the selected host and scope in the installer, and review the files it adds. This page displays commands for you to run; it does not execute them.
npx skills add thedesignproject/agent-skills
# Or install one selected skill:
npx skills add thedesignproject/agent-skills -s product-context-builder
Step 4. Confirm discovery and run a bounded task
Ask the agent to identify the installed skill and explain when it applies. Then provide a concrete input. For a context skill, choose one product folder or feature. For a component skill, choose one component. Request the sources consulted, output files, and anything it could not verify.
| Task | Resource to inspect |
|---|---|
| Organize product knowledge | product-context-builder |
| Describe component usage | ai-component-metadata |
| Audit accessibility | accessibility |
| Extract visual foundations | extract-design-system |
Step 5. Review before reuse
Inspect changed files and compare the result with the intended outcome. Run checks appropriate to the task and review the actual interface when the output affects UI. If the host cannot discover the skill, check its documented installation path and supported format. Record the working setup so a teammate can reproduce it.
Choose the skill by the outcome you need
Write the task in one sentence before browsing. “Audit the spacing in this settings form against our tokens” is more useful than “improve our AI workflow.” Compare the candidate skill’s inputs, tool requirements, and output with that sentence.
| Need | What to look for | What to verify first |
|---|---|---|
| Inspect a Figma component | A Figma workflow skill | Host integration and access to the actual file |
| Document a component | A metadata or documentation procedure | Existing implementation and approved behavior |
| Extract a starter token map | An extraction workflow | Source access and how inferred values are labeled |
| Review accessibility | A focused audit procedure | A runnable flow and checks beyond screenshots |
Read the instructions before using the skill on important work. A polished name does not tell you which operations it performs or what assumptions it makes. If the procedure expects a tool you do not have, resolve that prerequisite or choose a suitable alternative.
Decide project scope versus personal scope
Project-level installation can make a workflow available alongside the code and its conventions. Personal installation can be useful for a procedure you use across projects. The exact directories and precedence rules depend on the host and installer, so follow their current instructions.
For a team-specific component audit, project scope is often easier to review because the skill can reference the same token paths as the application. A personal generic skill should defer to the project’s current rules instead of imposing a palette or framework on every repository.
Record the source and version or revision you installed when available. That gives you a way to explain why two teammates see different behavior and to review changes before adopting an update.
Verify installation with a bounded first task
Do not start by asking for a full redesign. Choose a component or screen whose expected behavior you understand. Ask the agent to identify the skill it is using, the source files it needs, and any missing prerequisites before making changes.
For an illustrative token-audit run, provide one component and the token source. Review the reported mappings before implementation. A correct result should distinguish observed values from proposed semantic roles and retain uncertainties rather than guessing.
Use the installed token-audit workflow on this component.
First confirm the instructions and token source you can access.
Return findings only, with file references and proposed mappings.
Do not change files yet.
If the agent ignores the skill, check discovery and trigger wording. If it loads the skill but uses the wrong context, check project paths and instructions. If it follows the procedure but produces poor findings, improve the procedure or choose another skill. These are separate problems.
Review updates as changes to a working process
An updated skill may change its trigger, dependencies, output format, or editing behavior. Read the difference and repeat your small acceptance task. Preserve the known-good version until you have enough evidence to adopt the update.
Avoid keeping several overlapping versions with unclear precedence. When results differ between machines, compare the installed source and scope before assuming the model behaved randomly. Document the team’s chosen setup where contributors already find onboarding instructions.
Turn the first successful run into a team example
Keep a short record of the input, expected output, checks, and any corrections. A teammate should be able to reproduce the task without reading your entire conversation. Link the example from the skill’s local documentation if that is how your team shares workflow guidance.
When no existing skill fits, use create a design agent skill to package the proven procedure. Start from evidence of a repeated task, then test activation and boundaries.
Completion checklist
- Host compatibility and dependencies are understood.
- The selected skill is discoverable in the intended project.
- The first task has a clear expected output.
- Changes and unresolved questions were reviewed.
- The team knows how to update or remove the installed resource.
Common questions
Does installing every skill make the agent better?
Install the resources that fit your workflow and that you can maintain. Start with one task so you can identify what actually improves the result.
Do skills replace a design system?
No. A skill can help use or maintain a system, but it still needs accurate tokens, components, and product rules to work from.
Sources and TDP resources
- TDP skills repository and installation instructions
- Browse the TDP skills experience for the curated resource collection; it may request free signup.