OpenCode · Dart · Flutter · Popular baseline

# OpenCode · Dart + Flutter  
Generated February 10, 2026  
Agent: OpenCode  
Language: Dart  
Framework: Flutter

## Global rules
- Start by reading existing project instructions and architecture docs before changing behavior.

- Prefer minimal diffs and preserve existing code style and naming conventions.

- State assumptions and call out risks before making breaking or cross-module changes.

- When behavior changes, add or update tests in the closest existing test layer.

- Never commit secrets, tokens, credentials, or generated private keys.

Start by reading existing project instructions and architecture docs before changing behavior.

Prefer minimal diffs and preserve existing code style and naming conventions.

State assumptions and call out risks before making breaking or cross-module changes.

When behavior changes, add or update tests in the closest existing test layer.

Never commit secrets, tokens, credentials, or generated private keys.

## Agent-specific
- Prioritize terminal-native workflows and reproducible command sequences.

- Explain intent before applying multi-file changes.

- Keep patches minimal and verify with focused checks.

## Language-specific
- Use sound null safety and avoid force unwraps in non-test code.

- Keep async flows explicit with clear cancellation/error handling.

- Separate UI state from networking and persistence logic.

## Framework-specific
- Keep widgets declarative and move business logic into state controllers.

- Avoid rebuilding large trees unnecessarily; structure by feature and state.

## Options

### Token saving rules
- Reuse shared instruction snippets instead of restating long guidance.

- Avoid duplicating context already available in repository docs.

### Testing rules
- Require tests for changed behavior or document why tests were not added.

- Run the smallest relevant test subset first, then broaden if needed.

### Code style rules
- Follow existing formatter/linter configuration.

- Avoid style-only churn in unrelated files.

### Architecture rules
- Preserve module boundaries and avoid leaking internal abstractions.

- Prefer incremental refactors over large rewrites.

### Security rules
- Validate and sanitize all user-controlled input.

- Apply least-privilege defaults for data access and actions.

### Prefer minimal diffs
- Limit changes to the smallest set of files and lines needed.

- Defer unrelated cleanup to separate follow-up changes.

### Documentation rules
- Update docs/examples whenever behavior, APIs, or setup steps change.

- Add concise release notes for user-facing or breaking changes.