---
name: jira-ticket-implementation
description: When implementing a refined Jira ticket point by point. Covers discovery (finding the right REFINEMENT and README), implementation cadence, review, and commit.
---

# Jira ticket implementation — workflow

When the user asks to **implement** a ticket that already has a `REFINEMENT-*.md`, follow this workflow.

## 1. Identify the ticket (always do this first)

Before writing any code, you need to know **which ticket** you're working on:

1. **Check if the user already told you** the ticket ID, module, or which refinement to implement (in their message or earlier in the conversation).
2. **If not clear, list files in `.refinements/`** to find available `REFINEMENT-*.md` files.
   - If **one** refinement 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.
3. **Read the refinement file** end-to-end: understand the full plan, what's done, what's pending. Extract the ticket ID and module from the refinement's "Ticket (summary)" section.
4. **Read the module's `README.md`** (e.g. `src/pages/dashboard/<Module>/README.md`) if it exists, for migration scope, screens, and module-specific rules.
5. **Read project rules** in `.cursor/rules/` — especially `file-types/` — to understand module structure, coding standards, and patterns. The implementation must follow these conventions.

Only after completing these reads, proceed to implementation.

## 2. One point at a time

- Work **only** on the **next** uncompleted point in the "Implementation plan" (or the point the user indicates).
- After completing a point: summarize what was done and how to validate, then **stop and wait** for the user to confirm before moving to the next point.
- Do **not** implement multiple plan points in one go unless the user explicitly asks to.

## 3. Answer before acting

- When the user asks a **question** (e.g. "how can we…?", "what happens if…?", "is there a rule for…?"), **answer it first** in plain text before writing or modifying any code.
- Do not treat a question as an implicit instruction to implement. Wait for the user to confirm they want to proceed before touching files.
- If the answer is "yes, and here's how", explain the approach, then ask or wait for a go-ahead.

## 4. Back and forth

- If the user **questions a decision** in the plan or the code (e.g. "why is X needed?", "can't this go here instead?", "seems unnecessary"):
  - Re-evaluate and, if it simplifies the solution, **adjust the implementation** (and optionally the plan) before considering the point done.
  - Do not treat the point as finished until the user's concern is addressed or explicitly set aside.

- If the user **provides a UI mockup or image** during implementation:
  - Compare it against the current plan and the translation keys listed in the refinement.
  - Flag any elements visible in the image that are not covered in the plan: helper texts below inputs, missing buttons (e.g. delete per item), layout groupings that suggest a dedicated section component, or copy that doesn't have an i18n key yet.
  - **Update the refinement before implementing** so the document stays the source of truth. Do not silently implement undocumented elements.

## 4. Keep the plan in sync

- When **implementation diverges** from the plan (simplifications, different approach, new findings): suggest or apply **updates to the REFINEMENT-*.md** so the document stays the source of truth.
- Prefer adding short notes over leaving the plan outdated.

## 5. Keep module READMEs updated

- After finishing implementation, **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.

## 6. Pre-commit review

- **Before** committing, do a **code review** of the changes: go through the modified files, leave **suggestions** and **possible improvements** (readability, conventions, edge cases, alignment with project rules).
- Output a short review: what was changed, what looks good, and any concrete suggestions (with file/line or snippet if useful). The user can then apply, ignore, or discuss before proceeding to commit.
- Optionally run **lint/typecheck** in each modified repo and fix reported errors so the commit is clean. Only then proceed to §7.

## 7. Commit per repo at the end

- When **all plan points are done and validated** and the **pre-commit review** passes, make a **commit in each repo** that was modified.
- Use commit format: `[TICKET-ID] Module | Summary` (ticket ID and module from the refinement file).
- One commit per repo for the implementation work; stage all changes in that repo and commit. If the user prefers a different strategy (e.g. one commit per point), follow their preference.