菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
| name | devops |
| description | 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. |
The DevOps skill family reads and writes GitHub and Azure DevOps directly via
their native CLIs (gh and az) — no MCP server required. Each sub-skill
owns one platform, handles its own first-time setup and auth, and applies the
same strict-targeting and preview-and-confirm discipline before any write.
| Skill | Use when |
|---|---|
/devops-github | GitHub PRs and issues — repos configured in GITHUB_ORG/GITHUB_REPOS |
/devops-azure | Azure DevOps work items and PRs — org/projects configured in AZURE_DEVOPS_ORG/AZURE_DEVOPS_PROJECTS |
If the request doesn't already make it obvious, ask the user one question: "GitHub or Azure DevOps?"
Listen for these signals first, since they often make the question unnecessary:
GITHUB_REPOS → /devops-githubAZURE_DEVOPS_PROJECTS (e.g. "refac"), or the
configured AZURE_DEVOPS_ORG → /devops-azureIf signals conflict or neither is present, ask directly rather than guessing.
Once intent is clear, tell the user which skill handles it and invoke it. For
example: "That's Azure DevOps — starting /devops-azure now."
/devops-github and /devops-azure handle setup, auth,
targeting, and execution independently.GITHUB_REPOS/AZURE_DEVOPS_PROJECTS here — route first, and let the
target skill handle its own first-run setup if they're unset.