create-bug

Step 0 — Load configuration

Read ${CLAUDE_PLUGIN_ROOT}/config.yaml. If it does not exist, tell the user to copy config.example.yaml to config.yaml and fill in their values. Stop here.

Extract:

• issue_tracker — determines which adapter to load
• Issue tracker-specific config (e.g., jira.default_project, jira.default_bug_epic)

Step 1 — Load adapter

Read the adapter file at ${CLAUDE_PLUGIN_ROOT}/skills/create-bug/adapters/{issue_tracker}.md. If the adapter does not exist, tell the user that {issue_tracker} is not yet supported and stop.

All tool-specific calls come from the adapter. Do not invent tool calls.

Step 2 — Gather information

If $ARGUMENTS contains a brief description, use it as the starting point. Otherwise, ask.

Gather the following through conversation:

1. What is broken? — The observable defect (what the user sees)
2. Where does it happen? — Service, module, endpoint, or screen
3. Environment — dev, staging, prod
4. Steps to reproduce — if known
5. Expected behavior — what should happen
6. Evidence — error logs, screenshots, HTTP status codes, stack traces
7. Severity assessment — blocking users? data loss? workaround exists?

Do NOT ask all questions at once. Start with what the user already provided and only ask for what is missing. Be conversational.

Step 3 — Root cause analysis

Based on the gathered information, analyze and propose:

1. Probable root cause — what is likely failing and why
2. Required fix — what needs to change at a high level
3. Impact — what is affected (users, data, other services)

Present this analysis to the user for validation before creating the ticket.

Step 4 — Find parent epic

Use the adapter's search command to find the configured bug epic (from config). If the configured epic does not exist or is not set, ask the user if they want to:

• Create the bug without a parent epic
• Specify a different parent epic

Step 5 — Build bug description

Use this template for the bug description body:

## Descripción
{Clear explanation of the defect — what happens, when, and the observable impact}

## Evidencia
- **Entorno:** {environment}
- **Servicio/Módulo:** {service or module name}
- **Error observado:** {error message, HTTP status, stack trace snippet}
- **Pasos para reproducir:**
  1. {step 1}
  2. {step 2}
  3. {step 3}

## Causa raíz
{Analysis of why this is happening — the technical root cause}

## Fix requerido
{What needs to change to resolve the issue}

## Impacto
- **Usuarios afectados:** {scope — all users, specific role, specific flow}
- **Severidad:** {critical / high / medium / low}
- **Workaround:** {exists? describe it, or "No hay workaround conocido"}

Step 6 — Build summary

Format the ticket summary as:

{service}: {what is broken and the visible effect}

Examples:

• auth-service: login fails with 500 for users with special characters in email
• payments: duplicate charges created when retry button is clicked rapidly
• dashboard: performance metrics chart shows empty state despite data existing

Step 7 — Create the bug

Show the user the complete bug (summary + description) for approval.

Once approved, use the adapter's create issue command with:

• Type: Bug
• Summary: from Step 6
• Description: from Step 5
• Parent: from Step 4 (if found)
• Project: from config

Step 8 — Post-creation

After creation:

1. Display the created ticket key and URL
2. Ask if the user wants to:
   • Assign it to someone (use adapter's search for user + edit command)
   • Set priority (use adapter's edit command)
   • Add labels (use adapter's edit command)
   • Create another bug (restart from Step 2)