check-downstream-consumers

Name: check-downstream-consumers
Author: flutter

2.7kstars159forks

How to install check-downstream-consumers?

flutter/agent-plugins/check-downstream-consumers

$npx -y skills add flutter/agent-plugins --skill check-downstream-consumers

Installs into the current project.

Summary

Validates an in-progress PR or feature branch of dart_skills_lint against known downstream ecosystem consumers. Use when assessing breaking changes across external repositories during PR evaluation, testing migrations against the changelog, or determining necessary backwards comp

Files · 1

View on GitHub

SKILL.md

1	# Check Downstream Consumers & Evaluate Breaking Changes
2
3	> [!IMPORTANT]
4	> No Downstream Commits Allowed
5	> This skill is focused entirely on evaluating breaking changes within `dart_skills_lint` during PR review and changelog validation. All modifications applied to downstream consumer repositories (such as temporarily editing `pubspec.yaml` `ref:` hashes or updating calling syntax to verify migrations) are strictly diagnostic and transient. You must never stage, commit, or push code inside external downstream repositories during this workflow.
6
7	## 1. Preparation & Repository Verification
8
9	1. Verify Local Linter State (`dart_skills_lint`)
10	- Ensure your working directory in `dart_skills_lint` is clean (`git status`).
11	- Verify all existing tests pass cleanly (`dart test`).
12	- Push current commits to the remote branch so downstream consumers can resolve git hashes directly via the network.
13	- Record the latest remote git SHA-1 commit hash (e.g., `1e1f280...`).
14
15	2. Locate & Check Out Downstream Consumers
16	- Read [`resources/known_consumers.md`](resources/known_consumers.md) to review typical consumer repositories (`flutter/flutter`, `flutter/devtools`, `dart-lang/site-www`, etc.) and their specific consumption subdirectories.
17	- Discovering Local Checkouts: If you do not already know the exact directory paths where these consumer repositories live on disk:
18	1. Check Workspace Knowledge: Inspect active workspace definitions and machine-specific local Knowledge Items (`KIs`), which frequently record configured system directory structures.
19	2. Inspect Adjacent Parent Directories: Check common sibling paths right around your current repository root (for example, listing adjacent directories under `..` or running localized, depth-limited searches like `find .. -maxdepth 3 -name pubspec.yaml`).
20	3. Ask Before Running Blind Traversals: Never execute unbounded root filesystem sweeps (`find / -name ...`). If a target repository cannot be found within adjacent workspace boundaries, immediately ask the user whether the repository is checked out locally and prompt for its path before evaluating.
21	- For every target checked out on disk, verify its git state is clean and resting on its primary upstream branch (`main` or `master`). Do not run tests against dirty or out-of-date branches.
22
23	---
24
25	## 2. Pointing Consumers to the In-Progress Hash
26
27	For each downstream consumer under evaluation:
28
29	1. Update `pubspec.yaml`
30	- Locate the target's relevant dependency specification (e.g., `dev/tools/pubspec.yaml` or `tool/pubspec.yaml`).
31	- Update the `ref:` field under the `git` configuration for `dart_skills_lint` to exact match the in-progress commit hash:
32	```yaml
33	dart_skills_lint:
34	git:
35	url: https://github.com/flutter/agent-plugins
36	path: tool/dart_skills_lint
37	ref: <LATEST_COMMIT_HASH>
38	```
39
40	2. Resolve Dependencies & Run Verification Tests (Legacy Check)
41	- Execute dependency resolution according to the consumer environment (Flutter workspaces require `flutter pub get`; standard pure Dart repositories require `dart pub get`).
42	- Run the consumer's verification tests against their existing code (typically targeting tests like `test/validate_skills_test.dart` or running `flutter test` / `dart test`).
43	- Confirm that all existing tests and static analyses compile and pass cleanly when using their established calling syntax. This ensures backward-compatibility deprecation shims function properly right alongside legacy calling conventions.
44
45	3. Perform Diagnostic API Migration & Boundary Verification
46	After verifying across each target consumer that legacy calls function properly without regressions in Step 2:
47	- Migrate Consumer Calling Syntax: For every repository in the set of downstream targets under evaluation (whether a single target, a requested subset, or all known consumers), update its codebase to remove any usage of deprecated getters, parameters, or constructors directly, replacing them with the new API surface introduced in `dart_skills_lint` (for example, transitioning `resolvedRules` arguments to `resolvedRuleConfigs`).
48	- Verify Public Boundary Resolution: Execute strict static analysis (`dart analyze --fatal-infos <modified_test_or_package_path>`) within the consumer's package directory after completing the migration.
49	- Confirm that all newly exposed classes and parameters resolve cleanly through the public library barrier (`import 'package:dart_skills_lint/dart_skills_lint.dart';`).
50	- Any syn

People who liked this also viewed

6 picks

Type

check-downstream-consumers

2.7kstars159forks

View on GitHub

How to install check-downstream-consumers?

flutter/agent-plugins/check-downstream-consumers

$npx -y skills add flutter/agent-plugins --skill check-downstream-consumers

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Check Downstream Consumers & Evaluate Breaking Changes
2
3	> [!IMPORTANT]
4	> No Downstream Commits Allowed
5	> This skill is focused entirely on evaluating breaking changes within `dart_skills_lint` during PR review and changelog validation. All modifications applied to downstream consumer repositories (such as temporarily editing `pubspec.yaml` `ref:` hashes or updating calling syntax to verify migrations) are strictly diagnostic and transient. You must never stage, commit, or push code inside external downstream repositories during this workflow.
6
7	## 1. Preparation & Repository Verification
8
9	1. Verify Local Linter State (`dart_skills_lint`)
10	- Ensure your working directory in `dart_skills_lint` is clean (`git status`).
11	- Verify all existing tests pass cleanly (`dart test`).
12	- Push current commits to the remote branch so downstream consumers can resolve git hashes directly via the network.
13	- Record the latest remote git SHA-1 commit hash (e.g., `1e1f280...`).
14
15	2. Locate & Check Out Downstream Consumers
16	- Read [`resources/known_consumers.md`](resources/known_consumers.md) to review typical consumer repositories (`flutter/flutter`, `flutter/devtools`, `dart-lang/site-www`, etc.) and their specific consumption subdirectories.
17	- Discovering Local Checkouts: If you do not already know the exact directory paths where these consumer repositories live on disk:
18	1. Check Workspace Knowledge: Inspect active workspace definitions and machine-specific local Knowledge Items (`KIs`), which frequently record configured system directory structures.
19	2. Inspect Adjacent Parent Directories: Check common sibling paths right around your current repository root (for example, listing adjacent directories under `..` or running localized, depth-limited searches like `find .. -maxdepth 3 -name pubspec.yaml`).
20	3. Ask Before Running Blind Traversals: Never execute unbounded root filesystem sweeps (`find / -name ...`). If a target repository cannot be found within adjacent workspace boundaries, immediately ask the user whether the repository is checked out locally and prompt for its path before evaluating.
21	- For every target checked out on disk, verify its git state is clean and resting on its primary upstream branch (`main` or `master`). Do not run tests against dirty or out-of-date branches.
22
23	---
24
25	## 2. Pointing Consumers to the In-Progress Hash
26
27	For each downstream consumer under evaluation:
28
29	1. Update `pubspec.yaml`
30	- Locate the target's relevant dependency specification (e.g., `dev/tools/pubspec.yaml` or `tool/pubspec.yaml`).
31	- Update the `ref:` field under the `git` configuration for `dart_skills_lint` to exact match the in-progress commit hash:
32	```yaml
33	dart_skills_lint:
34	git:
35	url: https://github.com/flutter/agent-plugins
36	path: tool/dart_skills_lint
37	ref: <LATEST_COMMIT_HASH>
38	```
39
40	2. Resolve Dependencies & Run Verification Tests (Legacy Check)
41	- Execute dependency resolution according to the consumer environment (Flutter workspaces require `flutter pub get`; standard pure Dart repositories require `dart pub get`).
42	- Run the consumer's verification tests against their existing code (typically targeting tests like `test/validate_skills_test.dart` or running `flutter test` / `dart test`).
43	- Confirm that all existing tests and static analyses compile and pass cleanly when using their established calling syntax. This ensures backward-compatibility deprecation shims function properly right alongside legacy calling conventions.
44
45	3. Perform Diagnostic API Migration & Boundary Verification
46	After verifying across each target consumer that legacy calls function properly without regressions in Step 2:
47	- Migrate Consumer Calling Syntax: For every repository in the set of downstream targets under evaluation (whether a single target, a requested subset, or all known consumers), update its codebase to remove any usage of deprecated getters, parameters, or constructors directly, replacing them with the new API surface introduced in `dart_skills_lint` (for example, transitioning `resolvedRules` arguments to `resolvedRuleConfigs`).
48	- Verify Public Boundary Resolution: Execute strict static analysis (`dart analyze --fatal-infos <modified_test_or_package_path>`) within the consumer's package directory after completing the migration.
49	- Confirm that all newly exposed classes and parameters resolve cleanly through the public library barrier (`import 'package:dart_skills_lint/dart_skills_lint.dart';`).
50	- Any syn

People who liked this also viewed

6 picks

Type