Add a skills for adding changelog entries and updating package versions

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

@@ -0,0 +1,14 @@
+---
+name: adding-changelog-entries
+description: Use when documenting changes in CHANGELOG.md files for devtools_shared, devtools_app_shared, or devtools_extensions.
+---
+
+# Adding Changelog Entries
+
+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`) or follow the existing convention in the file, such as `(not released)`. You should also match the existing header level (H1 or H2) used for versions in that file. Avoid generic placeholder headers like `# WIP`!
+- **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.
+- **User visible changes ONLY**: Only add entries in the changelog if the change is meaningful to consumers of the package. Do not include internal refactoring notes or other trivial changes that users do not care about.

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

@@ -0,0 +1,22 @@
+---
+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.
+- **No Dependencies on Unpublished Packages**: Published packages (`devtools_shared`, `devtools_app_shared`, and `devtools_extensions`) MUST NOT depend on unpublished packages like `devtools_app` or `devtools_test`.
+- **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.

.gemini/styleguide.md

@@ -14,7 +14,7 @@ and the CI testing ensures that the code is formatted correctly.
     - `[NIT]`: Idiomatic improvements or minor naming suggestions.
 - **Focus:** Prioritize logic, performance on the UI thread, and architectural consistency.
 - **No Empty Praise:** Do not leave "Looks good" or "Nice change" comments. If there are no issues, leave no comments.
-- **Copyright Headers:** Ensure all new files have a proper copyright header with the current year. For example:
+- **Copyright Headers:** Ensure all new files (except for agent skills and generated files) have a proper copyright header with the current year. For example:
   ```
   // Copyright 2026 The Flutter Authors
   // Use of this source code is governed by a BSD-style license that can be