Add skill for updating package versions that is used from the changelog skill

Author: kenzieschmoll

.agents/skills/adding-changelog-entries/SKILL.md

@@ -8,11 +8,6 @@ description: Guides the creation of changelog entries for published packages in
 When adding changelog entries to published packages (`devtools_shared`, `devtools_app_shared`, and `devtools_extensions`), follow these rules:
 
 - **Check Publication State**: Never add an entry to an already published version (e.g. `# 12.1.0`). You MUST check which versions are published on pub.dev (e.g., at `https://pub.dev/packages/<package_name>/versions`) before determining section headers! If a version is not yet published, it should be suffixed with the next numeric `-wip` tag (e.g., `## 0.5.1-wip`) rather than generic placeholder headers like `# WIP`!
-- **Lock-step Mono-repo Updates**: Between the published packages (`devtools_shared`, `devtools_app_shared`, and `devtools_extensions`), version bumps and dependency constraints modifications targeting each other MUST happen in lock-step to avoid graph resolution failures! Always update them together!
-- **Match Pubspec Versions Exactly**: When updating dependency versions in published package `pubspec.yaml` files, ALWAYS use the *actual* version specified in the target package's `pubspec.yaml`. If a package version contains a suffix like `-wip` (e.g., `13.0.0-wip`), that full string MUST be used in dependency declarations (e.g., `devtools_shared: ^13.0.0-wip`). Leaving off the suffix will cause version solving failures.
-- **Version Decisions**: Decide if it should be a major, minor, or patch version based on your edits:
-  - **Breaking changes**: Major bump (+1 to first component, others reset to 0). E.g., removals of public constants, properties, getters/setters, or APIs.
-  - **New features or deprecation start**: Minor bump (+1 to second component, patch resets to 0).
-  - **Bug fixes and non-breaking changes**: Patch bump (+1 to third component).
+- **New Version Headers**: If a version bump is required, you MUST first use the instructions in [updating-package-versions](../updating-package-versions/SKILL.md) to update the package version in `pubspec.yaml`, and then add a new header to the changelog file with the new version (e.g., `## 0.5.1-wip`) before adding your entries.
 - **Accurately Distinguish Packages**: Ensure that the cleanups or edits applied to a specific package's changelog entries belong strictly to that package path (e.g., changes in `devtools_app` do not warrant entries in `devtools_shared`).
 - **Conciseness and Accuracy**: Describe clearly what was changed and why. Avoid generic descriptions without context, such as "Fixes missing deprecation message". Indicate specifically what was added or removed.

.agents/skills/updating-package-versions/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: updating-package-versions
+description: Guides updating dependency versions in published packages to avoid mono-repo resolution failures.
+---
+
+# Updating Package Versions
+
+When updating dependency versions in published package `pubspec.yaml` files (`devtools_shared`, `devtools_app_shared`, and `devtools_extensions`), follow these rules to protect the local mono-repo workspace graph:
+
+- **Version Decisions**: Decide if it should be a major, minor, or patch version based on your edits:
+  - **Breaking changes**: Major bump (+1 to first component, others reset to 0). E.g., removals of public constants, properties, getters/setters, or APIs.
+  - **New features or deprecation start**: Minor bump (+1 to second component, patch resets to 0).
+  - **Bug fixes and non-breaking changes**: Patch bump (+1 to third component).
+- **Match Exact Versions**: Always use the **actual** version specified in the target package's `pubspec.yaml` file.
+- **Suffix Preservation**: If a requested version contains a suffix like `-wip` (e.g., `13.0.0-wip`), the full string MUST be used in dependency constraints (e.g., `devtools_shared: ^13.0.0-wip`).
+- **Prevent Graph Failures**: Do not drop the suffix or estimate the base version tags. Version solver operations will fail in the local workspace if dependencies point to published strings that can't be resolved in non-published repositories.
+- **Resolution Testing**: After updating versions, run `flutter pub get` in the repository to ensure version solving is satisfied. If this returns errors, you should fix the errors and try again.
+- **Updating devtools_app**: In `packages/devtools_app/pubspec.yaml`:
+  - Dependencies on published packages do not have version constraints. This is intentional; do not change this when updating versions.
+  - Always use the `dt update-version` tool to update the `devtools_app` version.
+  - This should only be updated for monthly releases and cherry pick releases, so perform this update only when explicitly asked to.