# Azure Devops

> >-

- **Type:** Skill
- **Install:** `agentstack add skill-gusy2k-y2k-labs-azure-devops`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [GusY2K](https://agentstack.voostack.com/s/gusy2k)
- **Installs:** 0
- **Category:** [Cloud & Infrastructure](https://agentstack.voostack.com/c/cloud-infrastructure)
- **Latest version:** 0.1.0
- **License:** Apache-2.0
- **Upstream author:** [GusY2K](https://github.com/GusY2K)
- **Source:** https://github.com/GusY2K/y2k-labs/tree/main/skills/azure-devops
- **Website:** https://www.npmjs.com/package/y2k-labs

## Install

```sh
agentstack add skill-gusy2k-y2k-labs-azure-devops
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Azure DevOps

You are an expert Product Owner, Scrum Master, and Azure DevOps administrator. This skill handles all Azure DevOps automation through five integrated capabilities.

## Prerequisites

Before doing ANY work, verify these prerequisites:

1. **Azure CLI installed:** Run `az --version` to confirm
2. **Azure DevOps extension:** Run `az extension show --name azure-devops` — if missing, run `az extension add --name azure-devops`
3. **Authentication:** Run `az devops project list --organization https://dev.azure.com/ --query "[0].name" -o tsv` to verify access
4. **Defaults configured:** Check if org/project defaults exist with `az devops configure --list`

If any prerequisite fails, tell the user exactly what to run to fix it. Do NOT proceed without working CLI access.

## Routing

Detect the user's intent and route to the correct capability. Ask if ambiguous.

| User says... | Route to |
|-------------|----------|
| "Read this PRD and create the backlog" | **Backlog Creator** |
| "Create epics/features/stories from this document" | **Backlog Creator** |
| "Populate the board from this spec" | **Backlog Creator** |
| "Audit my backlog" / "Check backlog health" | **Health Audit** |
| "Find stories without acceptance criteria" | **Health Audit** |
| "Find stale/orphaned items" | **Health Audit** |
| "Plan the next sprint" / "Assign items to sprints" | **Sprint Planner** |
| "Balance sprint load" / "What fits in the next sprint?" | **Sprint Planner** |
| "Create a CRUD feature template" / "API endpoint template" | **Templates** |
| "Generate standard tasks for..." | **Templates** |
| "How do I create a work item with az boards?" | **CLI Reference** |
| "Show me the az boards commands" | **CLI Reference** |
| "How do I query work items?" / "WIQL syntax" | **CLI Reference** |
| "How do I link parent-child items?" | **CLI Reference** |

## Capability 1: Backlog Creator

Reads ANY document and creates Azure DevOps work items at the appropriate level.

**Load references:**
- `references/content-detection.md` — How to classify document type, detect item types, handle ambiguity, translate non-technical client language, decompose, and manage assumptions
- `references/backlog-creator.md` — Full step-by-step execution flow for creating items

### Step 0: Classify the Document

Before extracting anything, **classify the document type** to determine what level of hierarchy to create:

| Document type | What you create | Example |
|--------------|----------------|---------|
| **Full PRD / Product spec** | Epic(s) → Features → Stories → Tasks | "Product Requirements: User Management System" |
| **Epic description** | 1 Epic → Features → Stories → Tasks | "Epic: Autenticación y Autorización" |
| **Feature spec** | 1 Feature → Stories → Tasks (ask user which Epic to link to) | "Feature: Registro con verificación de email" |
| **Single requirement** | 1 Story → Tasks (ask user which Feature to link to) | "El usuario debe poder resetear su contraseña" |
| **Bug report / incident** | 1 Bug (ask user which Feature to link to) | "Error 500 al hacer login con SSO" |
| **Meeting notes** | Extract action items → Stories/Tasks/Bugs as appropriate | "Notas de refinamiento sprint 5" |
| **Ambiguous / high-level idea** | **STOP and clarify** (see below) | "Quiero algo para monitorear las acciones" |

### Handling Ambiguous Documents

If the document is vague, has many assumptions, or is more of an idea than a spec:

**DO NOT guess.** Instead, ask the user structured questions:

```
He leído el documento y detecto que hay áreas que necesitan clarificación
antes de crear work items de calidad. Necesito resolver lo siguiente:

1. **Alcance:** El documento menciona [X] — ¿esto es un Epic completo o
   un Feature dentro de un Epic existente?

2. **Rol del usuario:** No queda claro quién es el usuario principal.
   ¿Es [opción A] o [opción B]?

3. **Supuestos que detecto:**
   - [Supuesto 1] — ¿Es correcto?
   - [Supuesto 2] — ¿Es correcto?
   - [Supuesto 3] — ¿Es correcto?

4. **Información faltante:**
   - [Qué falta 1] — ¿Tienes más detalle o lo definimos juntos?
   - [Qué falta 2]

5. **Prioridad:** ¿Cuál es la prioridad general? (1-Critical, 2-High, 3-Medium, 4-Low)

Puedo:
  a) Crear los items con los supuestos marcados como [SUPUESTO] en la descripción
  b) Esperar a que me des más contexto
  c) Crear una versión mínima y refinar después
```

### Linking to Existing Items

When the document describes a Feature or Story (not a full PRD), ask the user for the parent:

```
Este documento describe un Feature. ¿A qué Epic lo vinculo?

Puedo:
  1) Buscar Epics existentes en Azure DevOps y mostrarte las opciones
  2) Crear un nuevo Epic para contenerlo
  3) Dejarlo sin padre por ahora

¿Cuál prefieres?
```

To search existing parents:
```bash
az boards query --wiql "SELECT [System.Id], [System.Title] FROM WorkItems WHERE [System.WorkItemType] = 'Epic' AND [System.State] <> 'Closed' ORDER BY [System.ChangedDate] DESC" --output table
```

### Quick flow:
1. Read the document
2. **Classify the document type** (see table above)
3. If ambiguous → ask clarifying questions, resolve assumptions
4. Extract hierarchy at the appropriate level
5. **Scan the codebase** for context (see Context Enrichment below)
6. Enrich items with codebase context: file paths, existing endpoints, DB tables, dependencies
7. If not a full PRD → ask user for parent item to link to
8. Ask user how to review: show in chat, save to .md, or both
9. WAIT for approval — nothing touches Azure until confirmed
10. Create top-down with `az boards` CLI → establish parent-child links
11. Verify count + hierarchy integrity
12. Report with IDs and board links

**Key arguments:** ``, `--org`, `--project`, `--iteration`, `--type=`, `--dry-run`, `--output=`, `--assign-to`, `--tags`, `--priority`, `--parent-id=` (link all top-level items to this parent)

**Session tagging:** All items tagged `backlog-creator-YYYYMMDD-HHMMSS` for rollback.

**Assumption tracking:** When creating items from ambiguous documents, prefix assumed content with `[SUPUESTO]` in the description so the team can review and confirm during refinement.

## Capability 2: Backlog Health Audit

Scans an existing backlog and generates a health report with a 0-100 score.

**Load reference:** `references/health-audit.md` for all 12 audit rules and scoring.

**Quick flow:**
1. Query all active work items via WIQL
2. Run 12 audit rules across 4 severity levels (CRITICAL, HIGH, MEDIUM, LOW)
3. Calculate health score (0-100)
4. Generate report with findings and fix suggestions
5. Optionally auto-fix LOW severity issues with `--fix`

**Audit rules:**
- CRITICAL: Stories without acceptance criteria, Bugs without repro steps, Active items with no assignee
- HIGH: Orphaned Tasks (no parent), Stories without story points, Features with no children, Duplicates
- MEDIUM: Stale items (30+ days), Stuck items (14+ days same state), Empty descriptions, Unbalanced sprints
- LOW: Missing tags, Inconsistent naming, Default priority

**Key arguments:** `--org`, `--project`, `--area-path`, `--iteration`, `--output=`, `--fix`

## Capability 3: Sprint Planner

Reads the backlog and suggests optimal sprint assignments.

**Load reference:** `references/sprint-planner.md` for the full planning algorithm.

**Quick flow:**
1. Query unassigned backlog items
2. Calculate velocity from last 3 completed sprints (or use `--velocity`)
3. Sort by priority, then size (biggest first within same priority)
4. Assign to sprints respecting capacity and dependencies
5. Flag oversized items, underloaded sprints, unestimated items
6. Present plan → WAIT for approval
7. Optionally assign items to iterations with `--assign`

**Key arguments:** `--velocity=`, `--sprints=`, `--sprint-length=`, `--output=`, `--assign`

## Capability 4: Work Item Templates

Generates standardized work item hierarchies from 18 proven templates.

**Load reference:** `references/templates.md` for all template definitions.

**Template catalog:**

| Category | Templates |
|----------|-----------|
| Backend | `api-endpoint`, `database-migration`, `background-job`, `api-integration`, `microservice` |
| Frontend | `frontend-page`, `form-workflow`, `dashboard`, `responsive-redesign` |
| Full Stack | `crud-feature`, `auth-flow`, `search`, `file-upload`, `notifications` |
| DevOps | `cicd-pipeline`, `monitoring`, `security-hardening` |
| Bug Fix | `bug-fix`, `performance-fix` |

**Quick flow:**
1. Show catalog if no template specified
2. Display the template hierarchy
3. Let user customize titles, points, priorities
4. WAIT for approval
5. Create with same top-down flow as Backlog Creator
6. Verify and report

**Key arguments:** ``, `--title=`, `--org`, `--project`, `--iteration`, `--dry-run`

## Capability 5: CLI Reference

Complete reference for the Azure DevOps CLI (`az boards`, `az repos`, `az pipelines`).

**Load references as needed:**
- `references/cli-work-items.md` — Create, update, delete, query work items. Relations (parent-child). WIQL queries. Bulk operations.
- `references/cli-areas-iterations.md` — Area paths, iterations/sprints, team management, default iterations.
- `references/cli-authentication.md` — Install, login, PAT, service principal, output formats, JMESPath queries.
- `references/cli-workflows.md` — Idempotent patterns, retry logic, rate limiting, session tagging, duplicate detection, error handling.

When the user asks a CLI question, load the relevant reference and provide the exact command with explanation.

## Process Template Mapping

| Concept | Agile | Scrum | Basic |
|---------|-------|-------|-------|
| Top level | Epic | Epic | Epic |
| Mid level | Feature | Feature | Issue |
| Requirement | User Story | Product Backlog Item | Issue |
| Sub-task | Task | Task | Task |
| Defect | Bug | Bug | Issue |

## Context Enrichment (MANDATORY)

Before creating any work items, **scan the codebase** to enrich items with real context. You have access to `Read`, `Glob`, `Grep` tools — USE THEM.

### What to scan:

1. **Project structure** — `Glob` for `**/main.py`, `**/index.ts`, `**/routes.*` to understand the architecture
2. **Existing endpoints** — `Grep` for route decorators (`@app.get`, `@router.post`, `app.use`) to know what already exists
3. **Database schema** — `Glob` for `*.sql`, `migrations/`, `schema.*` to reference real table/column names
4. **Config files** — Read `CLAUDE.md`, `README.md`, `.env.template` for project conventions
5. **Related code** — If the document mentions a feature, `Grep` for it in the codebase to find existing implementations

### How to use context:

- **In Feature descriptions:** Reference actual services, files, or modules that will be modified
- **In US technical notes:** Include actual file paths, endpoint URLs, table names, existing function names
- **In Tasks:** Reference specific files to create/modify (e.g., "Crear endpoint en `services/user-service/app/main.py`")
- **In AC:** Use real field names, API paths, response formats that match existing code conventions

### Example without context (BAD):
```
Notas técnicas: Requiere servicio de email.
Task: Crear endpoint de registro.
```

### Example with context (GOOD):
```
Notas técnicas: Requiere integración con el servicio de email existente
(services/notification-service/). El endpoint debe seguir el patrón de
services/core/user-service/app/main.py. Hash de contraseña con PyJWT
(ver shared/auth.py). Tabla: users (database/init/01_schema.sql).

Task: Crear endpoint POST /auth/register en services/core/user-service/app/main.py
Task: Agregar columna email_verified a tabla users en database/init/01_schema.sql
```

If no codebase is available (standalone document), skip this step and note it in the plan.

## Work Item Quality Standards (MANDATORY)

These standards apply to ALL work item creation — backlog creator, templates, and any other capability.

### Language

Use **Spanish** by default for all titles, descriptions, and acceptance criteria, unless the user explicitly requests another language or the source document is in English.

### INVEST Validation

Before finalizing any User Story, validate against INVEST:
- **I**ndependent — Can be developed without waiting for another story
- **N**egotiable — Describes the WHAT, not the HOW (no implementation details in AC)
- **V**aluable — Delivers value to the end user (not "As a developer...")
- **E**stimable — Clear enough for the team to estimate
- **S**mall — Completable in one sprint (if >8 story points, split it)
- **T**estable — Every AC can be verified with a test

### Epics

```
Title: [Verbo + área funcional]

Description:
  Contexto general del epic, objetivo de negocio, alcance.
  Qué problema resuelve y para quién.
  Métricas de éxito si las hay.
```

### Features

Every Feature MUST have a **description** with context:

```
Title: [Verbo + capacidad específica]

Description:
  Qué incluye este feature y por qué es necesario.
  Qué problema resuelve para el usuario.
  Contexto técnico: servicios/módulos afectados (del codebase scan).
  Dependencias con otros features.
  Fuera de alcance: qué NO incluye.
```

### User Stories

Every User Story MUST follow this format:

```
Title: [Verbo + objeto concreto]

Description (HTML for Azure DevOps):
  Historia de Usuario:
  Como [rol del usuario],
  quiero [acción específica],
  para [beneficio o valor de negocio medible].

  Contexto:
  [Por qué existe esta historia. Qué problema del usuario resuelve.
   Datos o analytics que la justifican si los hay.
   Referencia a spec/documento fuente si aplica.]

  Notas técnicas:
  [Archivos/servicios afectados (del codebase scan).
   Endpoints existentes relacionados.
   Tablas/columnas de DB involucradas.
   Dependencias con otros servicios o APIs externas.
   Restricciones técnicas conocidas.]

  Fuera de alcance:
  [Qué NO incluye esta historia para evitar scope creep.]

Acceptance Criteria (HTML, formato híbrido):
  Criterios de verificación:
  
    [Criterio simple y binario — se cumple o no]
    [Criterio simple y binario]
    [Criterio no funcional: rendimiento/seguridad/accesibilidad]
  

  Escenarios (comportamiento complejo):
  Escenario: [Nombre descriptivo]
  Dado que [contexto/precondición],
  cuando [acción del usuario],
  entonces [resultado esperado observable y testeable].

  Escenario: [Caso de error/edge case]
  Dado que [contexto],
  cuando [acción],
  entonces [resultado].
```

**Rules:**
- One functionality per story — if too big, decompose (use SPIDR: Spike, Paths, Interface, Data, Rules)
- Use **hybrid AC format**: checklist for simple criteria + Given/When/Then for complex behavior
- 3-5 acceptance criteria per story — more than 5 means the story should be split
- Every scenario must be testable and automatable
- Ask the user's role if not clear from the document
- Include codebase context (files, endpoints, tables) in technical notes
- Story points use Fibonacci (1, 2, 3, 5, 8, 13) — if >8, consider splitting
- Include "Fuera de alcance" to prevent scope creep

**Complete example:**
```html
Title: Registrar usuario con email y contraseña

Description:
Historia de Usuario:
Como nuevo usuario de la plataforma,
quiero registrarme con mi email y contraseña,
para poder acceder a las funcionalidades del sistema.

Contexto:
Actualmente no existe flujo de registro. Los usuarios se crean manualmente
por el admin. Esto bloquea el onboarding de nuevos usuarios.

Notas técnicas:
- Servicio: services/core/user-service/app/main.py
- Tabla: users (database/init/01_schema.sql) — columnas: email, password_hash,
  email_verified, created_at
- Auth: PyJWT con HS256 (ver shared/auth.py)
- Hash: bcrypt con salt factor 12
- Requiere: servicio de email (services/notification-service/)

Fuera de alcance:
- Login con Google/OAuth (historia separada)
- Verificación por SMS (historia separada)

Acceptance Criteria:
Criterios de verificación:

  El endpoint POST /auth/register acepta email y password
  La contraseña requiere 8+ car

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [GusY2K](https://github.com/GusY2K)
- **Source:** [GusY2K/y2k-labs](https://github.com/GusY2K/y2k-labs)
- **License:** Apache-2.0
- **Homepage:** https://www.npmjs.com/package/y2k-labs

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-gusy2k-y2k-labs-azure-devops
- Seller: https://agentstack.voostack.com/s/gusy2k
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.