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:
@@ -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}}
|
||||
|
||||
Reference in New Issue
Block a user