reviewing-devtools-prs

作成者: flutter

DevTools repository-specific PR review workflow enforcing DevTools style guidelines and common review patterns. Use when reviewing pull requests in the…

npx skills add https://github.com/flutter/devtools --skill reviewing-devtools-prs

Reviewing DevTools Pull Requests

Extends reviewing-prs for pull requests in flutter/devtools. Follow reviewing-prs for GitHub CLI data retrieval and the strict user approval workflow.

References & Style Guidelines

Read and enforce:

  • Style Guide: styleguide.md (severity tags [MUST-FIX], [CONCERN], [NIT], zero-formatting policy, copyright headers, DRY rules, magic values)
  • Repository Constraints: AGENTS.md
  • Code Style: 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 if a user-facing PR lacks one.

flutterのその他のスキル

adding-release-notes
flutter
DevToolsのリリースノートにユーザー向けの変更説明を追加します。NEXT_RELEASE_NOTES.mdファイルに改善点、修正、新機能を文書化する際に使用します。
official
dart-modern-features
flutter
モダナイゼーションの候補を見つけるには:
official
api-review
flutter
指定されたコードを標準的なAPI設計ガイドラインに照らしてレビューします。ユーザーがAPIレビューを依頼した場合や、コードをAPI設計に照らして確認したい場合にこのスキルを使用します。
official
code-documentation
flutter
効果的なコードドキュメントを書くためのガイド。docstring、JSDoc、dartdoc、実装コメントを含む。新しいコードを書く際や追加する際にこのスキルを使用する。
official
dart-add-unit-test
flutter
Write and organize unit tests for functions, methods, and classes using `package:test`. Use when creating new logic or fixing bugs to ensure code remains…
official
dart-build-cli-app
flutter
エントリポイント構造、終了コード、クロスプラットフォームのスクリプト。コマンドラインユーティリティ、スクリプト、またはアプリケーションを構築する際に使用します。
official
dart-collect-coverage
flutter
coverageパッケージを使用してカバレッジを収集し、LCOVレポートを作成します
official
dart-fix-runtime-errors
flutter
get_runtime_errors と lsp を使用してアクティブなスタックトレースを取得し、失敗している行を特定して修正を適用し、hot_reload で解決を確認します。
official