| name | ticket-analysis |
| description | Use when doing comprehensive ticket analysis before implementation. Analyzes Jira ticket, Figma designs, Confluence/Notion docs, and codebase to produce a data map where every field is questioned and scope is explicitly defined. Use when user says "analiza ticket", "ticket analysis", "prepara ticket", "revisar ticket completo", or "qué falta en este ticket". |
| argument-hint | [TICKET-KEY or URL] |
| allowed-tools | Read, Grep, Glob, Bash, Agent, AskUserQuestion, ToolSearch, Edit, Write, mcp__claude_ai_Atlassian__getJiraIssue, mcp__claude_ai_Atlassian__editJiraIssue, mcp__claude_ai_Atlassian__addCommentToJiraIssue, mcp__claude_ai_Atlassian__searchConfluenceUsingCql, mcp__claude_ai_Atlassian__getConfluencePage, mcp__claude_ai_Notion__notion-search, mcp__claude_ai_Notion__notion-fetch, mcp__claude_ai_Figma__get_design_context, mcp__claude_ai_Figma__get_screenshot |
Ticket Analysis
Analyze a ticket across 4 sources (Jira, Figma, docs, code) and produce a structured report with fixed format.
Language
Instructions in this file are in English (for LLM processing). ALL user-facing output MUST be in Spanish, following the template in references/output-format.md.
Core Principles
- Zero assumptions — if there is the slightest doubt, ask. Never write "se asume que...". Write a question instead.
- Traceability — every finding must cite its source (page title + URL, or file path + line).
- Fixed structure — the output ALWAYS has the same 8 sections in the same order. See references/output-format.md.
Configuration
- Confluence Cloud ID:
afianza-ac.atlassian.net
Instructions
Phase 1: Fetch ticket
Parse $ARGUMENTS to extract ticket key. Can be:
- Key:
DEVPT-52 → use as-is
- URL: extract from
selectedIssue=DEVPT-52 or /browse/DEVPT-52
ToolSearch → "select:mcp__claude_ai_Atlassian__getJiraIssue"
mcp__claude_ai_Atlassian__getJiraIssue(cloudId: "afianza-ac.atlassian.net", issueIdOrKey: "<key>")
Extract from ticket content:
- Figma URLs (
figma.com/design/..., figma.com/file/...)
- Confluence URLs (
afianza-ac.atlassian.net/wiki/...)
- Notion URLs
- ALL data terms: every noun that could be a field, entity, concept, state, or action. Do not filter.
- Referenced tickets: scan description, ACs, comments, and linked issues for
DEVPT-XXX patterns
Resolve Jira dependencies: For each referenced ticket (pattern DEVPT-XXX):
- Fetch with
mcp__claude_ai_Atlassian__getJiraIssue(cloudId: "afianza-ac.atlassian.net", issueIdOrKey: "<key>")
- Classify status:
✅ Resuelto — Done, Closed, Released⚠️ En progreso — In Progress, In Review, In QA🚧 Bloqueante — To Do, Backlog, Open (not yet started)
- Extract: title, status, and what the current ticket needs from it
Phase 1b: Classify ticket
Based on the ticket content (description, ACs, type, linked issues), classify into one of 4 types:
| Type | Indicators | Agents to launch |
|---|
business-feature | UI mentions, Figma URLs, user flows, business rules, screens | Design + Docs + Data Model (all 3) |
technical-infra | cron, lock, cache, module, migration, config, scheduler, performance. No UI. | Data Model + Tech Feasibility |
bug-fix | Jira type = Bug, error, regression, stack trace, "no funciona" | Data Model |
data-integration | AMQP, consumer, sync, webhook, external system, queue, message | Docs + Data Model |
Classification rules:
- Check Jira issue type first (Bug →
bug-fix)
- Then scan description + ACs for indicator keywords
- If multiple types match, prefer the one with more indicators
- When in doubt, default to
business-feature (launches all agents — safest)
Store the classification as TICKET_TYPE for use in Phase 2 and output.
Phase 2: Parallel analysis
Launch agents in parallel using the Agent tool based on TICKET_TYPE from Phase 1b. Each agent must receive complete instructions — they cannot access skill definitions.
IMPORTANT: If any agent fails or returns incomplete data, do NOT retry. Report the failure in FUENTES as ⚠️ Error al analizar [source]: [reason] and continue with the sources that did succeed.
Agents skipped due to ticket classification are reported in FUENTES as ⏭️ Omitido por clasificación ([TICKET_TYPE]).
Agent 1 — Design (launch if: business-feature | skip if: no Figma URLs or ticket type is technical-infra, bug-fix, data-integration):
Prompt must include:
- The Figma URL(s) to analyze
- Instructions to first read the skill file:
Read ~/.claude/skills/analyze-design/SKILL.md then follow its instructions
- Use
ToolSearch to load mcp__claude_ai_Figma__get_design_context and mcp__claude_ai_Figma__get_screenshot
- For each field/input: extract label, type, format, required?, editable?
- For each button/action: what it does, confirmation step?, success/error states?
- Detect covered and missing UI states (empty, loading, error, success, pagination)
- If Figma MCP fails, report it — do NOT attempt Playwright
Agent 2 — Documentation (launch if: business-feature, data-integration | skip if: technical-infra, bug-fix):
Prompt must include:
- The key terms to search (extracted from ticket in Phase 1)
- Any Confluence/Notion URLs found in the ticket
- Instructions to first read the skill file:
Read ~/.claude/skills/analyze-docs/SKILL.md then follow its instructions
- Confluence Cloud ID:
afianza-ac.atlassian.net
- Use
ToolSearch to load Atlassian and Notion MCP tools
- Return direct quotes (never paraphrase), business rules, contradictions between sources
- If a platform is unreachable, report it and continue with the other
Agent 3 — Data model (launch if: ALL ticket types):
Prompt must include:
- The entity/concept names to analyze (extracted from ticket in Phase 1)
- Instructions to first read the skill file:
Read ~/.claude/skills/analyze-data-model/SKILL.md then follow its instructions
- For each field: trace origin (who creates it), mutations (who changes it), validations, possible values
- Map relationships between entities (direction, cardinality, cascade behavior)
- Check migrations for recent schema changes
Agent 4 — Technical feasibility (launch if: technical-infra, or ticket proposes a specific technical approach | skip if: business-feature, bug-fix, data-integration without technical proposal):
Prompt must include:
- The technical approach/solution described in the ticket
- Instructions to first read the skill file:
Read ~/.claude/skills/analyze-technical-feasibility/SKILL.md then follow its instructions
- Check if required packages are installed (
package.json)
- Analyze where the solution fits in the codebase architecture
- Search for existing patterns (scheduling, locks, raw SQL, etc.)
- Identify implementation gaps (new files, migrations, config)
- Evaluate risks (multi-replica scaling, testing strategy, rollback)
Inline — Ticket clarification (main thread, while agents run):
- Detect author's open questions
- Analyze ambiguities
- Structural validations (description, ACs, Figma link, SP, subtasks)
Phase 3: Cross-reference
Once all agents return, build a flat data table. For EACH data element from ANY source, assign status:
- ✅ Claro — fully understood: what it is, where it comes from, what values it has
- ❓ Dudoso — partially known, has open questions. MUST have at least one question.
- ❌ No existe — mentioned in ticket/design but not found in code/docs. MUST have at least one question.
For configuration parameters (detected by Agent 3's config interrogation), use an alternative template in the DATOS table:
📋 [parameter] (CONFIGURACIÓN)
¿Qué es? / Valor default? / Entornos? / Validación? / Rango?
Detect cross-reference problems:
- Ghost data (in ticket/design, not in code)
- Orphan data (in code, not in ticket/design)
- Contradictions between sources
- Data without known origin
- Data without documented rules
Phase 4: Build questions
Group ALL questions by who must answer:
PARA EL PO / NEGOCIO — non-technical language, with concrete example, stating what it blocks.
PARA EL TECH LEAD / EQUIPO DEV — technical questions the team resolves internally.
PARA DISEÑO — missing UI states, undefined flows, design gaps.
Each question gets a sequential number (#1, #2, ...) referenced in SCOPE and PRÓXIMOS PASOS.
Phase 5: Define scope
- SE ENTREGA — only items with ✅ data and no blocking questions
- NO SE ENTREGA — explicitly excluded items with reason
- BLOQUEADO — items waiting on specific question numbers or unresolved Jira dependencies (
🚧 Bloqueante)
There is NO "Asumido" section. If there's doubt, it's a question.
Phase 6: Build next steps
Ordered by priority (what unblocks the most first):
- Each step has a responsible role and references the question it unblocks
- Separate "SE PUEDE EMPEZAR YA" from "REQUIERE RESPUESTA PRIMERO"
For technical-infra tickets, add a SUGERENCIA DE ESTRUCTURA sub-section in PRÓXIMOS PASOS:
Phase 7: Output
Display the full analysis using the EXACT format in references/output-format.md.
ALL 8 sections ALWAYS appear. If a section has no content, show "Ninguno" or "No aplica".
Phase 8: Offer actions
Ask the user (multiselect):
- Comment on Jira — post technical analysis + questions as comment
- Update description — add PO questions + proposed scope to ticket description
- Update glossary — add/update entries in
docs/glossary.md
- None
If commenting: mcp__claude_ai_Atlassian__addCommentToJiraIssue (cloudId: afianza-ac.atlassian.net).
If updating description: mcp__claude_ai_Atlassian__editJiraIssue. Preserve existing content. Only add/replace "Preguntas bloqueantes" and "Scope propuesto" sections.
If updating glossary: Read docs/glossary.md, add/update entries using this template:
## [Nombre en español] ([Entity name in code])
- **Qué es**: [definición de negocio — NO técnica]
- **De dónde viene**: [quién lo crea y cuándo — evento, usuario, seed, cálculo]
- **Campos clave**:
- `fieldName`: [significado en lenguaje de negocio]
- `fieldName`: [significado en lenguaje de negocio]
- **Condiciones**: [cuándo cambia de estado, reglas de negocio conocidas]
- **Fuente de verdad**: [sistema o proceso que origina este dato]
- **Última revisión**: [YYYY-MM-DD — TICKET-KEY]
Rules: Only add data confirmed from code or docs. Mark unconfirmed with ❓. Update Última revisión. Keep definitions in business language.
Edge cases
- No Figma URLs → report in FUENTES as "No hay URL de Figma en el ticket". Still show DISEÑO section as "No aplica".
- Confluence/Notion empty → report in FUENTES. Continue with other sources.
- No matching entities in code → ticket describes new functionality. Note in FUENTES.
- No description → analyze summary, ACs, comments.
- Invalid ticket key → tell user and stop.
- Do NOT invent questions. If something is clear, say it's clear.
- Do NOT invent scope items. If there isn't enough info to define scope, say so in SCOPE.
