feat(flutter-cursor-templates): introduce MCP integration and conventions in project brief

- Added optional MCP integration settings in project-brief.yaml, allowing for environment-based server configurations.
- Introduced conventions for strict package imports to enhance code organization and maintainability.
- Updated brief schema to validate new MCP properties and ensure correct usage.
- Implemented MCP JSON builder to generate .cursor/mcp.json based on project brief settings.
- Enhanced resolver to include MCP configuration in generated files when enabled.

This update improves integration capabilities and enforces coding standards across the project.
This commit is contained in:
2026-05-14 13:33:13 +05:30
parent 2ee257c630
commit da64f769da
109 changed files with 2076 additions and 85 deletions
@@ -1,6 +1,7 @@
---
description: "Core Flutter conventions for {{PROJECT_NAME}} — always applied"
alwaysApply: true
description: "Core Flutter conventions for {{PROJECT_NAME}}"
globs: ["lib/**/*.dart", "test/**/*.dart", "integration_test/**/*.dart"]
alwaysApply: false
---
# Flutter Core Standards — {{PROJECT_NAME}}
@@ -29,10 +30,7 @@ alwaysApply: true
- Private members: `_camelCase`
## Imports
- Order: dart: → package: → relative
- Use relative imports within a feature; absolute for cross-feature
- Never import a feature's internal files from outside that feature
{{IMPORT_POLICY_BLOCK}}
## Code quality
- Max function length: 40 lines. Extract widgets and helpers aggressively
- No `print()` in production code — use a logging package
@@ -1,6 +1,7 @@
---
description: "Project context for {{PROJECT_NAME}} — always applied"
alwaysApply: true
description: "Stack summary and product context for {{PROJECT_NAME}}"
globs: ["project-brief.yaml", ".cursor/**/*.md", ".cursor/**/*.mdc", "pubspec.yaml"]
alwaysApply: false
---
# Project Context — {{PROJECT_NAME}}
@@ -0,0 +1,24 @@
---
description: How Cursor rules in this repository must be written and maintained.
globs: [".cursor/rules/**/*.mdc"]
alwaysApply: true
---
# Rule authoring — {{PROJECT_NAME}}
## Context
Rules are version-controlled contracts for AI assistants. Poor rules waste context and silently steer every edit.
## Constraints
- One focused concern per file; split broad topics instead of one mega-rule
- Every rule MUST have a clear `description` in frontmatter (one sentence)
- Prefer `alwaysApply: false` with **narrow** `globs` for domain rules — reserve `alwaysApply: true` for meta and safety
- `globs` must be as specific as possible — never `["**/*"]` unless tooling requires it
- Code samples in rules MUST be valid for this project (Dart/Flutter/YAML as appropriate)
- Deprecated guidance is removed, not left commented out
- Each substantive rule includes **Context** (why), **Constraints** (must/must not), and where helpful **Patterns** / **Anti-patterns**
## Anti-patterns
- Domain rules (testing, l10n, a feature) with `alwaysApply: true` — burns context
- Rules with no concrete examples when the topic is code-facing
- Stale feature rules after modules are removed — run `tool/cursor_audit.sh` periodically
@@ -1,6 +1,7 @@
---
description: "UI/UX standards for {{PROJECT_NAME}} — always applied"
alwaysApply: true
description: "UI/UX standards for {{PROJECT_NAME}}"
globs: ["lib/**/*.dart", "test/**/*.dart", "integration_test/**/*.dart"]
alwaysApply: false
---
# UI / UX Standards — {{PROJECT_NAME}}