agentleFS
LuanCesarDCLuanCesarDC/dart-sentinel/.cursor/rules/sentinel.mdc

dart-sentinel / rules

Cursor rule1 starsChanged 8 months agoMITView on GitHub

Dart Sentinel architecture enforcement

  • 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 repository2 other files it gives its agents.

The file

Show its rules and text

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

16 rules. About 0 are common, 5 are distinctive, and 11 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.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before writing code: call get_architecture to read layer boundaries.

    line 40
  2. Very specific:

    Before adding an import: call check_import to verify it's allowed.

    line 41
  3. Very specific:

    After creating/modifying a file: call analyze_file to check for violations.

    line 42
  4. Very specific:

    Before a big refactor: call impact_analysis to understand blast radius.

    line 44
  5. Distinctive:

    No empty catch blocks — handle, rethrow, or document why

    line 67
  6. Very specific:

    No generic names (data, result, value, temp, item)

    line 69
  7. Distinctive:

    No commented-out code blocks

    line 70
  8. Distinctive:

    No magic numbers — extract to named constants

    line 71
  9. Distinctive:

    No duplicate if/else branches

    line 72
  10. Very specific:

    Call get_architecture from dart-sentinel MCP to read layers and constraints.

    line 88
  11. Very specific:

    Call check_import with the source file path and the import URI.

    line 91
  12. Distinctive:

    If it returns a violation, find an alternative.

    line 92
  13. Very specific:

    Call analyze_file with the file path.

    line 95
  14. Very specific:

    Call generate_model_scaffold with class name and fields to get copyWith, toMap, fromMap, ==, hashCode, toString.

    line 115
  15. Very specific:

    Call generate_test_scaffold with the source file path to get test stubs for all public methods.

    line 118
  16. Very specific:

    Call impact_analysis with the file(s) you plan to change.

    line 121

≈ “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
sentinel.mdc
---
description: Dart Sentinel architecture enforcement
globs: ["**/*.dart", "analyzer.yaml"]
alwaysApply: true
---

# Project Instructions

Architecture is enforced by **Dart Sentinel** (`analyzer.yaml`). The AI agent has access to Sentinel via MCP.

## Architecture

- **utils**: `lib/src/utils/**` → (no deps)
- **core**: `lib/src/core/**, lib/src/config/**` → utils
- **analysis**: `lib/src/analysis/**` → core, utils
- **rules**: `lib/src/rules/**` → core, utils
- **output**: `lib/src/output/**` → core
- **mcp**: `lib/src/mcp/**` → core, rules, analysis, utils

## Import Restrictions
- Rules must be independent — don't import other rule files.
- Output formatters must not depend on rule implementations.
- Utils must be pure algorithms — no I/O or internal dependencies.
- Rules must not use dart:io — use ProjectContext for file data.

## Thresholds
- Cyclomatic complexity: warning 10, error 20
- Lines per file: warning 300, error 600
- Lines per method: warning 50, error 100
- Max parameters: warning 5, error 7
- Max nesting: warning 4, error 6
- Build method LOC: warning 30, error 60
- Build method branches: warning 3, error 6
- Methods per class: warning 15, error 30
- Weighted methods per class: warning 30, error 80
- Lines per class: warning 300, error 600

## Workflow — MANDATORY for every task

1. **Before writing code**: call `get_architecture` to read layer boundaries.
2. **Before adding an import**: call `check_import` to verify it's allowed.
3. **After creating/modifying a file**: call `analyze_file` to check for violations.
4. Fix ALL issues before moving on — treat violations as compile errors.
5. **Before a big refactor**: call `impact_analysis` to understand blast radius.

## MCP Tools (dart-sentinel server)

| Tool | When to use |
|------|-------------|
| `get_architecture` | Before any architectural decision |
| `check_import` | Before adding any cross-layer import |
| `analyze_file` | After every file create/edit |
| `analyze` | Full project scan |
| `impact_analysis` | Before refactoring |
| `dependency_map` | Visualize module structure |
| `generate_model_scaffold` | Create model with copyWith, toMap, fromMap, ==, hashCode |
| `generate_model_update` | Add fields to existing model |
| `generate_test_scaffold` | Generate test stubs for a file |
| `scan_hardcoded_strings` | Find hardcoded UI strings |
| `l10n_status` | Check translation coverage |
| `generate_l10n` | Write ARB translation files |
| `migrations` | Track banned-symbol migration progress |

## Code Quality

- Dispose all resources (StreamSubscription, TextEditingController, AnimationController)
- No empty catch blocks — handle, rethrow, or document why
- No `setState`/`context` after `await` without `mounted` check
- No generic names (`data`, `result`, `value`, `temp`, `item`)
- No commented-out code blocks
- No magic numbers — extract to named constants
- No duplicate if/else branches

**Treat Sentinel violations as compile errors — never ignore them.**

---
applyTo: "**/*.dart"
---

# Dart Sentinel — Checks for Dart files

## Active Rules
- **Errors** (block CI): `banned-imports`, `layer-dependency`
- **Warnings**: `import-cycles`, `feature-isolation`, `dead-files`, `dead-exports`, `unused-code`, `complexity`, `build-complexity`, `class-metrics`, `dispose-check`, `async-safety`, `empty-catch`, `generic-naming`, `lazy-null-check`, `no-equal-then-else`, `no-equal-arguments`, `avoid-self-compare`, `avoid-global-state`, `avoid-returning-widgets`, `flutter-anti-patterns`, `test-quality`, `pubspec`
- **Info**: `dead-todos`, `redundant-comments`, `verbose-logging`, `single-method-class`, `passthrough-function`, `avoid-commented-out-code`, `no-magic-number`, `untested-files`, `misused-dependencies`, `model-missing-methods`

## Before writing code
- Call `get_architecture` from dart-sentinel MCP to read layers and constraints.

## Before adding any import
- Call `check_import` with the source file path and the import URI.
- If it returns a violation, find an alternative.

## After creating or modifying any Dart file
- Call `analyze_file` with the file path.
- Fix ALL violations before considering the task done.

### How to fix common violations

| Violation | Fix |
|-----------|-----|
| `layer-dependency` | You imported from a forbidden layer. Move the import or restructure. |
| `banned-imports` | This import is explicitly forbidden. Read the message for the reason. |
| `complexity` | Method too complex. Extract helpers or simplify conditionals. |
| `empty-catch` | Add error handling: `rethrow`, log the error, or add a `// deliberate` comment. |
| `generic-naming` | Rename `data`/`result`/`item` to something domain-specific. |
| `dispose-check` | Add `subscription.cancel()` or `controller.dispose()` in `dispose()`. |
| `async-safety` | Add `if (!mounted) return;` after the `await`. |
| `unused-code` | Remove the unused declaration, or export it if it's public API. |
| `no-magic-number` | Extract `42` to `const _maxRetries = 42;`. |
| `no-equal-then-else` | The if and else branches are identical — remove the conditional. |
| `avoid-global-state` | Move top-level `var` into a class or make it `final`. |

## When creating a model class
- Call `generate_model_scaffold` with class name and fields to get `copyWith`, `toMap`, `fromMap`, `==`, `hashCode`, `toString`.

## When creating tests
- Call `generate_test_scaffold` with the source file path to get test stubs for all public methods.

## When refactoring
- Call `impact_analysis` with the file(s) you plan to change.
- Review the blast radius before making breaking changes.

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.