The WinApp CLI is rapidly adding features and expanding, as a result, it'll be necessary to make sure that the skills stay up to date.
I see this lying heavily on the CLI review part process for triggering work, if necessary (it may make sense for this issue to live there, but we can move it later on). The official CLI review process should take the skills into account and ask these questions. Any official contribution or review process would take these into account:
-
Is this a breaking change for a skill - does it change functionality in such a way that the skill may not work properly anymore? If yes, the CLI change should be tied to an associate win-dev-skills update, and cannot move forward until an associated skill update is authored.
-
Does this change add functionality that could improve an existing skill? If yes, the CLI change should not be gated on a skill update, but an associated issue should be opened and prioritized based on perceived import of the improvement.
-
Does this change enable a possible new skill in an existing plugin? If yes, the CLI change should not be gated on the new skill, but an associated issue should be opened and prioritized as above.
Proposal
To streamline this process, it may be nice to create an internal "skill-review" skill (turtles all the way down) that analyzes CLI updates against our skills to, most importantly, flag potential breaking changes to the skills, but also propose recommendations for how updates to the CLI could be surfaced in existing skills/new skills. These recommendations would not replace human judgement, but could keep the thought process of considering the skill automatic on every CLI review and flag potential breaking changes.
It's possible this could even be tacked on as an 8th agent sub category in the existing pr-review skill, but my instinct is to keep it separate.
In addition to this, the PR review templates should clearly state expectations for considering skills.
The WinApp CLI is rapidly adding features and expanding, as a result, it'll be necessary to make sure that the skills stay up to date.
I see this lying heavily on the CLI review part process for triggering work, if necessary (it may make sense for this issue to live there, but we can move it later on). The official CLI review process should take the skills into account and ask these questions. Any official contribution or review process would take these into account:
Is this a breaking change for a skill - does it change functionality in such a way that the skill may not work properly anymore? If yes, the CLI change should be tied to an associate win-dev-skills update, and cannot move forward until an associated skill update is authored.
Does this change add functionality that could improve an existing skill? If yes, the CLI change should not be gated on a skill update, but an associated issue should be opened and prioritized based on perceived import of the improvement.
Does this change enable a possible new skill in an existing plugin? If yes, the CLI change should not be gated on the new skill, but an associated issue should be opened and prioritized as above.
Proposal
To streamline this process, it may be nice to create an internal "skill-review" skill (turtles all the way down) that analyzes CLI updates against our skills to, most importantly, flag potential breaking changes to the skills, but also propose recommendations for how updates to the CLI could be surfaced in existing skills/new skills. These recommendations would not replace human judgement, but could keep the thought process of considering the skill automatic on every CLI review and flag potential breaking changes.
It's possible this could even be tacked on as an 8th agent sub category in the existing pr-review skill, but my instinct is to keep it separate.
In addition to this, the PR review templates should clearly state expectations for considering skills.