LuanCesarDCLuanCesarDC/dart-sentinel/.github/copilot-instructions.md

dart-sentinel

Copilot instructions1 starsChanged 8 months agoMITView on GitHub

Architecture is enforced by Dart Sentinel (analyzer.yaml). The AI agent has access to Sentinel via MCP. Treat Sentinel violations as compile errors — never ignore them.

Where files are headingNew Copilot instructions files have more rules about branches and pull requests, and fewer about code style.
Of the Copilot instructions files we read, the 2,336 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.
- CLAUDE.mdCLAUDE.md
- .cursor/rules/sentinel.mdcCursor rule

The file

We split this copilot-instructions.md into the rules it gives an agent

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

≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
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:
Before writing code: call get_architecture to read layer boundaries.
line 34
Very specific:
Before adding an import: call check_import to verify it's allowed.
line 35
Very specific:
After creating/modifying a file: call analyze_file to check for violations.
line 36
Very specific:
Before a big refactor: call impact_analysis to understand blast radius.
line 38
Distinctive:
No empty catch blocks — handle, rethrow, or document why
line 61
Very specific:
No generic names (data, result, value, temp, item)
line 63
Distinctive:
No commented-out code blocks
line 64
Distinctive:
No magic numbers — extract to named constants
line 65
Distinctive:
No duplicate if/else branches
line 66

≈ “Common” is an estimate: at least 1 in 5 of the 3,779 Copilot instructions 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

copilot-instructions.md

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

Before writing code: call get_architecture to read layer boundaries.
Before adding an import: call check_import to verify it's allowed.
After creating/modifying a file: call analyze_file to check for violations.
Fix ALL issues before moving on — treat violations as compile errors.
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.

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.

Check your setup, free