|
| 1 | +--- |
| 2 | +description: Take a triaged bug or feature request through to a verified change on a branch, ready for /commit and /pr — using this session's investigation plus the Jira ticket |
| 3 | +--- |
| 4 | + |
| 5 | +Implement a fix or feature that's already been triaged (typically by `/slack-triage` earlier in this |
| 6 | +same session) and land it as a **verified change on a branch**, stopping before commit. This is the |
| 7 | +bridge between a Jira ticket and `/commit` → `/pr`. Works for both bugs and feature requests — it's |
| 8 | +not always a "fix". |
| 9 | + |
| 10 | +Usage: `/implement [INSTUI-1234]` — pass a ticket key if you have one. If `$ARGUMENTS` is empty, use |
| 11 | +the ticket and investigation from this session. |
| 12 | + |
| 13 | +## Step 1 — Establish context (prefer this session over the ticket) |
| 14 | + |
| 15 | +A Jira ticket is a **short summary** of a much richer investigation. When `/slack-triage` ran earlier |
| 16 | +in this conversation, the full picture is already in context — root cause, exact `file:line`, the |
| 17 | +introducing commit/PR, the confirmed reproduction recipe, version/v1-v2 notes. **Use that. Do not |
| 18 | +downgrade to the ticket's summary when the fuller investigation is in the session.** |
| 19 | + |
| 20 | +Source context in this priority order: |
| 21 | + |
| 22 | +1. **This session's investigation** (primary). If triage already happened here, carry forward its root |
| 23 | + cause, the precise code location, and the confirmed repro. Treat these as the working spec. |
| 24 | +2. **The Jira ticket** (durable anchor). Read it (Jira MCP / `$ARGUMENTS` key) to pin the scope, |
| 25 | + acceptance criteria, and the Slack-thread link — but as a *reference point*, not a replacement for |
| 26 | + the session's detail. If the ticket and your session findings conflict, prefer the verified session |
| 27 | + findings and note the discrepancy to the user. |
| 28 | +3. **Cold start fallback.** If there's *no* prior investigation in this session (fresh conversation, or |
| 29 | + you only have a ticket key), reconstruct it before coding: read the ticket, then re-run the |
| 30 | + investigation — mirror `/slack-triage` Step 3 (read the README/`props.ts`/`theme.ts`, trace the |
| 31 | + introducing commit/PR for a regression, cross-check the published docs) and rebuild the repro. Don't |
| 32 | + start editing off a one-paragraph ticket. |
| 33 | + |
| 34 | +State briefly which sources you're working from before you start changing code. |
| 35 | + |
| 36 | +## Step 2 — Branch (confirm first) |
| 37 | + |
| 38 | +The change goes on a **new branch off `master`** — not the current branch (CLAUDE.md: branch from |
| 39 | +master, integrate by **rebasing**, never merge). Before creating it, **sanity-check with the user**: |
| 40 | + |
| 41 | +- Show the current branch and the branch you propose to create (a descriptive name; include the |
| 42 | + ticket key if there is one), and wait for confirmation before running `git switch -c`. |
| 43 | +- Call out anything off: if you're already on a feature branch (especially one with unrelated WIP, or |
| 44 | + the very session that ran `/slack-triage`), say so — the user may want to branch off `master` |
| 45 | + rather than stack on it, or may intend to keep working on the current branch. |
| 46 | + |
| 47 | +Only branch once the user confirms the name and starting point. |
| 48 | + |
| 49 | +## Step 3 — Implement, honoring InstUI conventions |
| 50 | + |
| 51 | +Make the change at the location identified in Step 1. Enforce the rules the commit/PR skills don't: |
| 52 | + |
| 53 | +- **No hardcoded user-facing strings** — all UI text comes from props for i18n (the most common review |
| 54 | + comment). |
| 55 | +- **New components: functional + hooks only.** Styling via the co-located Emotion `theme.ts`. |
| 56 | +- **No breaking changes unless the user explicitly asked** — removing/renaming a prop, component, theme |
| 57 | + variable, or exported util; changing a prop type or a behavior-altering default. Adding optional |
| 58 | + props / new components / new theme variables is fine. If a break is genuinely required, flag it and |
| 59 | + get explicit sign-off; it must carry `BREAKING CHANGE:` in the commit. |
| 60 | +- **v1/v2:** if the component has both, change the right version (default to v2 for new work; confirm |
| 61 | + before touching deprecated v1). |
| 62 | +- **Docs & tests in the same change:** if you add/change a prop, update the component **README**. Add or |
| 63 | + extend co-located **unit tests** (`*.test.tsx`), a **regression-test page** under |
| 64 | + `/regression-test/src/app/<name>/page.tsx`, and a **Cypress entry** in |
| 65 | + `/regression-test/cypress/e2e/spec.cy.ts`. Maintain WCAG 2.1 AA and RTL support. |
| 66 | + |
| 67 | +## Step 4 — Verify against the original repro |
| 68 | + |
| 69 | +A change isn't done until it's shown to work: |
| 70 | + |
| 71 | +- Run the package's unit tests: `pnpm run test:vitest <pkg>`. |
| 72 | +- Re-run the **confirmed reproduction from triage** and show it now behaves as expected (use the |
| 73 | + `verify` skill / `pnpm run dev`). For a bug, the exact repro that demonstrated the failure should now |
| 74 | + pass; for a feature, the use case from the ticket should work. Report what you observed. |
| 75 | + |
| 76 | +## Step 5 — Hand off (stop before commit) |
| 77 | + |
| 78 | +Stop at a **verified diff on the branch** and summarize: what changed and why, files touched, test/repro |
| 79 | +results, and any follow-ups. **Do not commit or open a PR automatically** — the diff needs human review. |
| 80 | +Tell the user to run `/commit` then `/pr` (the PR body should reference the `INSTUI-` ticket) once they're |
| 81 | +happy. |
| 82 | + |
| 83 | +If the change is non-trivial and you only got partway, **say so plainly** — leave a documented WIP branch |
| 84 | +and list what's left, rather than forcing a wrong or incomplete change to look finished. |
0 commit comments