Interactive wizard that walks service teams through creating a package-specific skill for their Azure SDK package. Scans the package, detects customization patterns, scaffolds a SKILL.md with references, and validates with vally lint. The skill is placed inside the package's .github/skills/ directory so find-package-skill discovers it automatically. WHEN: create package skill; add service skill; bootstrap skill for package; new package skill; skill for my SDK package; write skill for search; write skill for cosmos.
Interactive wizard that walks service teams through creating a package-specific skill for their Azure SDK package. Scans the package, detects customization patterns, scaffolds a SKILL.md with references, and validates with vally lint. The skill is placed inside the package's .github/skills/ directory so find-package-skill discovers it automatically. WHEN: create package skill; add service skill; bootstrap skill for package; new package skill; skill for my SDK package; write skill for search; write skill for cosmos.
Create Package Skill Wizard
Minimal beats comprehensive. Human-written beats auto-generated. Scaffold and iterate.
Skills encode tribal knowledge — the "I wish someone had told me" stuff that's hard to learn from just reading code. Focus on what's non-obvious and package-specific.
Every line must be non-obvious and package-specific. No generic TypeScript/SDK patterns.
SKILL.md should be under 500 tokens (soft limit). Move details to references/.
References under 1000 tokens each. Split if larger.
Never duplicate what's already in AGENTS.md or shared skills.
Relationship to existing SDK tools:
Package skills complement the Azure SDK MCP tools (azsdk_package_generate_code, azsdk_package_build_code, etc.) and the sdk-workflow shared skill — they do NOT replace them.
MCP tools handle deterministic operations (generate, build, test). Package skills provide the reasoning context an agent needs to use those tools correctly for a specific package.
Never redefine how generation, building, or testing works — reference the existing tools instead (e.g., "Run npm run generate:client", not custom generation steps).
If a workflow step is already handled by an MCP tool or shared skill, just reference it — don't re-document it.