---
name: implement-jira-ticket
description: When the user asks to implement a ticket, start a plan point, or says "vamos con el punto N", "implementar", "siguiente punto". Loads refinement file, module README, and project conventions before starting implementation.
---

# Skill: Implement Jira Ticket

When the user asks to **implement** a ticket, start a plan point, or says "vamos con el punto N", "implementar", "siguiente punto", follow this flow to get full context before writing any code.

## When to use

- User says "implementar", "vamos con el punto 1", "siguiente punto", "arranquemos".
- A `REFINEMENT-*.md` exists and the user wants to start or continue implementing.
- A new agent is resuming work on a ticket.

## Steps

### 1. Identify the ticket

The user should tell you which ticket to implement — either by ticket ID, module name, or by referencing a refinement file. If they haven't:

- **List files in `.refinements/`** to find available `REFINEMENT-*.md` files.
  - If **one** exists → use it.
  - If **multiple** exist → list them and **ask the user** which one to implement.
  - If **none** exist → **ask the user** what ticket they want to work on, or suggest running the refinement skill first.
- **Never guess** which ticket to work on. Always confirm with the user if ambiguous.

### 2. Create the working branch

Before reading any code, set up the branch so all work lands in the right place.

- **Determine base branch**: suggest `develop` as the base. If the user specifies a different branch, use that instead.
- **Pull latest**: checkout and pull the base branch so the new branch starts from its latest state:
  ```bash
  git checkout <base-branch> && git pull
  ```
- **Determine branch name**:
  - If the user provides a branch name → use it as-is.
  - Otherwise → auto-generate one from the ticket ID and a short description of its goal.
    Format: `<ticket-id>-<short-slug>` (lowercase, hyphens, ≤ 50 chars).
    Example: `sqgz-880-add-export-button-to-payroll-table`
  - Show the proposed name and **ask the user to confirm or change it** before creating.
- **Create and checkout the branch**:
  ```bash
  git checkout -b <branch-name>
  ```

### 3. Read the refinement file and context

- Read the refinement file end-to-end: understand the full plan, what's already done, and what's pending.
- Extract the **ticket ID** and **module** from the refinement's "Ticket (summary)" section.
- **Module README**: read `src/pages/dashboard/<Module>/README.md` if it exists. It has migration scope, screens, and module-specific rules.
- **Project conventions**: read all rules in `.cursor/rules/` — especially `file-types/` — to understand module structure, coding standards, and patterns.
- The implementation **must** follow these conventions. If legacy code contradicts them, follow the conventions (they represent the target state).

### 4. Start implementing

- Follow the **jira-ticket-implementation** workflow (`.cursor/rules/workflows/jira-ticket-implementation.mdc`):
  - Work **one point at a time** from the "Implementation plan". **Do NOT start the next step until the user explicitly confirms the current one is done.**
  - After completing a point, summarize what was done and what the user can do to verify it, then **stop and wait**.
  - Keep the refinement file in sync if the implementation diverges.
  - After finishing implementation (or after each significant point if there are structural changes), **update the `README.md`** of every module or feature folder that was touched (e.g. `src/pages/dashboard/<Module>/README.md`). Reflect any new screens, flows, components, hooks, or architectural decisions introduced by the ticket. If a module doesn't have a `README.md` yet and the changes are significant enough, create one following the style of existing module READMEs.
  - Do a pre-commit review when all points are done.

#### Before writing any file: find the analog

Before creating or modifying any file for a given step, look for an existing implementation that follows the same pattern:

1. **Search the codebase** for a file that plays the same role (e.g. if you're creating a new form, find an existing form of the same type).
2. **Read it fully** before writing a single line. The real code is the source of truth — not the pattern description in the refinement.
3. **If no analog is obvious**, ask the user: *"Is there something already implemented that I should use as a reference for this step?"* They know the codebase better and can save significant back-and-forth.

> **Why this matters:** Description of a pattern and the actual implementation can diverge (extra params, simplified APIs, shared utilities). Reading an existing analog reveals these details — and surfaces decisions like "no new service needed, the existing one handles all cases" that are easy to miss from the description alone.

> **Why one step at a time matters:** Steps in the refinement are designed as vertical slices — each one leaves the app in a working, testable state. Implementing multiple steps at once bypasses this and makes it impossible to catch issues early. If you find yourself needing context from a later step to implement the current one, that's a sign the refinement needs to be updated first.

## Quick reference: where is what?

| Question | Answer |
|----------|--------|
| What ticket am I working on? | Ask the user, or read from `REFINEMENT-*.md` → "Ticket (summary)" section |
| What module? | From the refinement file, or ask the user |
| Where is the plan? | `.refinements/REFINEMENT-<ticket-id>.md` |
| What are the coding conventions? | `.cursor/rules/file-types/` |