Hi, I've opened a number of PRs related to Skills over the last week or so. Most are currently intentionally marked as Draft. The goal is to get broader review and feedback on the approach before they get merged.
Several of these introduce new skills, mentoring workflows, or intervention patterns, and I'd prefer to get feedback on design, usability, and direction early rather than merge and iterate later. Current Skills PRs include: - #252: feat(mentoring): add pr-management-mentor intervention eval suite; mark Mentoring experimental - #251: feat(pairing-self-review): add pre-flight self-review skill and eval suite - #250: Add spec-driven build loop and product specs - #229: committer-onboarding — post-vote onboarding for committers and PMC members - #228: contributor-activity-sweep skill with eval suite - #227: contributor-nomination skill with eval suite #228 and #229 are related. #228 is intentionally lightweight and narrow in scope as an initial building block rather than attempting to solve contributor analysis in a single large skill. Feedback on whether that decomposition makes sense would be particularly useful. #250 is a little different from the others. It introduces a spec-driven workflow that can generate new skills from written specifications. Several of the PRs above were created using that approach, so it also serves to exercise and validate the workflow itself. A simple way to test it is: Start on the #250 branch and run: ./tools/spec-loop/look.sh 1 This reviews the specs and existing PRs, decides what should be implemented next, creates a branch, and attempts to implement it. Expect it to take around 10–15 minutes. The output still needs review. You'll want to inspect what it generated and run tests as normal, but it should give a sense of how the workflow behaves in practice. Separately, there are also two smaller eval/test PRs: - #268: feat(eval): add write-skill eval suite for Step 5 security checklist - #267: feat(eval): add list-steward-skills eval suite (7 cases, 2 steps) These should be relatively straightforward to review and are probably a good place to start if you'd like to provide feedback without digging into something bigger. Feedback on approach, naming, scope, assumptions, or anything that feels off would be very helpful before these move out of Draft. Thanks, Justin
