From e7eaefff8b16f2745f492008037a30288360867a Mon Sep 17 00:00:00 2001 From: Oleksandr Bezdieniezhnykh Date: Tue, 5 May 2026 01:08:48 +0300 Subject: [PATCH] chore: sync .cursor from suite --- .cursor/rules/skill-building.mdc | 38 ++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 .cursor/rules/skill-building.mdc diff --git a/.cursor/rules/skill-building.mdc b/.cursor/rules/skill-building.mdc new file mode 100644 index 0000000..7fbf1ed --- /dev/null +++ b/.cursor/rules/skill-building.mdc @@ -0,0 +1,38 @@ +--- +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.