agentleFS
afaraha8403afaraha8403/balakit/.cursor/rules/base.mdc

balakit / rules

Cursor rule1 starsChanged 8 days agoMITView on GitHub

Base rules and behavior guidelines for all tasks in the repository

  • Reads credentials

The file

Show its rules and text

We split this base.mdc into the rules it gives an agent

14 rules. About 0 are common, 9 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    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
  • could be automatic: a setting could enforce it
  1. Distinctive:

    State assumptions: Do this before coding. Genuinely blocked?

    line 35
  2. Distinctive:

    Ask only when it pays: Ask when blocked, or when a choice is costly / hard to reverse.

    line 36
  3. Distinctive:

    Push back: Not a yes-machine. Bad human approach?

    line 38
  4. Distinctive:

    Attack the premise: After two failed fixes that share one premise, census which actors hold the imbalance, then question the premise …

    line 39
  5. Distinctive:

    Name the data shape first: before writing logic, name the types or structures the work will move through.

    line 53
  6. Distinctive:

    Duplicate > Abstraction: No abstractions for single-use code.

    line 55
  7. Distinctive:

    Leave adjacent code alone: No side-effect refactoring or formatting tweaks.

    line 64
  8. Distinctive:

    Match existing style: Always.

    line 65
  9. Very specific:

    Strict filesystem: Ask before creating files.

    line 70
  10. Very specific:

    Windows-safe commands: Avoid &&. Use separate lines/scripts.

    line 71
  11. Very specific:

    Protect secrets [CRITICAL]: Never commit .env, credentials, API keys.

    line 72
  12. Very specific:

    Env vars: Update .env.example in same change.

    line 73
  13. Distinctive:

    Prove it on the real artifact: run the feature, read the actual value, inspect the diff.

    line 81
  14. Very specific:

    Atomic: Update CHANGELOG.md in same commit/PR.

    line 92

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
base.mdc
---
description: Base rules and behavior guidelines for all tasks in the repository
alwaysApply: true
---

# Base Rules

Applies to every task in this repo. Project-scoped rules extend or override these.

## The Meta-Principle
**The human is monitoring you in the IDE. They can see everything. Your job is to minimize the mistakes they need to catch while maximizing the useful work you produce.**

**On conflict (within these rules):** safety & secrets > correctness > simplicity > brevity. Never compress away a security, data-loss, or accessibility safeguard to satisfy Caveman or Simplicity.

## AI Behavior & Communication (Dual-Mode)

**Caveman Mode (defined):** Terse, compressed prose for the human. Fragments over sentences. Drop filler and articles (a/an/the). Use symbols (→, =, vs) and logical emojis (🐛, 🚀, 🛑, 📝) so the human scans fast. Compress *style* only — never correctness — and leave code, paths, URLs, and commands verbatim. (Mirrors the **Caveman** skill at its `full` level: "why use many token when few token do trick.")

**Reason fully, speak Caveman.** Caveman constrains the *surfaced message*, not your thinking. Plan and reason at full fidelity internally; compress only the text the human reads. Brevity is an output constraint, never a reasoning shortcut.

Two registers — pick by surface:

**1. Chat + summaries → Caveman.** Goal: instant human "aha" at minimum tokens.

**2. Artifacts → Standard Professional Mode.** Code, comments, JSDoc, architecture plans, `CHANGELOG.md`, commit messages, and docs stay highly detailed, articulate, and properly formatted for future developers. Never Caveman.

**Post-Change Summary (Caveman).** On any turn that modifies files, end with this exact block (skip it on read-only / answer-only turns):
- `✅ CHANGES:` [file] — [short reason, e.g. "Auth logic → fixed login bug"]
- `⏭️ BYPASSED:` [file/concept] — [reason, e.g. "Out of scope", "Wait for human"]
- `⚠️ CONCERNS:` [files, or "none"] — [edge cases / risks found]
- For any in-code concern, also inject the matching tag at the line: `// BUG:`, `// FIXME:`, `// TODO:`, `// CONCERN:`, `// OPTIMIZE:`.

## Think Before Coding
**No assumptions. No hidden confusion. Surface tradeoffs.**
- **State assumptions:** Do this before coding. Genuinely blocked? Stop → name the confusion → ask.
- **Ask only when it pays:** Ask when blocked, or when a choice is costly / hard to reverse. Otherwise pick the sane default, act, and state the call in one line. Don't stall on reversible decisions.
- **Surface tradeoffs:** On real forks, present options → let human pick. No silent high-stakes choices.
- **Push back:** Not a yes-machine. Bad human approach? Explain downside → propose alternative. Accept override.
- **Attack the premise:** After two failed fixes that share one premise, census which actors hold the imbalance, then question the premise instead of writing a third fix that assumes it.

## Simplicity First (Lazy, Not Negligent)
**Best code = the code you never wrote. Write only what the task needs.**

Climb the ladder before writing code → stop at the first rung that works:
1. **Need it?** → No: skip it (YAGNI).
2. **Stdlib does it?** → Use it.
3. **Native platform feature?** → Use it.
4. **Installed dependency?** → Use it. No new dep for what a higher rung covers.
5. **One line?** → One line.
6. **Only then:** the minimum that works.

- **Naive → Optimize:** Build correct naive version first. Verify. Optimize later. Correctness > Performance.
- **Name the data shape first:** before writing logic, name the types or structures the work will move through. Downstream code should become obvious from that shape.
- **Only requested features:** Build exact request. No unasked "flexibility," no speculative abstraction.
- **Duplicate > Abstraction:** No abstractions for single-use code. Stateful or branchy logic belongs in a type, a table, or a state machine — not a growing if-chain.
- **Validate at trust boundaries:** user input, external API — and not internal glue. Make illegal states unrepresentable at those boundaries.
- **Build the lever:** non-trivial bulk work (migrations, sweeps, similar edits) is a rerunnable script or codemod, not a pile of hand edits.
- **Refine:** 200 lines → 50 lines.
- **NEVER cut [non-negotiable]:** trust-boundary validation, data-loss handling, security, accessibility. Code stays small because it is *necessary*, not golfed.

## Surgical Changes & Code Discipline
**Touch only what is needed. Clean your own mess.**
- **Fix cause, not symptom:** Change must trace directly to request. Do not add a guard that silences a crash; reproduce, then fix the cause.
- **Leave adjacent code alone:** No side-effect refactoring or formatting tweaks. Redesign from first principles only when the new requirement **invalidates** the current shape.
- **Match existing style:** Always.
- **Explain "Why":** Articulate, clear inline comments or JSDoc for *why*, not *what* (Standard Mode).
- **Dead code hygiene:** List unreachable code after refactor. Ask to delete. No silent corpses. Remove dead weight **before** adding the new path. When reshaping an internal API, migrate callers and delete the old path in the same change.

## Filesystem, Environment & Execution
- **Strict filesystem:** Ask before creating files. No `.md` unless instructed.
- **Windows-safe commands:** Avoid `&&`. Use separate lines/scripts. Use PowerShell.
- **Protect secrets [CRITICAL]:** Never commit `.env`, credentials, API keys.
- **Env vars:** Update `.env.example` in same change. Comment purpose, format, source.

## Goal-Driven Execution & Validation
**Tests = safety net. Changesets = record.**
- **Test-first:** Complex logic? Write failing test → implement → pass. Show both.
- **Establish criteria:** - Validation: failing test → pass.
  - Bug: failing reproduction → pass.
  - Refactor: pass before → pass after.
- **Prove it on the real artifact:** run the feature, read the actual value, inspect the diff. Compiling, a delegate summary, or "it looks right" is not proof.
- **Sequence verifiable units:** multi-step work checks each unit before the next. Do not batch verification at the end.
- **Minimize reader load:** a competent reader should answer "where does X come from?" in thirty seconds. Collapse one-caller wrappers and shrink mutable scope.
- **Skipped tests:** Explain in chat, not code comments.

## Change Log Maintenance
**Maintain human-readable history (Standard Mode - No Caveman).**
- **Version:** SemVer ([Major].[Minor].[Patch]).
- **Grouping:** `[Unreleased]` on top; group entries under `Features` / `Fixes` / `Changes`. A project changelog rule (e.g. `rules/changelog.mdc`), if present, is authoritative.
- **Chronological:** Newest top.
- **Human-Centric:** Clear, articulate impact descriptions. No pure technical logs. 
- **Atomic:** Update `CHANGELOG.md` in same commit/PR.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.