Adds pre-push readiness skill

[camsim99]

Adds a new pre-push skill that verifies changes made to a packages are ready to be "pushed", i.e. the committed changes could successfully be made into a pull request that follows the requirements of the flutter/packages repository (including some of the items in the checklist below).

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[camsim99]

Just saw that we could also use the --set-exit-if-changed option. But we could format directly since it might help the developer. @LouiseHsu what do you think?

[LouiseHsu]

I think what you have is good already!

[LouiseHsu]

So from what I remember, skills are invoked only based off the description and the name. So maybe you can make the desc more detailed? something like

"Executes the required pre-push steps for the flutter/packages repository. Call this tool immediately whenever the user asks to push, requests a code review before committing, or wants to validate their local changes for a pull request. Do NOT use this tool if the user is working in flutter/flutter or flutter/engine."

[camsim99]

I see. Good call, I like your description! Updated it.

[gemini-code-assist]

Code Review

This pull request adds a new markdown document, SKILL.md, defining the pre-push validation steps and checklist for the flutter/packages repository. The review feedback suggests two improvements to the instructions: first, recommending that developers commit rather than stash their changes during the initial working tree check to ensure latest changes are validated; and second, clarifying that any auto-generated changes in the final check should be committed rather than discarded.

[gemini-code-assist]

Instructing the developer to stash their changes is counterproductive for validation. If they stash their changes, the working tree is reverted to the HEAD commit, meaning the subsequent validation steps (formatting, analysis, tests) will run on the older code without their latest changes. Instead, they should be instructed to commit their changes (e.g., as a temporary WIP commit) so that those changes can actually be validated.

Suggested change

	If this command outputs anything, the code WAS NOT ready to push.
	The developer must commit or stash their changes
	before you can proceed with the remaining validation steps.
	Do not continue if there are uncommitted changes.
	If this command outputs anything, the code WAS NOT ready to push.
	The developer must commit their changes (e.g., as a temporary WIP commit)
	before you can proceed with the remaining validation steps.
	Do not continue if there are uncommitted changes.

[gemini-code-assist]

Using the phrase 'cleaned up' might be confusing, as it could be interpreted as discarding the changes (e.g., via git checkout or git clean). Since any changes at this stage are likely formatting fixes or version updates generated by the validation tools, they should be committed instead of discarded. Clarify that these changes must be committed.

Suggested change

	If this command outputs anything, the code WAS NOT ready to push.
	The changes must be cleaned up before the developer can push.
	If this command outputs anything, the code WAS NOT ready to push.
	The changes must be committed before the developer can push.