{"owner":"dart-lang","repo":"sdk","hasSkills":true,"totalSkillsCount":30,"totalTokensCount":17395,"categories":["anthropic-skill","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":[".agents/skills/update-dependency/SKILL.md",".agents/skills/read-gerrit-cl/SKILL.md",".agents/skills/find-release-for-commit/SKILL.md",".agents/skills/dart-aot-development/SKILL.md",".agents/skills/update-native-rev/SKILL.md","pkg/analysis_server/.agents/skills/close-obsolete-issues/SKILL.md","runtime/tools/pubspec.yaml",".agents/rules/add_license_header.md","pkg/analysis_server/.agents/skills/improve-performance-with-session-log/SKILL.md","pkg/dart2js_tools/README.md","pkg/dds_service_extensions/README.md","pkg/analysis_server/.agents/skills/implement-a-lint/SKILL.md","runtime/tools/dartfuzz/README.md","runtime/tools/dartfuzz/README_minimize.md","runtime/tools/dartfuzz/analysis_options.yaml","runtime/tools/dartfuzz/pubspec.yaml","runtime/tools/entitlements/README.md","runtime/tools/heapsnapshot/CHANGELOG.md","runtime/tools/heapsnapshot/README.md","runtime/tools/heapsnapshot/pubspec.yaml","runtime/tools/profiling/CHANGELOG.md","runtime/tools/profiling/README.md","runtime/tools/profiling/analysis_options.yaml","runtime/tools/profiling/pubspec.yaml","runtime/tools/wiki/README.md","pkg/linter/test/rules/analysis_options.yaml","pkg/front_end/testcases/extensions/as_show/libraries.json","pkg/front_end/testcases/extensions/patch/libraries.json","pkg/front_end/testcases/extensions/patching/libraries.json","pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md"],"skills":{".agents/skills/update-dependency/SKILL.md":"---\nname: update-dependency\ndescription: Updates third party dependencies in the Dart SDK\n---\n\n# Instructions\n\nUse this skill to update dependencies in the Dart SDK's `DEPS` file to their\nlatest (or a specific) version. This tool automates the process of updating\nthe version, syncing dependencies, updating package configurations, and\ncreating a CL.\n\n## Prerequisites\n\nBefore running the tool, ensure your environment is prepared correctly:\n\n1. **Clean Git State**: Your git checkout MUST be clean. No uncommitted\n changes should be present.\n2. **On Main Branch**: You MUST be on the `main` branch. The tool creates a\n new branch from your current HEAD, so being on `main` ensures the bump\n starts from a clean baseline.\n\n## Tool Usage\n\nRun the `tools/manage_deps.dart` script with the `bump` command from the root\nof the SDK.\n\n### Command Syntax\n\n```bash\ndart tools/manage_deps.dart bump \\\n [--branch ] [--target ]\n```\n\n### Arguments\n\n1. `` (required): The path to the dependency directory\n relative to the SDK root. Dependencies are entire repositories and not\n packages, so the path will usually be `third_party/pkg/`.\n - **CRITICAL**: DO NOT include a trailing slash in the path.\n - If unsure of the repository, you can look at the\n `.dart_tool/package_config.json` file relative to the SDK root, and search\n for `\"name\": \"\"`. Next to that you should see a \"rootUri\"\n key which will give you the path to the dependency. Do not use the full\n path though, just the top level directory under `third_party/pkg/`,\n since entire repos are always rolled at once.\n - If the `.dart_tool/package_config.json` file does not exist, it can be\n generated by running `gclient sync`.\n2. `--branch ` (optional): The name of the branch to create for\n this update. Defaults to `bump_`.\n3. `--target ` (optional): The specific git ref (SHA, tag, branch) to\n update to. Defaults to the latest version on the remote's default branch.\n\n## Example\n\nTo bump the `unified_analytics` dependency, which is a part of the `tools` repo:\n\n```bash\ndart tools/manage_deps.dart bump third_party/pkg/tools\n```\n\n## Troubleshooting\n\n- **\"Already at - nothing to do\" (or missing recent GitHub commit)**:\n The dependency is already at the latest version on the mirror, or the\n `dart.googlesource.com` mirror has not yet synced a recently merged GitHub\n commit.\n - **For Googlers**: If a commit recently landed on GitHub (check with\n `git ls-remote https://github.com//.git refs/heads/main`, where\n `` is typically `dart-lang`) but is not yet on\n `https://dart.googlesource.com/.git`, trigger an immediate mirror\n fetch:\n ```bash\n gob-ctl repos update-mirror-config github// \\\n --fetch_frequency 5m \\\n --uri https://github.com//.git\n ```\n Wait ~10 seconds, verify with\n `git ls-remote https://dart.googlesource.com/.git refs/heads/main`,\n and rerun `tools/manage_deps.dart`.\n- **Branch already exists**: If the tool says a branch with the target name\n already exists, you will be prompted to delete it. Usually, it is safe to say\n \"y\" if you want a fresh bump.\n- **\"CorpSSO login required. To log in, run glogin or gcert\"**: This indicates a\n Google-internal SSO authentication failure during fetching/syncing\n dependencies. This error and the suggested fix (`gcert` / `glogin`) are only\n applicable for Googlers. Since this requires interactive authentication, you\n must ask the user to run `gcert` (or `glogin`) in their terminal to\n authenticate, and then retry.\n",".agents/skills/read-gerrit-cl/SKILL.md":"---\nname: read-gerrit-cl\ndescription: Fetch and display the full patch/diff or comments for a Gerrit CL.\n---\n\n# Instructions\n\nUse this skill to inspect a Gerrit Change List (CL).\nThis is useful for reviewing code changes, understanding the scope of a modification, checking comments.\n\n## Requirements\n\nThe following command-line tools are required:\n\n- `curl`: For making HTTP requests.\n- `jq`: For parsing JSON (needed for comments).\n- `base64`: For decoding patch content (needed for patches).\n\n## Scripts\n\n### 1. Read Patch\n\nRun the `read_patch.sh` script to fetch the unified diff of a CL.\n\n#### Usage\n\n```bash\n./scripts/read_patch.sh [patchset]\n```\n\n#### Arguments\n\n1. `change_number`: The numeric ID of the Gerrit change (e.g., `12345`).\n2. `patchset` (optional): The patchset number or `current` (default).\n\n#### Example\n\nTo fetch the patch for CL 12345 (latest revision):\n\n```bash\n./scripts/read_patch.sh 12345\n```\n\nTo fetch a specific revision (e.g. patchset 2):\n\n```bash\n./scripts/read_patch.sh 12345 2\n```\n\nThe output will be the unified diff format of the patch.\n\n### 2. Read Comments\n\nRun the `read_comments.sh` script to fetch the comments on a CL.\n\n#### Usage\n\n```bash\n./scripts/read_comments.sh \n```\n\n#### Arguments\n\n1. `change_number`: The numeric ID of the Gerrit change (e.g., `12345`).\n\n#### Example\n\nTo fetch comments for CL 12345:\n\n```bash\n./scripts/read_comments.sh 12345\n```\n\nThe output will be a JSON object containing the comments.\n",".agents/skills/find-release-for-commit/SKILL.md":"---\nname: find-release-for-commit\ndescription: Find which Dart/Flutter releases contain a specific commit sha.\n---\n\n# Instructions\n\nUse this skill to determine which releases a specific commit SHA (Dart or Flutter) first appeared in.\nThis is useful for identifying the earliest SDK version that includes a given feature, fix, or change.\n\n## Tool Usage\n\nRun the `tools/find_release.dart` script from the root of the SDK (`../../../` relative to this file) to discover the releases for a given commit SHA.\n\n```bash\ndart tools/find_release.dart --commit= --channel=\n```\n\n### Arguments\n\n1. `--commit=` (required): The SHA of the commit.\n2. `--channel=` (required): The channel to search in.\n\n### Example\n\nTo find which releases contain commit `abcdef123...` on the `stable` channel:\n\n```bash\ndart tools/find_release.dart --commit=abcdef123... --channel=stable\n```\n\nThe output will include:\n\n- Whether the commit was found in the Dart or Flutter repository.\n- The lowest (earliest) git release tag containing that commit.\n- The corresponding official Flutter release (if found).\n- The corresponding official Dart SDK release (if found).\n\n## Important Considerations\n\n- **Git Tags vs. Official Releases**: The tool first identifies the lowest git tag that includes the commit. However, the presence of a tag (especially a `-dev` tag) **does not guarantee that an official SDK release has being published for that version.**\n- **Verification**: You should look for the \"Lowest Dart release\" or \"Lowest Flutter release\" in the tool's output to confirm that the commit has actually reached a released state. If the tool reports \"No Dart releases found that were newer than \", then the commit has not yet reached any official released version on that channel.\n- **Reporting**: When communicating the findings, distinguish clearly between the git tag it first appeared in and the earliest official release (if any).\n",".agents/skills/dart-aot-development/SKILL.md":"---\nname: dart-aot-development\ndescription: Instructions on building and testing changes using Dart AOT mode. Use when working on Dart runtime, Dart AOT compiler or other related components.\n---\n\n# Testing changes to Dart SDK in AOT mode\n\nIf you are making changes to Dart SDK (including but not limited to modifying\nDart VM runtime, Dart VM compiler pipeline, Dart common front-end, Dart type\nflow analysis, etc) and you want to test the changes in AOT mode, you should\nuse the following instructions.\n\n1. Build `gen_snapshot`, `vm_platform.dill` and `dartaotruntime` targets using the following command `tools/build.py -m $MODE -a $ARCH --rbe gen_snapshot vm_platform.dill dartaotruntime`. Here `$MODE` specifies preferred compilation mode (`debug` or `release`), `$ARCH` specifies target architecture (e.g. `x64`, `arm64`). Prefer building using `release` mode and prefer using `$ARCH` that matches the host\nunless something else is requested. A combination of `$MODE` and `$ARCH` is called `DART_CONFIGURATION` (e.g. `ReleaseX64` is `release` build targeting `x64`).\n2. Use helper script `pkg/vm/tool/precompiler2 test.dart test.aot` to compile test script `test.dart` to AOT snapshot `test.aot`. To check commands executed by the script you can pass `-v` to the script.\n3. Use `out/${DART_CONFIGURATION}/dartaotruntime test.aot` to execute AOT snapshot.\n4. Use `perf record -g out/${DART_CONFIGURATION}/dartaotruntime test.aot` to profile the code and `perf report` and `perf annotate` to explore performance of different parts of code.\n5. Use `--print-flow-graph` flag to get IL generated by optimizing compiler, `--print-flow-graph-filter=$NAME_STR` allows to filter out only methods which contain $NAME_STR in their fully qualified names. You can also use `--disassemble --code-comments` to dump disassembly annotated with IL instructions. The output produced by all these flags is written to stderr. You can pass these flags to `precompiler2` script.\n6. When making changes to runtime system, AOT compiler or core libraries - always make sure to rebuild Dart SDK components given in the first item of this list before recompiling and rerunning test or benchmark code.\n",".agents/skills/update-native-rev/SKILL.md":"---\nname: update-native-rev\ndescription: Updates the native_rev dependency in the DEPS file with all correct verification, sync, and testing procedures\n---\n\n\n\n# Instructions\n\nUse this skill when you are requested to roll or update the `native_rev` variable (the hash of `third_party/pkg/native` repository) in the `DEPS` file.\n\n## 0. Initial Synchronization\n\nBefore beginning the roll, **ask the user** if the SDK git repository should be switched to the `main` branch and synchronized.\nIf they confirm, run:\n```bash\ngit checkout main && git pull && gclient sync -D -f\n```\n\n## 1. Commit Selection Rules\n\n> [!IMPORTANT]\n> **CRITICAL RULE**: NEVER EVER pick a local commit or a commit from a custom branch/PR branch. You MUST only pick remote commits that have already landed on the remote `main` branch.\n\nTo select the correct commit SHA:\n1. If the `dart.googlesource.com/native.git` mirror is lagging behind GitHub:\n * **For Googlers**: Trigger an immediate mirror sync instead of modifying `DEPS`:\n ```bash\n gob-ctl repos update-mirror-config github/dart-lang/native \\\n --fetch_frequency 5m \\\n --uri https://github.com/dart-lang/native.git\n ```\n Wait ~10 seconds, verify with `git ls-remote https://dart.googlesource.com/native.git refs/heads/main`, and proceed with the default mirrored googlesource setup below.\n * **Otherwise, ask the user** if the newest hash/commit should be taken directly from **GitHub**:\n * **If the user says YES**:\n 1. First, temporarily change the repository URL and host permissions in the `DEPS` file by following the instructions in the **[Troubleshooting Sync Failures](#troubleshooting-sync-failures)** section (changing `third_party/pkg/native` under `deps` to use `\"https://github.com/dart-lang/native.git\"` and adding `'github.com'` to `allowed_hosts` in `DEPS`).\n 2. Run `gclient sync` from the SDK root to update the checkout mapping to GitHub.\n 3. Navigate to the `native` package subdirectory: `third_party/pkg/native`.\n 4. Run `git fetch origin` to fetch the latest commits from the GitHub remote (origin will now point to GitHub).\n 5. After checking commits, **immediately set the repository URL and host permissions in `DEPS` back to googlesource** (reverting the changes made in sub-step 1), so that subsequent steps and the final commit only roll the commit hash without permanently keeping GitHub host settings.\n * **If the user says NO / default**:\n 1. Proceed with the default mirrored googlesource setup.\n 2. Navigate to the `native` package subdirectory: `third_party/pkg/native`.\n 3. Run `git fetch origin` to fetch the latest commits from the mirror.\n2. Inspect the commits on remote `origin/main` of the `native` repository:\n ```bash\n git log origin/main -n 10 --oneline\n ```\n3. Obtain the full SHA of the newest commit on remote `origin/main` (or the specific one that contains the required change):\n ```bash\n git rev-parse origin/main\n ```\n4. **Revert Host to GoogleSource**:\n * **IMPORTANT**: If the host was set to GitHub, you **MUST** now revert the repository URL and allowed hosts changes in the `DEPS` file back to the mirrored googlesource URL, removing `github.com` from `allowed_hosts`. Do this before updating `native_rev` so that the final committed change only rolls the commit hash, not checkout hosts.\n\n## 2. Updating DEPS and Synchronizing\n\n1. Locate `native_rev` in the `DEPS` file (typically under `vars`):\n ```python\n \"native_rev\": \"\",\n```\n2. Replace the hash with the chosen remote `origin/main` commit SHA.\n3. If not already done in step 4 above, ensure the `DEPS` host and URL configuration are reverted to the googlesource mirror, leaving only the updated `native_rev` hash.\n4. Run `gclient sync -f` from the SDK root directory to update the checkout of the dependencies and regenerate the package configuration using the mirror.\n\n### Troubleshooting Sync Failures\nIf the synchronization fails because of host restrictions:\n1. Temporarily modify the repository configuration under `deps` in `DEPS` to use:\n `https://github.com/dart-lang/native.git` as the git repo.\n2. Temporarily add `'github.com'` to the `allowed_hosts` list in `DEPS`.\n3. Re-run `gclient sync -f` to complete the update.\n4. **IMPORTANT**: Immediately after successful syncing, revert the host and URL changes in the `DEPS` file, removing `github.com` from `allowed_hosts` and returning to the mirrored googlesource URL, but keep the newly synced native commit hash.\n\n## 3. Mandatory Testing and Verification\n\nBefore completing the update, you must run the following tests:\n\n### Native Assets Package Tests\nBuild the target SDK and run the primary native asset tests:\n```bash\nRBE_exec_strategy=racing tools/build.py -mrelease create_sdk runtime ffi_test_functions runtime_precompiled && tools/test.py -n unittest-asserts-release-mac-arm64 pkg/dartdev/test/native_assets/\n```\n\n### Record Use Optimization Tests\nSince `record_use` integrates closely with `native_rev` updates, these tests must be validated for both backends (Wasm and VM). **Note**: `record_use` is now 1.0, so breaking changes are not allowed and expectations should NOT need updating.\n\n1. Build the required target backends and run all record use tests:\n ```bash\n RBE_exec_strategy=racing tools/build.py -mrelease create_sdk dart2wasm runtime ffi_test_functions runtime_precompiled && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/compiler/test/record_use/record_use_test.dart && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/dart2wasm/test/record_use_test.dart && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/vm/test/transformations/record_use_test.dart\n ```\n2. **Test Failure Policy**:\n > [!IMPORTANT]\n > Since `record_use` is 1.0, any test failure here indicates an illegal breaking change rather than a need for expectation updates. Do not update expectations; report any failure immediately.\n3. **Running Individual Tests**:\n To debug or verify a single test:\n ```bash\n python3 tools/test.py -n wasm-unittest-asserts-mac pkg/dart2wasm/test/record_use_test.dart\n ```\n\n## 4. Pre-Completion Protocol\n\nFollow these final validation steps before announcing completion:\n\n1. **Format touched files**: Run `dart format` on all modified Dart files.\n2. **Analyze touched files**: Run `dart analyze` to ensure there are no lint or static analysis issues.\n3. **Presubmit checks**: Run `git cl presubmit` to ensure build/format sanity.\n4. **Update Coverage (Front-End changes only)**:\n If any related changes were also introduced in the `front_end` directory, regenerate test coverage:\n ```bash\n dart --enable-asserts pkg/front_end/test/coverage_suite.dart --tasks=5 --add-and-remove-comments\n ```\n * *Critical*: Revert the coverage comment changes in any files that you did not otherwise modify.\n\n## 5. Branching and Committing\n\nAfter all tests pass and formatting/analysis is clean:\n1. **Ask the user** if they want to create a roll branch and commit the changes.\n2. If confirmed, get the current date in `YYYYMMDD` format (e.g., `20260630`) and run:\n ```bash\n git new-branch roll-\n git commit -a -m \"[deps] Roll dart-lang/native\"\n ```\n","pkg/analysis_server/.agents/skills/close-obsolete-issues/SKILL.md":"---\nname: close-obsolete-issues\ndescription: Find obsolete, stale, or not reproducible analysis-server issues in the dart-lang/sdk repository.\n---\n\n# Close Obsolete Issues\n\nUse this skill to find old, outdated issues in the `dart-lang/sdk` repository that have been fixed, are stale, obsolete, or not reproducible.\n\n## Instructions\n\n1. **Identify Target Issues**:\n - Use the GitHub CLI (`gh`) to search for the oldest open issues.\n - Use the label `area-devexp` to identify analysis server issues.\n - Also use label `type-bug` and any other label that the user gives you.\n - **Exclude Labeled Issues**: Exclude issues already labeled `verified-by-an-agent` or `closed-by-an-agent` by adding `-label:verified-by-an-agent -label:closed-by-an-agent` to the search query. These labels are the record of which issues have already been investigated; there is no separate tracking file.\n - Sort by creation date (`created-asc`) or last update (`updated-asc`) to find the most likely candidates for being outdated.\n - Fetch at least 100–150 candidates. Many candidates fail the guardrails in step 2, so 50 usually leaves only a handful. Alternating between `created-asc` and `updated-asc` across runs also helps surface new candidates.\n - Example command (with label): `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open label:type-bug -label:verified-by-an-agent -label:closed-by-an-agent sort:created-asc\" --limit 150 | cat`\n - Example command (without label): `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open -label:verified-by-an-agent -label:closed-by-an-agent sort:created-asc\" --limit 150 | cat`\n - **Re-verify Old Verifications**: A `verified-by-an-agent` label only says that the issue reproduced when the comment was posted. Occasionally (for example, when the searches above return few candidates, or when the user asks), also look at labeled issues that haven't been updated for more than a year, using a date one year before today: `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open label:verified-by-an-agent -label:closed-by-an-agent updated:\" | cat`. See rationale 7 in `references/rationale_templates.md`.\n\n2. **Investigate Status**:\n - **Pre-Qualification Guardrails**: Before evaluating any candidate against obsolete rationales, check the issue metadata. **Abort evaluation and keep the issue open** if any of the following are true:\n 1. *Recent Activity*: The issue has any comment or status change from a user within the last 365 days.\n 2. *Priority/Milestone*: The issue carries a high-priority label (e.g., `P0`, `P1`, `critical`) or is assigned to an active milestone.\n 3. *Corporate Interest*: The issue has active engagement or reproduction steps provided by a Dart/Flutter team member within the last 2 years.\n - For candidates that pass pre-qualification, analyze their description and comments.\n - Use the bundled script `scripts/fetch_issue_details.sh ` to get a comprehensive view of the issue and its comments.\n - **Check for Existing Tests First**: Search the test directories for the issue number, e.g. `grep -rn \"issues/\" test/` (and in `pkg/analyzer/test` or `pkg/linter/test` if relevant). Tests annotated with `@FailingTest(issue: '…/')` are a ready-made reproduction: if they still fail, the bug is still valid; if they now pass, the bug may have been fixed silently.\n - **Verify with a Locally Built SDK**: The `dart` on `PATH`could be an older SDK (for example the one bundled with Flutter). Reproduce with the SDK built from the current checkout, e.g. `/xcodebuild/ReleaseX64/dart-sdk/bin/dart` on macOS or `/out/ReleaseX64/dart-sdk/bin/dart` on Linux. Confirm with `--version` that it matches `HEAD`, and record that version (or commit) for use in your comments.\n - Compare the issue's request or reported bug and subsequent comments with the current state of the codebase.\n - Refer to the data-driven checks in `references/rationale_templates.md` to verify if a rationale applies.\n - **Safety Rule**: Do not assume a bug is fixed or obsolete just because the code has changed or the issue has not been updated for a long time. Verify if the specific bug behavior is still possible. Valid bugs or feature requests should not be closed as stale just because they are old or have no activity. Inactivity alone does not invalidate a feature request or bug report.\n\n3. **Draft and Review Comments (CRITICAL MANDATE)**:\n - **For Candidates for Closure**: For issues identified as candidates for closure, draft a detailed comment for each explaining *why* it can be closed. Consult `references/rationale_templates.md` for wording inspiration. Each comment MUST end with: \"If there is more work to do here, please let us know by filing a new issue with up to date information. Thanks!\"\n - **State the Verification SDK**: Every comment (closure or still-valid) should say which SDK the behavior was verified on, e.g. \"Verified on a local build of `main` (`3.14.0-edge.`)\", so readers can judge how current the finding is.\n - **For Still-Valid Issues**: If you determine that a bug is still valid (reproducible on `HEAD`):\n - Draft a comment confirming that the bug remains reproducible at `HEAD` on the latest SDK.\n - Construct a minimal, self-contained Dart reproduction code example or a formal Dart unit test case (following existing testing patterns in the `test/` directory) demonstrating the issue.\n - If you write a unit test, run it to confirm that it actually fails on `HEAD`, and include the actual (wrong) output in the comment alongside the expected output.\n - Where you can identify it, point to the likely root cause (file and function) so the issue is actionable.\n - Include this reproduction or unit test in your drafted comment to assist developers in fixing the bug.\n - **Revert Temporary Tests**: Tests added to the repository only to verify a bug must be reverted afterwards (e.g. `git checkout `). Leave the working tree as you found it unless the user asks you to fix the bug (see step 6).\n - **Footer Restriction**: Do NOT end comments on still-valid issues with the closure footer (about filing a new issue), as this issue is remaining open.\n - **Required Output Format**: For each evaluated issue, generate your assessment in this structured JSON format so that a coordinator agent or human supervisor can easily parse, validate, and approve your findings:\n ```json\n {\n \"issue_number\": 12345,\n \"issue_url\": \"https://github.com/dart-lang/sdk/issues/12345\",\n \"eligible_for_close\": true,\n \"matched_rationale_id\": 1,\n \"confidence_score\": 0.95,\n \"verification_finding\": \"Verified that standard LSP protocol capabilities natively handle the requested server configuration.\",\n \"proposed_comment\": \"[Full proposed comment including the mandatory footer]\"\n }\n ```\n - **User Approval Required**: You MUST present both (a) the candidates for closure with their drafted comments, and (b) the still-valid issues with their drafted confirmation comments and reproductions, to the user and obtain explicit approval BEFORE running any command that comments on or closes an issue. You can present the JSON findings format directly to the user for review.\n\n4. **Iterate on Skill Knowledge (Learning Loop)**:\n - If you discover a new, distinct category of closing rationale that is not covered in `references/rationale_templates.md`, **update the reference file** to include it.\n\n5. **Execute and Summarize**:\n - **For Approved Closure Candidates**: Use `gh issue close` with the `-c` flag to post the comment and close the issue. Apply the `closed-by-an-agent` label to the issue.\n - **For Approved Still-Valid Issues**: Use `gh issue comment -b \"\"` to post the confirmation comment containing the minimal reproduction / test case. Apply the `verified-by-an-agent` label to the issue using `gh issue edit --add-label \"verified-by-an-agent\"`.\n - **Label Every Still-Valid Issue You Leave Open**: The label is how future runs know to skip an issue, so each investigated issue that stays open should get a confirmation comment and the `verified-by-an-agent` label. Don't apply the label without a comment: if the user decides not to post a comment for an issue, leave it unlabeled, and it may come up again on a later run.\n - Provide the user with a clean bulleted list of closed issues and updated/commented valid issues.\n\n6. **Optional: Fix It (only when the user asks)**:\n - Some still-valid issues are cheap to fix. A good candidate has a **failing unit test** from step 3 and a **localized root cause** (one function or one condition). When you present the step 5 summary, point out which verified issues look like quick fixes; don't start fixing unless the user asks.\n - When fixing:\n - Turn the verification test into a permanent regression test (a link to the issue in a comment is enough). If the fix touches a code path shared by related behaviors (e.g. both `extractAll: true` and `extractAll: false`), add a test for each.\n - If the repository already has `@FailingTest(issue: '…/')` tests for the issue, remove the annotation so they run as normal tests.\n - Run the whole test file for the changed code, plus closely related suites (e.g. the LSP and legacy protocol tests for a refactoring), and run `dart analyze` and `dart format` on the changed files.\n - Call out any intentional behavior change beyond the reported bug so reviewers can weigh it.\n - Suggest a commit message that ends with `Fixes https://github.com/dart-lang/sdk/issues/` so the issue closes automatically when the change lands. Leave committing and uploading to the user unless they ask you to do it.\n - After the fix lands, remove the issue from `references/investigated_issues.txt` (see step 5).\n\n## Tips\n\n- Use available file and content search tools (such as `grep`, `ripgrep`, or environment-specific\nsearch tools) to check the current codebase for references to the issue or relevant code.\n- Look for related Gerrit CLs that might have fixed the issue but didn't close it automatically.\n- **Pro Tip**: Use the `read-gerrit-cl` skill ([SKILL.md](../../../../../.agents/skills/read-gerrit-cl/SKILL.md)) to inspect the patchset diffs and comments of open or merged Gerrit CLs.\n- **Always prioritize active verification on HEAD**: Regardless of how old an issue is or what version it specifies, always attempt to research and reproduce the reported issue against the current `HEAD` of the codebase before proposing closure. Never assume a bug is obsolete or fixed based solely on the passage of time or version discrepancies. If you cannot reproduce it, provide clear details of your reproduction attempt on the current codebase.\n","runtime/tools/pubspec.yaml":"name: runtime_tools\ndescription: Internal runtime tools.\n\nenvironment:\n sdk: ^3.9.0\n\nresolution: workspace\npublish_to: none\n",".agents/rules/add_license_header.md":"---\ntrigger: glob\ndescription: Ensure standard Dart license header on newly created Dart files.\nglobs: *.dart\n---\n\n# License Header Rule\n\nWhenever you create a new Dart (`.dart`) file in this repository, you MUST include the standard Dart project license header at the very top (line 1).\n\nReplace `` with the actual current year (e.g., 2026).\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n```\n\n## Requirements\n- Insert at line 1.\n- Ensure a blank line follows the license header before any other code or comments.\n","pkg/analysis_server/.agents/skills/improve-performance-with-session-log/SKILL.md":"---\nname: improve-performance-with-session-log\ndescription: >-\n Use this skill when diagnosing, reproducing, and improving the performance or\n latency of Dart Analysis Server (DAS) LSP requests and responses using\n recorded session communications logs, log normalization, replay tools, and\n fresh local SDK compilation.\n---\n\n# Improve LSP Performance with Session Logs\n\nThis skill guides you through diagnosing slow LSP request/response interactions\nin the Dart Analysis Server (DAS), reproducing them with the log player replay\ntool, optimizing the server implementation, recompiling the SDK, and validating\nthe latency improvement.\n\n---\n\n## Workflow Overview\n\n```mermaid\nflowchart LR\n A[\"1. Inspect Log\"] --> B[\"2. Normalize Log\"] --> C[\"3. Reproduce & Measure Baseline\"]\n C --> D[\"4. Optimize & Rebuild SDK\"] --> E[\"5. Replay with Built SDK & Validate\"]\n```\n\n1. **Inspect Log**: Locate target requests (e.g. `textDocument/documentColor`,\n `textDocument/completion`) and calculate request-to-response duration\n (`response.time - request.time`).\n2. **Normalize Log**: Replace machine-specific paths with portable placeholders\n (`{{workspaceFolder-0}}`, `{{dartSdkRoot}}`).\n3. **Reproduce Baseline**: Replay the log against the baseline server using\n `server_driver_main.dart` or automated playback, isolating warm request\n latency from cold-start queueing.\n4. **Optimize Code**: Implement performance improvements in `pkg/analysis_server`\n or `pkg/analyzer`.\n5. **Recompile SDK**: From ``, run `python3 tools/build.py -mrelease create_sdk`.\n6. **Replay with the freshly built SDK**: Replay using the newly compiled `dart` binary to\n verify latency reduction and correctness.\n7. **Run unit and integration tests**: Run existing unit tests and add regression tests for\n modified logic.\n\n## Step 1: Inspect the session communications log\n\nSession logs are line-delimited JSON (JSON Lines). Each line is an independent\nJSON object containing `time` and `kind`. Depending on the kind of entry (e.g.\n`message` versus `commandLine`), lines may also have `sender`, `receiver`, and\n`message` (though some entries might omit them).\n\n### Analyze the Log with `analyze_session_log.dart`\n\nThe skill provides\n[`scripts/analyze_session_log.dart`](scripts/analyze_session_log.dart) to parse,\ninspect, and summarize session logs automatically:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/analyze_session_log.dart \\\n [--method=] [--min-ms=] [--warm-only] [--summary] \n```\n\nKey capabilities:\n\n* **Measures Client & Server Durations**: Displays client-perceived duration\n (`response.time - request.clientRequestTime`) and server processing duration\n (`response.time - request.time`).\n* **Detects Cold-Start Queueing**: Identifies whether requests occurred during\n initial background analysis (`$/progress` `\"Analyzing...\"`) or against a warm\n server.\n* **Extracts Errors & Crashes**: Automatically parses and surfaces server\n exceptions (e.g. `Bad state: SimpleIdentifierImpl is not in the V2 AST view`).\n\nExample of inspecting 'textDocument/documentColor' requests in a session:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/analyze_session_log.dart \\\n -m documentColor session-log-2.txt\n```\n\n## Step 2: Normalize the Log\n\nRaw session logs contain absolute paths from the machine where they were\nrecorded. Normalize them to make them replayable against any local workspace:\n\n```bash\ndart /pkg/analysis_server/tool/log_player/normalize.dart \\\n -i \\\n -o \\\n -r \\\n [-p ]\n```\n\nOptions:\n\n* `-i`, `--input`: Path to the raw recorded log file.\n* `-o`, `--output`: Destination path for the normalized log.\n* `-r`, `--root-dir`: Root directory of the project open during recording.\n* `-p`, `--package-config`: (Optional) Explicit path to `package_config.json`\n if not at `/.dart_tool/package_config.json`.\n\nNormalizing replaces machine paths with `{{workspaceFolder-0}}`,\n`{{dartSdkRoot}}`, and package URIs with `{{package-root:...}}`.\n\n---\n\n## Step 3: Reproduce and Measure Baseline Latency\n\n### Automated Replay & Measurement (`measure_request_latency.dart`)\n\nThe skill provides\n[`scripts/measure_request_latency.dart`](scripts/measure_request_latency.dart)\nto automatically replay setup messages up to a target request, wait for\nbackground analysis to finish, and measure wall-clock latency across multiple\niterations:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/measure_request_latency.dart \\\n -i -w -r 3 \n```\n\nOptions:\n\n* `-i`, `--request-id`: (**Required**) The target request ID identified in Step 1\n (e.g. `153`). Always specify this to ensure you benchmark the exact target\n request.\n* `-m`, `--method`: Target request method (e.g. `textDocument/documentColor`).\n Avoid using this without `-i`, as matching by method alone yields the first\n occurrence in the log rather than the slowest or target request.\n* `-w`, `--workspace`: Local project directory to map `{{workspaceFolder-0}}`\n to (defaults to current working directory).\n* `-r`, `--repeat`: Number of iterations to measure consistency (default: 1).\n\n> [!IMPORTANT]\n> **Always use `--request-id` (`-i`)**: Pass the specific request ID found from\n> inspecting or analyzing the log in Step 1. Do not rely on `--method` alone:\n> `--method` only matches the *first* occurrence of that method in the session\n> log, which is often a fast initial request rather than the slow interaction\n> you are trying to optimize.\n\n### Interactive replay (`server_driver_main.dart`)\n\nFor manual inspection and stepping through messages one-by-one:\n\n```bash\ncd /path/to/project/root\ndart /pkg/analysis_server/tool/log_player/server_driver_main.dart /path/to/normalized_log.json\n```\n\n* Press **Enter** to step through messages.\n* Wait for background analysis to finish (`$/progress` `{\"kind\": \"end\"}`) before\n stepping to the target request to measure warm handler latency.\n\n**Note** that this tool can absolutely change the timing of the operations in\nthe log, which can potentially change the **behavior** of the server.\n\n## Step 4: Investigate code and implement optimizations\n\n1. Identify the handler or computer responsible for the request method:\n * Method `textDocument/documentColor` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_document_color.dart` and\n `pkg/analysis_server/lib/src/computer/computer_color.dart`.\n * Method `textDocument/completion` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_completion.dart` and\n `pkg/analysis_server/lib/src/services/completion/`.\n * Method `textDocument/codeAction` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_code_actions.dart`.\n2. Inspect profiling data or trace execution paths for common bottlenecks:\n * **Unnecessary AST traversals**: Are visitors walking AST subtrees that\n cannot contain relevant nodes?\n * **Excessive element resolution or type evaluation**: Can lightweight\n syntactic checks filter out candidates before resolving types or evaluating\n constant values?\n * **Repeated allocations or computations**: Can maps/sets be reused, or early\n exits added?\n3. Apply optimizations in `pkg/analysis_server` or `pkg/analyzer`.\n\n## Step 5: Recompile the Dart SDK\n\nRecompile the analysis server snapshot and SDK binaries:\n\n```bash\n(cd && python3 tools/build.py -mrelease create_sdk)\n```\n\nThe compiled SDK binaries will be located at:\n\n* **macOS**: `xcodebuild/ReleaseARM64/dart-sdk/bin/dart` (or\n `xcodebuild/ReleaseX64/...`)\n* **Linux / Windows**: `out/ReleaseX64/dart-sdk/bin/dart`\n\n## Step 6: Replay with the freshly built SDK\n\n> [!IMPORTANT]\n> `ServerDriver` starts the server process using `Platform.resolvedExecutable`.\n> To run against your freshly built changes, you **must** execute `server_driver_main.dart` (or your replay script) using the compiled `dart` binary, not the system `dart`.\n\n### Running automated replay with the built SDK\n\nRun `measure_request_latency.dart` with the compiled binary to measure latency after changes:\n\n```bash\n \\\n /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/measure_request_latency.dart \\\n -i -w -r 3 /path/to/normalized_log.json\n```\n\n### Interactive stepping with the built SDK\n\n```bash\n \\\n /pkg/analysis_server/tool/log_player/server_driver_main.dart \\\n /path/to/normalized_log.json\n```\n\nIf running from an external project root and package resolution fails, specify\nthe package config:\n\n```bash\n--packages=/.dart_tool/package_config.json\n```\n\n### Validation checklist\n\n- [ ] Confirm the target request returns the exact same valid response payload\n (colors, completions, etc.).\n- [ ] Verify that request execution latency is substantially reduced compared to\n baseline.\n- [ ] Confirm no unhandled exceptions or error responses are produced in the\n server output stream.\n\n## Step 7: Run unit and integration tests\n\nRun relevant existing tests with the compiled Dart binary:\n\n```bash\n test /pkg/analysis_server/test/src/...\n```\n\nAdd new unit tests in the appropriate test suite (e.g.\n`pkg/analysis_server/test/src/computer/...`) to lock in the performance\noptimization and guard against regressions.\n","pkg/dart2js_tools/README.md":"\n### dart2js\\_tools\n\nThis package collects tools used with dart2js.\n\nFor now, this contains scripts useful to work with obfuscated stack traces in\nproduction and reading data from the extensions added to source-maps by dart2js\n(like minified names and inlined stack frames).\n\nIn the future we plan to merge here tools in the dart2js\\_info package as well.\n","pkg/dds_service_extensions/README.md":"[![pub package](https://img.shields.io/pub/v/dds_service_extensions.svg)](https://pub.dev/packages/dds_service_extensions)\n[![package publisher](https://img.shields.io/pub/publisher/dds_service_extensions.svg)](https://pub.dev/packages/dds_service_extensions/publisher)\n\nA package used to expand the `package:vm_service` interface with support for RPCs added in the [Dart Developer Service (DDS) protocol][dds-protocol].\n\n[dds-protocol]: https://github.com/dart-lang/sdk/blob/main/pkg/dds/dds_protocol.md\n","pkg/analysis_server/.agents/skills/implement-a-lint/SKILL.md":"---\nname: implement-a-lint\ndescription: Guide for creating, registering, documenting, and testing a new lint in the Dart SDK.\n---\n\n## Overview\n\nUse this skill when you need to create a new lint in the Dart SDK codebase. It details the step-by-step implementation and testing procedures.\n\n## Target Reference Example\n\nBefore starting, review this existing feature as the canonical implementation model:\n* **Reference Implementation:** `pkg/linter/lib/src/rules/unnecessary_primary_constructor_body.dart`\n* **Reference Test:** `pkg/linter/test/rules/unnecessary_primary_constructor_body_test.dart`\n\n## File Layout & Naming Conventions\n\nWhen implementing a new lint, you will modify or create the following files:\n\n| File Path | Action | Description |\n|---|---|---|\n| `pkg/linter/lib/src/rules/.dart` | **Create** | The main implementation and AST visitor logic. |\n| `pkg/linter/messages.yaml` | **Modify** | Alphabetical diagnostic entry, problem/correction messages, and documentation. |\n| `pkg/linter/lib/src/rules.dart` | **Modify** | Imports and registers the lint class in the linter registry. |\n| `pkg/linter/test/rules/_test.dart` | **Create** | The reflective tests for the new lint. |\n| `pkg/linter/test/rules/all.dart` | **Modify** | Imports and runs the main entry point of the test file. |\n| `pkg/analysis_server/lib/src/services/correction/error_fix_status.yaml` | **Modify** | Records which diagnostics have or should have a fix. |\n\n## Execution Checklist\n\n### 1. Define the diagnostic code(s)\n\nUnless explicitly instructed otherwise by the user, the rule should have a single diagnostic code.\n\nCopy the following structure to define each of the diagnostic codes that the lint will produce. The definitions should be added alphabetically to `pkg/linter/messages.yaml`.\n\n````yaml\n :\n type: lint\n parameters: none\n problemMessage: \"\"\n correctionMessage: \"\"\n state:\n experimental: \"\"\n categories: [style]\n hasPublishedDocs: false\n documentation: |-\n #### Description\n\n The analyzer produces this diagnostic when \n\n #### Example\n\n The following code produces this diagnostic because :\n\n ```dart\n // Bad code here\n ```\n\n #### Common fixes\n\n If , then :\n\n ```dart\n // Good code here\n ```\n deprecatedDetails: |-\n \n````\n\nIf the user has explicitly requested different diagnostic codes for different contexts, then use the template above for each code, alphabetizing the entries. In this case, each code should have a `sharedName:` entry that is the same for all of the codes being added, and that should be the name of the lint rule. The `ruleName` for each entry should then be something like `ruleName_context`. Only one diagnostic code should have the `documentation:` and `deprecatedDetails:` entries (typically the one that is lexically first). These values will be shared by any codes that have the same `sharedName`.\n\nThe presence of the `deprecatedDetails` property is strictly validated by the generator script. You MUST include it, even for newly added lints. The code snippets in this documentation are not validated, so do not include range markers ('[!' '!]') or use any of the `%` directives.\n\nThe `hasPublishedDocs` property must be included and must have a value of `false`. The flag will be changed to `true` after the documentation has been published to the web site.\n\nThe `categories:` property lists the categories that developers can use to discover new lints. Choose from the following allowed categories: `binarySize`, `brevity`, `documentationCommentMaintenance`, `effectiveDart`, `errorProne`, `flutter`, `languageFeatureUsage`, `memoryLeaks`, `nonPerformant`, `pub`, `publicInterface`, `style`, `unintentional`, `unusedCode`, `web`.\n\nRun the following commands to update the generated files (`lint_names.g.dart`, `diagnostic.g.dart`, etc.):\n\n```bash\ndart run pkg/linter/tool/generate_lints.dart\ndart run pkg/analyzer/tool/messages/generate.dart\n```\n\n**BEFORE CONTINUING TO THE NEXT STEP:**\n\nRun `dart test pkg/analyzer/test/verify_diagnostics_test.dart` to verify that the example and fixes code in the documentation is correct. Make changes as necessary to get the test to pass, re-running the test until it passes. If you modify the `messages.yaml` file then you must re-run the generators before re-testing.\n\n### 2. Implement the lint\n\nIf the lint is dependent on a language experiment, and that experiment is not enabled by default, confirm that the list of experiments returned by `experimentsForTests` in `pkg/analyzer_testing/lib/experiments/experiments.dart` includes the experiment. If not, add it.\n\nNote that a new lint should use the next version of the Dart SDK for the `since` property in the `AnalysisRule` constructor.\n\nCreate an implementation of the lint in the file `pkg/linter/lib/src/rules/.dart` by copying the following template:\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n\nimport 'package:analyzer/analysis_rule/analysis_rule.dart';\nimport 'package:analyzer/analysis_rule/rule_context.dart';\nimport 'package:analyzer/analysis_rule/rule_visitor_registry.dart';\nimport 'package:analyzer/dart/ast/ast.dart';\nimport 'package:analyzer/dart/ast/visitor.dart';\n\nimport '../analyzer.dart';\nimport '../diagnostic.dart' as diag;\n\nconst _desc = r'';\n\n/// \nclass extends AnalysisRule {\n new() : super(\n name: LintNames.,\n description: _desc,\n state: RuleState.experimental(since: .new(, , 0)),\n );\n\n @override\n DiagnosticCode get diagnosticCode => diag.ruleName;\n\n @override\n void registerNodeProcessors(\n RuleVisitorRegistry registry,\n RuleContext context,\n ) {\n var visitor = _Visitor(this, context);\n // \n }\n}\n\nclass _Visitor(final AnalysisRule rule, final RuleContext context)\n extends SimpleAstVisitor {\n // \n}\n```\n\nThere must be a visit method for every registered node type and there must be a registration for every `visit` method.\n\nUse either `rule.reportAtToken(token)` or `rule.reportAtNode(node)` to emit the diagnostics. Prefer using `rule.reportAtToken(token)` to report at a single token.\n\nIf the lint produces multiple diagnostic codes, make the implementation class a subclass of `MultiAnalysisRule`. For rules with multiple diagnostic codes:\n1. Extend `MultiAnalysisRule` instead of `AnalysisRule`.\n2. Override `diagnosticCodes` (plural) returning a list of codes instead of `diagnosticCode` (singular):\n ```dart\n @override\n List get diagnosticCodes => [\n diag.ruleName_contextOne,\n diag.ruleName_contextTwo,\n ];\n ```\n3. Provide the specific diagnostic code when reporting:\n ```dart\n rule.reportAtToken(token, diagnosticCode: diag.ruleName_contextOne);\n ```\n\n#### Useful Analyzer APIs for Lint Logic\n\n- Unwrapping Parentheses: Use `node.unParenthesized` to inspect the target of an expression without manually traversing parenthesized wrappers.\n- Element Model: Use `node.declaredFragment?.element` to retrieve the `Element` corresponding to the declared node.\n- Experiment/Feature Flags: Use `context.isFeatureEnabled(Feature.feature_name)` to conditionally enable or check features.\n\n#### Useful tools\n\n- The tool `pkg/linter/tool/spelunk.dart` can be used to print/dump the AST of a given file. This might be helpful to determine which AST node types need to be visited.\n\n**BEFORE CONTINUING TO THE NEXT STEP:**\n\nEnsure that the implementation passes `dart analyze` without any diagnostics. If there are diagnostics, you must fix them before proceeding.\n\n### 3. Register the lint\n\nAfter the class is written, modify `pkg/linter/lib/src/rules.dart` to import your rule and register it alphabetically:\n\n```dart\n ..registerLintRule(RuleName())\n```\n\n### 4. Record the status of the lint's fixes\n\nEdit the file `pkg/analysis_server/lib/src/services/correction/error_fix_status.yaml` to indicate that the lint needs to be evaluated to determine whether one or more fixes should be provided. Do this by alphabetically adding an entry of the form\n```yaml\n:\n status: needsEvaluation\n```\n\n### 5. Write tests for the lint\n\nCreate a reflective test suite in the file `pkg/linter/test/rules/_test.dart` by copying the following template:\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n\nimport 'package:test_reflective_loader/test_reflective_loader.dart';\n\nimport '../rule_test_support.dart';\n\nvoid main() {\n defineReflectiveSuite(() {\n defineReflectiveTests(Test);\n });\n}\n\n@reflectiveTest\nclass Test extends LintRuleTest {\n @override\n String get lintRule => LintNames.;\n\n // \n}\n```\n\nUse `assertDiagnosticsFromMarkup` to test cases where a diagnostic is expected and `assertNoDiagnostics` to test cases where a diagnostic is not expected. Do not use `assertDiagnostics`.\n\nIf the implementation of the lint has any conditions that must be true in order for the diagnostic to be generated, ensure that there is at least one test for each condition that shows that the diagnostic is not generated when the condition is false.\n\nIf the lint is dependent on a language experiment, then tests that verify the behavior of the lint when the experiment is not enabled must include a language override comment in the test code. The version should be the version before the experiment was introduced, which is given as the `experimentalReleaseVersion` key in `pkg/analyzer/lib/src/dart/analysis/experiments.g.dart`. If the release version is `null`, then use the current Dart SDK version.\n\nLinter tests run against a lightweight mocked SDK (`pkg/analyzer/lib/src/test_utilities/mock_sdk.dart`) rather than the real disk SDK. If a test references standard library APIs (e.g. `Iterable`) and the test fails because the API isn't found, try using a different API or enhance the mock SDK to include the APIs.\n\n### 6. Run the tests\n\nExecute the tests directly using the `dart test` runner:\n\n```bash\ndart test pkg/linter/test/rules/_test.dart\n```\n\nIf the tests don't pass, then either fix the implementation or fix the test, as appropriate.\n\nAfter the tests that you added are passing, run\n```bash\ndart run pkg/linter/test/all.dart\ndart run pkg/analyzer/test/test_all.dart\ndart run pkg/analysis_server/test/test_all.dart\n```\n\nThese will usually all pass at this point, but will sometimes fail. If they do, fix the failures and repeat the test commands until they all pass.\n\n### 7. Verify that the code is error free and formatted correctly\n\nVerify that every file that was either created or modified analyzes cleanly (no diagnostics):\n\n```bash\ndart analyze \n```\n\nIf any diagnostics are reported, attempt to fix them by running:\n\n```bash\ndart fix \n```\n\nThen rerun `dart analyze`. If there are still diagnostics, fix them directly. Repeat until `dart analyze` reports no diagnostics.\n\nThen run the following command on all created or modified files, but not on generated files:\n```bash\ndart format \n```\n","runtime/tools/dartfuzz/README.md":"# dartfuzz Documentation\n\nPath: `runtime/tools/dartfuzz/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/README.md)","runtime/tools/dartfuzz/README_minimize.md":"# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/README_minimize.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/README_minimize.md)","runtime/tools/dartfuzz/analysis_options.yaml":"# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/analysis_options.yaml)","runtime/tools/dartfuzz/pubspec.yaml":"# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/pubspec.yaml)","runtime/tools/entitlements/README.md":"# entitlements Documentation\n\nPath: `runtime/tools/entitlements/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/entitlements/README.md)","runtime/tools/heapsnapshot/CHANGELOG.md":"# Heapsnapshot Skill\n\nPath: `runtime/tools/heapsnapshot/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/CHANGELOG.md)","runtime/tools/heapsnapshot/README.md":"# heapsnapshot Documentation\n\nPath: `runtime/tools/heapsnapshot/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/README.md)","runtime/tools/heapsnapshot/pubspec.yaml":"# Heapsnapshot Skill\n\nPath: `runtime/tools/heapsnapshot/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/pubspec.yaml)","runtime/tools/profiling/CHANGELOG.md":"# Profiling Skill\n\nPath: `runtime/tools/profiling/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/CHANGELOG.md)","runtime/tools/profiling/README.md":"# profiling Documentation\n\nPath: `runtime/tools/profiling/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/README.md)","runtime/tools/profiling/analysis_options.yaml":"# Profiling Skill\n\nPath: `runtime/tools/profiling/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/analysis_options.yaml)","runtime/tools/profiling/pubspec.yaml":"# Profiling Skill\n\nPath: `runtime/tools/profiling/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/pubspec.yaml)","runtime/tools/wiki/README.md":"# wiki Documentation\n\nPath: `runtime/tools/wiki/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/wiki/README.md)","pkg/linter/test/rules/analysis_options.yaml":"# Rules Skill\n\nPath: `pkg/linter/test/rules/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/linter/test/rules/analysis_options.yaml)","pkg/front_end/testcases/extensions/as_show/libraries.json":"# As_show Skill\n\nPath: `pkg/front_end/testcases/extensions/as_show/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/as_show/libraries.json)","pkg/front_end/testcases/extensions/patch/libraries.json":"# Patch Skill\n\nPath: `pkg/front_end/testcases/extensions/patch/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/patch/libraries.json)","pkg/front_end/testcases/extensions/patching/libraries.json":"# Patching Skill\n\nPath: `pkg/front_end/testcases/extensions/patching/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/patching/libraries.json)","pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md":"# References Skill\n\nPath: `pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md)"},"files":{".agents/skills/update-dependency/SKILL.md":"---\nname: update-dependency\ndescription: Updates third party dependencies in the Dart SDK\n---\n\n# Instructions\n\nUse this skill to update dependencies in the Dart SDK's `DEPS` file to their\nlatest (or a specific) version. This tool automates the process of updating\nthe version, syncing dependencies, updating package configurations, and\ncreating a CL.\n\n## Prerequisites\n\nBefore running the tool, ensure your environment is prepared correctly:\n\n1. **Clean Git State**: Your git checkout MUST be clean. No uncommitted\n changes should be present.\n2. **On Main Branch**: You MUST be on the `main` branch. The tool creates a\n new branch from your current HEAD, so being on `main` ensures the bump\n starts from a clean baseline.\n\n## Tool Usage\n\nRun the `tools/manage_deps.dart` script with the `bump` command from the root\nof the SDK.\n\n### Command Syntax\n\n```bash\ndart tools/manage_deps.dart bump \\\n [--branch ] [--target ]\n```\n\n### Arguments\n\n1. `` (required): The path to the dependency directory\n relative to the SDK root. Dependencies are entire repositories and not\n packages, so the path will usually be `third_party/pkg/`.\n - **CRITICAL**: DO NOT include a trailing slash in the path.\n - If unsure of the repository, you can look at the\n `.dart_tool/package_config.json` file relative to the SDK root, and search\n for `\"name\": \"\"`. Next to that you should see a \"rootUri\"\n key which will give you the path to the dependency. Do not use the full\n path though, just the top level directory under `third_party/pkg/`,\n since entire repos are always rolled at once.\n - If the `.dart_tool/package_config.json` file does not exist, it can be\n generated by running `gclient sync`.\n2. `--branch ` (optional): The name of the branch to create for\n this update. Defaults to `bump_`.\n3. `--target ` (optional): The specific git ref (SHA, tag, branch) to\n update to. Defaults to the latest version on the remote's default branch.\n\n## Example\n\nTo bump the `unified_analytics` dependency, which is a part of the `tools` repo:\n\n```bash\ndart tools/manage_deps.dart bump third_party/pkg/tools\n```\n\n## Troubleshooting\n\n- **\"Already at - nothing to do\" (or missing recent GitHub commit)**:\n The dependency is already at the latest version on the mirror, or the\n `dart.googlesource.com` mirror has not yet synced a recently merged GitHub\n commit.\n - **For Googlers**: If a commit recently landed on GitHub (check with\n `git ls-remote https://github.com//.git refs/heads/main`, where\n `` is typically `dart-lang`) but is not yet on\n `https://dart.googlesource.com/.git`, trigger an immediate mirror\n fetch:\n ```bash\n gob-ctl repos update-mirror-config github// \\\n --fetch_frequency 5m \\\n --uri https://github.com//.git\n ```\n Wait ~10 seconds, verify with\n `git ls-remote https://dart.googlesource.com/.git refs/heads/main`,\n and rerun `tools/manage_deps.dart`.\n- **Branch already exists**: If the tool says a branch with the target name\n already exists, you will be prompted to delete it. Usually, it is safe to say\n \"y\" if you want a fresh bump.\n- **\"CorpSSO login required. To log in, run glogin or gcert\"**: This indicates a\n Google-internal SSO authentication failure during fetching/syncing\n dependencies. This error and the suggested fix (`gcert` / `glogin`) are only\n applicable for Googlers. Since this requires interactive authentication, you\n must ask the user to run `gcert` (or `glogin`) in their terminal to\n authenticate, and then retry.\n",".agents/skills/read-gerrit-cl/SKILL.md":"---\nname: read-gerrit-cl\ndescription: Fetch and display the full patch/diff or comments for a Gerrit CL.\n---\n\n# Instructions\n\nUse this skill to inspect a Gerrit Change List (CL).\nThis is useful for reviewing code changes, understanding the scope of a modification, checking comments.\n\n## Requirements\n\nThe following command-line tools are required:\n\n- `curl`: For making HTTP requests.\n- `jq`: For parsing JSON (needed for comments).\n- `base64`: For decoding patch content (needed for patches).\n\n## Scripts\n\n### 1. Read Patch\n\nRun the `read_patch.sh` script to fetch the unified diff of a CL.\n\n#### Usage\n\n```bash\n./scripts/read_patch.sh [patchset]\n```\n\n#### Arguments\n\n1. `change_number`: The numeric ID of the Gerrit change (e.g., `12345`).\n2. `patchset` (optional): The patchset number or `current` (default).\n\n#### Example\n\nTo fetch the patch for CL 12345 (latest revision):\n\n```bash\n./scripts/read_patch.sh 12345\n```\n\nTo fetch a specific revision (e.g. patchset 2):\n\n```bash\n./scripts/read_patch.sh 12345 2\n```\n\nThe output will be the unified diff format of the patch.\n\n### 2. Read Comments\n\nRun the `read_comments.sh` script to fetch the comments on a CL.\n\n#### Usage\n\n```bash\n./scripts/read_comments.sh \n```\n\n#### Arguments\n\n1. `change_number`: The numeric ID of the Gerrit change (e.g., `12345`).\n\n#### Example\n\nTo fetch comments for CL 12345:\n\n```bash\n./scripts/read_comments.sh 12345\n```\n\nThe output will be a JSON object containing the comments.\n",".agents/skills/find-release-for-commit/SKILL.md":"---\nname: find-release-for-commit\ndescription: Find which Dart/Flutter releases contain a specific commit sha.\n---\n\n# Instructions\n\nUse this skill to determine which releases a specific commit SHA (Dart or Flutter) first appeared in.\nThis is useful for identifying the earliest SDK version that includes a given feature, fix, or change.\n\n## Tool Usage\n\nRun the `tools/find_release.dart` script from the root of the SDK (`../../../` relative to this file) to discover the releases for a given commit SHA.\n\n```bash\ndart tools/find_release.dart --commit= --channel=\n```\n\n### Arguments\n\n1. `--commit=` (required): The SHA of the commit.\n2. `--channel=` (required): The channel to search in.\n\n### Example\n\nTo find which releases contain commit `abcdef123...` on the `stable` channel:\n\n```bash\ndart tools/find_release.dart --commit=abcdef123... --channel=stable\n```\n\nThe output will include:\n\n- Whether the commit was found in the Dart or Flutter repository.\n- The lowest (earliest) git release tag containing that commit.\n- The corresponding official Flutter release (if found).\n- The corresponding official Dart SDK release (if found).\n\n## Important Considerations\n\n- **Git Tags vs. Official Releases**: The tool first identifies the lowest git tag that includes the commit. However, the presence of a tag (especially a `-dev` tag) **does not guarantee that an official SDK release has being published for that version.**\n- **Verification**: You should look for the \"Lowest Dart release\" or \"Lowest Flutter release\" in the tool's output to confirm that the commit has actually reached a released state. If the tool reports \"No Dart releases found that were newer than \", then the commit has not yet reached any official released version on that channel.\n- **Reporting**: When communicating the findings, distinguish clearly between the git tag it first appeared in and the earliest official release (if any).\n",".agents/skills/dart-aot-development/SKILL.md":"---\nname: dart-aot-development\ndescription: Instructions on building and testing changes using Dart AOT mode. Use when working on Dart runtime, Dart AOT compiler or other related components.\n---\n\n# Testing changes to Dart SDK in AOT mode\n\nIf you are making changes to Dart SDK (including but not limited to modifying\nDart VM runtime, Dart VM compiler pipeline, Dart common front-end, Dart type\nflow analysis, etc) and you want to test the changes in AOT mode, you should\nuse the following instructions.\n\n1. Build `gen_snapshot`, `vm_platform.dill` and `dartaotruntime` targets using the following command `tools/build.py -m $MODE -a $ARCH --rbe gen_snapshot vm_platform.dill dartaotruntime`. Here `$MODE` specifies preferred compilation mode (`debug` or `release`), `$ARCH` specifies target architecture (e.g. `x64`, `arm64`). Prefer building using `release` mode and prefer using `$ARCH` that matches the host\nunless something else is requested. A combination of `$MODE` and `$ARCH` is called `DART_CONFIGURATION` (e.g. `ReleaseX64` is `release` build targeting `x64`).\n2. Use helper script `pkg/vm/tool/precompiler2 test.dart test.aot` to compile test script `test.dart` to AOT snapshot `test.aot`. To check commands executed by the script you can pass `-v` to the script.\n3. Use `out/${DART_CONFIGURATION}/dartaotruntime test.aot` to execute AOT snapshot.\n4. Use `perf record -g out/${DART_CONFIGURATION}/dartaotruntime test.aot` to profile the code and `perf report` and `perf annotate` to explore performance of different parts of code.\n5. Use `--print-flow-graph` flag to get IL generated by optimizing compiler, `--print-flow-graph-filter=$NAME_STR` allows to filter out only methods which contain $NAME_STR in their fully qualified names. You can also use `--disassemble --code-comments` to dump disassembly annotated with IL instructions. The output produced by all these flags is written to stderr. You can pass these flags to `precompiler2` script.\n6. When making changes to runtime system, AOT compiler or core libraries - always make sure to rebuild Dart SDK components given in the first item of this list before recompiling and rerunning test or benchmark code.\n",".agents/skills/update-native-rev/SKILL.md":"---\nname: update-native-rev\ndescription: Updates the native_rev dependency in the DEPS file with all correct verification, sync, and testing procedures\n---\n\n\n\n# Instructions\n\nUse this skill when you are requested to roll or update the `native_rev` variable (the hash of `third_party/pkg/native` repository) in the `DEPS` file.\n\n## 0. Initial Synchronization\n\nBefore beginning the roll, **ask the user** if the SDK git repository should be switched to the `main` branch and synchronized.\nIf they confirm, run:\n```bash\ngit checkout main && git pull && gclient sync -D -f\n```\n\n## 1. Commit Selection Rules\n\n> [!IMPORTANT]\n> **CRITICAL RULE**: NEVER EVER pick a local commit or a commit from a custom branch/PR branch. You MUST only pick remote commits that have already landed on the remote `main` branch.\n\nTo select the correct commit SHA:\n1. If the `dart.googlesource.com/native.git` mirror is lagging behind GitHub:\n * **For Googlers**: Trigger an immediate mirror sync instead of modifying `DEPS`:\n ```bash\n gob-ctl repos update-mirror-config github/dart-lang/native \\\n --fetch_frequency 5m \\\n --uri https://github.com/dart-lang/native.git\n ```\n Wait ~10 seconds, verify with `git ls-remote https://dart.googlesource.com/native.git refs/heads/main`, and proceed with the default mirrored googlesource setup below.\n * **Otherwise, ask the user** if the newest hash/commit should be taken directly from **GitHub**:\n * **If the user says YES**:\n 1. First, temporarily change the repository URL and host permissions in the `DEPS` file by following the instructions in the **[Troubleshooting Sync Failures](#troubleshooting-sync-failures)** section (changing `third_party/pkg/native` under `deps` to use `\"https://github.com/dart-lang/native.git\"` and adding `'github.com'` to `allowed_hosts` in `DEPS`).\n 2. Run `gclient sync` from the SDK root to update the checkout mapping to GitHub.\n 3. Navigate to the `native` package subdirectory: `third_party/pkg/native`.\n 4. Run `git fetch origin` to fetch the latest commits from the GitHub remote (origin will now point to GitHub).\n 5. After checking commits, **immediately set the repository URL and host permissions in `DEPS` back to googlesource** (reverting the changes made in sub-step 1), so that subsequent steps and the final commit only roll the commit hash without permanently keeping GitHub host settings.\n * **If the user says NO / default**:\n 1. Proceed with the default mirrored googlesource setup.\n 2. Navigate to the `native` package subdirectory: `third_party/pkg/native`.\n 3. Run `git fetch origin` to fetch the latest commits from the mirror.\n2. Inspect the commits on remote `origin/main` of the `native` repository:\n ```bash\n git log origin/main -n 10 --oneline\n ```\n3. Obtain the full SHA of the newest commit on remote `origin/main` (or the specific one that contains the required change):\n ```bash\n git rev-parse origin/main\n ```\n4. **Revert Host to GoogleSource**:\n * **IMPORTANT**: If the host was set to GitHub, you **MUST** now revert the repository URL and allowed hosts changes in the `DEPS` file back to the mirrored googlesource URL, removing `github.com` from `allowed_hosts`. Do this before updating `native_rev` so that the final committed change only rolls the commit hash, not checkout hosts.\n\n## 2. Updating DEPS and Synchronizing\n\n1. Locate `native_rev` in the `DEPS` file (typically under `vars`):\n ```python\n \"native_rev\": \"\",\n```\n2. Replace the hash with the chosen remote `origin/main` commit SHA.\n3. If not already done in step 4 above, ensure the `DEPS` host and URL configuration are reverted to the googlesource mirror, leaving only the updated `native_rev` hash.\n4. Run `gclient sync -f` from the SDK root directory to update the checkout of the dependencies and regenerate the package configuration using the mirror.\n\n### Troubleshooting Sync Failures\nIf the synchronization fails because of host restrictions:\n1. Temporarily modify the repository configuration under `deps` in `DEPS` to use:\n `https://github.com/dart-lang/native.git` as the git repo.\n2. Temporarily add `'github.com'` to the `allowed_hosts` list in `DEPS`.\n3. Re-run `gclient sync -f` to complete the update.\n4. **IMPORTANT**: Immediately after successful syncing, revert the host and URL changes in the `DEPS` file, removing `github.com` from `allowed_hosts` and returning to the mirrored googlesource URL, but keep the newly synced native commit hash.\n\n## 3. Mandatory Testing and Verification\n\nBefore completing the update, you must run the following tests:\n\n### Native Assets Package Tests\nBuild the target SDK and run the primary native asset tests:\n```bash\nRBE_exec_strategy=racing tools/build.py -mrelease create_sdk runtime ffi_test_functions runtime_precompiled && tools/test.py -n unittest-asserts-release-mac-arm64 pkg/dartdev/test/native_assets/\n```\n\n### Record Use Optimization Tests\nSince `record_use` integrates closely with `native_rev` updates, these tests must be validated for both backends (Wasm and VM). **Note**: `record_use` is now 1.0, so breaking changes are not allowed and expectations should NOT need updating.\n\n1. Build the required target backends and run all record use tests:\n ```bash\n RBE_exec_strategy=racing tools/build.py -mrelease create_sdk dart2wasm runtime ffi_test_functions runtime_precompiled && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/compiler/test/record_use/record_use_test.dart && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/dart2wasm/test/record_use_test.dart && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/vm/test/transformations/record_use_test.dart\n ```\n2. **Test Failure Policy**:\n > [!IMPORTANT]\n > Since `record_use` is 1.0, any test failure here indicates an illegal breaking change rather than a need for expectation updates. Do not update expectations; report any failure immediately.\n3. **Running Individual Tests**:\n To debug or verify a single test:\n ```bash\n python3 tools/test.py -n wasm-unittest-asserts-mac pkg/dart2wasm/test/record_use_test.dart\n ```\n\n## 4. Pre-Completion Protocol\n\nFollow these final validation steps before announcing completion:\n\n1. **Format touched files**: Run `dart format` on all modified Dart files.\n2. **Analyze touched files**: Run `dart analyze` to ensure there are no lint or static analysis issues.\n3. **Presubmit checks**: Run `git cl presubmit` to ensure build/format sanity.\n4. **Update Coverage (Front-End changes only)**:\n If any related changes were also introduced in the `front_end` directory, regenerate test coverage:\n ```bash\n dart --enable-asserts pkg/front_end/test/coverage_suite.dart --tasks=5 --add-and-remove-comments\n ```\n * *Critical*: Revert the coverage comment changes in any files that you did not otherwise modify.\n\n## 5. Branching and Committing\n\nAfter all tests pass and formatting/analysis is clean:\n1. **Ask the user** if they want to create a roll branch and commit the changes.\n2. If confirmed, get the current date in `YYYYMMDD` format (e.g., `20260630`) and run:\n ```bash\n git new-branch roll-\n git commit -a -m \"[deps] Roll dart-lang/native\"\n ```\n","pkg/analysis_server/.agents/skills/close-obsolete-issues/SKILL.md":"---\nname: close-obsolete-issues\ndescription: Find obsolete, stale, or not reproducible analysis-server issues in the dart-lang/sdk repository.\n---\n\n# Close Obsolete Issues\n\nUse this skill to find old, outdated issues in the `dart-lang/sdk` repository that have been fixed, are stale, obsolete, or not reproducible.\n\n## Instructions\n\n1. **Identify Target Issues**:\n - Use the GitHub CLI (`gh`) to search for the oldest open issues.\n - Use the label `area-devexp` to identify analysis server issues.\n - Also use label `type-bug` and any other label that the user gives you.\n - **Exclude Labeled Issues**: Exclude issues already labeled `verified-by-an-agent` or `closed-by-an-agent` by adding `-label:verified-by-an-agent -label:closed-by-an-agent` to the search query. These labels are the record of which issues have already been investigated; there is no separate tracking file.\n - Sort by creation date (`created-asc`) or last update (`updated-asc`) to find the most likely candidates for being outdated.\n - Fetch at least 100–150 candidates. Many candidates fail the guardrails in step 2, so 50 usually leaves only a handful. Alternating between `created-asc` and `updated-asc` across runs also helps surface new candidates.\n - Example command (with label): `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open label:type-bug -label:verified-by-an-agent -label:closed-by-an-agent sort:created-asc\" --limit 150 | cat`\n - Example command (without label): `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open -label:verified-by-an-agent -label:closed-by-an-agent sort:created-asc\" --limit 150 | cat`\n - **Re-verify Old Verifications**: A `verified-by-an-agent` label only says that the issue reproduced when the comment was posted. Occasionally (for example, when the searches above return few candidates, or when the user asks), also look at labeled issues that haven't been updated for more than a year, using a date one year before today: `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open label:verified-by-an-agent -label:closed-by-an-agent updated:\" | cat`. See rationale 7 in `references/rationale_templates.md`.\n\n2. **Investigate Status**:\n - **Pre-Qualification Guardrails**: Before evaluating any candidate against obsolete rationales, check the issue metadata. **Abort evaluation and keep the issue open** if any of the following are true:\n 1. *Recent Activity*: The issue has any comment or status change from a user within the last 365 days.\n 2. *Priority/Milestone*: The issue carries a high-priority label (e.g., `P0`, `P1`, `critical`) or is assigned to an active milestone.\n 3. *Corporate Interest*: The issue has active engagement or reproduction steps provided by a Dart/Flutter team member within the last 2 years.\n - For candidates that pass pre-qualification, analyze their description and comments.\n - Use the bundled script `scripts/fetch_issue_details.sh ` to get a comprehensive view of the issue and its comments.\n - **Check for Existing Tests First**: Search the test directories for the issue number, e.g. `grep -rn \"issues/\" test/` (and in `pkg/analyzer/test` or `pkg/linter/test` if relevant). Tests annotated with `@FailingTest(issue: '…/')` are a ready-made reproduction: if they still fail, the bug is still valid; if they now pass, the bug may have been fixed silently.\n - **Verify with a Locally Built SDK**: The `dart` on `PATH`could be an older SDK (for example the one bundled with Flutter). Reproduce with the SDK built from the current checkout, e.g. `/xcodebuild/ReleaseX64/dart-sdk/bin/dart` on macOS or `/out/ReleaseX64/dart-sdk/bin/dart` on Linux. Confirm with `--version` that it matches `HEAD`, and record that version (or commit) for use in your comments.\n - Compare the issue's request or reported bug and subsequent comments with the current state of the codebase.\n - Refer to the data-driven checks in `references/rationale_templates.md` to verify if a rationale applies.\n - **Safety Rule**: Do not assume a bug is fixed or obsolete just because the code has changed or the issue has not been updated for a long time. Verify if the specific bug behavior is still possible. Valid bugs or feature requests should not be closed as stale just because they are old or have no activity. Inactivity alone does not invalidate a feature request or bug report.\n\n3. **Draft and Review Comments (CRITICAL MANDATE)**:\n - **For Candidates for Closure**: For issues identified as candidates for closure, draft a detailed comment for each explaining *why* it can be closed. Consult `references/rationale_templates.md` for wording inspiration. Each comment MUST end with: \"If there is more work to do here, please let us know by filing a new issue with up to date information. Thanks!\"\n - **State the Verification SDK**: Every comment (closure or still-valid) should say which SDK the behavior was verified on, e.g. \"Verified on a local build of `main` (`3.14.0-edge.`)\", so readers can judge how current the finding is.\n - **For Still-Valid Issues**: If you determine that a bug is still valid (reproducible on `HEAD`):\n - Draft a comment confirming that the bug remains reproducible at `HEAD` on the latest SDK.\n - Construct a minimal, self-contained Dart reproduction code example or a formal Dart unit test case (following existing testing patterns in the `test/` directory) demonstrating the issue.\n - If you write a unit test, run it to confirm that it actually fails on `HEAD`, and include the actual (wrong) output in the comment alongside the expected output.\n - Where you can identify it, point to the likely root cause (file and function) so the issue is actionable.\n - Include this reproduction or unit test in your drafted comment to assist developers in fixing the bug.\n - **Revert Temporary Tests**: Tests added to the repository only to verify a bug must be reverted afterwards (e.g. `git checkout `). Leave the working tree as you found it unless the user asks you to fix the bug (see step 6).\n - **Footer Restriction**: Do NOT end comments on still-valid issues with the closure footer (about filing a new issue), as this issue is remaining open.\n - **Required Output Format**: For each evaluated issue, generate your assessment in this structured JSON format so that a coordinator agent or human supervisor can easily parse, validate, and approve your findings:\n ```json\n {\n \"issue_number\": 12345,\n \"issue_url\": \"https://github.com/dart-lang/sdk/issues/12345\",\n \"eligible_for_close\": true,\n \"matched_rationale_id\": 1,\n \"confidence_score\": 0.95,\n \"verification_finding\": \"Verified that standard LSP protocol capabilities natively handle the requested server configuration.\",\n \"proposed_comment\": \"[Full proposed comment including the mandatory footer]\"\n }\n ```\n - **User Approval Required**: You MUST present both (a) the candidates for closure with their drafted comments, and (b) the still-valid issues with their drafted confirmation comments and reproductions, to the user and obtain explicit approval BEFORE running any command that comments on or closes an issue. You can present the JSON findings format directly to the user for review.\n\n4. **Iterate on Skill Knowledge (Learning Loop)**:\n - If you discover a new, distinct category of closing rationale that is not covered in `references/rationale_templates.md`, **update the reference file** to include it.\n\n5. **Execute and Summarize**:\n - **For Approved Closure Candidates**: Use `gh issue close` with the `-c` flag to post the comment and close the issue. Apply the `closed-by-an-agent` label to the issue.\n - **For Approved Still-Valid Issues**: Use `gh issue comment -b \"\"` to post the confirmation comment containing the minimal reproduction / test case. Apply the `verified-by-an-agent` label to the issue using `gh issue edit --add-label \"verified-by-an-agent\"`.\n - **Label Every Still-Valid Issue You Leave Open**: The label is how future runs know to skip an issue, so each investigated issue that stays open should get a confirmation comment and the `verified-by-an-agent` label. Don't apply the label without a comment: if the user decides not to post a comment for an issue, leave it unlabeled, and it may come up again on a later run.\n - Provide the user with a clean bulleted list of closed issues and updated/commented valid issues.\n\n6. **Optional: Fix It (only when the user asks)**:\n - Some still-valid issues are cheap to fix. A good candidate has a **failing unit test** from step 3 and a **localized root cause** (one function or one condition). When you present the step 5 summary, point out which verified issues look like quick fixes; don't start fixing unless the user asks.\n - When fixing:\n - Turn the verification test into a permanent regression test (a link to the issue in a comment is enough). If the fix touches a code path shared by related behaviors (e.g. both `extractAll: true` and `extractAll: false`), add a test for each.\n - If the repository already has `@FailingTest(issue: '…/')` tests for the issue, remove the annotation so they run as normal tests.\n - Run the whole test file for the changed code, plus closely related suites (e.g. the LSP and legacy protocol tests for a refactoring), and run `dart analyze` and `dart format` on the changed files.\n - Call out any intentional behavior change beyond the reported bug so reviewers can weigh it.\n - Suggest a commit message that ends with `Fixes https://github.com/dart-lang/sdk/issues/` so the issue closes automatically when the change lands. Leave committing and uploading to the user unless they ask you to do it.\n - After the fix lands, remove the issue from `references/investigated_issues.txt` (see step 5).\n\n## Tips\n\n- Use available file and content search tools (such as `grep`, `ripgrep`, or environment-specific\nsearch tools) to check the current codebase for references to the issue or relevant code.\n- Look for related Gerrit CLs that might have fixed the issue but didn't close it automatically.\n- **Pro Tip**: Use the `read-gerrit-cl` skill ([SKILL.md](../../../../../.agents/skills/read-gerrit-cl/SKILL.md)) to inspect the patchset diffs and comments of open or merged Gerrit CLs.\n- **Always prioritize active verification on HEAD**: Regardless of how old an issue is or what version it specifies, always attempt to research and reproduce the reported issue against the current `HEAD` of the codebase before proposing closure. Never assume a bug is obsolete or fixed based solely on the passage of time or version discrepancies. If you cannot reproduce it, provide clear details of your reproduction attempt on the current codebase.\n","runtime/tools/pubspec.yaml":"name: runtime_tools\ndescription: Internal runtime tools.\n\nenvironment:\n sdk: ^3.9.0\n\nresolution: workspace\npublish_to: none\n",".agents/rules/add_license_header.md":"---\ntrigger: glob\ndescription: Ensure standard Dart license header on newly created Dart files.\nglobs: *.dart\n---\n\n# License Header Rule\n\nWhenever you create a new Dart (`.dart`) file in this repository, you MUST include the standard Dart project license header at the very top (line 1).\n\nReplace `` with the actual current year (e.g., 2026).\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n```\n\n## Requirements\n- Insert at line 1.\n- Ensure a blank line follows the license header before any other code or comments.\n","pkg/analysis_server/.agents/skills/improve-performance-with-session-log/SKILL.md":"---\nname: improve-performance-with-session-log\ndescription: >-\n Use this skill when diagnosing, reproducing, and improving the performance or\n latency of Dart Analysis Server (DAS) LSP requests and responses using\n recorded session communications logs, log normalization, replay tools, and\n fresh local SDK compilation.\n---\n\n# Improve LSP Performance with Session Logs\n\nThis skill guides you through diagnosing slow LSP request/response interactions\nin the Dart Analysis Server (DAS), reproducing them with the log player replay\ntool, optimizing the server implementation, recompiling the SDK, and validating\nthe latency improvement.\n\n---\n\n## Workflow Overview\n\n```mermaid\nflowchart LR\n A[\"1. Inspect Log\"] --> B[\"2. Normalize Log\"] --> C[\"3. Reproduce & Measure Baseline\"]\n C --> D[\"4. Optimize & Rebuild SDK\"] --> E[\"5. Replay with Built SDK & Validate\"]\n```\n\n1. **Inspect Log**: Locate target requests (e.g. `textDocument/documentColor`,\n `textDocument/completion`) and calculate request-to-response duration\n (`response.time - request.time`).\n2. **Normalize Log**: Replace machine-specific paths with portable placeholders\n (`{{workspaceFolder-0}}`, `{{dartSdkRoot}}`).\n3. **Reproduce Baseline**: Replay the log against the baseline server using\n `server_driver_main.dart` or automated playback, isolating warm request\n latency from cold-start queueing.\n4. **Optimize Code**: Implement performance improvements in `pkg/analysis_server`\n or `pkg/analyzer`.\n5. **Recompile SDK**: From ``, run `python3 tools/build.py -mrelease create_sdk`.\n6. **Replay with the freshly built SDK**: Replay using the newly compiled `dart` binary to\n verify latency reduction and correctness.\n7. **Run unit and integration tests**: Run existing unit tests and add regression tests for\n modified logic.\n\n## Step 1: Inspect the session communications log\n\nSession logs are line-delimited JSON (JSON Lines). Each line is an independent\nJSON object containing `time` and `kind`. Depending on the kind of entry (e.g.\n`message` versus `commandLine`), lines may also have `sender`, `receiver`, and\n`message` (though some entries might omit them).\n\n### Analyze the Log with `analyze_session_log.dart`\n\nThe skill provides\n[`scripts/analyze_session_log.dart`](scripts/analyze_session_log.dart) to parse,\ninspect, and summarize session logs automatically:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/analyze_session_log.dart \\\n [--method=] [--min-ms=] [--warm-only] [--summary] \n```\n\nKey capabilities:\n\n* **Measures Client & Server Durations**: Displays client-perceived duration\n (`response.time - request.clientRequestTime`) and server processing duration\n (`response.time - request.time`).\n* **Detects Cold-Start Queueing**: Identifies whether requests occurred during\n initial background analysis (`$/progress` `\"Analyzing...\"`) or against a warm\n server.\n* **Extracts Errors & Crashes**: Automatically parses and surfaces server\n exceptions (e.g. `Bad state: SimpleIdentifierImpl is not in the V2 AST view`).\n\nExample of inspecting 'textDocument/documentColor' requests in a session:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/analyze_session_log.dart \\\n -m documentColor session-log-2.txt\n```\n\n## Step 2: Normalize the Log\n\nRaw session logs contain absolute paths from the machine where they were\nrecorded. Normalize them to make them replayable against any local workspace:\n\n```bash\ndart /pkg/analysis_server/tool/log_player/normalize.dart \\\n -i \\\n -o \\\n -r \\\n [-p ]\n```\n\nOptions:\n\n* `-i`, `--input`: Path to the raw recorded log file.\n* `-o`, `--output`: Destination path for the normalized log.\n* `-r`, `--root-dir`: Root directory of the project open during recording.\n* `-p`, `--package-config`: (Optional) Explicit path to `package_config.json`\n if not at `/.dart_tool/package_config.json`.\n\nNormalizing replaces machine paths with `{{workspaceFolder-0}}`,\n`{{dartSdkRoot}}`, and package URIs with `{{package-root:...}}`.\n\n---\n\n## Step 3: Reproduce and Measure Baseline Latency\n\n### Automated Replay & Measurement (`measure_request_latency.dart`)\n\nThe skill provides\n[`scripts/measure_request_latency.dart`](scripts/measure_request_latency.dart)\nto automatically replay setup messages up to a target request, wait for\nbackground analysis to finish, and measure wall-clock latency across multiple\niterations:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/measure_request_latency.dart \\\n -i -w -r 3 \n```\n\nOptions:\n\n* `-i`, `--request-id`: (**Required**) The target request ID identified in Step 1\n (e.g. `153`). Always specify this to ensure you benchmark the exact target\n request.\n* `-m`, `--method`: Target request method (e.g. `textDocument/documentColor`).\n Avoid using this without `-i`, as matching by method alone yields the first\n occurrence in the log rather than the slowest or target request.\n* `-w`, `--workspace`: Local project directory to map `{{workspaceFolder-0}}`\n to (defaults to current working directory).\n* `-r`, `--repeat`: Number of iterations to measure consistency (default: 1).\n\n> [!IMPORTANT]\n> **Always use `--request-id` (`-i`)**: Pass the specific request ID found from\n> inspecting or analyzing the log in Step 1. Do not rely on `--method` alone:\n> `--method` only matches the *first* occurrence of that method in the session\n> log, which is often a fast initial request rather than the slow interaction\n> you are trying to optimize.\n\n### Interactive replay (`server_driver_main.dart`)\n\nFor manual inspection and stepping through messages one-by-one:\n\n```bash\ncd /path/to/project/root\ndart /pkg/analysis_server/tool/log_player/server_driver_main.dart /path/to/normalized_log.json\n```\n\n* Press **Enter** to step through messages.\n* Wait for background analysis to finish (`$/progress` `{\"kind\": \"end\"}`) before\n stepping to the target request to measure warm handler latency.\n\n**Note** that this tool can absolutely change the timing of the operations in\nthe log, which can potentially change the **behavior** of the server.\n\n## Step 4: Investigate code and implement optimizations\n\n1. Identify the handler or computer responsible for the request method:\n * Method `textDocument/documentColor` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_document_color.dart` and\n `pkg/analysis_server/lib/src/computer/computer_color.dart`.\n * Method `textDocument/completion` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_completion.dart` and\n `pkg/analysis_server/lib/src/services/completion/`.\n * Method `textDocument/codeAction` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_code_actions.dart`.\n2. Inspect profiling data or trace execution paths for common bottlenecks:\n * **Unnecessary AST traversals**: Are visitors walking AST subtrees that\n cannot contain relevant nodes?\n * **Excessive element resolution or type evaluation**: Can lightweight\n syntactic checks filter out candidates before resolving types or evaluating\n constant values?\n * **Repeated allocations or computations**: Can maps/sets be reused, or early\n exits added?\n3. Apply optimizations in `pkg/analysis_server` or `pkg/analyzer`.\n\n## Step 5: Recompile the Dart SDK\n\nRecompile the analysis server snapshot and SDK binaries:\n\n```bash\n(cd && python3 tools/build.py -mrelease create_sdk)\n```\n\nThe compiled SDK binaries will be located at:\n\n* **macOS**: `xcodebuild/ReleaseARM64/dart-sdk/bin/dart` (or\n `xcodebuild/ReleaseX64/...`)\n* **Linux / Windows**: `out/ReleaseX64/dart-sdk/bin/dart`\n\n## Step 6: Replay with the freshly built SDK\n\n> [!IMPORTANT]\n> `ServerDriver` starts the server process using `Platform.resolvedExecutable`.\n> To run against your freshly built changes, you **must** execute `server_driver_main.dart` (or your replay script) using the compiled `dart` binary, not the system `dart`.\n\n### Running automated replay with the built SDK\n\nRun `measure_request_latency.dart` with the compiled binary to measure latency after changes:\n\n```bash\n \\\n /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/measure_request_latency.dart \\\n -i -w -r 3 /path/to/normalized_log.json\n```\n\n### Interactive stepping with the built SDK\n\n```bash\n \\\n /pkg/analysis_server/tool/log_player/server_driver_main.dart \\\n /path/to/normalized_log.json\n```\n\nIf running from an external project root and package resolution fails, specify\nthe package config:\n\n```bash\n--packages=/.dart_tool/package_config.json\n```\n\n### Validation checklist\n\n- [ ] Confirm the target request returns the exact same valid response payload\n (colors, completions, etc.).\n- [ ] Verify that request execution latency is substantially reduced compared to\n baseline.\n- [ ] Confirm no unhandled exceptions or error responses are produced in the\n server output stream.\n\n## Step 7: Run unit and integration tests\n\nRun relevant existing tests with the compiled Dart binary:\n\n```bash\n test /pkg/analysis_server/test/src/...\n```\n\nAdd new unit tests in the appropriate test suite (e.g.\n`pkg/analysis_server/test/src/computer/...`) to lock in the performance\noptimization and guard against regressions.\n","pkg/dart2js_tools/README.md":"\n### dart2js\\_tools\n\nThis package collects tools used with dart2js.\n\nFor now, this contains scripts useful to work with obfuscated stack traces in\nproduction and reading data from the extensions added to source-maps by dart2js\n(like minified names and inlined stack frames).\n\nIn the future we plan to merge here tools in the dart2js\\_info package as well.\n","pkg/dds_service_extensions/README.md":"[![pub package](https://img.shields.io/pub/v/dds_service_extensions.svg)](https://pub.dev/packages/dds_service_extensions)\n[![package publisher](https://img.shields.io/pub/publisher/dds_service_extensions.svg)](https://pub.dev/packages/dds_service_extensions/publisher)\n\nA package used to expand the `package:vm_service` interface with support for RPCs added in the [Dart Developer Service (DDS) protocol][dds-protocol].\n\n[dds-protocol]: https://github.com/dart-lang/sdk/blob/main/pkg/dds/dds_protocol.md\n","pkg/analysis_server/.agents/skills/implement-a-lint/SKILL.md":"---\nname: implement-a-lint\ndescription: Guide for creating, registering, documenting, and testing a new lint in the Dart SDK.\n---\n\n## Overview\n\nUse this skill when you need to create a new lint in the Dart SDK codebase. It details the step-by-step implementation and testing procedures.\n\n## Target Reference Example\n\nBefore starting, review this existing feature as the canonical implementation model:\n* **Reference Implementation:** `pkg/linter/lib/src/rules/unnecessary_primary_constructor_body.dart`\n* **Reference Test:** `pkg/linter/test/rules/unnecessary_primary_constructor_body_test.dart`\n\n## File Layout & Naming Conventions\n\nWhen implementing a new lint, you will modify or create the following files:\n\n| File Path | Action | Description |\n|---|---|---|\n| `pkg/linter/lib/src/rules/.dart` | **Create** | The main implementation and AST visitor logic. |\n| `pkg/linter/messages.yaml` | **Modify** | Alphabetical diagnostic entry, problem/correction messages, and documentation. |\n| `pkg/linter/lib/src/rules.dart` | **Modify** | Imports and registers the lint class in the linter registry. |\n| `pkg/linter/test/rules/_test.dart` | **Create** | The reflective tests for the new lint. |\n| `pkg/linter/test/rules/all.dart` | **Modify** | Imports and runs the main entry point of the test file. |\n| `pkg/analysis_server/lib/src/services/correction/error_fix_status.yaml` | **Modify** | Records which diagnostics have or should have a fix. |\n\n## Execution Checklist\n\n### 1. Define the diagnostic code(s)\n\nUnless explicitly instructed otherwise by the user, the rule should have a single diagnostic code.\n\nCopy the following structure to define each of the diagnostic codes that the lint will produce. The definitions should be added alphabetically to `pkg/linter/messages.yaml`.\n\n````yaml\n :\n type: lint\n parameters: none\n problemMessage: \"\"\n correctionMessage: \"\"\n state:\n experimental: \"\"\n categories: [style]\n hasPublishedDocs: false\n documentation: |-\n #### Description\n\n The analyzer produces this diagnostic when \n\n #### Example\n\n The following code produces this diagnostic because :\n\n ```dart\n // Bad code here\n ```\n\n #### Common fixes\n\n If , then :\n\n ```dart\n // Good code here\n ```\n deprecatedDetails: |-\n \n````\n\nIf the user has explicitly requested different diagnostic codes for different contexts, then use the template above for each code, alphabetizing the entries. In this case, each code should have a `sharedName:` entry that is the same for all of the codes being added, and that should be the name of the lint rule. The `ruleName` for each entry should then be something like `ruleName_context`. Only one diagnostic code should have the `documentation:` and `deprecatedDetails:` entries (typically the one that is lexically first). These values will be shared by any codes that have the same `sharedName`.\n\nThe presence of the `deprecatedDetails` property is strictly validated by the generator script. You MUST include it, even for newly added lints. The code snippets in this documentation are not validated, so do not include range markers ('[!' '!]') or use any of the `%` directives.\n\nThe `hasPublishedDocs` property must be included and must have a value of `false`. The flag will be changed to `true` after the documentation has been published to the web site.\n\nThe `categories:` property lists the categories that developers can use to discover new lints. Choose from the following allowed categories: `binarySize`, `brevity`, `documentationCommentMaintenance`, `effectiveDart`, `errorProne`, `flutter`, `languageFeatureUsage`, `memoryLeaks`, `nonPerformant`, `pub`, `publicInterface`, `style`, `unintentional`, `unusedCode`, `web`.\n\nRun the following commands to update the generated files (`lint_names.g.dart`, `diagnostic.g.dart`, etc.):\n\n```bash\ndart run pkg/linter/tool/generate_lints.dart\ndart run pkg/analyzer/tool/messages/generate.dart\n```\n\n**BEFORE CONTINUING TO THE NEXT STEP:**\n\nRun `dart test pkg/analyzer/test/verify_diagnostics_test.dart` to verify that the example and fixes code in the documentation is correct. Make changes as necessary to get the test to pass, re-running the test until it passes. If you modify the `messages.yaml` file then you must re-run the generators before re-testing.\n\n### 2. Implement the lint\n\nIf the lint is dependent on a language experiment, and that experiment is not enabled by default, confirm that the list of experiments returned by `experimentsForTests` in `pkg/analyzer_testing/lib/experiments/experiments.dart` includes the experiment. If not, add it.\n\nNote that a new lint should use the next version of the Dart SDK for the `since` property in the `AnalysisRule` constructor.\n\nCreate an implementation of the lint in the file `pkg/linter/lib/src/rules/.dart` by copying the following template:\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n\nimport 'package:analyzer/analysis_rule/analysis_rule.dart';\nimport 'package:analyzer/analysis_rule/rule_context.dart';\nimport 'package:analyzer/analysis_rule/rule_visitor_registry.dart';\nimport 'package:analyzer/dart/ast/ast.dart';\nimport 'package:analyzer/dart/ast/visitor.dart';\n\nimport '../analyzer.dart';\nimport '../diagnostic.dart' as diag;\n\nconst _desc = r'';\n\n/// \nclass extends AnalysisRule {\n new() : super(\n name: LintNames.,\n description: _desc,\n state: RuleState.experimental(since: .new(, , 0)),\n );\n\n @override\n DiagnosticCode get diagnosticCode => diag.ruleName;\n\n @override\n void registerNodeProcessors(\n RuleVisitorRegistry registry,\n RuleContext context,\n ) {\n var visitor = _Visitor(this, context);\n // \n }\n}\n\nclass _Visitor(final AnalysisRule rule, final RuleContext context)\n extends SimpleAstVisitor {\n // \n}\n```\n\nThere must be a visit method for every registered node type and there must be a registration for every `visit` method.\n\nUse either `rule.reportAtToken(token)` or `rule.reportAtNode(node)` to emit the diagnostics. Prefer using `rule.reportAtToken(token)` to report at a single token.\n\nIf the lint produces multiple diagnostic codes, make the implementation class a subclass of `MultiAnalysisRule`. For rules with multiple diagnostic codes:\n1. Extend `MultiAnalysisRule` instead of `AnalysisRule`.\n2. Override `diagnosticCodes` (plural) returning a list of codes instead of `diagnosticCode` (singular):\n ```dart\n @override\n List get diagnosticCodes => [\n diag.ruleName_contextOne,\n diag.ruleName_contextTwo,\n ];\n ```\n3. Provide the specific diagnostic code when reporting:\n ```dart\n rule.reportAtToken(token, diagnosticCode: diag.ruleName_contextOne);\n ```\n\n#### Useful Analyzer APIs for Lint Logic\n\n- Unwrapping Parentheses: Use `node.unParenthesized` to inspect the target of an expression without manually traversing parenthesized wrappers.\n- Element Model: Use `node.declaredFragment?.element` to retrieve the `Element` corresponding to the declared node.\n- Experiment/Feature Flags: Use `context.isFeatureEnabled(Feature.feature_name)` to conditionally enable or check features.\n\n#### Useful tools\n\n- The tool `pkg/linter/tool/spelunk.dart` can be used to print/dump the AST of a given file. This might be helpful to determine which AST node types need to be visited.\n\n**BEFORE CONTINUING TO THE NEXT STEP:**\n\nEnsure that the implementation passes `dart analyze` without any diagnostics. If there are diagnostics, you must fix them before proceeding.\n\n### 3. Register the lint\n\nAfter the class is written, modify `pkg/linter/lib/src/rules.dart` to import your rule and register it alphabetically:\n\n```dart\n ..registerLintRule(RuleName())\n```\n\n### 4. Record the status of the lint's fixes\n\nEdit the file `pkg/analysis_server/lib/src/services/correction/error_fix_status.yaml` to indicate that the lint needs to be evaluated to determine whether one or more fixes should be provided. Do this by alphabetically adding an entry of the form\n```yaml\n:\n status: needsEvaluation\n```\n\n### 5. Write tests for the lint\n\nCreate a reflective test suite in the file `pkg/linter/test/rules/_test.dart` by copying the following template:\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n\nimport 'package:test_reflective_loader/test_reflective_loader.dart';\n\nimport '../rule_test_support.dart';\n\nvoid main() {\n defineReflectiveSuite(() {\n defineReflectiveTests(Test);\n });\n}\n\n@reflectiveTest\nclass Test extends LintRuleTest {\n @override\n String get lintRule => LintNames.;\n\n // \n}\n```\n\nUse `assertDiagnosticsFromMarkup` to test cases where a diagnostic is expected and `assertNoDiagnostics` to test cases where a diagnostic is not expected. Do not use `assertDiagnostics`.\n\nIf the implementation of the lint has any conditions that must be true in order for the diagnostic to be generated, ensure that there is at least one test for each condition that shows that the diagnostic is not generated when the condition is false.\n\nIf the lint is dependent on a language experiment, then tests that verify the behavior of the lint when the experiment is not enabled must include a language override comment in the test code. The version should be the version before the experiment was introduced, which is given as the `experimentalReleaseVersion` key in `pkg/analyzer/lib/src/dart/analysis/experiments.g.dart`. If the release version is `null`, then use the current Dart SDK version.\n\nLinter tests run against a lightweight mocked SDK (`pkg/analyzer/lib/src/test_utilities/mock_sdk.dart`) rather than the real disk SDK. If a test references standard library APIs (e.g. `Iterable`) and the test fails because the API isn't found, try using a different API or enhance the mock SDK to include the APIs.\n\n### 6. Run the tests\n\nExecute the tests directly using the `dart test` runner:\n\n```bash\ndart test pkg/linter/test/rules/_test.dart\n```\n\nIf the tests don't pass, then either fix the implementation or fix the test, as appropriate.\n\nAfter the tests that you added are passing, run\n```bash\ndart run pkg/linter/test/all.dart\ndart run pkg/analyzer/test/test_all.dart\ndart run pkg/analysis_server/test/test_all.dart\n```\n\nThese will usually all pass at this point, but will sometimes fail. If they do, fix the failures and repeat the test commands until they all pass.\n\n### 7. Verify that the code is error free and formatted correctly\n\nVerify that every file that was either created or modified analyzes cleanly (no diagnostics):\n\n```bash\ndart analyze \n```\n\nIf any diagnostics are reported, attempt to fix them by running:\n\n```bash\ndart fix \n```\n\nThen rerun `dart analyze`. If there are still diagnostics, fix them directly. Repeat until `dart analyze` reports no diagnostics.\n\nThen run the following command on all created or modified files, but not on generated files:\n```bash\ndart format \n```\n","runtime/tools/dartfuzz/README.md":"# dartfuzz Documentation\n\nPath: `runtime/tools/dartfuzz/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/README.md)","runtime/tools/dartfuzz/README_minimize.md":"# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/README_minimize.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/README_minimize.md)","runtime/tools/dartfuzz/analysis_options.yaml":"# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/analysis_options.yaml)","runtime/tools/dartfuzz/pubspec.yaml":"# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/pubspec.yaml)","runtime/tools/entitlements/README.md":"# entitlements Documentation\n\nPath: `runtime/tools/entitlements/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/entitlements/README.md)","runtime/tools/heapsnapshot/CHANGELOG.md":"# Heapsnapshot Skill\n\nPath: `runtime/tools/heapsnapshot/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/CHANGELOG.md)","runtime/tools/heapsnapshot/README.md":"# heapsnapshot Documentation\n\nPath: `runtime/tools/heapsnapshot/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/README.md)","runtime/tools/heapsnapshot/pubspec.yaml":"# Heapsnapshot Skill\n\nPath: `runtime/tools/heapsnapshot/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/pubspec.yaml)","runtime/tools/profiling/CHANGELOG.md":"# Profiling Skill\n\nPath: `runtime/tools/profiling/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/CHANGELOG.md)","runtime/tools/profiling/README.md":"# profiling Documentation\n\nPath: `runtime/tools/profiling/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/README.md)","runtime/tools/profiling/analysis_options.yaml":"# Profiling Skill\n\nPath: `runtime/tools/profiling/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/analysis_options.yaml)","runtime/tools/profiling/pubspec.yaml":"# Profiling Skill\n\nPath: `runtime/tools/profiling/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/pubspec.yaml)","runtime/tools/wiki/README.md":"# wiki Documentation\n\nPath: `runtime/tools/wiki/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/wiki/README.md)","pkg/linter/test/rules/analysis_options.yaml":"# Rules Skill\n\nPath: `pkg/linter/test/rules/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/linter/test/rules/analysis_options.yaml)","pkg/front_end/testcases/extensions/as_show/libraries.json":"# As_show Skill\n\nPath: `pkg/front_end/testcases/extensions/as_show/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/as_show/libraries.json)","pkg/front_end/testcases/extensions/patch/libraries.json":"# Patch Skill\n\nPath: `pkg/front_end/testcases/extensions/patch/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/patch/libraries.json)","pkg/front_end/testcases/extensions/patching/libraries.json":"# Patching Skill\n\nPath: `pkg/front_end/testcases/extensions/patching/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/patching/libraries.json)","pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md":"# References Skill\n\nPath: `pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md)"},"items":[{"name":"add_license_header.md","path":".agents/rules/add_license_header.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/.agents/rules/add_license_header.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\ntrigger: glob\ndescription: Ensure standard Dart license header on newly created Dart files.\nglobs: *.dart\n---\n\n# License Header Rule\n\nWhenever you create a new Dart (`.dart`) file in this repository, you MUST include the standard Dart project license header at the very top (line 1).\n\nReplace `` with the actual current year (e.g., 2026).\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n```\n\n## Requirements\n- Insert at line 1.\n- Ensure a blank line follows the license header before any other code or comments.\n","isInternal":false,"tokens":164,"sizeBytes":717},{"name":"SKILL.md","path":".agents/skills/dart-aot-development/SKILL.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/.agents/skills/dart-aot-development/SKILL.md","title":"dart-aot-development","category":"anthropic-skill","format":"markdown","content":"---\nname: dart-aot-development\ndescription: Instructions on building and testing changes using Dart AOT mode. Use when working on Dart runtime, Dart AOT compiler or other related components.\n---\n\n# Testing changes to Dart SDK in AOT mode\n\nIf you are making changes to Dart SDK (including but not limited to modifying\nDart VM runtime, Dart VM compiler pipeline, Dart common front-end, Dart type\nflow analysis, etc) and you want to test the changes in AOT mode, you should\nuse the following instructions.\n\n1. Build `gen_snapshot`, `vm_platform.dill` and `dartaotruntime` targets using the following command `tools/build.py -m $MODE -a $ARCH --rbe gen_snapshot vm_platform.dill dartaotruntime`. Here `$MODE` specifies preferred compilation mode (`debug` or `release`), `$ARCH` specifies target architecture (e.g. `x64`, `arm64`). Prefer building using `release` mode and prefer using `$ARCH` that matches the host\nunless something else is requested. A combination of `$MODE` and `$ARCH` is called `DART_CONFIGURATION` (e.g. `ReleaseX64` is `release` build targeting `x64`).\n2. Use helper script `pkg/vm/tool/precompiler2 test.dart test.aot` to compile test script `test.dart` to AOT snapshot `test.aot`. To check commands executed by the script you can pass `-v` to the script.\n3. Use `out/${DART_CONFIGURATION}/dartaotruntime test.aot` to execute AOT snapshot.\n4. Use `perf record -g out/${DART_CONFIGURATION}/dartaotruntime test.aot` to profile the code and `perf report` and `perf annotate` to explore performance of different parts of code.\n5. Use `--print-flow-graph` flag to get IL generated by optimizing compiler, `--print-flow-graph-filter=$NAME_STR` allows to filter out only methods which contain $NAME_STR in their fully qualified names. You can also use `--disassemble --code-comments` to dump disassembly annotated with IL instructions. The output produced by all these flags is written to stderr. You can pass these flags to `precompiler2` script.\n6. When making changes to runtime system, AOT compiler or core libraries - always make sure to rebuild Dart SDK components given in the first item of this list before recompiling and rerunning test or benchmark code.\n","frontmatter":{"name":"dart-aot-development","description":"Instructions on building and testing changes using Dart AOT mode. Use when working on Dart runtime, Dart AOT compiler or other related components."},"isInternal":false,"tokens":512,"sizeBytes":2177},{"name":"SKILL.md","path":".agents/skills/find-release-for-commit/SKILL.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/.agents/skills/find-release-for-commit/SKILL.md","title":"find-release-for-commit","category":"anthropic-skill","format":"markdown","content":"---\nname: find-release-for-commit\ndescription: Find which Dart/Flutter releases contain a specific commit sha.\n---\n\n# Instructions\n\nUse this skill to determine which releases a specific commit SHA (Dart or Flutter) first appeared in.\nThis is useful for identifying the earliest SDK version that includes a given feature, fix, or change.\n\n## Tool Usage\n\nRun the `tools/find_release.dart` script from the root of the SDK (`../../../` relative to this file) to discover the releases for a given commit SHA.\n\n```bash\ndart tools/find_release.dart --commit= --channel=\n```\n\n### Arguments\n\n1. `--commit=` (required): The SHA of the commit.\n2. `--channel=` (required): The channel to search in.\n\n### Example\n\nTo find which releases contain commit `abcdef123...` on the `stable` channel:\n\n```bash\ndart tools/find_release.dart --commit=abcdef123... --channel=stable\n```\n\nThe output will include:\n\n- Whether the commit was found in the Dart or Flutter repository.\n- The lowest (earliest) git release tag containing that commit.\n- The corresponding official Flutter release (if found).\n- The corresponding official Dart SDK release (if found).\n\n## Important Considerations\n\n- **Git Tags vs. Official Releases**: The tool first identifies the lowest git tag that includes the commit. However, the presence of a tag (especially a `-dev` tag) **does not guarantee that an official SDK release has being published for that version.**\n- **Verification**: You should look for the \"Lowest Dart release\" or \"Lowest Flutter release\" in the tool's output to confirm that the commit has actually reached a released state. If the tool reports \"No Dart releases found that were newer than \", then the commit has not yet reached any official released version on that channel.\n- **Reporting**: When communicating the findings, distinguish clearly between the git tag it first appeared in and the earliest official release (if any).\n","frontmatter":{"name":"find-release-for-commit","description":"Find which Dart/Flutter releases contain a specific commit sha."},"isInternal":false,"tokens":420,"sizeBytes":1949},{"name":"SKILL.md","path":".agents/skills/read-gerrit-cl/SKILL.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/.agents/skills/read-gerrit-cl/SKILL.md","title":"read-gerrit-cl","category":"anthropic-skill","format":"markdown","content":"---\nname: read-gerrit-cl\ndescription: Fetch and display the full patch/diff or comments for a Gerrit CL.\n---\n\n# Instructions\n\nUse this skill to inspect a Gerrit Change List (CL).\nThis is useful for reviewing code changes, understanding the scope of a modification, checking comments.\n\n## Requirements\n\nThe following command-line tools are required:\n\n- `curl`: For making HTTP requests.\n- `jq`: For parsing JSON (needed for comments).\n- `base64`: For decoding patch content (needed for patches).\n\n## Scripts\n\n### 1. Read Patch\n\nRun the `read_patch.sh` script to fetch the unified diff of a CL.\n\n#### Usage\n\n```bash\n./scripts/read_patch.sh [patchset]\n```\n\n#### Arguments\n\n1. `change_number`: The numeric ID of the Gerrit change (e.g., `12345`).\n2. `patchset` (optional): The patchset number or `current` (default).\n\n#### Example\n\nTo fetch the patch for CL 12345 (latest revision):\n\n```bash\n./scripts/read_patch.sh 12345\n```\n\nTo fetch a specific revision (e.g. patchset 2):\n\n```bash\n./scripts/read_patch.sh 12345 2\n```\n\nThe output will be the unified diff format of the patch.\n\n### 2. Read Comments\n\nRun the `read_comments.sh` script to fetch the comments on a CL.\n\n#### Usage\n\n```bash\n./scripts/read_comments.sh \n```\n\n#### Arguments\n\n1. `change_number`: The numeric ID of the Gerrit change (e.g., `12345`).\n\n#### Example\n\nTo fetch comments for CL 12345:\n\n```bash\n./scripts/read_comments.sh 12345\n```\n\nThe output will be a JSON object containing the comments.\n","frontmatter":{"name":"read-gerrit-cl","description":"Fetch and display the full patch/diff or comments for a Gerrit CL."},"isInternal":false,"tokens":380,"sizeBytes":1491},{"name":"SKILL.md","path":".agents/skills/update-dependency/SKILL.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/.agents/skills/update-dependency/SKILL.md","title":"update-dependency","category":"anthropic-skill","format":"markdown","content":"---\nname: update-dependency\ndescription: Updates third party dependencies in the Dart SDK\n---\n\n# Instructions\n\nUse this skill to update dependencies in the Dart SDK's `DEPS` file to their\nlatest (or a specific) version. This tool automates the process of updating\nthe version, syncing dependencies, updating package configurations, and\ncreating a CL.\n\n## Prerequisites\n\nBefore running the tool, ensure your environment is prepared correctly:\n\n1. **Clean Git State**: Your git checkout MUST be clean. No uncommitted\n changes should be present.\n2. **On Main Branch**: You MUST be on the `main` branch. The tool creates a\n new branch from your current HEAD, so being on `main` ensures the bump\n starts from a clean baseline.\n\n## Tool Usage\n\nRun the `tools/manage_deps.dart` script with the `bump` command from the root\nof the SDK.\n\n### Command Syntax\n\n```bash\ndart tools/manage_deps.dart bump \\\n [--branch ] [--target ]\n```\n\n### Arguments\n\n1. `` (required): The path to the dependency directory\n relative to the SDK root. Dependencies are entire repositories and not\n packages, so the path will usually be `third_party/pkg/`.\n - **CRITICAL**: DO NOT include a trailing slash in the path.\n - If unsure of the repository, you can look at the\n `.dart_tool/package_config.json` file relative to the SDK root, and search\n for `\"name\": \"\"`. Next to that you should see a \"rootUri\"\n key which will give you the path to the dependency. Do not use the full\n path though, just the top level directory under `third_party/pkg/`,\n since entire repos are always rolled at once.\n - If the `.dart_tool/package_config.json` file does not exist, it can be\n generated by running `gclient sync`.\n2. `--branch ` (optional): The name of the branch to create for\n this update. Defaults to `bump_`.\n3. `--target ` (optional): The specific git ref (SHA, tag, branch) to\n update to. Defaults to the latest version on the remote's default branch.\n\n## Example\n\nTo bump the `unified_analytics` dependency, which is a part of the `tools` repo:\n\n```bash\ndart tools/manage_deps.dart bump third_party/pkg/tools\n```\n\n## Troubleshooting\n\n- **\"Already at - nothing to do\" (or missing recent GitHub commit)**:\n The dependency is already at the latest version on the mirror, or the\n `dart.googlesource.com` mirror has not yet synced a recently merged GitHub\n commit.\n - **For Googlers**: If a commit recently landed on GitHub (check with\n `git ls-remote https://github.com//.git refs/heads/main`, where\n `` is typically `dart-lang`) but is not yet on\n `https://dart.googlesource.com/.git`, trigger an immediate mirror\n fetch:\n ```bash\n gob-ctl repos update-mirror-config github// \\\n --fetch_frequency 5m \\\n --uri https://github.com//.git\n ```\n Wait ~10 seconds, verify with\n `git ls-remote https://dart.googlesource.com/.git refs/heads/main`,\n and rerun `tools/manage_deps.dart`.\n- **Branch already exists**: If the tool says a branch with the target name\n already exists, you will be prompted to delete it. Usually, it is safe to say\n \"y\" if you want a fresh bump.\n- **\"CorpSSO login required. To log in, run glogin or gcert\"**: This indicates a\n Google-internal SSO authentication failure during fetching/syncing\n dependencies. This error and the suggested fix (`gcert` / `glogin`) are only\n applicable for Googlers. Since this requires interactive authentication, you\n must ask the user to run `gcert` (or `glogin`) in their terminal to\n authenticate, and then retry.\n","frontmatter":{"name":"update-dependency","description":"Updates third party dependencies in the Dart SDK"},"isInternal":false,"tokens":924,"sizeBytes":3726},{"name":"SKILL.md","path":".agents/skills/update-native-rev/SKILL.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/.agents/skills/update-native-rev/SKILL.md","title":"update-native-rev","category":"anthropic-skill","format":"markdown","content":"---\nname: update-native-rev\ndescription: Updates the native_rev dependency in the DEPS file with all correct verification, sync, and testing procedures\n---\n\n\n\n# Instructions\n\nUse this skill when you are requested to roll or update the `native_rev` variable (the hash of `third_party/pkg/native` repository) in the `DEPS` file.\n\n## 0. Initial Synchronization\n\nBefore beginning the roll, **ask the user** if the SDK git repository should be switched to the `main` branch and synchronized.\nIf they confirm, run:\n```bash\ngit checkout main && git pull && gclient sync -D -f\n```\n\n## 1. Commit Selection Rules\n\n> [!IMPORTANT]\n> **CRITICAL RULE**: NEVER EVER pick a local commit or a commit from a custom branch/PR branch. You MUST only pick remote commits that have already landed on the remote `main` branch.\n\nTo select the correct commit SHA:\n1. If the `dart.googlesource.com/native.git` mirror is lagging behind GitHub:\n * **For Googlers**: Trigger an immediate mirror sync instead of modifying `DEPS`:\n ```bash\n gob-ctl repos update-mirror-config github/dart-lang/native \\\n --fetch_frequency 5m \\\n --uri https://github.com/dart-lang/native.git\n ```\n Wait ~10 seconds, verify with `git ls-remote https://dart.googlesource.com/native.git refs/heads/main`, and proceed with the default mirrored googlesource setup below.\n * **Otherwise, ask the user** if the newest hash/commit should be taken directly from **GitHub**:\n * **If the user says YES**:\n 1. First, temporarily change the repository URL and host permissions in the `DEPS` file by following the instructions in the **[Troubleshooting Sync Failures](#troubleshooting-sync-failures)** section (changing `third_party/pkg/native` under `deps` to use `\"https://github.com/dart-lang/native.git\"` and adding `'github.com'` to `allowed_hosts` in `DEPS`).\n 2. Run `gclient sync` from the SDK root to update the checkout mapping to GitHub.\n 3. Navigate to the `native` package subdirectory: `third_party/pkg/native`.\n 4. Run `git fetch origin` to fetch the latest commits from the GitHub remote (origin will now point to GitHub).\n 5. After checking commits, **immediately set the repository URL and host permissions in `DEPS` back to googlesource** (reverting the changes made in sub-step 1), so that subsequent steps and the final commit only roll the commit hash without permanently keeping GitHub host settings.\n * **If the user says NO / default**:\n 1. Proceed with the default mirrored googlesource setup.\n 2. Navigate to the `native` package subdirectory: `third_party/pkg/native`.\n 3. Run `git fetch origin` to fetch the latest commits from the mirror.\n2. Inspect the commits on remote `origin/main` of the `native` repository:\n ```bash\n git log origin/main -n 10 --oneline\n ```\n3. Obtain the full SHA of the newest commit on remote `origin/main` (or the specific one that contains the required change):\n ```bash\n git rev-parse origin/main\n ```\n4. **Revert Host to GoogleSource**:\n * **IMPORTANT**: If the host was set to GitHub, you **MUST** now revert the repository URL and allowed hosts changes in the `DEPS` file back to the mirrored googlesource URL, removing `github.com` from `allowed_hosts`. Do this before updating `native_rev` so that the final committed change only rolls the commit hash, not checkout hosts.\n\n## 2. Updating DEPS and Synchronizing\n\n1. Locate `native_rev` in the `DEPS` file (typically under `vars`):\n ```python\n \"native_rev\": \"\",\n```\n2. Replace the hash with the chosen remote `origin/main` commit SHA.\n3. If not already done in step 4 above, ensure the `DEPS` host and URL configuration are reverted to the googlesource mirror, leaving only the updated `native_rev` hash.\n4. Run `gclient sync -f` from the SDK root directory to update the checkout of the dependencies and regenerate the package configuration using the mirror.\n\n### Troubleshooting Sync Failures\nIf the synchronization fails because of host restrictions:\n1. Temporarily modify the repository configuration under `deps` in `DEPS` to use:\n `https://github.com/dart-lang/native.git` as the git repo.\n2. Temporarily add `'github.com'` to the `allowed_hosts` list in `DEPS`.\n3. Re-run `gclient sync -f` to complete the update.\n4. **IMPORTANT**: Immediately after successful syncing, revert the host and URL changes in the `DEPS` file, removing `github.com` from `allowed_hosts` and returning to the mirrored googlesource URL, but keep the newly synced native commit hash.\n\n## 3. Mandatory Testing and Verification\n\nBefore completing the update, you must run the following tests:\n\n### Native Assets Package Tests\nBuild the target SDK and run the primary native asset tests:\n```bash\nRBE_exec_strategy=racing tools/build.py -mrelease create_sdk runtime ffi_test_functions runtime_precompiled && tools/test.py -n unittest-asserts-release-mac-arm64 pkg/dartdev/test/native_assets/\n```\n\n### Record Use Optimization Tests\nSince `record_use` integrates closely with `native_rev` updates, these tests must be validated for both backends (Wasm and VM). **Note**: `record_use` is now 1.0, so breaking changes are not allowed and expectations should NOT need updating.\n\n1. Build the required target backends and run all record use tests:\n ```bash\n RBE_exec_strategy=racing tools/build.py -mrelease create_sdk dart2wasm runtime ffi_test_functions runtime_precompiled && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/compiler/test/record_use/record_use_test.dart && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/dart2wasm/test/record_use_test.dart && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/vm/test/transformations/record_use_test.dart\n ```\n2. **Test Failure Policy**:\n > [!IMPORTANT]\n > Since `record_use` is 1.0, any test failure here indicates an illegal breaking change rather than a need for expectation updates. Do not update expectations; report any failure immediately.\n3. **Running Individual Tests**:\n To debug or verify a single test:\n ```bash\n python3 tools/test.py -n wasm-unittest-asserts-mac pkg/dart2wasm/test/record_use_test.dart\n ```\n\n## 4. Pre-Completion Protocol\n\nFollow these final validation steps before announcing completion:\n\n1. **Format touched files**: Run `dart format` on all modified Dart files.\n2. **Analyze touched files**: Run `dart analyze` to ensure there are no lint or static analysis issues.\n3. **Presubmit checks**: Run `git cl presubmit` to ensure build/format sanity.\n4. **Update Coverage (Front-End changes only)**:\n If any related changes were also introduced in the `front_end` directory, regenerate test coverage:\n ```bash\n dart --enable-asserts pkg/front_end/test/coverage_suite.dart --tasks=5 --add-and-remove-comments\n ```\n * *Critical*: Revert the coverage comment changes in any files that you did not otherwise modify.\n\n## 5. Branching and Committing\n\nAfter all tests pass and formatting/analysis is clean:\n1. **Ask the user** if they want to create a roll branch and commit the changes.\n2. If confirmed, get the current date in `YYYYMMDD` format (e.g., `20260630`) and run:\n ```bash\n git new-branch roll-\n git commit -a -m \"[deps] Roll dart-lang/native\"\n ```\n","frontmatter":{"name":"update-native-rev","description":"Updates the native_rev dependency in the DEPS file with all correct verification, sync, and testing procedures"},"isInternal":false,"tokens":1786,"sizeBytes":7432},{"name":"rationale_templates.md","path":"pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md)","tokens":300,"sizeBytes":293},{"name":"SKILL.md","path":"pkg/analysis_server/.agents/skills/close-obsolete-issues/SKILL.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/analysis_server/.agents/skills/close-obsolete-issues/SKILL.md","title":"close-obsolete-issues","category":"anthropic-skill","format":"markdown","content":"---\nname: close-obsolete-issues\ndescription: Find obsolete, stale, or not reproducible analysis-server issues in the dart-lang/sdk repository.\n---\n\n# Close Obsolete Issues\n\nUse this skill to find old, outdated issues in the `dart-lang/sdk` repository that have been fixed, are stale, obsolete, or not reproducible.\n\n## Instructions\n\n1. **Identify Target Issues**:\n - Use the GitHub CLI (`gh`) to search for the oldest open issues.\n - Use the label `area-devexp` to identify analysis server issues.\n - Also use label `type-bug` and any other label that the user gives you.\n - **Exclude Labeled Issues**: Exclude issues already labeled `verified-by-an-agent` or `closed-by-an-agent` by adding `-label:verified-by-an-agent -label:closed-by-an-agent` to the search query. These labels are the record of which issues have already been investigated; there is no separate tracking file.\n - Sort by creation date (`created-asc`) or last update (`updated-asc`) to find the most likely candidates for being outdated.\n - Fetch at least 100–150 candidates. Many candidates fail the guardrails in step 2, so 50 usually leaves only a handful. Alternating between `created-asc` and `updated-asc` across runs also helps surface new candidates.\n - Example command (with label): `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open label:type-bug -label:verified-by-an-agent -label:closed-by-an-agent sort:created-asc\" --limit 150 | cat`\n - Example command (without label): `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open -label:verified-by-an-agent -label:closed-by-an-agent sort:created-asc\" --limit 150 | cat`\n - **Re-verify Old Verifications**: A `verified-by-an-agent` label only says that the issue reproduced when the comment was posted. Occasionally (for example, when the searches above return few candidates, or when the user asks), also look at labeled issues that haven't been updated for more than a year, using a date one year before today: `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open label:verified-by-an-agent -label:closed-by-an-agent updated:\" | cat`. See rationale 7 in `references/rationale_templates.md`.\n\n2. **Investigate Status**:\n - **Pre-Qualification Guardrails**: Before evaluating any candidate against obsolete rationales, check the issue metadata. **Abort evaluation and keep the issue open** if any of the following are true:\n 1. *Recent Activity*: The issue has any comment or status change from a user within the last 365 days.\n 2. *Priority/Milestone*: The issue carries a high-priority label (e.g., `P0`, `P1`, `critical`) or is assigned to an active milestone.\n 3. *Corporate Interest*: The issue has active engagement or reproduction steps provided by a Dart/Flutter team member within the last 2 years.\n - For candidates that pass pre-qualification, analyze their description and comments.\n - Use the bundled script `scripts/fetch_issue_details.sh ` to get a comprehensive view of the issue and its comments.\n - **Check for Existing Tests First**: Search the test directories for the issue number, e.g. `grep -rn \"issues/\" test/` (and in `pkg/analyzer/test` or `pkg/linter/test` if relevant). Tests annotated with `@FailingTest(issue: '…/')` are a ready-made reproduction: if they still fail, the bug is still valid; if they now pass, the bug may have been fixed silently.\n - **Verify with a Locally Built SDK**: The `dart` on `PATH`could be an older SDK (for example the one bundled with Flutter). Reproduce with the SDK built from the current checkout, e.g. `/xcodebuild/ReleaseX64/dart-sdk/bin/dart` on macOS or `/out/ReleaseX64/dart-sdk/bin/dart` on Linux. Confirm with `--version` that it matches `HEAD`, and record that version (or commit) for use in your comments.\n - Compare the issue's request or reported bug and subsequent comments with the current state of the codebase.\n - Refer to the data-driven checks in `references/rationale_templates.md` to verify if a rationale applies.\n - **Safety Rule**: Do not assume a bug is fixed or obsolete just because the code has changed or the issue has not been updated for a long time. Verify if the specific bug behavior is still possible. Valid bugs or feature requests should not be closed as stale just because they are old or have no activity. Inactivity alone does not invalidate a feature request or bug report.\n\n3. **Draft and Review Comments (CRITICAL MANDATE)**:\n - **For Candidates for Closure**: For issues identified as candidates for closure, draft a detailed comment for each explaining *why* it can be closed. Consult `references/rationale_templates.md` for wording inspiration. Each comment MUST end with: \"If there is more work to do here, please let us know by filing a new issue with up to date information. Thanks!\"\n - **State the Verification SDK**: Every comment (closure or still-valid) should say which SDK the behavior was verified on, e.g. \"Verified on a local build of `main` (`3.14.0-edge.`)\", so readers can judge how current the finding is.\n - **For Still-Valid Issues**: If you determine that a bug is still valid (reproducible on `HEAD`):\n - Draft a comment confirming that the bug remains reproducible at `HEAD` on the latest SDK.\n - Construct a minimal, self-contained Dart reproduction code example or a formal Dart unit test case (following existing testing patterns in the `test/` directory) demonstrating the issue.\n - If you write a unit test, run it to confirm that it actually fails on `HEAD`, and include the actual (wrong) output in the comment alongside the expected output.\n - Where you can identify it, point to the likely root cause (file and function) so the issue is actionable.\n - Include this reproduction or unit test in your drafted comment to assist developers in fixing the bug.\n - **Revert Temporary Tests**: Tests added to the repository only to verify a bug must be reverted afterwards (e.g. `git checkout `). Leave the working tree as you found it unless the user asks you to fix the bug (see step 6).\n - **Footer Restriction**: Do NOT end comments on still-valid issues with the closure footer (about filing a new issue), as this issue is remaining open.\n - **Required Output Format**: For each evaluated issue, generate your assessment in this structured JSON format so that a coordinator agent or human supervisor can easily parse, validate, and approve your findings:\n ```json\n {\n \"issue_number\": 12345,\n \"issue_url\": \"https://github.com/dart-lang/sdk/issues/12345\",\n \"eligible_for_close\": true,\n \"matched_rationale_id\": 1,\n \"confidence_score\": 0.95,\n \"verification_finding\": \"Verified that standard LSP protocol capabilities natively handle the requested server configuration.\",\n \"proposed_comment\": \"[Full proposed comment including the mandatory footer]\"\n }\n ```\n - **User Approval Required**: You MUST present both (a) the candidates for closure with their drafted comments, and (b) the still-valid issues with their drafted confirmation comments and reproductions, to the user and obtain explicit approval BEFORE running any command that comments on or closes an issue. You can present the JSON findings format directly to the user for review.\n\n4. **Iterate on Skill Knowledge (Learning Loop)**:\n - If you discover a new, distinct category of closing rationale that is not covered in `references/rationale_templates.md`, **update the reference file** to include it.\n\n5. **Execute and Summarize**:\n - **For Approved Closure Candidates**: Use `gh issue close` with the `-c` flag to post the comment and close the issue. Apply the `closed-by-an-agent` label to the issue.\n - **For Approved Still-Valid Issues**: Use `gh issue comment -b \"\"` to post the confirmation comment containing the minimal reproduction / test case. Apply the `verified-by-an-agent` label to the issue using `gh issue edit --add-label \"verified-by-an-agent\"`.\n - **Label Every Still-Valid Issue You Leave Open**: The label is how future runs know to skip an issue, so each investigated issue that stays open should get a confirmation comment and the `verified-by-an-agent` label. Don't apply the label without a comment: if the user decides not to post a comment for an issue, leave it unlabeled, and it may come up again on a later run.\n - Provide the user with a clean bulleted list of closed issues and updated/commented valid issues.\n\n6. **Optional: Fix It (only when the user asks)**:\n - Some still-valid issues are cheap to fix. A good candidate has a **failing unit test** from step 3 and a **localized root cause** (one function or one condition). When you present the step 5 summary, point out which verified issues look like quick fixes; don't start fixing unless the user asks.\n - When fixing:\n - Turn the verification test into a permanent regression test (a link to the issue in a comment is enough). If the fix touches a code path shared by related behaviors (e.g. both `extractAll: true` and `extractAll: false`), add a test for each.\n - If the repository already has `@FailingTest(issue: '…/')` tests for the issue, remove the annotation so they run as normal tests.\n - Run the whole test file for the changed code, plus closely related suites (e.g. the LSP and legacy protocol tests for a refactoring), and run `dart analyze` and `dart format` on the changed files.\n - Call out any intentional behavior change beyond the reported bug so reviewers can weigh it.\n - Suggest a commit message that ends with `Fixes https://github.com/dart-lang/sdk/issues/` so the issue closes automatically when the change lands. Leave committing and uploading to the user unless they ask you to do it.\n - After the fix lands, remove the issue from `references/investigated_issues.txt` (see step 5).\n\n## Tips\n\n- Use available file and content search tools (such as `grep`, `ripgrep`, or environment-specific\nsearch tools) to check the current codebase for references to the issue or relevant code.\n- Look for related Gerrit CLs that might have fixed the issue but didn't close it automatically.\n- **Pro Tip**: Use the `read-gerrit-cl` skill ([SKILL.md](../../../../../.agents/skills/read-gerrit-cl/SKILL.md)) to inspect the patchset diffs and comments of open or merged Gerrit CLs.\n- **Always prioritize active verification on HEAD**: Regardless of how old an issue is or what version it specifies, always attempt to research and reproduce the reported issue against the current `HEAD` of the codebase before proposing closure. Never assume a bug is obsolete or fixed based solely on the passage of time or version discrepancies. If you cannot reproduce it, provide clear details of your reproduction attempt on the current codebase.\n","frontmatter":{"name":"close-obsolete-issues","description":"Find obsolete, stale, or not reproducible analysis-server issues in the dart-lang/sdk repository."},"isInternal":false,"tokens":2660,"sizeBytes":11699},{"name":"SKILL.md","path":"pkg/analysis_server/.agents/skills/implement-a-lint/SKILL.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/analysis_server/.agents/skills/implement-a-lint/SKILL.md","title":"implement-a-lint","category":"anthropic-skill","format":"markdown","content":"---\nname: implement-a-lint\ndescription: Guide for creating, registering, documenting, and testing a new lint in the Dart SDK.\n---\n\n## Overview\n\nUse this skill when you need to create a new lint in the Dart SDK codebase. It details the step-by-step implementation and testing procedures.\n\n## Target Reference Example\n\nBefore starting, review this existing feature as the canonical implementation model:\n* **Reference Implementation:** `pkg/linter/lib/src/rules/unnecessary_primary_constructor_body.dart`\n* **Reference Test:** `pkg/linter/test/rules/unnecessary_primary_constructor_body_test.dart`\n\n## File Layout & Naming Conventions\n\nWhen implementing a new lint, you will modify or create the following files:\n\n| File Path | Action | Description |\n|---|---|---|\n| `pkg/linter/lib/src/rules/.dart` | **Create** | The main implementation and AST visitor logic. |\n| `pkg/linter/messages.yaml` | **Modify** | Alphabetical diagnostic entry, problem/correction messages, and documentation. |\n| `pkg/linter/lib/src/rules.dart` | **Modify** | Imports and registers the lint class in the linter registry. |\n| `pkg/linter/test/rules/_test.dart` | **Create** | The reflective tests for the new lint. |\n| `pkg/linter/test/rules/all.dart` | **Modify** | Imports and runs the main entry point of the test file. |\n| `pkg/analysis_server/lib/src/services/correction/error_fix_status.yaml` | **Modify** | Records which diagnostics have or should have a fix. |\n\n## Execution Checklist\n\n### 1. Define the diagnostic code(s)\n\nUnless explicitly instructed otherwise by the user, the rule should have a single diagnostic code.\n\nCopy the following structure to define each of the diagnostic codes that the lint will produce. The definitions should be added alphabetically to `pkg/linter/messages.yaml`.\n\n````yaml\n :\n type: lint\n parameters: none\n problemMessage: \"\"\n correctionMessage: \"\"\n state:\n experimental: \"\"\n categories: [style]\n hasPublishedDocs: false\n documentation: |-\n #### Description\n\n The analyzer produces this diagnostic when \n\n #### Example\n\n The following code produces this diagnostic because :\n\n ```dart\n // Bad code here\n ```\n\n #### Common fixes\n\n If , then :\n\n ```dart\n // Good code here\n ```\n deprecatedDetails: |-\n \n````\n\nIf the user has explicitly requested different diagnostic codes for different contexts, then use the template above for each code, alphabetizing the entries. In this case, each code should have a `sharedName:` entry that is the same for all of the codes being added, and that should be the name of the lint rule. The `ruleName` for each entry should then be something like `ruleName_context`. Only one diagnostic code should have the `documentation:` and `deprecatedDetails:` entries (typically the one that is lexically first). These values will be shared by any codes that have the same `sharedName`.\n\nThe presence of the `deprecatedDetails` property is strictly validated by the generator script. You MUST include it, even for newly added lints. The code snippets in this documentation are not validated, so do not include range markers ('[!' '!]') or use any of the `%` directives.\n\nThe `hasPublishedDocs` property must be included and must have a value of `false`. The flag will be changed to `true` after the documentation has been published to the web site.\n\nThe `categories:` property lists the categories that developers can use to discover new lints. Choose from the following allowed categories: `binarySize`, `brevity`, `documentationCommentMaintenance`, `effectiveDart`, `errorProne`, `flutter`, `languageFeatureUsage`, `memoryLeaks`, `nonPerformant`, `pub`, `publicInterface`, `style`, `unintentional`, `unusedCode`, `web`.\n\nRun the following commands to update the generated files (`lint_names.g.dart`, `diagnostic.g.dart`, etc.):\n\n```bash\ndart run pkg/linter/tool/generate_lints.dart\ndart run pkg/analyzer/tool/messages/generate.dart\n```\n\n**BEFORE CONTINUING TO THE NEXT STEP:**\n\nRun `dart test pkg/analyzer/test/verify_diagnostics_test.dart` to verify that the example and fixes code in the documentation is correct. Make changes as necessary to get the test to pass, re-running the test until it passes. If you modify the `messages.yaml` file then you must re-run the generators before re-testing.\n\n### 2. Implement the lint\n\nIf the lint is dependent on a language experiment, and that experiment is not enabled by default, confirm that the list of experiments returned by `experimentsForTests` in `pkg/analyzer_testing/lib/experiments/experiments.dart` includes the experiment. If not, add it.\n\nNote that a new lint should use the next version of the Dart SDK for the `since` property in the `AnalysisRule` constructor.\n\nCreate an implementation of the lint in the file `pkg/linter/lib/src/rules/.dart` by copying the following template:\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n\nimport 'package:analyzer/analysis_rule/analysis_rule.dart';\nimport 'package:analyzer/analysis_rule/rule_context.dart';\nimport 'package:analyzer/analysis_rule/rule_visitor_registry.dart';\nimport 'package:analyzer/dart/ast/ast.dart';\nimport 'package:analyzer/dart/ast/visitor.dart';\n\nimport '../analyzer.dart';\nimport '../diagnostic.dart' as diag;\n\nconst _desc = r'';\n\n/// \nclass extends AnalysisRule {\n new() : super(\n name: LintNames.,\n description: _desc,\n state: RuleState.experimental(since: .new(, , 0)),\n );\n\n @override\n DiagnosticCode get diagnosticCode => diag.ruleName;\n\n @override\n void registerNodeProcessors(\n RuleVisitorRegistry registry,\n RuleContext context,\n ) {\n var visitor = _Visitor(this, context);\n // \n }\n}\n\nclass _Visitor(final AnalysisRule rule, final RuleContext context)\n extends SimpleAstVisitor {\n // \n}\n```\n\nThere must be a visit method for every registered node type and there must be a registration for every `visit` method.\n\nUse either `rule.reportAtToken(token)` or `rule.reportAtNode(node)` to emit the diagnostics. Prefer using `rule.reportAtToken(token)` to report at a single token.\n\nIf the lint produces multiple diagnostic codes, make the implementation class a subclass of `MultiAnalysisRule`. For rules with multiple diagnostic codes:\n1. Extend `MultiAnalysisRule` instead of `AnalysisRule`.\n2. Override `diagnosticCodes` (plural) returning a list of codes instead of `diagnosticCode` (singular):\n ```dart\n @override\n List get diagnosticCodes => [\n diag.ruleName_contextOne,\n diag.ruleName_contextTwo,\n ];\n ```\n3. Provide the specific diagnostic code when reporting:\n ```dart\n rule.reportAtToken(token, diagnosticCode: diag.ruleName_contextOne);\n ```\n\n#### Useful Analyzer APIs for Lint Logic\n\n- Unwrapping Parentheses: Use `node.unParenthesized` to inspect the target of an expression without manually traversing parenthesized wrappers.\n- Element Model: Use `node.declaredFragment?.element` to retrieve the `Element` corresponding to the declared node.\n- Experiment/Feature Flags: Use `context.isFeatureEnabled(Feature.feature_name)` to conditionally enable or check features.\n\n#### Useful tools\n\n- The tool `pkg/linter/tool/spelunk.dart` can be used to print/dump the AST of a given file. This might be helpful to determine which AST node types need to be visited.\n\n**BEFORE CONTINUING TO THE NEXT STEP:**\n\nEnsure that the implementation passes `dart analyze` without any diagnostics. If there are diagnostics, you must fix them before proceeding.\n\n### 3. Register the lint\n\nAfter the class is written, modify `pkg/linter/lib/src/rules.dart` to import your rule and register it alphabetically:\n\n```dart\n ..registerLintRule(RuleName())\n```\n\n### 4. Record the status of the lint's fixes\n\nEdit the file `pkg/analysis_server/lib/src/services/correction/error_fix_status.yaml` to indicate that the lint needs to be evaluated to determine whether one or more fixes should be provided. Do this by alphabetically adding an entry of the form\n```yaml\n:\n status: needsEvaluation\n```\n\n### 5. Write tests for the lint\n\nCreate a reflective test suite in the file `pkg/linter/test/rules/_test.dart` by copying the following template:\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n\nimport 'package:test_reflective_loader/test_reflective_loader.dart';\n\nimport '../rule_test_support.dart';\n\nvoid main() {\n defineReflectiveSuite(() {\n defineReflectiveTests(Test);\n });\n}\n\n@reflectiveTest\nclass Test extends LintRuleTest {\n @override\n String get lintRule => LintNames.;\n\n // \n}\n```\n\nUse `assertDiagnosticsFromMarkup` to test cases where a diagnostic is expected and `assertNoDiagnostics` to test cases where a diagnostic is not expected. Do not use `assertDiagnostics`.\n\nIf the implementation of the lint has any conditions that must be true in order for the diagnostic to be generated, ensure that there is at least one test for each condition that shows that the diagnostic is not generated when the condition is false.\n\nIf the lint is dependent on a language experiment, then tests that verify the behavior of the lint when the experiment is not enabled must include a language override comment in the test code. The version should be the version before the experiment was introduced, which is given as the `experimentalReleaseVersion` key in `pkg/analyzer/lib/src/dart/analysis/experiments.g.dart`. If the release version is `null`, then use the current Dart SDK version.\n\nLinter tests run against a lightweight mocked SDK (`pkg/analyzer/lib/src/test_utilities/mock_sdk.dart`) rather than the real disk SDK. If a test references standard library APIs (e.g. `Iterable`) and the test fails because the API isn't found, try using a different API or enhance the mock SDK to include the APIs.\n\n### 6. Run the tests\n\nExecute the tests directly using the `dart test` runner:\n\n```bash\ndart test pkg/linter/test/rules/_test.dart\n```\n\nIf the tests don't pass, then either fix the implementation or fix the test, as appropriate.\n\nAfter the tests that you added are passing, run\n```bash\ndart run pkg/linter/test/all.dart\ndart run pkg/analyzer/test/test_all.dart\ndart run pkg/analysis_server/test/test_all.dart\n```\n\nThese will usually all pass at this point, but will sometimes fail. If they do, fix the failures and repeat the test commands until they all pass.\n\n### 7. Verify that the code is error free and formatted correctly\n\nVerify that every file that was either created or modified analyzes cleanly (no diagnostics):\n\n```bash\ndart analyze \n```\n\nIf any diagnostics are reported, attempt to fix them by running:\n\n```bash\ndart fix \n```\n\nThen rerun `dart analyze`. If there are still diagnostics, fix them directly. Repeat until `dart analyze` reports no diagnostics.\n\nThen run the following command on all created or modified files, but not on generated files:\n```bash\ndart format \n```\n","frontmatter":{"name":"implement-a-lint","description":"Guide for creating, registering, documenting, and testing a new lint in the Dart SDK."},"isInternal":false,"tokens":2653,"sizeBytes":11919},{"name":"SKILL.md","path":"pkg/analysis_server/.agents/skills/improve-performance-with-session-log/SKILL.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/analysis_server/.agents/skills/improve-performance-with-session-log/SKILL.md","title":"improve-performance-with-session-log","category":"anthropic-skill","format":"markdown","content":"---\nname: improve-performance-with-session-log\ndescription: >-\n Use this skill when diagnosing, reproducing, and improving the performance or\n latency of Dart Analysis Server (DAS) LSP requests and responses using\n recorded session communications logs, log normalization, replay tools, and\n fresh local SDK compilation.\n---\n\n# Improve LSP Performance with Session Logs\n\nThis skill guides you through diagnosing slow LSP request/response interactions\nin the Dart Analysis Server (DAS), reproducing them with the log player replay\ntool, optimizing the server implementation, recompiling the SDK, and validating\nthe latency improvement.\n\n---\n\n## Workflow Overview\n\n```mermaid\nflowchart LR\n A[\"1. Inspect Log\"] --> B[\"2. Normalize Log\"] --> C[\"3. Reproduce & Measure Baseline\"]\n C --> D[\"4. Optimize & Rebuild SDK\"] --> E[\"5. Replay with Built SDK & Validate\"]\n```\n\n1. **Inspect Log**: Locate target requests (e.g. `textDocument/documentColor`,\n `textDocument/completion`) and calculate request-to-response duration\n (`response.time - request.time`).\n2. **Normalize Log**: Replace machine-specific paths with portable placeholders\n (`{{workspaceFolder-0}}`, `{{dartSdkRoot}}`).\n3. **Reproduce Baseline**: Replay the log against the baseline server using\n `server_driver_main.dart` or automated playback, isolating warm request\n latency from cold-start queueing.\n4. **Optimize Code**: Implement performance improvements in `pkg/analysis_server`\n or `pkg/analyzer`.\n5. **Recompile SDK**: From ``, run `python3 tools/build.py -mrelease create_sdk`.\n6. **Replay with the freshly built SDK**: Replay using the newly compiled `dart` binary to\n verify latency reduction and correctness.\n7. **Run unit and integration tests**: Run existing unit tests and add regression tests for\n modified logic.\n\n## Step 1: Inspect the session communications log\n\nSession logs are line-delimited JSON (JSON Lines). Each line is an independent\nJSON object containing `time` and `kind`. Depending on the kind of entry (e.g.\n`message` versus `commandLine`), lines may also have `sender`, `receiver`, and\n`message` (though some entries might omit them).\n\n### Analyze the Log with `analyze_session_log.dart`\n\nThe skill provides\n[`scripts/analyze_session_log.dart`](scripts/analyze_session_log.dart) to parse,\ninspect, and summarize session logs automatically:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/analyze_session_log.dart \\\n [--method=] [--min-ms=] [--warm-only] [--summary] \n```\n\nKey capabilities:\n\n* **Measures Client & Server Durations**: Displays client-perceived duration\n (`response.time - request.clientRequestTime`) and server processing duration\n (`response.time - request.time`).\n* **Detects Cold-Start Queueing**: Identifies whether requests occurred during\n initial background analysis (`$/progress` `\"Analyzing...\"`) or against a warm\n server.\n* **Extracts Errors & Crashes**: Automatically parses and surfaces server\n exceptions (e.g. `Bad state: SimpleIdentifierImpl is not in the V2 AST view`).\n\nExample of inspecting 'textDocument/documentColor' requests in a session:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/analyze_session_log.dart \\\n -m documentColor session-log-2.txt\n```\n\n## Step 2: Normalize the Log\n\nRaw session logs contain absolute paths from the machine where they were\nrecorded. Normalize them to make them replayable against any local workspace:\n\n```bash\ndart /pkg/analysis_server/tool/log_player/normalize.dart \\\n -i \\\n -o \\\n -r \\\n [-p ]\n```\n\nOptions:\n\n* `-i`, `--input`: Path to the raw recorded log file.\n* `-o`, `--output`: Destination path for the normalized log.\n* `-r`, `--root-dir`: Root directory of the project open during recording.\n* `-p`, `--package-config`: (Optional) Explicit path to `package_config.json`\n if not at `/.dart_tool/package_config.json`.\n\nNormalizing replaces machine paths with `{{workspaceFolder-0}}`,\n`{{dartSdkRoot}}`, and package URIs with `{{package-root:...}}`.\n\n---\n\n## Step 3: Reproduce and Measure Baseline Latency\n\n### Automated Replay & Measurement (`measure_request_latency.dart`)\n\nThe skill provides\n[`scripts/measure_request_latency.dart`](scripts/measure_request_latency.dart)\nto automatically replay setup messages up to a target request, wait for\nbackground analysis to finish, and measure wall-clock latency across multiple\niterations:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/measure_request_latency.dart \\\n -i -w -r 3 \n```\n\nOptions:\n\n* `-i`, `--request-id`: (**Required**) The target request ID identified in Step 1\n (e.g. `153`). Always specify this to ensure you benchmark the exact target\n request.\n* `-m`, `--method`: Target request method (e.g. `textDocument/documentColor`).\n Avoid using this without `-i`, as matching by method alone yields the first\n occurrence in the log rather than the slowest or target request.\n* `-w`, `--workspace`: Local project directory to map `{{workspaceFolder-0}}`\n to (defaults to current working directory).\n* `-r`, `--repeat`: Number of iterations to measure consistency (default: 1).\n\n> [!IMPORTANT]\n> **Always use `--request-id` (`-i`)**: Pass the specific request ID found from\n> inspecting or analyzing the log in Step 1. Do not rely on `--method` alone:\n> `--method` only matches the *first* occurrence of that method in the session\n> log, which is often a fast initial request rather than the slow interaction\n> you are trying to optimize.\n\n### Interactive replay (`server_driver_main.dart`)\n\nFor manual inspection and stepping through messages one-by-one:\n\n```bash\ncd /path/to/project/root\ndart /pkg/analysis_server/tool/log_player/server_driver_main.dart /path/to/normalized_log.json\n```\n\n* Press **Enter** to step through messages.\n* Wait for background analysis to finish (`$/progress` `{\"kind\": \"end\"}`) before\n stepping to the target request to measure warm handler latency.\n\n**Note** that this tool can absolutely change the timing of the operations in\nthe log, which can potentially change the **behavior** of the server.\n\n## Step 4: Investigate code and implement optimizations\n\n1. Identify the handler or computer responsible for the request method:\n * Method `textDocument/documentColor` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_document_color.dart` and\n `pkg/analysis_server/lib/src/computer/computer_color.dart`.\n * Method `textDocument/completion` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_completion.dart` and\n `pkg/analysis_server/lib/src/services/completion/`.\n * Method `textDocument/codeAction` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_code_actions.dart`.\n2. Inspect profiling data or trace execution paths for common bottlenecks:\n * **Unnecessary AST traversals**: Are visitors walking AST subtrees that\n cannot contain relevant nodes?\n * **Excessive element resolution or type evaluation**: Can lightweight\n syntactic checks filter out candidates before resolving types or evaluating\n constant values?\n * **Repeated allocations or computations**: Can maps/sets be reused, or early\n exits added?\n3. Apply optimizations in `pkg/analysis_server` or `pkg/analyzer`.\n\n## Step 5: Recompile the Dart SDK\n\nRecompile the analysis server snapshot and SDK binaries:\n\n```bash\n(cd && python3 tools/build.py -mrelease create_sdk)\n```\n\nThe compiled SDK binaries will be located at:\n\n* **macOS**: `xcodebuild/ReleaseARM64/dart-sdk/bin/dart` (or\n `xcodebuild/ReleaseX64/...`)\n* **Linux / Windows**: `out/ReleaseX64/dart-sdk/bin/dart`\n\n## Step 6: Replay with the freshly built SDK\n\n> [!IMPORTANT]\n> `ServerDriver` starts the server process using `Platform.resolvedExecutable`.\n> To run against your freshly built changes, you **must** execute `server_driver_main.dart` (or your replay script) using the compiled `dart` binary, not the system `dart`.\n\n### Running automated replay with the built SDK\n\nRun `measure_request_latency.dart` with the compiled binary to measure latency after changes:\n\n```bash\n \\\n /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/measure_request_latency.dart \\\n -i -w -r 3 /path/to/normalized_log.json\n```\n\n### Interactive stepping with the built SDK\n\n```bash\n \\\n /pkg/analysis_server/tool/log_player/server_driver_main.dart \\\n /path/to/normalized_log.json\n```\n\nIf running from an external project root and package resolution fails, specify\nthe package config:\n\n```bash\n--packages=/.dart_tool/package_config.json\n```\n\n### Validation checklist\n\n- [ ] Confirm the target request returns the exact same valid response payload\n (colors, completions, etc.).\n- [ ] Verify that request execution latency is substantially reduced compared to\n baseline.\n- [ ] Confirm no unhandled exceptions or error responses are produced in the\n server output stream.\n\n## Step 7: Run unit and integration tests\n\nRun relevant existing tests with the compiled Dart binary:\n\n```bash\n test /pkg/analysis_server/test/src/...\n```\n\nAdd new unit tests in the appropriate test suite (e.g.\n`pkg/analysis_server/test/src/computer/...`) to lock in the performance\noptimization and guard against regressions.\n","frontmatter":{"name":"improve-performance-with-session-log","description":"Use this skill when diagnosing, reproducing, and improving the performance or latency of Dart Analysis Server (DAS) LSP requests and responses using recorded session communications logs, log normalization, replay tools, and fresh local SDK compilation."},"isInternal":false,"tokens":2261,"sizeBytes":9666},{"name":"libraries.json","path":"pkg/front_end/testcases/extensions/as_show/libraries.json","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/as_show/libraries.json","title":"As_show Skill","category":"anthropic-skill","format":"json","content":"# As_show Skill\n\nPath: `pkg/front_end/testcases/extensions/as_show/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/as_show/libraries.json)","tokens":300,"sizeBytes":224},{"name":"libraries.json","path":"pkg/front_end/testcases/extensions/patch/libraries.json","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/patch/libraries.json","title":"Patch Skill","category":"anthropic-skill","format":"json","content":"# Patch Skill\n\nPath: `pkg/front_end/testcases/extensions/patch/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/patch/libraries.json)","tokens":300,"sizeBytes":218},{"name":"libraries.json","path":"pkg/front_end/testcases/extensions/patching/libraries.json","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/patching/libraries.json","title":"Patching Skill","category":"anthropic-skill","format":"json","content":"# Patching Skill\n\nPath: `pkg/front_end/testcases/extensions/patching/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/patching/libraries.json)","tokens":300,"sizeBytes":227},{"name":"analysis_options.yaml","path":"pkg/linter/test/rules/analysis_options.yaml","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/linter/test/rules/analysis_options.yaml","title":"Rules Skill","category":"anthropic-skill","format":"yaml","content":"# Rules Skill\n\nPath: `pkg/linter/test/rules/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/linter/test/rules/analysis_options.yaml)","tokens":300,"sizeBytes":194},{"name":"analysis_options.yaml","path":"runtime/tools/dartfuzz/analysis_options.yaml","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/analysis_options.yaml","title":"Dartfuzz Skill","category":"anthropic-skill","format":"yaml","content":"# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/analysis_options.yaml)","tokens":300,"sizeBytes":199},{"name":"pubspec.yaml","path":"runtime/tools/dartfuzz/pubspec.yaml","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/pubspec.yaml","title":"Dartfuzz Skill","category":"anthropic-skill","format":"yaml","content":"# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/pubspec.yaml)","tokens":300,"sizeBytes":181},{"name":"README_minimize.md","path":"runtime/tools/dartfuzz/README_minimize.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/README_minimize.md","title":"Dartfuzz Skill","category":"anthropic-skill","format":"markdown","content":"# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/README_minimize.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/README_minimize.md)","tokens":300,"sizeBytes":193},{"name":"CHANGELOG.md","path":"runtime/tools/heapsnapshot/CHANGELOG.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/CHANGELOG.md","title":"Heapsnapshot Skill","category":"anthropic-skill","format":"markdown","content":"# Heapsnapshot Skill\n\nPath: `runtime/tools/heapsnapshot/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/CHANGELOG.md)","tokens":300,"sizeBytes":193},{"name":"pubspec.yaml","path":"runtime/tools/heapsnapshot/pubspec.yaml","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/pubspec.yaml","title":"Heapsnapshot Skill","category":"anthropic-skill","format":"yaml","content":"# Heapsnapshot Skill\n\nPath: `runtime/tools/heapsnapshot/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/pubspec.yaml)","tokens":300,"sizeBytes":193},{"name":"analysis_options.yaml","path":"runtime/tools/profiling/analysis_options.yaml","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/analysis_options.yaml","title":"Profiling Skill","category":"anthropic-skill","format":"yaml","content":"# Profiling Skill\n\nPath: `runtime/tools/profiling/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/analysis_options.yaml)","tokens":300,"sizeBytes":202},{"name":"CHANGELOG.md","path":"runtime/tools/profiling/CHANGELOG.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/CHANGELOG.md","title":"Profiling Skill","category":"anthropic-skill","format":"markdown","content":"# Profiling Skill\n\nPath: `runtime/tools/profiling/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/CHANGELOG.md)","tokens":300,"sizeBytes":184},{"name":"pubspec.yaml","path":"runtime/tools/profiling/pubspec.yaml","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/pubspec.yaml","title":"Profiling Skill","category":"anthropic-skill","format":"yaml","content":"# Profiling Skill\n\nPath: `runtime/tools/profiling/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/pubspec.yaml)","tokens":300,"sizeBytes":184},{"name":"pubspec.yaml","path":"runtime/tools/pubspec.yaml","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/pubspec.yaml","title":"Tools Skill","category":"anthropic-skill","format":"yaml","content":"name: runtime_tools\ndescription: Internal runtime tools.\n\nenvironment:\n sdk: ^3.9.0\n\nresolution: workspace\npublish_to: none\n","isInternal":false,"tokens":32,"sizeBytes":125},{"name":"README.md","path":"pkg/dart2js_tools/README.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/dart2js_tools/README.md","title":"dart2js_tools Documentation","category":"plugin-manifest","format":"markdown","content":"\n### dart2js\\_tools\n\nThis package collects tools used with dart2js.\n\nFor now, this contains scripts useful to work with obfuscated stack traces in\nproduction and reading data from the extensions added to source-maps by dart2js\n(like minified names and inlined stack frames).\n\nIn the future we plan to merge here tools in the dart2js\\_info package as well.\n","isInternal":false,"tokens":82,"sizeBytes":356},{"name":"README.md","path":"pkg/dds_service_extensions/README.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/dds_service_extensions/README.md","title":"dds_service_extensions Documentation","category":"plugin-manifest","format":"markdown","content":"[![pub package](https://img.shields.io/pub/v/dds_service_extensions.svg)](https://pub.dev/packages/dds_service_extensions)\n[![package publisher](https://img.shields.io/pub/publisher/dds_service_extensions.svg)](https://pub.dev/packages/dds_service_extensions/publisher)\n\nA package used to expand the `package:vm_service` interface with support for RPCs added in the [Dart Developer Service (DDS) protocol][dds-protocol].\n\n[dds-protocol]: https://github.com/dart-lang/sdk/blob/main/pkg/dds/dds_protocol.md\n","isInternal":false,"tokens":121,"sizeBytes":505},{"name":"README.md","path":"runtime/tools/dartfuzz/README.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/README.md","title":"dartfuzz Documentation","category":"plugin-manifest","format":"markdown","content":"# dartfuzz Documentation\n\nPath: `runtime/tools/dartfuzz/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/README.md)","tokens":300,"sizeBytes":183},{"name":"README.md","path":"runtime/tools/entitlements/README.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/entitlements/README.md","title":"entitlements Documentation","category":"plugin-manifest","format":"markdown","content":"# entitlements Documentation\n\nPath: `runtime/tools/entitlements/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/entitlements/README.md)","tokens":300,"sizeBytes":195},{"name":"README.md","path":"runtime/tools/heapsnapshot/README.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/README.md","title":"heapsnapshot Documentation","category":"plugin-manifest","format":"markdown","content":"# heapsnapshot Documentation\n\nPath: `runtime/tools/heapsnapshot/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/README.md)","tokens":300,"sizeBytes":195},{"name":"README.md","path":"runtime/tools/profiling/README.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/README.md","title":"profiling Documentation","category":"plugin-manifest","format":"markdown","content":"# profiling Documentation\n\nPath: `runtime/tools/profiling/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/README.md)","tokens":300,"sizeBytes":186},{"name":"README.md","path":"runtime/tools/wiki/README.md","rawUrl":"https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/wiki/README.md","title":"wiki Documentation","category":"plugin-manifest","format":"markdown","content":"# wiki Documentation\n\nPath: `runtime/tools/wiki/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/wiki/README.md)","tokens":300,"sizeBytes":171}],"systemPromptSnippet":"\n\n---\ntrigger: glob\ndescription: Ensure standard Dart license header on newly created Dart files.\nglobs: *.dart\n---\n\n# License Header Rule\n\nWhenever you create a new Dart (`.dart`) file in this repository, you MUST include the standard Dart project license header at the very top (line 1).\n\nReplace `` with the actual current year (e.g., 2026).\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n```\n\n## Requirements\n- Insert at line 1.\n- Ensure a blank line follows the license header before any other code or comments.\n\n\n---\nname: dart-aot-development\ndescription: Instructions on building and testing changes using Dart AOT mode. Use when working on Dart runtime, Dart AOT compiler or other related components.\n---\n\n# Testing changes to Dart SDK in AOT mode\n\nIf you are making changes to Dart SDK (including but not limited to modifying\nDart VM runtime, Dart VM compiler pipeline, Dart common front-end, Dart type\nflow analysis, etc) and you want to test the changes in AOT mode, you should\nuse the following instructions.\n\n1. Build `gen_snapshot`, `vm_platform.dill` and `dartaotruntime` targets using the following command `tools/build.py -m $MODE -a $ARCH --rbe gen_snapshot vm_platform.dill dartaotruntime`. Here `$MODE` specifies preferred compilation mode (`debug` or `release`), `$ARCH` specifies target architecture (e.g. `x64`, `arm64`). Prefer building using `release` mode and prefer using `$ARCH` that matches the host\nunless something else is requested. A combination of `$MODE` and `$ARCH` is called `DART_CONFIGURATION` (e.g. `ReleaseX64` is `release` build targeting `x64`).\n2. Use helper script `pkg/vm/tool/precompiler2 test.dart test.aot` to compile test script `test.dart` to AOT snapshot `test.aot`. To check commands executed by the script you can pass `-v` to the script.\n3. Use `out/${DART_CONFIGURATION}/dartaotruntime test.aot` to execute AOT snapshot.\n4. Use `perf record -g out/${DART_CONFIGURATION}/dartaotruntime test.aot` to profile the code and `perf report` and `perf annotate` to explore performance of different parts of code.\n5. Use `--print-flow-graph` flag to get IL generated by optimizing compiler, `--print-flow-graph-filter=$NAME_STR` allows to filter out only methods which contain $NAME_STR in their fully qualified names. You can also use `--disassemble --code-comments` to dump disassembly annotated with IL instructions. The output produced by all these flags is written to stderr. You can pass these flags to `precompiler2` script.\n6. When making changes to runtime system, AOT compiler or core libraries - always make sure to rebuild Dart SDK components given in the first item of this list before recompiling and rerunning test or benchmark code.\n\n\n---\nname: find-release-for-commit\ndescription: Find which Dart/Flutter releases contain a specific commit sha.\n---\n\n# Instructions\n\nUse this skill to determine which releases a specific commit SHA (Dart or Flutter) first appeared in.\nThis is useful for identifying the earliest SDK version that includes a given feature, fix, or change.\n\n## Tool Usage\n\nRun the `tools/find_release.dart` script from the root of the SDK (`../../../` relative to this file) to discover the releases for a given commit SHA.\n\n```bash\ndart tools/find_release.dart --commit= --channel=\n```\n\n### Arguments\n\n1. `--commit=` (required): The SHA of the commit.\n2. `--channel=` (required): The channel to search in.\n\n### Example\n\nTo find which releases contain commit `abcdef123...` on the `stable` channel:\n\n```bash\ndart tools/find_release.dart --commit=abcdef123... --channel=stable\n```\n\nThe output will include:\n\n- Whether the commit was found in the Dart or Flutter repository.\n- The lowest (earliest) git release tag containing that commit.\n- The corresponding official Flutter release (if found).\n- The corresponding official Dart SDK release (if found).\n\n## Important Considerations\n\n- **Git Tags vs. Official Releases**: The tool first identifies the lowest git tag that includes the commit. However, the presence of a tag (especially a `-dev` tag) **does not guarantee that an official SDK release has being published for that version.**\n- **Verification**: You should look for the \"Lowest Dart release\" or \"Lowest Flutter release\" in the tool's output to confirm that the commit has actually reached a released state. If the tool reports \"No Dart releases found that were newer than \", then the commit has not yet reached any official released version on that channel.\n- **Reporting**: When communicating the findings, distinguish clearly between the git tag it first appeared in and the earliest official release (if any).\n\n\n---\nname: read-gerrit-cl\ndescription: Fetch and display the full patch/diff or comments for a Gerrit CL.\n---\n\n# Instructions\n\nUse this skill to inspect a Gerrit Change List (CL).\nThis is useful for reviewing code changes, understanding the scope of a modification, checking comments.\n\n## Requirements\n\nThe following command-line tools are required:\n\n- `curl`: For making HTTP requests.\n- `jq`: For parsing JSON (needed for comments).\n- `base64`: For decoding patch content (needed for patches).\n\n## Scripts\n\n### 1. Read Patch\n\nRun the `read_patch.sh` script to fetch the unified diff of a CL.\n\n#### Usage\n\n```bash\n./scripts/read_patch.sh [patchset]\n```\n\n#### Arguments\n\n1. `change_number`: The numeric ID of the Gerrit change (e.g., `12345`).\n2. `patchset` (optional): The patchset number or `current` (default).\n\n#### Example\n\nTo fetch the patch for CL 12345 (latest revision):\n\n```bash\n./scripts/read_patch.sh 12345\n```\n\nTo fetch a specific revision (e.g. patchset 2):\n\n```bash\n./scripts/read_patch.sh 12345 2\n```\n\nThe output will be the unified diff format of the patch.\n\n### 2. Read Comments\n\nRun the `read_comments.sh` script to fetch the comments on a CL.\n\n#### Usage\n\n```bash\n./scripts/read_comments.sh \n```\n\n#### Arguments\n\n1. `change_number`: The numeric ID of the Gerrit change (e.g., `12345`).\n\n#### Example\n\nTo fetch comments for CL 12345:\n\n```bash\n./scripts/read_comments.sh 12345\n```\n\nThe output will be a JSON object containing the comments.\n\n\n---\nname: update-dependency\ndescription: Updates third party dependencies in the Dart SDK\n---\n\n# Instructions\n\nUse this skill to update dependencies in the Dart SDK's `DEPS` file to their\nlatest (or a specific) version. This tool automates the process of updating\nthe version, syncing dependencies, updating package configurations, and\ncreating a CL.\n\n## Prerequisites\n\nBefore running the tool, ensure your environment is prepared correctly:\n\n1. **Clean Git State**: Your git checkout MUST be clean. No uncommitted\n changes should be present.\n2. **On Main Branch**: You MUST be on the `main` branch. The tool creates a\n new branch from your current HEAD, so being on `main` ensures the bump\n starts from a clean baseline.\n\n## Tool Usage\n\nRun the `tools/manage_deps.dart` script with the `bump` command from the root\nof the SDK.\n\n### Command Syntax\n\n```bash\ndart tools/manage_deps.dart bump \\\n [--branch ] [--target ]\n```\n\n### Arguments\n\n1. `` (required): The path to the dependency directory\n relative to the SDK root. Dependencies are entire repositories and not\n packages, so the path will usually be `third_party/pkg/`.\n - **CRITICAL**: DO NOT include a trailing slash in the path.\n - If unsure of the repository, you can look at the\n `.dart_tool/package_config.json` file relative to the SDK root, and search\n for `\"name\": \"\"`. Next to that you should see a \"rootUri\"\n key which will give you the path to the dependency. Do not use the full\n path though, just the top level directory under `third_party/pkg/`,\n since entire repos are always rolled at once.\n - If the `.dart_tool/package_config.json` file does not exist, it can be\n generated by running `gclient sync`.\n2. `--branch ` (optional): The name of the branch to create for\n this update. Defaults to `bump_`.\n3. `--target ` (optional): The specific git ref (SHA, tag, branch) to\n update to. Defaults to the latest version on the remote's default branch.\n\n## Example\n\nTo bump the `unified_analytics` dependency, which is a part of the `tools` repo:\n\n```bash\ndart tools/manage_deps.dart bump third_party/pkg/tools\n```\n\n## Troubleshooting\n\n- **\"Already at - nothing to do\" (or missing recent GitHub commit)**:\n The dependency is already at the latest version on the mirror, or the\n `dart.googlesource.com` mirror has not yet synced a recently merged GitHub\n commit.\n - **For Googlers**: If a commit recently landed on GitHub (check with\n `git ls-remote https://github.com//.git refs/heads/main`, where\n `` is typically `dart-lang`) but is not yet on\n `https://dart.googlesource.com/.git`, trigger an immediate mirror\n fetch:\n ```bash\n gob-ctl repos update-mirror-config github// \\\n --fetch_frequency 5m \\\n --uri https://github.com//.git\n ```\n Wait ~10 seconds, verify with\n `git ls-remote https://dart.googlesource.com/.git refs/heads/main`,\n and rerun `tools/manage_deps.dart`.\n- **Branch already exists**: If the tool says a branch with the target name\n already exists, you will be prompted to delete it. Usually, it is safe to say\n \"y\" if you want a fresh bump.\n- **\"CorpSSO login required. To log in, run glogin or gcert\"**: This indicates a\n Google-internal SSO authentication failure during fetching/syncing\n dependencies. This error and the suggested fix (`gcert` / `glogin`) are only\n applicable for Googlers. Since this requires interactive authentication, you\n must ask the user to run `gcert` (or `glogin`) in their terminal to\n authenticate, and then retry.\n\n\n---\nname: update-native-rev\ndescription: Updates the native_rev dependency in the DEPS file with all correct verification, sync, and testing procedures\n---\n\n\n\n# Instructions\n\nUse this skill when you are requested to roll or update the `native_rev` variable (the hash of `third_party/pkg/native` repository) in the `DEPS` file.\n\n## 0. Initial Synchronization\n\nBefore beginning the roll, **ask the user** if the SDK git repository should be switched to the `main` branch and synchronized.\nIf they confirm, run:\n```bash\ngit checkout main && git pull && gclient sync -D -f\n```\n\n## 1. Commit Selection Rules\n\n> [!IMPORTANT]\n> **CRITICAL RULE**: NEVER EVER pick a local commit or a commit from a custom branch/PR branch. You MUST only pick remote commits that have already landed on the remote `main` branch.\n\nTo select the correct commit SHA:\n1. If the `dart.googlesource.com/native.git` mirror is lagging behind GitHub:\n * **For Googlers**: Trigger an immediate mirror sync instead of modifying `DEPS`:\n ```bash\n gob-ctl repos update-mirror-config github/dart-lang/native \\\n --fetch_frequency 5m \\\n --uri https://github.com/dart-lang/native.git\n ```\n Wait ~10 seconds, verify with `git ls-remote https://dart.googlesource.com/native.git refs/heads/main`, and proceed with the default mirrored googlesource setup below.\n * **Otherwise, ask the user** if the newest hash/commit should be taken directly from **GitHub**:\n * **If the user says YES**:\n 1. First, temporarily change the repository URL and host permissions in the `DEPS` file by following the instructions in the **[Troubleshooting Sync Failures](#troubleshooting-sync-failures)** section (changing `third_party/pkg/native` under `deps` to use `\"https://github.com/dart-lang/native.git\"` and adding `'github.com'` to `allowed_hosts` in `DEPS`).\n 2. Run `gclient sync` from the SDK root to update the checkout mapping to GitHub.\n 3. Navigate to the `native` package subdirectory: `third_party/pkg/native`.\n 4. Run `git fetch origin` to fetch the latest commits from the GitHub remote (origin will now point to GitHub).\n 5. After checking commits, **immediately set the repository URL and host permissions in `DEPS` back to googlesource** (reverting the changes made in sub-step 1), so that subsequent steps and the final commit only roll the commit hash without permanently keeping GitHub host settings.\n * **If the user says NO / default**:\n 1. Proceed with the default mirrored googlesource setup.\n 2. Navigate to the `native` package subdirectory: `third_party/pkg/native`.\n 3. Run `git fetch origin` to fetch the latest commits from the mirror.\n2. Inspect the commits on remote `origin/main` of the `native` repository:\n ```bash\n git log origin/main -n 10 --oneline\n ```\n3. Obtain the full SHA of the newest commit on remote `origin/main` (or the specific one that contains the required change):\n ```bash\n git rev-parse origin/main\n ```\n4. **Revert Host to GoogleSource**:\n * **IMPORTANT**: If the host was set to GitHub, you **MUST** now revert the repository URL and allowed hosts changes in the `DEPS` file back to the mirrored googlesource URL, removing `github.com` from `allowed_hosts`. Do this before updating `native_rev` so that the final committed change only rolls the commit hash, not checkout hosts.\n\n## 2. Updating DEPS and Synchronizing\n\n1. Locate `native_rev` in the `DEPS` file (typically under `vars`):\n ```python\n \"native_rev\": \"\",\n```\n2. Replace the hash with the chosen remote `origin/main` commit SHA.\n3. If not already done in step 4 above, ensure the `DEPS` host and URL configuration are reverted to the googlesource mirror, leaving only the updated `native_rev` hash.\n4. Run `gclient sync -f` from the SDK root directory to update the checkout of the dependencies and regenerate the package configuration using the mirror.\n\n### Troubleshooting Sync Failures\nIf the synchronization fails because of host restrictions:\n1. Temporarily modify the repository configuration under `deps` in `DEPS` to use:\n `https://github.com/dart-lang/native.git` as the git repo.\n2. Temporarily add `'github.com'` to the `allowed_hosts` list in `DEPS`.\n3. Re-run `gclient sync -f` to complete the update.\n4. **IMPORTANT**: Immediately after successful syncing, revert the host and URL changes in the `DEPS` file, removing `github.com` from `allowed_hosts` and returning to the mirrored googlesource URL, but keep the newly synced native commit hash.\n\n## 3. Mandatory Testing and Verification\n\nBefore completing the update, you must run the following tests:\n\n### Native Assets Package Tests\nBuild the target SDK and run the primary native asset tests:\n```bash\nRBE_exec_strategy=racing tools/build.py -mrelease create_sdk runtime ffi_test_functions runtime_precompiled && tools/test.py -n unittest-asserts-release-mac-arm64 pkg/dartdev/test/native_assets/\n```\n\n### Record Use Optimization Tests\nSince `record_use` integrates closely with `native_rev` updates, these tests must be validated for both backends (Wasm and VM). **Note**: `record_use` is now 1.0, so breaking changes are not allowed and expectations should NOT need updating.\n\n1. Build the required target backends and run all record use tests:\n ```bash\n RBE_exec_strategy=racing tools/build.py -mrelease create_sdk dart2wasm runtime ffi_test_functions runtime_precompiled && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/compiler/test/record_use/record_use_test.dart && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/dart2wasm/test/record_use_test.dart && xcodebuild/ReleaseARM64/dart-sdk/bin/dart pkg/vm/test/transformations/record_use_test.dart\n ```\n2. **Test Failure Policy**:\n > [!IMPORTANT]\n > Since `record_use` is 1.0, any test failure here indicates an illegal breaking change rather than a need for expectation updates. Do not update expectations; report any failure immediately.\n3. **Running Individual Tests**:\n To debug or verify a single test:\n ```bash\n python3 tools/test.py -n wasm-unittest-asserts-mac pkg/dart2wasm/test/record_use_test.dart\n ```\n\n## 4. Pre-Completion Protocol\n\nFollow these final validation steps before announcing completion:\n\n1. **Format touched files**: Run `dart format` on all modified Dart files.\n2. **Analyze touched files**: Run `dart analyze` to ensure there are no lint or static analysis issues.\n3. **Presubmit checks**: Run `git cl presubmit` to ensure build/format sanity.\n4. **Update Coverage (Front-End changes only)**:\n If any related changes were also introduced in the `front_end` directory, regenerate test coverage:\n ```bash\n dart --enable-asserts pkg/front_end/test/coverage_suite.dart --tasks=5 --add-and-remove-comments\n ```\n * *Critical*: Revert the coverage comment changes in any files that you did not otherwise modify.\n\n## 5. Branching and Committing\n\nAfter all tests pass and formatting/analysis is clean:\n1. **Ask the user** if they want to create a roll branch and commit the changes.\n2. If confirmed, get the current date in `YYYYMMDD` format (e.g., `20260630`) and run:\n ```bash\n git new-branch roll-\n git commit -a -m \"[deps] Roll dart-lang/native\"\n ```\n\n\n# References Skill\n\nPath: `pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/analysis_server/.agents/skills/close-obsolete-issues/references/rationale_templates.md)\n\n\n---\nname: close-obsolete-issues\ndescription: Find obsolete, stale, or not reproducible analysis-server issues in the dart-lang/sdk repository.\n---\n\n# Close Obsolete Issues\n\nUse this skill to find old, outdated issues in the `dart-lang/sdk` repository that have been fixed, are stale, obsolete, or not reproducible.\n\n## Instructions\n\n1. **Identify Target Issues**:\n - Use the GitHub CLI (`gh`) to search for the oldest open issues.\n - Use the label `area-devexp` to identify analysis server issues.\n - Also use label `type-bug` and any other label that the user gives you.\n - **Exclude Labeled Issues**: Exclude issues already labeled `verified-by-an-agent` or `closed-by-an-agent` by adding `-label:verified-by-an-agent -label:closed-by-an-agent` to the search query. These labels are the record of which issues have already been investigated; there is no separate tracking file.\n - Sort by creation date (`created-asc`) or last update (`updated-asc`) to find the most likely candidates for being outdated.\n - Fetch at least 100–150 candidates. Many candidates fail the guardrails in step 2, so 50 usually leaves only a handful. Alternating between `created-asc` and `updated-asc` across runs also helps surface new candidates.\n - Example command (with label): `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open label:type-bug -label:verified-by-an-agent -label:closed-by-an-agent sort:created-asc\" --limit 150 | cat`\n - Example command (without label): `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open -label:verified-by-an-agent -label:closed-by-an-agent sort:created-asc\" --limit 150 | cat`\n - **Re-verify Old Verifications**: A `verified-by-an-agent` label only says that the issue reproduced when the comment was posted. Occasionally (for example, when the searches above return few candidates, or when the user asks), also look at labeled issues that haven't been updated for more than a year, using a date one year before today: `gh issue list --repo dart-lang/sdk --search \"label:area-devexp is:open label:verified-by-an-agent -label:closed-by-an-agent updated:\" | cat`. See rationale 7 in `references/rationale_templates.md`.\n\n2. **Investigate Status**:\n - **Pre-Qualification Guardrails**: Before evaluating any candidate against obsolete rationales, check the issue metadata. **Abort evaluation and keep the issue open** if any of the following are true:\n 1. *Recent Activity*: The issue has any comment or status change from a user within the last 365 days.\n 2. *Priority/Milestone*: The issue carries a high-priority label (e.g., `P0`, `P1`, `critical`) or is assigned to an active milestone.\n 3. *Corporate Interest*: The issue has active engagement or reproduction steps provided by a Dart/Flutter team member within the last 2 years.\n - For candidates that pass pre-qualification, analyze their description and comments.\n - Use the bundled script `scripts/fetch_issue_details.sh ` to get a comprehensive view of the issue and its comments.\n - **Check for Existing Tests First**: Search the test directories for the issue number, e.g. `grep -rn \"issues/\" test/` (and in `pkg/analyzer/test` or `pkg/linter/test` if relevant). Tests annotated with `@FailingTest(issue: '…/')` are a ready-made reproduction: if they still fail, the bug is still valid; if they now pass, the bug may have been fixed silently.\n - **Verify with a Locally Built SDK**: The `dart` on `PATH`could be an older SDK (for example the one bundled with Flutter). Reproduce with the SDK built from the current checkout, e.g. `/xcodebuild/ReleaseX64/dart-sdk/bin/dart` on macOS or `/out/ReleaseX64/dart-sdk/bin/dart` on Linux. Confirm with `--version` that it matches `HEAD`, and record that version (or commit) for use in your comments.\n - Compare the issue's request or reported bug and subsequent comments with the current state of the codebase.\n - Refer to the data-driven checks in `references/rationale_templates.md` to verify if a rationale applies.\n - **Safety Rule**: Do not assume a bug is fixed or obsolete just because the code has changed or the issue has not been updated for a long time. Verify if the specific bug behavior is still possible. Valid bugs or feature requests should not be closed as stale just because they are old or have no activity. Inactivity alone does not invalidate a feature request or bug report.\n\n3. **Draft and Review Comments (CRITICAL MANDATE)**:\n - **For Candidates for Closure**: For issues identified as candidates for closure, draft a detailed comment for each explaining *why* it can be closed. Consult `references/rationale_templates.md` for wording inspiration. Each comment MUST end with: \"If there is more work to do here, please let us know by filing a new issue with up to date information. Thanks!\"\n - **State the Verification SDK**: Every comment (closure or still-valid) should say which SDK the behavior was verified on, e.g. \"Verified on a local build of `main` (`3.14.0-edge.`)\", so readers can judge how current the finding is.\n - **For Still-Valid Issues**: If you determine that a bug is still valid (reproducible on `HEAD`):\n - Draft a comment confirming that the bug remains reproducible at `HEAD` on the latest SDK.\n - Construct a minimal, self-contained Dart reproduction code example or a formal Dart unit test case (following existing testing patterns in the `test/` directory) demonstrating the issue.\n - If you write a unit test, run it to confirm that it actually fails on `HEAD`, and include the actual (wrong) output in the comment alongside the expected output.\n - Where you can identify it, point to the likely root cause (file and function) so the issue is actionable.\n - Include this reproduction or unit test in your drafted comment to assist developers in fixing the bug.\n - **Revert Temporary Tests**: Tests added to the repository only to verify a bug must be reverted afterwards (e.g. `git checkout `). Leave the working tree as you found it unless the user asks you to fix the bug (see step 6).\n - **Footer Restriction**: Do NOT end comments on still-valid issues with the closure footer (about filing a new issue), as this issue is remaining open.\n - **Required Output Format**: For each evaluated issue, generate your assessment in this structured JSON format so that a coordinator agent or human supervisor can easily parse, validate, and approve your findings:\n ```json\n {\n \"issue_number\": 12345,\n \"issue_url\": \"https://github.com/dart-lang/sdk/issues/12345\",\n \"eligible_for_close\": true,\n \"matched_rationale_id\": 1,\n \"confidence_score\": 0.95,\n \"verification_finding\": \"Verified that standard LSP protocol capabilities natively handle the requested server configuration.\",\n \"proposed_comment\": \"[Full proposed comment including the mandatory footer]\"\n }\n ```\n - **User Approval Required**: You MUST present both (a) the candidates for closure with their drafted comments, and (b) the still-valid issues with their drafted confirmation comments and reproductions, to the user and obtain explicit approval BEFORE running any command that comments on or closes an issue. You can present the JSON findings format directly to the user for review.\n\n4. **Iterate on Skill Knowledge (Learning Loop)**:\n - If you discover a new, distinct category of closing rationale that is not covered in `references/rationale_templates.md`, **update the reference file** to include it.\n\n5. **Execute and Summarize**:\n - **For Approved Closure Candidates**: Use `gh issue close` with the `-c` flag to post the comment and close the issue. Apply the `closed-by-an-agent` label to the issue.\n - **For Approved Still-Valid Issues**: Use `gh issue comment -b \"\"` to post the confirmation comment containing the minimal reproduction / test case. Apply the `verified-by-an-agent` label to the issue using `gh issue edit --add-label \"verified-by-an-agent\"`.\n - **Label Every Still-Valid Issue You Leave Open**: The label is how future runs know to skip an issue, so each investigated issue that stays open should get a confirmation comment and the `verified-by-an-agent` label. Don't apply the label without a comment: if the user decides not to post a comment for an issue, leave it unlabeled, and it may come up again on a later run.\n - Provide the user with a clean bulleted list of closed issues and updated/commented valid issues.\n\n6. **Optional: Fix It (only when the user asks)**:\n - Some still-valid issues are cheap to fix. A good candidate has a **failing unit test** from step 3 and a **localized root cause** (one function or one condition). When you present the step 5 summary, point out which verified issues look like quick fixes; don't start fixing unless the user asks.\n - When fixing:\n - Turn the verification test into a permanent regression test (a link to the issue in a comment is enough). If the fix touches a code path shared by related behaviors (e.g. both `extractAll: true` and `extractAll: false`), add a test for each.\n - If the repository already has `@FailingTest(issue: '…/')` tests for the issue, remove the annotation so they run as normal tests.\n - Run the whole test file for the changed code, plus closely related suites (e.g. the LSP and legacy protocol tests for a refactoring), and run `dart analyze` and `dart format` on the changed files.\n - Call out any intentional behavior change beyond the reported bug so reviewers can weigh it.\n - Suggest a commit message that ends with `Fixes https://github.com/dart-lang/sdk/issues/` so the issue closes automatically when the change lands. Leave committing and uploading to the user unless they ask you to do it.\n - After the fix lands, remove the issue from `references/investigated_issues.txt` (see step 5).\n\n## Tips\n\n- Use available file and content search tools (such as `grep`, `ripgrep`, or environment-specific\nsearch tools) to check the current codebase for references to the issue or relevant code.\n- Look for related Gerrit CLs that might have fixed the issue but didn't close it automatically.\n- **Pro Tip**: Use the `read-gerrit-cl` skill ([SKILL.md](../../../../../.agents/skills/read-gerrit-cl/SKILL.md)) to inspect the patchset diffs and comments of open or merged Gerrit CLs.\n- **Always prioritize active verification on HEAD**: Regardless of how old an issue is or what version it specifies, always attempt to research and reproduce the reported issue against the current `HEAD` of the codebase before proposing closure. Never assume a bug is obsolete or fixed based solely on the passage of time or version discrepancies. If you cannot reproduce it, provide clear details of your reproduction attempt on the current codebase.\n\n\n---\nname: implement-a-lint\ndescription: Guide for creating, registering, documenting, and testing a new lint in the Dart SDK.\n---\n\n## Overview\n\nUse this skill when you need to create a new lint in the Dart SDK codebase. It details the step-by-step implementation and testing procedures.\n\n## Target Reference Example\n\nBefore starting, review this existing feature as the canonical implementation model:\n* **Reference Implementation:** `pkg/linter/lib/src/rules/unnecessary_primary_constructor_body.dart`\n* **Reference Test:** `pkg/linter/test/rules/unnecessary_primary_constructor_body_test.dart`\n\n## File Layout & Naming Conventions\n\nWhen implementing a new lint, you will modify or create the following files:\n\n| File Path | Action | Description |\n|---|---|---|\n| `pkg/linter/lib/src/rules/.dart` | **Create** | The main implementation and AST visitor logic. |\n| `pkg/linter/messages.yaml` | **Modify** | Alphabetical diagnostic entry, problem/correction messages, and documentation. |\n| `pkg/linter/lib/src/rules.dart` | **Modify** | Imports and registers the lint class in the linter registry. |\n| `pkg/linter/test/rules/_test.dart` | **Create** | The reflective tests for the new lint. |\n| `pkg/linter/test/rules/all.dart` | **Modify** | Imports and runs the main entry point of the test file. |\n| `pkg/analysis_server/lib/src/services/correction/error_fix_status.yaml` | **Modify** | Records which diagnostics have or should have a fix. |\n\n## Execution Checklist\n\n### 1. Define the diagnostic code(s)\n\nUnless explicitly instructed otherwise by the user, the rule should have a single diagnostic code.\n\nCopy the following structure to define each of the diagnostic codes that the lint will produce. The definitions should be added alphabetically to `pkg/linter/messages.yaml`.\n\n````yaml\n :\n type: lint\n parameters: none\n problemMessage: \"\"\n correctionMessage: \"\"\n state:\n experimental: \"\"\n categories: [style]\n hasPublishedDocs: false\n documentation: |-\n #### Description\n\n The analyzer produces this diagnostic when \n\n #### Example\n\n The following code produces this diagnostic because :\n\n ```dart\n // Bad code here\n ```\n\n #### Common fixes\n\n If , then :\n\n ```dart\n // Good code here\n ```\n deprecatedDetails: |-\n \n````\n\nIf the user has explicitly requested different diagnostic codes for different contexts, then use the template above for each code, alphabetizing the entries. In this case, each code should have a `sharedName:` entry that is the same for all of the codes being added, and that should be the name of the lint rule. The `ruleName` for each entry should then be something like `ruleName_context`. Only one diagnostic code should have the `documentation:` and `deprecatedDetails:` entries (typically the one that is lexically first). These values will be shared by any codes that have the same `sharedName`.\n\nThe presence of the `deprecatedDetails` property is strictly validated by the generator script. You MUST include it, even for newly added lints. The code snippets in this documentation are not validated, so do not include range markers ('[!' '!]') or use any of the `%` directives.\n\nThe `hasPublishedDocs` property must be included and must have a value of `false`. The flag will be changed to `true` after the documentation has been published to the web site.\n\nThe `categories:` property lists the categories that developers can use to discover new lints. Choose from the following allowed categories: `binarySize`, `brevity`, `documentationCommentMaintenance`, `effectiveDart`, `errorProne`, `flutter`, `languageFeatureUsage`, `memoryLeaks`, `nonPerformant`, `pub`, `publicInterface`, `style`, `unintentional`, `unusedCode`, `web`.\n\nRun the following commands to update the generated files (`lint_names.g.dart`, `diagnostic.g.dart`, etc.):\n\n```bash\ndart run pkg/linter/tool/generate_lints.dart\ndart run pkg/analyzer/tool/messages/generate.dart\n```\n\n**BEFORE CONTINUING TO THE NEXT STEP:**\n\nRun `dart test pkg/analyzer/test/verify_diagnostics_test.dart` to verify that the example and fixes code in the documentation is correct. Make changes as necessary to get the test to pass, re-running the test until it passes. If you modify the `messages.yaml` file then you must re-run the generators before re-testing.\n\n### 2. Implement the lint\n\nIf the lint is dependent on a language experiment, and that experiment is not enabled by default, confirm that the list of experiments returned by `experimentsForTests` in `pkg/analyzer_testing/lib/experiments/experiments.dart` includes the experiment. If not, add it.\n\nNote that a new lint should use the next version of the Dart SDK for the `since` property in the `AnalysisRule` constructor.\n\nCreate an implementation of the lint in the file `pkg/linter/lib/src/rules/.dart` by copying the following template:\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n\nimport 'package:analyzer/analysis_rule/analysis_rule.dart';\nimport 'package:analyzer/analysis_rule/rule_context.dart';\nimport 'package:analyzer/analysis_rule/rule_visitor_registry.dart';\nimport 'package:analyzer/dart/ast/ast.dart';\nimport 'package:analyzer/dart/ast/visitor.dart';\n\nimport '../analyzer.dart';\nimport '../diagnostic.dart' as diag;\n\nconst _desc = r'';\n\n/// \nclass extends AnalysisRule {\n new() : super(\n name: LintNames.,\n description: _desc,\n state: RuleState.experimental(since: .new(, , 0)),\n );\n\n @override\n DiagnosticCode get diagnosticCode => diag.ruleName;\n\n @override\n void registerNodeProcessors(\n RuleVisitorRegistry registry,\n RuleContext context,\n ) {\n var visitor = _Visitor(this, context);\n // \n }\n}\n\nclass _Visitor(final AnalysisRule rule, final RuleContext context)\n extends SimpleAstVisitor {\n // \n}\n```\n\nThere must be a visit method for every registered node type and there must be a registration for every `visit` method.\n\nUse either `rule.reportAtToken(token)` or `rule.reportAtNode(node)` to emit the diagnostics. Prefer using `rule.reportAtToken(token)` to report at a single token.\n\nIf the lint produces multiple diagnostic codes, make the implementation class a subclass of `MultiAnalysisRule`. For rules with multiple diagnostic codes:\n1. Extend `MultiAnalysisRule` instead of `AnalysisRule`.\n2. Override `diagnosticCodes` (plural) returning a list of codes instead of `diagnosticCode` (singular):\n ```dart\n @override\n List get diagnosticCodes => [\n diag.ruleName_contextOne,\n diag.ruleName_contextTwo,\n ];\n ```\n3. Provide the specific diagnostic code when reporting:\n ```dart\n rule.reportAtToken(token, diagnosticCode: diag.ruleName_contextOne);\n ```\n\n#### Useful Analyzer APIs for Lint Logic\n\n- Unwrapping Parentheses: Use `node.unParenthesized` to inspect the target of an expression without manually traversing parenthesized wrappers.\n- Element Model: Use `node.declaredFragment?.element` to retrieve the `Element` corresponding to the declared node.\n- Experiment/Feature Flags: Use `context.isFeatureEnabled(Feature.feature_name)` to conditionally enable or check features.\n\n#### Useful tools\n\n- The tool `pkg/linter/tool/spelunk.dart` can be used to print/dump the AST of a given file. This might be helpful to determine which AST node types need to be visited.\n\n**BEFORE CONTINUING TO THE NEXT STEP:**\n\nEnsure that the implementation passes `dart analyze` without any diagnostics. If there are diagnostics, you must fix them before proceeding.\n\n### 3. Register the lint\n\nAfter the class is written, modify `pkg/linter/lib/src/rules.dart` to import your rule and register it alphabetically:\n\n```dart\n ..registerLintRule(RuleName())\n```\n\n### 4. Record the status of the lint's fixes\n\nEdit the file `pkg/analysis_server/lib/src/services/correction/error_fix_status.yaml` to indicate that the lint needs to be evaluated to determine whether one or more fixes should be provided. Do this by alphabetically adding an entry of the form\n```yaml\n:\n status: needsEvaluation\n```\n\n### 5. Write tests for the lint\n\nCreate a reflective test suite in the file `pkg/linter/test/rules/_test.dart` by copying the following template:\n\n```dart\n// Copyright (c) , the Dart project authors. Please see the AUTHORS file\n// for details. All rights reserved. Use of this source code is governed by a\n// BSD-style license that can be found in the LICENSE file.\n\nimport 'package:test_reflective_loader/test_reflective_loader.dart';\n\nimport '../rule_test_support.dart';\n\nvoid main() {\n defineReflectiveSuite(() {\n defineReflectiveTests(Test);\n });\n}\n\n@reflectiveTest\nclass Test extends LintRuleTest {\n @override\n String get lintRule => LintNames.;\n\n // \n}\n```\n\nUse `assertDiagnosticsFromMarkup` to test cases where a diagnostic is expected and `assertNoDiagnostics` to test cases where a diagnostic is not expected. Do not use `assertDiagnostics`.\n\nIf the implementation of the lint has any conditions that must be true in order for the diagnostic to be generated, ensure that there is at least one test for each condition that shows that the diagnostic is not generated when the condition is false.\n\nIf the lint is dependent on a language experiment, then tests that verify the behavior of the lint when the experiment is not enabled must include a language override comment in the test code. The version should be the version before the experiment was introduced, which is given as the `experimentalReleaseVersion` key in `pkg/analyzer/lib/src/dart/analysis/experiments.g.dart`. If the release version is `null`, then use the current Dart SDK version.\n\nLinter tests run against a lightweight mocked SDK (`pkg/analyzer/lib/src/test_utilities/mock_sdk.dart`) rather than the real disk SDK. If a test references standard library APIs (e.g. `Iterable`) and the test fails because the API isn't found, try using a different API or enhance the mock SDK to include the APIs.\n\n### 6. Run the tests\n\nExecute the tests directly using the `dart test` runner:\n\n```bash\ndart test pkg/linter/test/rules/_test.dart\n```\n\nIf the tests don't pass, then either fix the implementation or fix the test, as appropriate.\n\nAfter the tests that you added are passing, run\n```bash\ndart run pkg/linter/test/all.dart\ndart run pkg/analyzer/test/test_all.dart\ndart run pkg/analysis_server/test/test_all.dart\n```\n\nThese will usually all pass at this point, but will sometimes fail. If they do, fix the failures and repeat the test commands until they all pass.\n\n### 7. Verify that the code is error free and formatted correctly\n\nVerify that every file that was either created or modified analyzes cleanly (no diagnostics):\n\n```bash\ndart analyze \n```\n\nIf any diagnostics are reported, attempt to fix them by running:\n\n```bash\ndart fix \n```\n\nThen rerun `dart analyze`. If there are still diagnostics, fix them directly. Repeat until `dart analyze` reports no diagnostics.\n\nThen run the following command on all created or modified files, but not on generated files:\n```bash\ndart format \n```\n\n\n---\nname: improve-performance-with-session-log\ndescription: >-\n Use this skill when diagnosing, reproducing, and improving the performance or\n latency of Dart Analysis Server (DAS) LSP requests and responses using\n recorded session communications logs, log normalization, replay tools, and\n fresh local SDK compilation.\n---\n\n# Improve LSP Performance with Session Logs\n\nThis skill guides you through diagnosing slow LSP request/response interactions\nin the Dart Analysis Server (DAS), reproducing them with the log player replay\ntool, optimizing the server implementation, recompiling the SDK, and validating\nthe latency improvement.\n\n---\n\n## Workflow Overview\n\n```mermaid\nflowchart LR\n A[\"1. Inspect Log\"] --> B[\"2. Normalize Log\"] --> C[\"3. Reproduce & Measure Baseline\"]\n C --> D[\"4. Optimize & Rebuild SDK\"] --> E[\"5. Replay with Built SDK & Validate\"]\n```\n\n1. **Inspect Log**: Locate target requests (e.g. `textDocument/documentColor`,\n `textDocument/completion`) and calculate request-to-response duration\n (`response.time - request.time`).\n2. **Normalize Log**: Replace machine-specific paths with portable placeholders\n (`{{workspaceFolder-0}}`, `{{dartSdkRoot}}`).\n3. **Reproduce Baseline**: Replay the log against the baseline server using\n `server_driver_main.dart` or automated playback, isolating warm request\n latency from cold-start queueing.\n4. **Optimize Code**: Implement performance improvements in `pkg/analysis_server`\n or `pkg/analyzer`.\n5. **Recompile SDK**: From ``, run `python3 tools/build.py -mrelease create_sdk`.\n6. **Replay with the freshly built SDK**: Replay using the newly compiled `dart` binary to\n verify latency reduction and correctness.\n7. **Run unit and integration tests**: Run existing unit tests and add regression tests for\n modified logic.\n\n## Step 1: Inspect the session communications log\n\nSession logs are line-delimited JSON (JSON Lines). Each line is an independent\nJSON object containing `time` and `kind`. Depending on the kind of entry (e.g.\n`message` versus `commandLine`), lines may also have `sender`, `receiver`, and\n`message` (though some entries might omit them).\n\n### Analyze the Log with `analyze_session_log.dart`\n\nThe skill provides\n[`scripts/analyze_session_log.dart`](scripts/analyze_session_log.dart) to parse,\ninspect, and summarize session logs automatically:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/analyze_session_log.dart \\\n [--method=] [--min-ms=] [--warm-only] [--summary] \n```\n\nKey capabilities:\n\n* **Measures Client & Server Durations**: Displays client-perceived duration\n (`response.time - request.clientRequestTime`) and server processing duration\n (`response.time - request.time`).\n* **Detects Cold-Start Queueing**: Identifies whether requests occurred during\n initial background analysis (`$/progress` `\"Analyzing...\"`) or against a warm\n server.\n* **Extracts Errors & Crashes**: Automatically parses and surfaces server\n exceptions (e.g. `Bad state: SimpleIdentifierImpl is not in the V2 AST view`).\n\nExample of inspecting 'textDocument/documentColor' requests in a session:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/analyze_session_log.dart \\\n -m documentColor session-log-2.txt\n```\n\n## Step 2: Normalize the Log\n\nRaw session logs contain absolute paths from the machine where they were\nrecorded. Normalize them to make them replayable against any local workspace:\n\n```bash\ndart /pkg/analysis_server/tool/log_player/normalize.dart \\\n -i \\\n -o \\\n -r \\\n [-p ]\n```\n\nOptions:\n\n* `-i`, `--input`: Path to the raw recorded log file.\n* `-o`, `--output`: Destination path for the normalized log.\n* `-r`, `--root-dir`: Root directory of the project open during recording.\n* `-p`, `--package-config`: (Optional) Explicit path to `package_config.json`\n if not at `/.dart_tool/package_config.json`.\n\nNormalizing replaces machine paths with `{{workspaceFolder-0}}`,\n`{{dartSdkRoot}}`, and package URIs with `{{package-root:...}}`.\n\n---\n\n## Step 3: Reproduce and Measure Baseline Latency\n\n### Automated Replay & Measurement (`measure_request_latency.dart`)\n\nThe skill provides\n[`scripts/measure_request_latency.dart`](scripts/measure_request_latency.dart)\nto automatically replay setup messages up to a target request, wait for\nbackground analysis to finish, and measure wall-clock latency across multiple\niterations:\n\n```bash\ndart /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/measure_request_latency.dart \\\n -i -w -r 3 \n```\n\nOptions:\n\n* `-i`, `--request-id`: (**Required**) The target request ID identified in Step 1\n (e.g. `153`). Always specify this to ensure you benchmark the exact target\n request.\n* `-m`, `--method`: Target request method (e.g. `textDocument/documentColor`).\n Avoid using this without `-i`, as matching by method alone yields the first\n occurrence in the log rather than the slowest or target request.\n* `-w`, `--workspace`: Local project directory to map `{{workspaceFolder-0}}`\n to (defaults to current working directory).\n* `-r`, `--repeat`: Number of iterations to measure consistency (default: 1).\n\n> [!IMPORTANT]\n> **Always use `--request-id` (`-i`)**: Pass the specific request ID found from\n> inspecting or analyzing the log in Step 1. Do not rely on `--method` alone:\n> `--method` only matches the *first* occurrence of that method in the session\n> log, which is often a fast initial request rather than the slow interaction\n> you are trying to optimize.\n\n### Interactive replay (`server_driver_main.dart`)\n\nFor manual inspection and stepping through messages one-by-one:\n\n```bash\ncd /path/to/project/root\ndart /pkg/analysis_server/tool/log_player/server_driver_main.dart /path/to/normalized_log.json\n```\n\n* Press **Enter** to step through messages.\n* Wait for background analysis to finish (`$/progress` `{\"kind\": \"end\"}`) before\n stepping to the target request to measure warm handler latency.\n\n**Note** that this tool can absolutely change the timing of the operations in\nthe log, which can potentially change the **behavior** of the server.\n\n## Step 4: Investigate code and implement optimizations\n\n1. Identify the handler or computer responsible for the request method:\n * Method `textDocument/documentColor` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_document_color.dart` and\n `pkg/analysis_server/lib/src/computer/computer_color.dart`.\n * Method `textDocument/completion` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_completion.dart` and\n `pkg/analysis_server/lib/src/services/completion/`.\n * Method `textDocument/codeAction` $\\to$\n `pkg/analysis_server/lib/src/lsp/handlers/handler_code_actions.dart`.\n2. Inspect profiling data or trace execution paths for common bottlenecks:\n * **Unnecessary AST traversals**: Are visitors walking AST subtrees that\n cannot contain relevant nodes?\n * **Excessive element resolution or type evaluation**: Can lightweight\n syntactic checks filter out candidates before resolving types or evaluating\n constant values?\n * **Repeated allocations or computations**: Can maps/sets be reused, or early\n exits added?\n3. Apply optimizations in `pkg/analysis_server` or `pkg/analyzer`.\n\n## Step 5: Recompile the Dart SDK\n\nRecompile the analysis server snapshot and SDK binaries:\n\n```bash\n(cd && python3 tools/build.py -mrelease create_sdk)\n```\n\nThe compiled SDK binaries will be located at:\n\n* **macOS**: `xcodebuild/ReleaseARM64/dart-sdk/bin/dart` (or\n `xcodebuild/ReleaseX64/...`)\n* **Linux / Windows**: `out/ReleaseX64/dart-sdk/bin/dart`\n\n## Step 6: Replay with the freshly built SDK\n\n> [!IMPORTANT]\n> `ServerDriver` starts the server process using `Platform.resolvedExecutable`.\n> To run against your freshly built changes, you **must** execute `server_driver_main.dart` (or your replay script) using the compiled `dart` binary, not the system `dart`.\n\n### Running automated replay with the built SDK\n\nRun `measure_request_latency.dart` with the compiled binary to measure latency after changes:\n\n```bash\n \\\n /pkg/analysis_server/.agents/skills/improve-performance-with-session-log/scripts/measure_request_latency.dart \\\n -i -w -r 3 /path/to/normalized_log.json\n```\n\n### Interactive stepping with the built SDK\n\n```bash\n \\\n /pkg/analysis_server/tool/log_player/server_driver_main.dart \\\n /path/to/normalized_log.json\n```\n\nIf running from an external project root and package resolution fails, specify\nthe package config:\n\n```bash\n--packages=/.dart_tool/package_config.json\n```\n\n### Validation checklist\n\n- [ ] Confirm the target request returns the exact same valid response payload\n (colors, completions, etc.).\n- [ ] Verify that request execution latency is substantially reduced compared to\n baseline.\n- [ ] Confirm no unhandled exceptions or error responses are produced in the\n server output stream.\n\n## Step 7: Run unit and integration tests\n\nRun relevant existing tests with the compiled Dart binary:\n\n```bash\n test /pkg/analysis_server/test/src/...\n```\n\nAdd new unit tests in the appropriate test suite (e.g.\n`pkg/analysis_server/test/src/computer/...`) to lock in the performance\noptimization and guard against regressions.\n\n\n# As_show Skill\n\nPath: `pkg/front_end/testcases/extensions/as_show/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/as_show/libraries.json)\n\n\n# Patch Skill\n\nPath: `pkg/front_end/testcases/extensions/patch/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/patch/libraries.json)\n\n\n# Patching Skill\n\nPath: `pkg/front_end/testcases/extensions/patching/libraries.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/front_end/testcases/extensions/patching/libraries.json)\n\n\n# Rules Skill\n\nPath: `pkg/linter/test/rules/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/pkg/linter/test/rules/analysis_options.yaml)\n\n\n# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/analysis_options.yaml)\n\n\n# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/pubspec.yaml)\n\n\n# Dartfuzz Skill\n\nPath: `runtime/tools/dartfuzz/README_minimize.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/README_minimize.md)\n\n\n# Heapsnapshot Skill\n\nPath: `runtime/tools/heapsnapshot/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/CHANGELOG.md)\n\n\n# Heapsnapshot Skill\n\nPath: `runtime/tools/heapsnapshot/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/pubspec.yaml)\n\n\n# Profiling Skill\n\nPath: `runtime/tools/profiling/analysis_options.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/analysis_options.yaml)\n\n\n# Profiling Skill\n\nPath: `runtime/tools/profiling/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/CHANGELOG.md)\n\n\n# Profiling Skill\n\nPath: `runtime/tools/profiling/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/pubspec.yaml)\n\n\nname: runtime_tools\ndescription: Internal runtime tools.\n\nenvironment:\n sdk: ^3.9.0\n\nresolution: workspace\npublish_to: none\n\n\n### dart2js\\_tools\n\nThis package collects tools used with dart2js.\n\nFor now, this contains scripts useful to work with obfuscated stack traces in\nproduction and reading data from the extensions added to source-maps by dart2js\n(like minified names and inlined stack frames).\n\nIn the future we plan to merge here tools in the dart2js\\_info package as well.\n\n\n[![pub package](https://img.shields.io/pub/v/dds_service_extensions.svg)](https://pub.dev/packages/dds_service_extensions)\n[![package publisher](https://img.shields.io/pub/publisher/dds_service_extensions.svg)](https://pub.dev/packages/dds_service_extensions/publisher)\n\nA package used to expand the `package:vm_service` interface with support for RPCs added in the [Dart Developer Service (DDS) protocol][dds-protocol].\n\n[dds-protocol]: https://github.com/dart-lang/sdk/blob/main/pkg/dds/dds_protocol.md\n\n\n# dartfuzz Documentation\n\nPath: `runtime/tools/dartfuzz/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/dartfuzz/README.md)\n\n\n# entitlements Documentation\n\nPath: `runtime/tools/entitlements/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/entitlements/README.md)\n\n\n# heapsnapshot Documentation\n\nPath: `runtime/tools/heapsnapshot/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/heapsnapshot/README.md)\n\n\n# profiling Documentation\n\nPath: `runtime/tools/profiling/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/profiling/README.md)\n\n\n# wiki Documentation\n\nPath: `runtime/tools/wiki/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/dart-lang/sdk/HEAD/runtime/tools/wiki/README.md)\n"}