claudinho / rules
Cursor rule35 starsChanged 34 days agoMITView on GitHub
Release batching, gitignore policy, and pre-tag checks
- Reads credentials
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 4,157 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 repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/bundle-bracket-pr.mdcCursor rule
- .cursor/rules/change-discipline.mdcCursor rule
- .cursor/rules/surface-parity.mdcCursor rule
- .cursor/rules/trust-boundary.mdcCursor rule
- claudinho-modeSkill
- verify-claudinhoSkill
- claudinho-modeSkill
- verify-claudinhoSkill
The file
We split this release-discipline.mdc into the rules it gives an agent
6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 11
Do not tag npm until CI is green and pnpm release:qa passes (tripwires at the end must be 0 failed).
- Very specific: line 13
Before tagging: git diff main must not include accidental private paths (docs/, CLAUDE.local.md, .env).
- Very specific: line 17
Every commit produced with an AI agent: follow AGENTS.md § Commit attribution — trailer names the agent and model in use (e.g.
- Very specific: line 27
Never: add !docs/… exceptions to .gitignore without explicit maintainer approval.
- Distinctive: line 31
Before merge or release of bracket or kickoff-formatting work:
- Very specific: line 36
After pnpm -r build, run pnpm release:qa and eyeball the rendered sections.
≈ “Common” is an estimate: at least 1 in 5 of the 6,668 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
--- description: Release batching, gitignore policy, and pre-tag checks alwaysApply: true --- # Release discipline ## One feature, one release - **One user-facing feature → one minor.** Stack review fixes (tz, dates, guards) into the **same PR** before merge when they belong to the same feature. - Do **not** tag npm until CI is green **and** `pnpm release:qa` passes (tripwires at the end must be 0 failed). - `scripts/gate.sh` runs CI's gating list locally (not `pnpm release:qa`, not CI's Node 22 floor, Windows and macOS jobs), and `scripts/push-and-watch.sh <branch>` reads CI's per-job result on the pushed SHA. - Before tagging: `git diff main` must not include accidental private paths (`docs/`, `CLAUDE.local.md`, `.env`). ## Commit attribution Every commit produced with an AI agent: follow **`AGENTS.md` § Commit attribution** — trailer names the agent **and** model in use (e.g. `Co-Authored-By: Cursor (Composer 2.5) <cursoragent@cursor.com>`). ## Public vs private docs **Tracked (public engineering guides):** `AGENTS.md`, `CLAUDE.md`, `.cursor/rules/`, README, MCP tool descriptions. **Gitignored (maintainer-local):** `docs/` (the maintainer's private notes and notebook) and `CLAUDE.local.md`. Never cite a file under `docs/` from a tracked file — the pack guard (`scripts/check-pack.mjs`, run in CI) fails on any `docs/<name>` reference. - Engineering process → update the **public** guides above. - Candid history, strategy, or release post-mortems → `docs/` notebook only. - **Never** add `!docs/…` exceptions to `.gitignore` without explicit maintainer approval. ## Bracket / live-formatting ship checklist Before merge **or** release of bracket or kickoff-formatting work: 1. Adversarial tests: 0 games, mid-tournament (2/3 played), degraded standings. 2. **Surface parity:** CLI `bracket` + MCP `get_bracket` + `share bracket` all pass `tz` and show calendar dates on multi-week knockouts. 3. **Statusline and `ambient --json` knockouts (if touched):** indirect-resolve via cached `getKnockoutFixtures` — hot path fail-closed (no 🏳️ on countdown or `live · syncing…`); empty-cache short TTL; `knockout-surface-coverage.test.ts` + `statusline.test.ts` / `refresh.test.ts` green. See `.cursor/rules/surface-parity.mdc`. 4. After `pnpm -r build`, run **`pnpm release:qa`** and eyeball the rendered sections; keep `packages/mcp/test/tools.test.ts` green for MCP arg threading.
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.