Orchestrates the full agent-pack pipeline for a task: git-engineer → [tech-lead] → engineer(s) → code-reviewer → [security-reviewer] → [performance-reviewer] → smell-reviewer → test-engineer → merge-reviewer → git-engineer (push/PR). Use when implementing a feature, fix, or change end-to-end. Trigger this when someone says: implement this, build this feature, make this change, add this functionality, code this up, I need this feature built, ship this. Do NOT use for targeted bug fixes with a known root cause — use /hotfix or /debug instead. Do NOT use for pure restructuring with no behavior change — use /refactor instead.
Review changed files or an open PR with code-reviewer, smell-reviewer, security-reviewer, and performance-reviewer. Use when the user wants a quality check on a diff, a PR number, or the current working-tree changes without running the full implement pipeline. Trigger this when someone says: review my PR, check my code, look at this diff, quality check, code review, does this look good, review PR #123, give me feedback on these changes, smell check, structural review. Do NOT use when the user wants to implement new changes — use /implement instead.
Decompose a complex task using tech-lead and optionally pressure-test the plan using devils-advocate before implementation begins. Use when the task is ambiguous, spans multiple concerns, or when the user wants to stress-test an existing proposal before committing. Trigger this when someone says: how should I approach this, plan this out, I am not sure how to do this, think through this with me, is this a good approach, pressure-test my plan, help me design this. Do NOT use when the task is already well-scoped — go straight to /implement instead.
Refactor existing code with impact analysis first. Routes to tech-lead for blast-radius assessment, then engineers, with heavy emphasis on test coverage. Use when restructuring code with no intended behavior change. Trigger this when someone says: refactor this, clean up this code, extract this pattern, restructure this, this code is messy, improve the code structure, rename this across the codebase, remove duplication. Do NOT use when the change modifies behavior — use /implement instead. Do NOT use for single-file cleanup — just edit the file directly.
Scaffold a new feature end-to-end: API contract → database schema → backend service/controller → frontend. Use when building something new from scratch across multiple layers. More opinionated than /implement — always runs the full vertical slice in the correct dependency order. Trigger this when someone says: build this feature from scratch, scaffold a new endpoint, I need a full-stack feature, new feature end-to-end, build the whole thing. Do NOT use when the task is already partially built or only one layer needs changes — use /implement instead.
Read and create Azure DevOps work items and PRs via the az CLI (devops extension) for the org/projects configured in AZURE_DEVOPS_ORG/AZURE_DEVOPS_PROJECTS. Use for one-off Azure Boards/Repos operations outside the code pipeline: viewing or creating work items, viewing PRs, commenting, updating state, linking work items to PRs/commits. Trigger this when someone says: check my work items, list open PRs in Azure DevOps, create a work item, comment on PR #N, close this work item, link this commit to a work item, connect to azure devops, smoke test the az cli. Do NOT use for GitHub PRs/issues -- that's skills/devops-github. Do NOT use for a full code review or implementation pipeline -- use /review-pr or /implement instead.
Read and create GitHub PRs and issues via the gh CLI for repos configured in GITHUB_ORG/GITHUB_REPOS. Use for one-off GitHub Boards/Repos operations outside the code pipeline: viewing PRs or issues, commenting, changing state, linking commits. Trigger this when someone says: check my PRs, list open issues, create a GitHub issue, comment on PR #N, close this issue, link this commit to an issue, connect to github, smoke test the gh cli. Do NOT use for Azure DevOps boards/work items -- that's skills/devops-azure. Do NOT use for a full code review or implementation pipeline -- use /review-pr or /implement instead.
Use when unsure whether a request is a GitHub or Azure DevOps operation, or when someone says "devops help", "connect to devops", "check my work items or PRs", "devops?". Routes to devops-github or devops-azure based on intent. Also use as a fallback when a request doesn't clearly map to either one.