mirror of
https://github.com/azaion/ui.git
synced 2026-06-21 16:11:10 +00:00
Oleksandr Bezdieniezhnykh
39 lines
2.2 KiB
Plaintext
39 lines
2.2 KiB
Plaintext
---
|
|
description: "Standards for creating and maintaining Cursor skills"
|
|
globs: [".cursor/skills/**"]
|
|
---
|
|
|
|
# Skill Building
|
|
|
|
## When To Create A Skill
|
|
- Create a skill for repeatable, bounded workflows that benefit from a reusable process.
|
|
- Do not create a skill for a one-off task, vague goal, or workflow that still needs product decisions.
|
|
- Start small; evolve the skill when repeated use reveals clearer steps, constraints, or checks.
|
|
|
|
## Skill Contract
|
|
- `SKILL.md` must define a clear `name` and a proactive `description` that explains when the skill should be used.
|
|
- State expected inputs, constraints, workflow steps, and final output shape.
|
|
- Make trigger conditions explicit enough that the agent can recognize intent without an exact command.
|
|
- Base instructions on observable project evidence; do not invite fabrication or unsupported assumptions.
|
|
|
|
## Keep The Core Lean
|
|
- Keep `SKILL.md` concise and under the repo's `.cursor/` size guidance.
|
|
- Move detailed standards, examples, and background knowledge into `references/`.
|
|
- Put reusable output shapes in `templates/` or other skill-local assets instead of embedding them in the main instructions.
|
|
- Keep one primary responsibility per skill; use an orchestrator skill only when multiple existing skills must run in a defined order.
|
|
|
|
## Deterministic Work
|
|
- Use scripts for mechanical steps that are repeatable, parameterized, and safer outside the model's reasoning.
|
|
- Scripts must expose explicit inputs, avoid hidden side effects, and fail loudly on errors.
|
|
- Do not use scripts to bypass review, hide destructive behavior, or hardcode secrets.
|
|
|
|
## Quality Proof
|
|
- Include realistic examples, checklists, or eval-style scenarios that define what good output looks like.
|
|
- Cover common failure cases such as missing sections, leftover placeholders, hallucinated facts, unsafe actions, or malformed output.
|
|
- Review skill changes against those checks before treating the skill as ready.
|
|
|
|
## Security Review
|
|
- Treat third-party skills like untrusted code until reviewed.
|
|
- Inspect scripts, dependencies, references, secret handling, network calls, and destructive commands before use.
|
|
- Prefer local, project-scoped assets and dependencies; document any external dependency the skill requires.
|