From cd65a4c9d86e574a1f5432d5510ceb225d3beb06 Mon Sep 17 00:00:00 2001 From: Ben McIlwain Date: Thu, 28 May 2026 18:32:18 -0400 Subject: [PATCH] Apply continuous self-improvement to skills (#3072) - pr-polisher: Relaxed the package-lock.json strictness. If package.json or dependencies.gradle are modified, changes to package-lock.json now correctly trigger a WARNING rather than a fatal ERROR, streamlining intentional dependency updates. - java-ast-refactoring: Replaced the reliance on a local google-java-format binary with the project's native ./gradlew javaIncrementalFormatApply task for post-AST format fixes. - Updated GEMINI.md and skill instructions to explicitly authorize and mandate the agent to proactively propose systemic infrastructure fixes to the user when it encounters recurring friction, false positives, or brittle workarounds. - Overhauled the PR polisher "When to Use" instructions in GEMINI.md and SKILL.md into a critical mandate explicitly tying the execution of the polisher to the action of making or amending a commit to prevent agent forgetfulness. --- .gemini/skills/java-ast-refactoring/SKILL.md | 4 ++-- .../java-ast-refactoring/scripts/run_rewrite.sh | 9 +-------- .gemini/skills/pr-polisher/SKILL.md | 16 +++++++++------- .gemini/skills/pr-polisher/scripts/check_diff.py | 5 ++++- GEMINI.md | 14 +++++++++++--- 5 files changed, 27 insertions(+), 21 deletions(-) diff --git a/.gemini/skills/java-ast-refactoring/SKILL.md b/.gemini/skills/java-ast-refactoring/SKILL.md index 96ca08ec2..ba4d7d554 100644 --- a/.gemini/skills/java-ast-refactoring/SKILL.md +++ b/.gemini/skills/java-ast-refactoring/SKILL.md @@ -22,9 +22,9 @@ python3 .gemini/skills/java-ast-refactoring/scripts/safe_rename.py ) bsaQuery(...)` if it compiles without it). - **Visibility Modifiers:** Do not use `/* package */` comments to denote package-private visibility. Just leave the modifier blank; it is an established idiom in this codebase. +## Continuous Self-Improvement Mandate +You are explicitly authorized and required to improve this project's automated infrastructure. +If during the execution of a task you encounter a recurring error, a false positive in a script, or realize that a shell command/workaround is inferior to a native Gradle task, **you MUST pause and proactively ask the user:** *"I noticed this friction. Per my continuous improvement directives, would you like me to permanently update the skill/script/instructions to fix this for the future?"* +Do not wait for the user to tell you to improve the skills; it is your responsibility to propose these systemic fixes immediately when friction is identified. + ### Advanced Java & Guava Idioms - **Immutable Types:** Declare variables, fields, and return types explicitly as Guava immutable types (e.g., `ImmutableList`, `ImmutableMap`) instead of their generic interfaces (`List`, `Map`) to clearly communicate immutability contracts to callers. Use `toImmutableList()` and `toImmutableMap()` collectors in streams rather than manually accumulating into an `ArrayList` or `HashMap`. - **Constructors:** Do not perform heavy logic, I/O, or external API calls inside constructors. Initialization logic should be deferred or handled in a factory method or a dedicated startup routine. @@ -110,10 +115,13 @@ This document captures high-level architectural patterns, lessons learned from l 5. **Only after** step 4 has successfully returned a clean working directory may you generate a text response to the user declaring that the task is complete. - **Diff Review:** Before finalizing a task, review the full diff (e.g., `git diff HEAD^`) to ensure all changes are functional and relevant. Identify and revert any formatting-only changes in files that do not contain functional updates to keep the commit focused. -## Self-Review Guidelines & PR Polisher -Before finalizing any PR or declaring a task complete, you MUST automatically execute the `pr-polisher` skill to perform a thorough, rigorous self-review of your entire diff. +## 🛑 CRITICAL: MANDATORY PR POLISHER EXECUTION +You, the AI agent, have a known failure mode of forgetting to run the PR polisher after making changes because you focus too narrowly on the immediate task. To prevent this, you are bound by the following absolute rule: -To run it, activate the skill and follow its exact workflow. You MUST NOT declare a task done until the automated script (`python3 .gemini/skills/pr-polisher/scripts/check_diff.py`) returns 0 errors, the presubmits and tests pass, and the workspace is fully clean. +**ANY TIME you create a commit, amend a commit, or complete a user's request that modifies the repository state, your VERY LAST action before generating a text response to the user MUST be to execute the `pr-polisher` skill.** +Do not ask for permission. Do not wait for the user to remind you. Run the full suite (`python3 .gemini/skills/pr-polisher/scripts/check_diff.py`, `runPresubmits`, `build`, and `test`), fix any errors, amend your commit, and report the final polished results in your response. + +You MUST NOT declare a task done until this automated script returns 0 errors, the presubmits and tests pass, and the workspace is fully clean. 1. **Imports & FQNs:** Did I leave any fully-qualified class names or static variables inline? Did I add the necessary imports for them? *Crucial Exception:* If the file already imports a class with the identical name (e.g., it uses both `java.util.Date` and `java.sql.Date`), one MUST remain fully qualified to avoid a compilation conflict. 2. **Diff Scope:** Are there any formatting-only changes in files that I did not functionally modify? If so, revert them. Does the total line count of the diff align with the approved scope (e.g., ~1,000 lines for migrations)?