Basic project management skill - #13709
Conversation
🔍 Skill Validator Results
Summary
Full validator output```text Found 1 skill(s) [project-management] 📊 project-management: 3,246 BPE tokens [chars/4: 3,256] (standard ~), 34 sections, 11 code blocks [project-management] ⚠ Skill is 3,246 BPE tokens (chars/4 estimate: 3,256) — approaching "comprehensive" range where gains diminish. [project-management] ⚠ No numbered workflow steps — agents follow sequenced procedures more reliably. ✅ All checks passed (1 skill(s)) ``` |
There was a problem hiding this comment.
Pull request overview
Adds a new repository “skill” document to front-load practical GitHub issue + Projects (ProjectV2) management guidance for the dotnet/msbuild team, aimed at reducing churn during migrations and bulk board operations.
Changes:
- Introduces a
project-managementskill with conventions, commonghCLI commands, and GraphQL snippets for reading/updating ProjectV2 fields. - Documents pagination patterns and common GraphQL/CLI pitfalls (aliasing
fieldValueByName,--paginateJSON output behavior, union selection fragments). - Provides repeatable workflows for adding issues to the MSBuild project board and setting sprint/field values.
There was a problem hiding this comment.
Review Summary
Overall this is a well-written, valuable skill that addresses real friction with GitHub's project board APIs. The GraphQL examples are correct and the gotchas section will save agents a lot of trial-and-error cycles.
Blocking Issue
All /tmp/ path references must be changed. The primary consumers of this skill (Copilot coding agents) explicitly prohibit writing to /tmp. There are 5 occurrences (lines 51, 54, 57, 300, 301). Use working-directory-relative paths (e.g., ./comment.md) or inline the content via --body with heredocs.
Non-blocking suggestions
- Extract Status in the bulk-query Python example — it's queried but not processed, making the example incomplete for the most common audit use case.
- Add ID re-derivation command near the hardcoded identifiers table so the skill is self-healing.
- Add minimal error handling to the Python subprocess call for agent robustness.
- Sanitization checklist — consider adding email address scrubbing.
Positive notes
- Frontmatter follows repo skill conventions (
name,description,argument-hint). - GraphQL alias pattern for
fieldValueByNameis correct and the gotchas section explaining why is excellent. - The "tooling preference" section establishing
ghCLI over MCP tools is a good convention to codify. - Sanitization checklist is thoughtful and complete.
Generated by Expert Code Review (on open) for issue #13709 · ● 1.9M
- Replace /tmp/ paths with working-directory-relative ./ - Add re-derivation snippet for project & field IDs - Extract Status alongside Sprint/Assignees in bulk-query example - Add error handling around the GraphQL subprocess call - Add email-address scrubbing to sanitization checklist Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Addressed the review feedback in b63da32:
@copilot please re-review. |
Re-reviewed and confirmed the requested updates are present in |
addressed in later iteration
When doing some issue / project migrations, there was a bunch of friction with the vanilla model knowledge that required a lot of churn on using the graph API / CLI especially, so wondering if it makes sense to front-load some of that context