Anima / rules
Cursor rule1k starsChanged 5 months agoApache-2.0View on GitHub
Use a branch-first, commit-early workflow suitable for a maintained open source repository. Before making meaningful code changes, ensure the work is on a dedicated task branch rather than on a protected or shared integration branch. Once work starts, preserve progress through small, logical, reviewable commits instead of one large accumulated diff. At the beginning of meaningful work: Use short, descriptive, task-focused branch names. Prefer patterns such as: Branch names should be: Avoid vague names such as: Commit after each completed,…
We split this Branch-And-Commit-Workflow.mdc into the rules it gives an agent
14 rules. About 0 are common, 13 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈13
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 5
Use a branch-first, commit-early workflow suitable for a maintained open source repository.
- Distinctive: line 9
Before making meaningful code changes, ensure the work is on a dedicated task branch rather than on a protected or shared integration …
- Distinctive: line 17
Check the current branch.
- Distinctive: line 18
If already on a suitable task branch for the current task, continue there.
- Very specific: line 19
If on a protected or shared branch such as main, master, develop, dev, or release, create and switch to a dedicated task branch before …
- Distinctive: line 20
If on a branch unrelated to the current task, create and switch to a new task branch instead of mixing concerns.
- Distinctive: line 24
Use short, descriptive, task-focused branch names.
- Distinctive: line 26
Prefer patterns such as:
- Distinctive: line 42
Avoid vague names such as:
- Distinctive: line 52
Commit after each completed, coherent unit of work.
- Distinctive: line 73
Write concise commit messages that describe the intent clearly.
- Distinctive: line 98
Do not commit secrets, credentials, tokens, or private keys.
- Distinctive: line 99
Do not force-push, rewrite shared history, or delete branches unless explicitly requested.
- Distinctive: line 100
Do not merge into protected branches unless explicitly requested.
≈ “Common” is an estimate: at least 1 in 5 of the 6,350 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
--- alwaysApply: true --- Use a branch-first, commit-early workflow suitable for a maintained open source repository. ## Core rule Before making meaningful code changes, ensure the work is on a dedicated task branch rather than on a protected or shared integration branch. Once work starts, preserve progress through small, logical, reviewable commits instead of one large accumulated diff. ## Branch behavior At the beginning of meaningful work: 1. Check the current branch. 2. If already on a suitable task branch for the current task, continue there. 3. If on a protected or shared branch such as `main`, `master`, `develop`, `dev`, or `release`, create and switch to a dedicated task branch before making meaningful edits. 4. If on a branch unrelated to the current task, create and switch to a new task branch instead of mixing concerns. ## Branch naming Use short, descriptive, task-focused branch names. Prefer patterns such as: - `fix/dashboard-refresh-bug` - `fix/mqtt-timeout-handling` - `feat/device-status-history` - `refactor/adapter-payload-parser` - `docs/env-setup-clarification` - `test/add-timeout-regression` Branch names should be: - lowercase - concise - descriptive - scoped to one task or one closely related set of changes Avoid vague names such as: - `temp` - `misc` - `work` - `updates` - `new-branch` ## Commit behavior Commit after each completed, coherent unit of work. A commit should represent one logical step such as: - one bug fix - one small feature slice - one focused refactor - one interface update with its direct caller adjustments - one docs update tied to a code change - one regression test plus the related fix ## Commit quality Each commit should be: - small enough to review easily - coherent in purpose - safe to revert independently - tied to a clear intent - validated whenever practical Write concise commit messages that describe the intent clearly. Prefer: - `fix dashboard polling after reconnect` - `add regression test for adapter timeout` - `refactor mqtt payload normalization` - `update docs for broker configuration` Avoid: - `changes` - `fix stuff` - `update code` - `wip` ## Do not commit yet if - the code is in an obviously broken intermediate state - the change is only half-wired - imports, types, or tests are failing because the step is incomplete - the commit would include unrelated accidental edits ## Safety rules - Do not commit secrets, credentials, tokens, or private keys. - Do not force-push, rewrite shared history, or delete branches unless explicitly requested. - Do not merge into protected branches unless explicitly requested. ## End-state expectation By the end of the task: - work should live on a dedicated task branch - progress should be preserved in a sequence of small logical commits - history should be readable, reviewable, and easy to roll back
Where files are headingNew Cursor rule files have more rules about planning and tracking tasks, and fewer about code style.
Of the Cursor rule files we read, the 3,978 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository31 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .cursor/rules/Architecture-Guardrails.mdcCursor rule
- .cursor/rules/Changelog-And-Versioning-Discipline.mdcCursor rule
- .cursor/rules/Change-Scope-Control.mdcCursor rule
- .cursor/rules/Community-Standards-And-Contributor-Experience.mdcCursor rule
- .cursor/rules/Continuous-Execution-Until-Done.mdcCursor rule
- .cursor/rules/Dependency-And-Interface-Safety.mdcCursor rule
- .cursor/rules/Docs-And-Runbook-Sync.mdcCursor rule
- .cursor/rules/English-First-Engineering-Workflow.mdcCursor rule
- .cursor/rules/GitHub-MCP-Available.mdcCursor rule
- .cursor/rules/License-And-Dependency-Compliance.mdcCursor rule
- .cursor/rules/Migration-And-Backward-Compatibility.mdcCursor rule
- .cursor/rules/Open-Source-Contribution-Workflow.mdcCursor rule
- .cursor/rules/Pull-Request-Readiness-And-Reviewer-Hygiene.mdcCursor rule
- .cursor/rules/Repo-Navigation-And-Module-Ownership.mdcCursor rule
- .cursor/rules/Secrets-And-Environment-Safety.mdcCursor rule
- .cursor/rules/Self-Install-Tools-And-MCP-When-Necessary.mdcCursor rule
- .cursor/rules/Test-First-For-Bugs-And-Regression.mdcCursor rule
- .cursor/rules/Verification-And-Regression-Checks.mdcCursor rule
- custom_skill_bde0cedaSkill
- custom_skill_f4b0b238Skill
- your-skill-nameSkill
- Workday 8AM Smart Speaker WakeupSkill
- air_conditionerSkill
- air_purifierSkill
- coordinatorSkill
- device_discoverySkill
- humidifierSkill
- lightSkill
- skill_creatorSkill
- speakerSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.