jira-analyst-skill

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Jira Solution Designer

Skill autocontenida para analizar tickets de Jira. Produce análisis funcionales (reglas de negocio, flujos, dependencias) o técnicos (archivos, código, implementación) según el contexto. Todo el conocimiento necesario está en este archivo.

用于分析Jira工单的独立Skill，可根据上下文生成功能分析（业务规则、流程、依赖）或技术分析（文件、代码、实现方案），所有必要知识均包含在本文件中。

Disparadores

触发词

"Analiza el ticket MDCS-456"
"Dame posibles soluciones para JIRA-123"
"¿Qué está pasando con MDCS-789?"
"Análisis funcional de JIRA-456"
"Analiza MDCS-123 con contexto de HU anteriores"
"Analiza el ticket con dependencias CMM"
(usuario pega XML/SOAP/JSON/logs junto con un ticket key)

"分析MDCS-456工单"
"给我JIRA-123的可行解决方案"
"MDCS-789现在是什么情况？"
"JIRA-456的功能分析"
"结合之前的用户故事上下文分析MDCS-123"
"分析包含CMM依赖的工单"
(用户粘贴XML/SOAP/JSON/日志，同时提供工单号)

Detección de modo de análisis

分析模式检测

Determinar el modo antes de comenzar:

开始分析前先确定分析模式：

Modo FUNCIONAL (default)

功能模式（默认）

Usar cuando:

El ticket trata sobre reglas de negocio, flujos, requisitos, comportamiento CMM
El usuario no pide explícitamente cambios de código
El ticket involucra servicios backend/CMM sin código frontend asociado
El usuario pide "entender qué pasa" o "analizar el problema"

Salida: análisis de negocio, reglas, flujos, dependencias. NO incluye archivos candidatos ni plan de implementación.

适用场景：

工单涉及业务规则、流程、需求、CMM行为
用户未明确要求代码修改
工单涉及后端/CMM服务，无关联前端代码
用户要求"了解现状"或"分析问题"

输出：业务分析、规则、流程、依赖，不包含候选文件或实现计划。

Modo TECNICO

技术模式

Usar cuando:

El usuario pide explícitamente cambios de código, implementación, o solución técnica
El ticket es claramente de implementación frontend (UI, componentes, Redux)
El usuario dice "qué archivos hay que tocar", "cómo lo implemento", "dame la solución técnica"

Salida: análisis funcional + archivos candidatos, enfoques, plan de implementación.

适用场景：

用户明确要求代码修改、实现或技术解决方案
工单明确是前端实现需求（UI、组件、Redux）
用户询问"需要修改哪些文件"、"怎么实现"、"给我技术方案"

输出：功能分析 + 候选文件、实现思路、落地方案。

Detección de entorno

环境检测

Detectar qué herramientas están disponibles:

Código local: Verificar si existe
```
src/
```
en el directorio de trabajo (usar Glob)
- Si existe → usar filesystem local (Glob/Grep/Read). NO usar Bitbucket MCP.
- Si NO existe → usar Bitbucket MCP si está disponible (
```
bitbucket_browse
```
  ,
```
bitbucket_read
```
  )
Trace viewer: URL interna
```
http://172.12.24.172:8888/app/pages/index.html
```
— accesible si el usuario tiene VPN activa. Permite buscar traces CMM por número.

检测可用的工具资源：

本地代码：检查工作目录是否存在
```
src/
```
（使用Glob）
- 存在 → 使用本地文件系统（Glob/Grep/Read），不使用Bitbucket MCP
- 不存在 → 如Bitbucket MCP可用则使用（
```
bitbucket_browse
```
  、
```
bitbucket_read
```
  ）
Trace查看器：内部URL
```
http://172.12.24.172:8888/app/pages/index.html
```
— 用户开启VPN即可访问，支持按编号查询CMM trace。

Detección de artefactos proporcionados

用户提交材料检测

Antes de iniciar el flujo, revisar si el usuario incluyó artefactos en su mensaje:

启动流程前，先检查用户消息中是否包含附属材料：

Artefactos inline (pegados en el chat)

聊天内联材料（用户粘贴在对话中）

Detectar si el mensaje del usuario contiene:

XML/SOAP: tags
```
<soapenv:
```
,
```
<cmm:
```
,
```
<ns2:
```
,
```
<request>
```
,
```
<response>
```
, o cualquier XML estructurado
JSON: objetos
```
{...}
```
o arrays
```
[...]
```
con estructura de payload
Logs: líneas con timestamps, stack traces, mensajes de error, HTTP status codes
Interfaces CMM: definiciones de operaciones, campos, tipos de datos

Si se detectan artefactos:

Parsear e identificar qué tipo de artefacto es (request, response, error, interfaz)
Extraer información clave: operación invocada, campos enviados/recibidos, códigos de error, mensajes CMM
Incorporar al análisis como evidencia concreta (no hace falta buscarla en otra fuente)
Si es un request+response, analizar: ¿el request está bien formado? ¿La response indica error? ¿Qué campos faltan o son inesperados?

检测用户消息是否包含：

XML/SOAP：
```
<soapenv:
```
、
```
<cmm:
```
、
```
<ns2:
```
、
```
<request>
```
、
```
<response>
```
等标签，或任何结构化XML
JSON：结构化
```
{...}
```
对象或
```
[...]
```
数组payload
日志：带时间戳的行、栈追踪、错误信息、HTTP状态码
CMM接口：操作定义、字段、数据类型

如检测到相关材料：

解析并识别材料类型（请求、响应、错误、接口）
提取关键信息：调用的操作、发送/接收的字段、错误码、CMM消息
作为具体证据纳入分析（无需从其他渠道再查找）
如果同时包含请求+响应，分析：请求格式是否正确？响应是否提示错误？缺少哪些字段或存在哪些意外字段？

Número de trace

Trace编号

Si el usuario menciona un número de trace (ej. "trace 123456", "trace number: ABC-789"):

Intentar acceder al trace viewer vía WebFetch:
```
http://172.12.24.172:8888/app/pages/index.html
```
Si el trace viewer requiere interacción (formulario de búsqueda), indicar al usuario:
- "Necesito que busques el trace [NUMERO] en el trace viewer y pegues los request/response CMM aquí"
- Explicar qué buscar: los bloques de CMM request y CMM response relevantes al problema
Si se puede leer directamente vía WebFetch, parsear los resultados SOAP/XML

如果用户提到trace编号（例如"trace 123456"、"trace号：ABC-789"）：

尝试通过WebFetch访问trace查看器：

http://172.12.24.172:8888/app/pages/index.html

如果trace查看器需要交互（搜索表单），告知用户：
- "请你在trace查看器中搜索trace [编号]，并将CMM请求/响应粘贴到这里"
- 说明需要查找的内容：和问题相关的CMM请求、CMM响应块
如果可通过WebFetch直接读取，解析SOAP/XML结果

Flujo de trabajo (orden estricto)

工作流（严格按顺序执行）

Paso 1: Obtener ticket de Jira

步骤1：获取Jira工单

Llamar

jira_get_issue

con el key del issue. Campos:

summary,description,status,priority,assignee,labels,issuetype,created,updated,parent

. Usar

expand: "renderedFields"

si la descripción es HTML. Opcionalmente

comment_limit: 5

para comentarios recientes.

调用

jira_get_issue

接口传入工单号，获取字段：

summary,description,status,priority,assignee,labels,issuetype,created,updated,parent

。如果描述是HTML格式，使用

expand: "renderedFields"

参数。可可选添加

comment_limit: 5

获取最近评论。

Paso 2: Evaluar completitud del contexto

步骤2：评估上下文完整性

Clasificar el ticket como:

Claro — tiene feature/flujo objetivo, comportamiento actual/esperado, y al menos un criterio de aceptación
Parcial — tiene algunos elementos pero no todos
Insuficiente — una línea o vago (ej. "Corregir simulador de préstamos")

Umbral mínimo (todos deben estar presentes para avanzar directo al Paso 4):

Feature, flujo o servicio objetivo
Comportamiento actual o problema
Comportamiento deseado o resultado de negocio
Al menos un criterio de aceptación o señal de éxito

Nota: Los artefactos proporcionados por el usuario (logs, payloads, interfaces) cuentan como evidencia para evaluar el umbral. Un ticket vago + logs detallados puede ser suficiente.

Si el ticket es claro → saltar al Paso 4. Si es parcial o insuficiente → continuar al Paso 3.

将工单分为三类：

清晰：包含目标功能/流程、当前/预期行为、至少一个验收标准
部分完整：包含部分要素但不全
不足：只有一句话或描述模糊（例如"修复贷款模拟器"）

最低阈值（全部满足可直接进入步骤4）：

目标功能、流程或服务
当前行为或问题
期望行为或业务结果
至少一个验收标准或成功标识

注意：用户提供的材料（日志、payload、接口）可作为评估阈值的证据，模糊工单+详细日志也可满足阈值要求。

如果工单清晰 → 跳转至步骤4 如果是部分完整或不足 → 继续执行步骤3

Paso 3: Escalamiento progresivo de contexto

步骤3：上下文渐进式补充

Ejecutar los niveles en orden. Después de cada nivel, reevaluar el umbral mínimo. Si se alcanza → saltar al Paso 4. Si no → continuar al siguiente nivel.

按顺序执行以下层级，每完成一个层级重新评估最低阈值，满足则跳转至步骤4，不满足则继续下一层级。

Nivel 1: Tickets relacionados en Jira

层级1：Jira关联工单

Buscar contexto funcional en tickets previos del mismo flujo.

Búsquedas JQL (en orden de prioridad):

Mismo Epic/parent:

parent = <PARENT_KEY>

"Epic Link" = <EPIC_KEY>

Campos:

summary,description,status,issuetype,resolution,updated,labels

Límite: 20 resultados

Mismos labels:

labels IN (<LABELS>) AND project = <PROJECT> AND key != <KEY> ORDER BY updated DESC

Límite: 15 resultados

Mismo feature/servicio por texto:

project = <PROJECT> AND summary ~ "<TERMINO>" AND key != <KEY> AND status in (Done, Closed, Resolved) ORDER BY updated DESC

Límite: 10 resultados

Para cada ticket relevante, extraer:

Campo	Qué buscar
Regla de negocio	Requisito funcional que se desprende del ticket
Cambio realizado	Resolución o implementación documentada
Riesgo/restricción	Edge cases, limitaciones, "no hacer X"

→ Reevaluar umbral. Si alcanza → Paso 4.

从同流程的历史工单中查找功能上下文。

JQL查询（按优先级排序）：

相同史诗/父工单：

parent = <父工单KEY>

或

"Epic Link" = <史诗KEY>

字段：

summary,description,status,issuetype,resolution,updated,labels

上限：20条结果

相同标签：

labels IN (<标签列表>) AND project = <项目KEY> AND key != <当前工单KEY> ORDER BY updated DESC

上限：15条结果

相同功能/服务关键词：

project = <项目KEY> AND summary ~ "<关键词>" AND key != <当前工单KEY> AND status in (Done, Closed, Resolved) ORDER BY updated DESC

上限：10条结果

从每个相关工单中提取：

字段	提取内容
业务规则	工单中体现的功能需求
已完成变更	文档化的解决方案或实现
风险/限制	边界场景、限制、"禁止做X"类说明

→ 重新评估阈值，满足则进入步骤4

Nivel 2: Confluence

层级2：Confluence

Buscar documentación funcional del feature, servicio o Epic.

```
confluence_search
```
con términos: nombre del feature/servicio, nombre del Epic, términos clave del ticket
```
confluence_get_page
```
para las páginas más relevantes (máximo 3)
Extraer: reglas de negocio, flujos documentados, especificaciones funcionales, interfaces CMM, diagramas

→ Reevaluar umbral. Si alcanza → Paso 4.

查找功能、服务或史诗的功能文档。

使用功能/服务名、史诗名、工单关键词调用
```
confluence_search
```
调用
```
confluence_get_page
```
获取最相关的页面（最多3个）
提取：业务规则、文档化流程、功能规范、CMM接口、流程图

→ 重新评估阈值，满足则进入步骤4

Nivel 3: Inspección de código (solo si modo TECNICO o si aporta contexto funcional)

层级3：代码检查（仅技术模式或代码可提供功能上下文时执行）

Solo ejecutar si:

El modo es TECNICO, O
El código puede aportar contexto funcional (ej. entender validaciones, flujos, mapeo de campos)

Si hay código local:

```
Glob
```
para localizar archivos del feature:
```
src/features/<nombre-feature>/**/*
```
```
Grep
```
para buscar términos clave del ticket en el código
```
Read
```
para inspeccionar archivos relevantes

Si hay Bitbucket disponible:

```
bitbucket_browse
```
para navegar la estructura
```
bitbucket_read
```
para leer archivos relevantes

Extraer: flujo actual, servicios API invocados, payloads, validaciones, mapeo de campos.

→ Reevaluar umbral. Si alcanza → Paso 4.

仅满足以下条件时执行：

分析模式为技术模式，或
代码可提供功能上下文（例如理解校验规则、流程、字段映射）

如有本地代码：

使用
```
Glob
```
定位功能相关文件：
```
src/features/<功能名>/**/*
```
使用
```
Grep
```
在代码中搜索工单关键词
使用
```
Read
```
查看相关文件内容

如有可用Bitbucket：

使用
```
bitbucket_browse
```
浏览目录结构
使用
```
bitbucket_read
```
读取相关文件内容

提取：当前流程、调用的API服务、payload、校验规则、字段映射

→ 重新评估阈值，满足则进入步骤4

Nivel 4: Preguntas al usuario

层级4：向用户提问

Si tras los niveles anteriores el umbral no se alcanza, formular 3-5 preguntas de alto valor.

Categorías priorizadas:

Objetivo de negocio — ¿Qué resultado se espera? ¿Quién se beneficia?
Comportamiento actual vs esperado — ¿Qué pasa hoy? ¿Qué debería pasar?
Flujo afectado — ¿Qué pantalla, servicio o proceso? ¿Qué ruta?
Criterios de aceptación — ¿Cómo sabemos que el cambio es correcto?
Dependencias — ¿Backend, API, servicio CMM, configuración?

Ramas por tipo de ticket:

Tipo	Preguntas prioritarias
Bug	Pasos de reproducción, frecuencia, mensajes de error, entorno, comportamiento correcto esperado
UI	Pantalla/componente exacto, mockup/referencia visual, cambios de copy, antes/después
Servicio/API	Fuente de verdad, payload request/response, manejo de errores, endpoint nuevo o existente
CMM/Backend	Operación CMM, interfaz esperada, códigos de error, ¿tiene el trace number?
Ticket vago	Intención de negocio, área funcional, definición de "terminado", quién tiene más detalles

Si el problema involucra CMM y no hay artefactos, preguntar específicamente:

"¿Tenés el número de trace de la transacción que falla?"
"¿Podés pegar el request y response CMM (SOAP/XML) directamente acá?"
"¿Podés buscar el trace en el trace viewer y pegar los resultados?"

Esperar respuestas del usuario. Tras recibirlas, reevaluar.

→ Si alcanza → Paso 4. → Si no alcanza → Nivel 5.

如果完成以上层级后仍不满足最低阈值，提出3-5个高价值问题。

优先级分类：

业务目标 — 期望达成什么结果？受益方是谁？
当前 vs 预期行为 — 现在的表现是什么？应该是什么样？
受影响流程 — 涉及哪个页面、服务或进程？访问路径是什么？
验收标准 — 如何确认变更符合要求？
依赖 — 是否涉及后端、API、CMM服务、配置？

按工单类型区分提问重点：

工单类型	优先级提问
Bug	复现步骤、出现频率、错误信息、环境、预期正确行为
UI	具体页面/组件、设计稿/视觉参考、文案变更、前后对比
服务/API	数据源、请求/响应payload、错误处理、新增还是现有端点
CMM/后端	CMM操作、预期接口、错误码、是否有trace号？
模糊工单	业务意图、功能领域、"完成"的定义、谁掌握更多细节

如果问题涉及CMM且无相关材料，专门询问：

"你有失败交易的trace编号吗？"
"可以把CMM的请求和响应（SOAP/XML）直接粘贴在这里吗？"
"可以在trace查看器中搜索trace并粘贴结果吗？"

等待用户回复，收到后重新评估阈值。

→ 满足则进入步骤4 → 不满足则进入层级5

Nivel 5: Declarar bloqueo (Modo C)

层级5：声明阻塞（C模式）

Si tras todos los niveles no se alcanza el umbral mínimo → producir salida en Modo C y generar archivo markdown.

如果完成所有层级后仍不满足最低阈值 → 按C模式输出并生成Markdown文件。

Paso 4: Enriquecimiento complementario

步骤4：补充信息丰富分析

Una vez que el umbral mínimo se cumple, enriquecer con información adicional:

```
jira_get_issue_development_info
```
— PRs, branches, commits asociados
```
jira_get_issue_images
```
— mockups o capturas adjuntas
```
jira_get_issue_dates
```
— historial de estados y transiciones

Si el usuario pidió análisis extendido ("con contexto de HU anteriores", "análisis funcional", "dependencias CMM"):

Ejecutar búsquedas del Nivel 1 si no se hicieron
Sintetizar antecedentes funcionales en tabla
Identificar dependencias externas (CMM, backend, contratos)

Si modo TECNICO y no se inspeccionó código en Nivel 3:

Localizar y leer archivos del feature afectado
Identificar: componentes, reducers, sagas, servicios API, validaciones
Buscar patrones similares en features existentes

满足最低阈值后，补充额外信息：

```
jira_get_issue_development_info
```
— 关联的PR、分支、提交
```
jira_get_issue_images
```
— 附件中的设计稿或截图
```
jira_get_issue_dates
```
— 状态流转历史

如果用户要求扩展分析（"结合之前的用户故事上下文"、"功能分析"、"CMM依赖"）：

如未执行层级1的搜索则补执行
汇总历史功能背景到表格中
识别外部依赖（CMM、后端、接口约定）

如果是技术模式且层级3未检查代码：

定位并读取受影响功能的相关文件
识别：组件、reducers、sagas、API服务、校验规则
查找现有功能中的相似实现模式

Paso 5: Validación final de confianza

步骤5：最终可信度校验

Evaluar si se puede avanzar con confianza. Condiciones de bloqueo (si alguna aplica → Modo C):

No hay forma de reproducir el problema (faltan pasos, entorno o datos)
Múltiples flujos válidos y el ticket no identifica cuál
Falta respuesta esperada del backend o contrato de payload
Faltan logs o mensajes de error necesarios para localizar el fallo
Falta definición funcional o regla de negocio para elegir entre opciones válidas
Las respuestas del usuario siguen siendo ambiguas o contradictorias

Si hay bloqueo → Modo C. Si hay confianza suficiente → Paso 6.

评估是否可以可信地推进分析，阻塞条件（满足任意一项则进入C模式）：

无法复现问题（缺少步骤、环境或数据）
存在多个有效流程，工单未明确指定
缺少后端预期响应或payload约定
缺少定位故障所需的日志或错误信息
缺少业务规则或功能定义，无法在多个有效选项中选择
用户回复仍然模糊或矛盾

存在阻塞 → C模式 可信度足够 → 步骤6

Paso 6: Producir propuesta y generar archivo markdown

步骤6：生成方案并输出Markdown文件

Seleccionar el modo de salida apropiado según el modo de análisis (funcional/técnico) y generar tanto la respuesta como el archivo markdown.

根据分析模式（功能/技术）选择合适的输出模式，同时生成回复和Markdown文件。

Modos de salida

输出模式

Modo A-Funcional: Análisis funcional (contexto suficiente, sin código)

A-功能模式：功能分析（上下文足够，无代码）

undefined

undefined

1. Resumen de negocio

1. 业务概述

Qué se pide o qué problema se reporta (una oración)
Usuario/rol afectado
Impacto esperado

需求内容或上报的问题（一句话概括）
受影响的用户/角色
预期影响

2. Flujo afectado

2. 受影响流程

Descripción del flujo de negocio involucrado
Servicios o sistemas que participan (CMM, backend, frontend)
Puntos de integración relevantes

涉及的业务流程描述
参与的服务或系统（CMM、后端、前端）
相关集成点

3. Análisis del problema

3. 问题分析

Qué se entiende del problema a partir de la evidencia disponible
Si hay artefactos (logs, payloads): análisis detallado de qué muestran
Comportamiento actual vs esperado

基于现有证据对问题的理解
如有日志、payload等材料：详细分析内容
当前 vs 预期行为

4. Reglas de negocio identificadas

4. 识别的业务规则

Reglas explícitas (del ticket o documentación)
Reglas inferidas (marcadas como [INFERIDA])
Validaciones o condiciones relevantes

明确规则（来自工单或文档）
推导规则（标注为[推导]）
相关校验或条件

5. Diagnóstico o propuesta funcional

5. 诊断或功能方案

Causa probable del problema / qué se necesita cambiar funcionalmente
Opciones si hay más de un camino
Recomendación

问题大概率原因 / 需要做的功能变更
多路径时给出可选方案
推荐方案

6. Dependencias y riesgos

6. 依赖和风险

Dependencias externas (CMM, backend, otros equipos)
Riesgos identificados
Suposiciones (etiquetadas como [SUPOSICION])

外部依赖（CMM、后端、其他团队）
识别的风险
假设（标注为[假设]）

7. Próximos pasos recomendados

7. 推荐下一步

Acciones concretas para avanzar
A quién consultar si aplica
Qué evidencia adicional obtener si aplica

undefined

具体推进动作
如需咨询说明对接人
如需补充证据说明所需内容

undefined

Modo A-Técnico: Propuesta técnica (contexto suficiente, con código)

A-技术模式：技术方案（上下文足够，含代码）

undefined

undefined

1. Resumen de negocio

1. 业务概述

Qué se pide (una oración)
Usuario/rol afectado
Impacto esperado

需求内容（一句话概括）
受影响的用户/角色
预期影响

2. Áreas impactadas

2. 影响范围

Features involucrados (nombre + path)
Reducers, sagas, servicios API
Componentes principales

涉及的功能（名称+路径）
Reducers、sagas、API服务
核心组件

3. Archivos candidatos

3. 候选修改文件

Lista con rutas: src/features/..., src/api/..., etc.
Breve motivo por archivo

路径列表：src/features/..., src/api/..., 等
每个文件的修改原因简述

4. Enfoques posibles (1-3)

4. 可选实现方案（1-3个）

Para cada enfoque:

Descripción breve
Pros/cons
Complejidad estimada (baja/media/alta)

每个方案包含：

简要描述
优缺点
预估复杂度（低/中/高）

5. Enfoque recomendado

5. 推荐方案

Por qué este enfoque
Pasos concretos (ordenados)

选择理由
具体落地步骤（按顺序）

6. Riesgos e incógnitas

6. 风险和未知项

Requisitos faltantes o ambiguos
Dependencias externas
Suposiciones asumidas (etiquetadas como [SUPOSICION])

缺失或模糊的需求
外部依赖
采用的假设（标注为[假设]）

7. Plan de pruebas

7. 测试计划

Casos a validar
Datos de prueba necesarios

需要验证的场景
所需测试数据

8. Nombre de rama y commit

8. 分支和提交命名

Rama: feature/JIRA-XXX o fix/JIRA-XXX
Ejemplo commit: feat(scope): descripción en español

undefined

分支：feature/JIRA-XXX 或 fix/JIRA-XXX
提交示例：feat(scope): 中文描述

undefined

Modo B: Contexto faltante, preguntas primero

B模式：上下文缺失，先提问

undefined

undefined

Resumen del ticket

工单概要

Lo que el ticket establece (breve)
Qué está claro y qué no

工单明确说明的内容（简要）
明确信息和缺失信息说明

Contexto faltante

缺失的上下文

Elementos del umbral mínimo que faltan
Por qué bloquean una propuesta concreta

未满足的最低阈值项
为什么这些内容会阻塞方案输出

Preguntas para destrabar el análisis

推进分析需要确认的问题

3-5 preguntas numeradas, concretas
Priorizadas por impacto
Si involucra CMM: pedir trace number o request/response

3-5个编号的具体问题
按影响优先级排序
如涉及CMM：索要trace号或请求/响应内容

Suposiciones tentativas (opcional)

tentative假设（可选）

Marcadas como [NO CONFIRMADO]
No tratarlas como requisitos

标注为[未确认]
不作为需求对待

Próximo paso recomendado

Resumen de lo investigado

调研内容概要

Qué se leyó en Jira
Qué se encontró en Confluence (si aplica)
Qué código se inspeccionó (si aplica)
Qué artefactos proporcionó el usuario (si aplica)
Qué preguntas se hicieron y qué respuestas se obtuvieron

读取的Jira工单内容
Confluence中找到的内容（如有）
检查的代码内容（如有）
用户提供的材料（如有）
提出的问题和收到的回复

Por qué no puedo avanzar con confianza

无法可信推进的原因

Declaración explícita: "No tengo suficiente contexto para proponer una solución confiable."
Cuál condición de bloqueo aplica

明确声明："我没有足够的上下文输出可信的解决方案"
说明符合哪条阻塞条件

Evidencia faltante

缺失的证据

Clasificar cada ítem como funcional, técnico u observable:

Funcional: definición, regla de negocio, criterio aceptación, alcance
Técnico: payload request/response, contrato servicio, interfaz CMM, spec API
Observable: logs, mensajes error, pasos reproducción, screenshots, traces

Para dependencias externas usar formato: [Dependencia externa] <tipo>: <descripción>

Tipo: contrato | request | response | regla_negocio | observable | build
Artefacto faltante: <qué se necesita>
Quién puede proveerlo: <rol o sistema>

按功能、技术、可观测项分类：

功能类：定义、业务规则、验收标准、范围
技术类：请求/响应payload、服务约定、CMM接口、API规范
可观测类：日志、错误信息、复现步骤、截图、trace

外部依赖使用以下格式： [外部依赖] <类型>: <描述>

类型：约定 | 请求 | 响应 | 业务规则 | 可观测项 | 构建
缺失材料：<所需内容>
提供方：<角色或系统>

Preguntas o artefactos necesarios

需要的问题答复或材料

Preguntas concretas o artefactos que destrabarían el análisis

可以推进分析的具体问题或材料

Quién podría proveerlo

提供方

PO, QA, equipo backend, logs/APM, Confluence, trace viewer, etc.

PO、QA、后端团队、日志/APM、Confluence、trace查看器等

Próximo paso recomendado

1. Antecedentes funcionales relevantes

1. 相关功能历史

Key	Summary	Regla de negocio	Cambio realizado	Riesgo/restricción
MDCS-xxx	...	...	...	...

工单号	概要	业务规则	已完成变更	风险/限制
MDCS-xxx	...	...	...	...

2. Reglas de negocio inferidas del historial

2. 从历史推导的业务规则

Síntesis de reglas de los antecedentes
Marcar como (inferida) cuando no sea explícita
Ej: "El monto mínimo debe validarse contra el producto seleccionado (inferida de MDCS-320)"

历史规则汇总
非明确规则标注为（推导）
示例："最低金额需要根据选中的产品校验（推导自MDCS-320）"

3. Dependencias externas pendientes

3. 待确认的外部依赖

Para cada dependencia: tipo, artefacto faltante, quién puede proveerlo
Usar formato [Dependencia externa] del Modo C

每个依赖包含：类型、缺失材料、提供方
使用C模式中的[外部依赖]格式

4. Evidencia faltante para cerrar análisis

4. 完成分析缺失的证据

Clasificar: funcional, técnico, observable
Si no hay: "Evidencia suficiente para avanzar"

分类：功能、技术、可观测项
无缺失则写："证据足够，可推进分析"

5. Síntesis y próximo paso

5. 总结和下一步

Si hay contexto suficiente → producir Modo A-Funcional o A-Técnico según corresponda
Si hay bloqueos → cerrar con Modo C

---

上下文足够 → 按对应场景输出A-功能模式或A-技术模式
存在阻塞 → 按C模式输出

---

Análisis de artefactos CMM

CMM材料分析

Cuando el usuario pega artefactos CMM (SOAP/XML, JSON, logs), aplicar este análisis específico:

当用户粘贴CMM材料（SOAP/XML、JSON、日志）时，执行以下专项分析：

Request CMM

CMM请求

Identificar la operación invocada (nombre del servicio, método)
Listar campos enviados y sus valores
Detectar campos vacíos, nulos, o con formato sospechoso
Comparar contra la interfaz esperada si está disponible

识别调用的操作（服务名、方法名）
列出提交的字段和值
检测空字段、空值或格式异常的字段
如已有预期接口则做对比

Response CMM

CMM响应

Identificar si es éxito o error
Si error: extraer código CMM (
```
cmmCode
```
), mensaje (
```
cmmMsg
```
), detalle (
```
detail
```
), source
Analizar qué significa el error en contexto del flujo
Si éxito: verificar que los campos de respuesta sean coherentes con lo esperado

识别是成功还是错误
错误场景：提取CMM错误码（
```
cmmCode
```
）、消息（
```
cmmMsg
```
）、详情（
```
detail
```
）、来源
结合流程上下文分析错误含义
成功场景：校验响应字段是否符合预期

Request + Response juntos

请求+响应同时存在

Trazar el flujo: qué se envió → qué se recibió → es coherente?
Identificar discrepancias entre lo enviado y la respuesta
Proponer causa probable del error o comportamiento inesperado

流程追踪：发送内容 → 接收内容 → 是否符合逻辑？
识别发送内容和响应的不一致
给出错误或异常行为的大概率原因

Interfaz/Contrato CMM

CMM接口/约定

Mapear campos obligatorios vs opcionales
Identificar tipos de datos y restricciones
Comparar contra el request/response real si están disponibles

映射必填/可选字段
识别数据类型和限制
如已有实际请求/响应则做对比

Archivo de salida

输出文件

Siempre se genera un archivo markdown con el análisis completo, independientemente del modo.

Ruta del archivo:

Si hay código local (existe

src/

) →

docs/ai/analysis/<JIRA-KEY>-analisis.md

Si NO hay código local →

~/Desktop/Analysis/<JIRA-KEY>-analisis.md

Estructura del archivo:

markdown

undefined

所有场景均生成完整分析的Markdown文件，无例外。

文件路径：

存在本地代码（有

src/

目录） →

docs/ai/analysis/<JIRA-KEY>-analisis.md

无本地代码 →

~/Desktop/Analysis/<JIRA-KEY>-analisis.md

文件结构：

markdown

undefined

Análisis: <JIRA-KEY> — <Summary del ticket>

分析：<JIRA-KEY> — <工单概要>

日期: <当前日期> 模式: A-功能模式 | A-技术模式 | B | C | D 工单: <JIRA-KEY> 状态: <工单状态> 优先级: <优先级> 分析类型: 功能 | 技术

<选中的输出模式的完整内容>

Fuentes consultadas

参考来源

Jira: <tickets consultados>
Confluence: <páginas consultadas> (si aplica)
Código: <archivos inspeccionados> (si aplica)
Bitbucket: <archivos consultados> (si aplica)
Artefactos del usuario: <qué proporcionó> (si aplica)
Trace viewer: <trace consultado> (si aplica)


Crear el directorio de salida si no existe antes de escribir el archivo.

---

Jira: <查询的工单列表>
Confluence: <查询的页面列表>（如有）
代码: <检查的文件列表>（如有）
Bitbucket: <查询的文件列表>（如有）
用户提供材料: <用户提交的内容>（如有）
Trace查看器: <查询的trace>（如有）


写入文件前如果输出目录不存在则自动创建。

---

Reglas

规则

Funcional primero — el default es análisis funcional. Solo ir a código si el usuario lo pide o el ticket es claramente de implementación.
Jamás inventar — si el ticket es ambiguo o faltan requisitos, escalar por niveles. No inventar detalles.
Escalamiento antes que preguntas — investigar Jira, Confluence (y código si aplica) ANTES de preguntar al usuario.
Artefactos del usuario son evidencia de primera clase — logs, payloads, interfaces pegados en el chat tienen la misma validez que datos de Jira o código.
Pedir artefactos CMM proactivamente — si el problema involucra servicios CMM y no hay evidencia técnica, preguntar por trace number o pedir que peguen request/response.
Etiquetar suposiciones — toda suposición debe marcarse explícitamente como
```
[SUPOSICION]
```
o
```
[NO CONFIRMADO]
```
.
Archivo siempre — generar el archivo markdown de salida en todos los casos, sin excepción.
Propuesta concisa — 1-2 páginas salvo tickets muy complejos.
Terminología del proyecto — usar nombres de features, servicios y flujos tal como aparecen en Jira, Confluence y el código.
Convenciones de código (solo modo técnico) — branch naming
```
feature/JIRA-ID
```
o
```
fix/JIRA-ID
```
, commits en español.

功能优先 — 默认采用功能分析模式，仅用户明确要求或工单是明确的实现需求时才进行代码层面分析。
绝不编造 — 如果工单模糊或缺少需求，按层级补充上下文，不得编造细节。
先调研再提问 — 向用户提问前先检索Jira、Confluence（适用场景下检索代码）。
用户提交材料为一级证据 — 聊天中粘贴的日志、payload、接口和Jira、代码中的数据效力相同。
主动索要CMM材料 — 如果问题涉及CMM服务且无技术证据，主动询问trace号或要求粘贴请求/响应。
标注假设 — 所有假设必须明确标注为
```
[假设]
```
或
```
[未确认]
```
。
必生成文件 — 所有场景均生成Markdown输出文件，无例外。
方案简洁 — 除非是极复杂工单，否则输出控制在1-2页。
使用项目术语 — 功能、服务、流程名称和Jira、Confluence、代码中的命名保持一致。
代码规范（仅技术模式） — 分支命名
```
feature/JIRA-ID
```
或
```
fix/JIRA-ID
```
，提交信息使用中文。

Trace viewer

Trace查看器

URL:

http://172.12.24.172:8888/app/pages/index.html

Acceso: requiere VPN activa del usuario
Uso: buscar traces CMM por número, devuelve request/response en formato SOAP
Integración: intentar WebFetch primero. Si no funciona o requiere interacción, guiar al usuario para que busque y pegue los resultados.

URL:

http://172.12.24.172:8888/app/pages/index.html

访问要求: 用户开启VPN
用途: 按编号查询CMM trace，返回SOAP格式的请求/响应
集成逻辑: 优先尝试WebFetch访问，无法访问或需要交互时引导用户自行搜索粘贴结果。

Referencias opcionales (NO se leen por defecto)

可选参考（默认不读取）

Estos archivos pueden leerse manualmente si se necesita contexto adicional:

```
docs/ai/feature-map.md
```
— mapa de features y sus rutas
```
docs/ai/context-index.json
```
— índice generado de contexto
```
docs/ai/examples/*.md
```
— 4 ejemplos de análisis
```
docs/ai/clarification-playbook.md
```
— playbook de preguntas (deprecado, integrado aquí)
```
docs/ai/analysis-template.md
```
— template de análisis (deprecado, integrado aquí)
```
docs/ai/history-heuristics.md
```
— heurísticas de búsqueda (deprecado, integrado aquí)
```
docs/ai/external-evidence-model.md
```
— modelo de evidencia externa (deprecado, integrado aquí)

需要额外上下文时可手动读取以下文件：

```
docs/ai/feature-map.md
```
— 功能和路径映射表
```
docs/ai/context-index.json
```
— 上下文生成索引
```
docs/ai/examples/*.md
```
— 4个分析示例
```
docs/ai/clarification-playbook.md
```
— 提问指南（已废弃，已整合到本文件）
```
docs/ai/analysis-template.md
```
— 分析模板（已废弃，已整合到本文件）
```
docs/ai/history-heuristics.md
```
— 搜索启发式规则（已废弃，已整合到本文件）
```
docs/ai/external-evidence-model.md
```
— 外部证据模型（已废弃，已整合到本文件）