Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/Consiliency/Flutter-StructurizrWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/consiliency/flutter-structurizr/parser-and-test-consistency)<a href="https://agentmods.dev/rules/consiliency/flutter-structurizr/parser-and-test-consistency"><img src="https://agentmods.dev/badge/rules/consiliency/flutter-structurizr/parser-and-test-consistency/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/rules/consiliency/flutter-structurizr/parser-and-test-consistency"><img src="https://agentmods.dev/badge/rules/consiliency/flutter-structurizr/parser-and-test-consistency.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.00527 |
| Opus 5.5 | $0.00000 | $0.00211 |
| Sonnet 5.5 | $0.00000 | $0.00105 |
| Haiku 4.5 | $0.00000 | $0.00053 |
Grade A, and why
parser-and-test-consistency scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 40 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Parser and Test Consistency Rules
These rules ensure robust, maintainable, and consistent parser code and tests for Structurizr DSL parsing.
1. Use the Properties Map for Extensible Attributes
- All extensible or user-defined attributes (e.g.,
description,tags, custom properties) must be set and accessed via thepropertiesmap on model nodes. - Do not attempt to set or mutate
finalfields likedescriptionortagsdirectly after construction. - See model_element_node.dart
2. Test Assertions Should Use the Properties Map
- In tests, always check for attribute values using
node.properties?['key']rather than direct field access, unless the field is explicitly non-extensible and public. - See element_parser_test.dart
3. Context Stack Setup for Block/Property Parsing
- Before calling
parseParentChildor similar methods that set properties, push a context with the relevant node ascurrentElementonto theContextStack. - Always pop the context after the test to avoid stack contamination.
- See context_stack.dart
4. ErrorReporter Initialization in Tests
- When constructing an
ErrorReporterin tests, use a non-empty string (e.g.,' ' * 1000) to avoid out-of-bounds errors when reporting errors at specific offsets. - See error_reporter.dart
5. No Monkey-Patching or Method Overrides in Dart Tests
- Dart does not allow replacing methods or properties at runtime. Use subclassing, dependency injection, or test doubles if you need to intercept or mock behavior.
6. Parser Methods Should Not Mutate Node Fields After Construction
- All node fields that are
finalmust be set only in the constructor. Use thepropertiesmap for any dynamic or extensible data.
7. Keep Test Imports Canonical and Up-to-Date
- Always import node types and utility classes from their canonical files (e.g.,
model_element_node.dart,source_position.dart). - Remove imports of deleted or obsolete files.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 40 lines · 0 tokens per session scan A e719a3c6a2d2
parser-and-test-consistency is a cursor rule published in the GitHub repository Consiliency/Flutter-Structurizr (7 stars, last pushed 3mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 527 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other cursor rules, from other repositories
python_tests
We use the unit tests to cover internal behavior that can work without the web / backend counterpart. We aim for 95%+ unit test coverage of our Python code in lib/streamlit.
provider-devin
Devin transport framing, identity, and response semantics.
architecture
This document outlines the fundamental architectural principles and patterns for the mcp-debug codebase. Adherence to these guidelines is mandatory to maintain a clean, decoupled, and testable system.
create-a-testable-http-client-service
Cursor rule "create-a-testable-http-client-service" from PaulJPhilp/EffectPatterns, covering create a testable http client service, example, 1. define the service, 2. create the live implementation and 3. create the test implementation.
websockets
Real-time over WebSockets end to end, SocketRouter and wsEmit on the backend, socketSdk with useListener and useEmitter on the client, auth on upgrade, testing.
api-design
API design guidelines — REST principles, GraphQL patterns, versioning, pagination, error handling, documentation, security, caching, and testing. Applied when designing or reviewing API endpoints.