ibex-harness / rules
Cursor rule57 starsChanged 13 days agoMITView on GitHub
IBEX Harness repository rules for Cursor
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 repository7 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- loop-budgetSkill
- loop-constraintsSkill
- loop-triageSkill
- loop-verifierSkill
The file
We split this ibex-harness.mdc into the rules it gives an agent
8 rules. About 0 are common, 5 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 9
Read AGENTS.md and engineering/agent-playbook.md before changing code.
- Very specific: line 21
Never remove org_id filtering, even where PostgreSQL RLS exists.
- Distinctive: line 22
Never log tokens, keys, memory content, prompts, or personal data.
- Distinctive: line 23
Never add placeholder logic, stub handlers, or a dependency without stating why the stdlib/existing dependency is insufficient.
- Distinctive: line 25
Never weaken a lint rule, test, coverage threshold, or CI gate to make a change pass.
- Distinctive: line 26
Every commit needs a DCO sign-off: git commit -s.
- Distinctive: line 32
Run the checks for the area you changed.
- Very specific: line 43
Read engineering/DEVELOPMENT_GUIDE.md §4.4 for the service startup matrix and engineering/agent-playbook.md §6 for the full pre-push …
≈ “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: IBEX Harness repository rules for Cursor globs: ["**/*"] alwaysApply: true --- # IBEX Harness Read `AGENTS.md` and `engineering/agent-playbook.md` before changing code. `AGENTS.md` is the project constitution; this file is a short entry point, not a replacement. ## Product shape IBEX is a self-hosted memory and context layer for multi-tenant AI agents. The proxy is the adoption surface, the memory/context services are the differentiator, and the Console is the operations plane for the agent → session → memory → evidence lifecycle. Incidents, drift, analytics, and budgets are a later platform tier (ADR-0089). ## Hard rules - Never remove `org_id` filtering, even where PostgreSQL RLS exists. Cross-tenant reads return 404, not 403. - Never log tokens, keys, memory content, prompts, or personal data. - Never add placeholder logic, stub handlers, or a dependency without stating why the stdlib/existing dependency is insufficient. - Never weaken a lint rule, test, coverage threshold, or CI gate to make a change pass. - Every commit needs a DCO sign-off: `git commit -s`. - The Console is Nuxt 4 + Vue 3 + Nitro. Do not add React or Next.js. - Console surface status comes from `services/console/shared/operator/surfaces.ts`; do not restate it in prose. ## Before you finish Run the checks for the area you changed. The short list: ```bash make check pnpm --filter @ibex/console test pnpm --filter @ibex/console typecheck pnpm --filter @ibex/console lint pnpm --filter @ibex/console build pnpm site:build && pnpm site:check ``` Read `engineering/DEVELOPMENT_GUIDE.md` §4.4 for the service startup matrix and `engineering/agent-playbook.md` §6 for the full pre-push command list. ## Where to look - Architecture and product shape: `engineering/ARCHITECTURE.md`, `engineering/adr/` - Runtime claims: `engineering/architecture-v2/00-status-and-evidence.md` - Service inventory: `services/README.md` - Contracts: `engineering/API_DOCUMENTATION.md`, `packages/proto/` - Security and tenancy: `engineering/SECURITY.md`, `AGENTS.md` §4–§5
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.