- name
- reviewing-devtools-prs
- description
- DevTools repository-specific PR review workflow enforcing DevTools style guidelines and common review patterns. Use when reviewing pull requests in the flutter/devtools repository.
# Reviewing DevTools Pull Requests
Extends [reviewing-prs](../reviewing-prs/SKILL.md) for pull requests in `flutter/devtools`. Follow [reviewing-prs](../reviewing-prs/SKILL.md) for GitHub CLI data retrieval and the strict user approval workflow.
## References & Style Guidelines
Read and enforce:
- **Style Guide**: [styleguide.md](../../../.gemini/styleguide.md) (severity tags `[MUST-FIX]`, `[CONCERN]`, `[NIT]`, zero-formatting policy, copyright headers, DRY rules, magic values)
- **Repository Constraints**: [AGENTS.md](../../../AGENTS.md)
- **Code Style**: [STYLE.md](../../../STYLE.md)
## Common Review Patterns
1. **Listener & Resource Disposals**:
- Ensure controller and notifier listeners use `addAutoDisposeListener(...)`.
2. **Helper Widgets over Helper Methods**:
- Prefer small composable `Widget` classes over helper methods returning `Widget` (`_buildFoo()`).
3. **Reuse Shared Components & Test Helpers**:
- Use standard shared widgets (e.g. `CenteredMessage`) and test mocks (e.g. `mockConnectedApp`) instead of re-creating them inline.
4. **TODO Formatting**:
- Link TODOs to a GitHub issue or LDAP: `// TODO(https://github.com/flutter/devtools/issues/<issue_number>): <description>`.
5. **Async & Unawaited Futures**:
- Audit unawaited futures and suggest `unawaited(...)` or `safeUnawaited(...)` where appropriate.
6. **Feature Flags**:
- Default feature flags to `false` with explicit test expectations in `feature_flags_test.dart`.
7. **Test File Structure & PR Scope**:
- Place test fakes/helpers below `main()`.
- Ask authors to revert unrelated file changes or commented-out test code.
8. **Constant Scoping**:
- Keep single-use constants local to the component, but extract user-facing UI strings into shared constants when used across multiple places.
9. **Release Notes Scope (`NEXT_RELEASE_NOTES.md`)**:
- Release notes are strictly for end-user facing changes (e.g. Inspector, Memory UI/UX). Internal tools (`dt` / `devtools_tool`), CI, and refactors are NOT user-facing.
- Request removing release notes added for developer tools like `dt`, or suggest a `* <Description>. [#<PR_NUMBER>](https://github.com/flutter/devtools/pull/<PR_NUMBER>)` entry via [adding-release-notes](../adding-release-notes/SKILL.md) if a user-facing PR lacks one.
View on GitHub