Cursor recommends Agent Skills as the preferred way to extend agent behaviour — dynamic context that loads when a task matches a skill’s description, keeping the context window lean. Rules and the older .cursorrules approach still cover static or path-scoped enforcement; skills remain where Cursor steers agent work in their agent best practices guide. The collection now splits three trees — skills, rules, and agents — meant to be symlinked into ~/.cursor, not treated as an installable app.
It is available at codeberg.org/sbstjn/skills.
Skills: Topic Entry Points
Each topic is a directory under skills/<name>/ with a SKILL.md file. Cursor discovers those entry points; the YAML description is what the agent uses to decide relevance. The markdown body is the full criterion text the model should apply once the skill loads.
Hold every task against concepts first — strategic alignment, complexity, DDD where it matters, triple debt, resilience, release discipline, and explicit conflict-resolution rules. That file is the true north; narrower skills add stack-specific detail without replacing it.
flowchart TB Concepts[concepts] Concepts --> Rust[rust] Concepts --> TS[typescript] Concepts --> GoLang[go] Concepts --> Mono[monorepo] Concepts --> Write[writing] TS --> React[react]
Other topics in the collection today include language and runtime standards (rust, go, typescript, react, bash), data and API surfaces (postgres, graphql), delivery and infrastructure (docker, tofu, woodpecker, architecture), the browser platform (web-development), polyglot layout (monorepo), prose (writing), and review workflow (review).
Child files — for example rust/CONCEPT.md, rust/CROSS.md, typescript/CONFIG.md, graphql/SERVER.md — are not auto-loaded by Cursor. They exist so a parent SKILL.md (or a rule, agent, or human) can pull exactly the fragment needed without stuffing the whole tree into context.
Rules: Always-On and Path-Scoped
Rules pair with skills: the rule states what fires on which files and often repeats a small set of hard prohibitions; the linked SKILL.md holds the full criterion set.
flowchart LR RustR["rust.mdc — **/*.rs"] WriteR["writing.mdc — *.md / *.mdx"] RustR --> RustS[rust/SKILL.md] WriteR --> WriteS[writing/SKILL.md]
The companion.mdc is alwaysApply: true — session-wide stance (production-first, non-destructive defaults, no engagement padding) and explicit hooks to load concepts before planning and review after completing a plan.
Topic rules are glob-scoped: for example rust.mdc matches **/*.rs, writing.mdc matches Markdown and MDX, astro.mdc matches **/*.astro and points at several skills together.
The pairing model is consistent: rules decide when the surface is in play; skills decide what good looks like at full depth.
Agents: Orchestration, Not Ownership
Agent files under agents/ describe multi-step workflows — who loads what, in what order, and how outputs merge. They do not replace skills: the skill they reference still owns the criteria and output shape.
The only agent in the repository today is review.md. It orchestrates a pillar fan-out (architecture, TypeScript, React when applicable, security, testing, hygiene), mandates loading review/SKILL.md first, and sends each worker to the relevant skills/… paths. That keeps parallel review cheap without duplicating the review skill’s rules in the agent file.
flowchart TB Agent[agents/review.md] Agent --> RevSkill[skills/review/SKILL.md] RevSkill --> Concepts[skills/concepts/SKILL.md] RevSkill --> Lang["per-pillar language skill"]
The real review.md file names every pillar, model choice, and ../skills/… path workers must load; the diagram only sketches the dependency chain.
How They Compose
Editing Rust in a polyglot workspace is a concrete stack: load concepts, then rust/SKILL.md, then follow that file’s links to rust/CONCEPT.md when Cargo workspace layout is in question, and monorepo/SKILL.md when more than one ecosystem shares the repository. On disk, rust.mdc still enforces a short non-negotiable list on **/*.rs while the rust skill carries the full standard.
Running the review agent inverts the emphasis: agents/review.md coordinates subagents, but every worker still ends in the same skill files — concepts plus the language or domain skills the pillar needs — so merged output stays aligned with the same definitions a single agent would use.
That’s It! 🎉
The repository at codeberg.org/sbstjn/skills replaces a single monolithic skills dump with skills (topic SKILL.md entry points and linked children), rules (always-on companion plus path-scoped .mdc pairs), and agents (orchestration such as multi-pillar review). concepts stays true north; everything else narrows the lens without replacing it.
Symlink skills, rules, and agents into ~/.cursor, and you get the same stack whether you are editing Rust crates, Astro pages, Markdown, or splitting planning and implementation across Opus and Sonnet.