# Fxa Jira Feature Description

> Drafts a concise Jira description for an FXA task. Gathers context via targeted interview, researches relevant patterns in the repo, outputs a clean description, and optionally files the ticket via the Atlassian MCP. Returns the new FXA-N key when filed.

- Skill: `mozilla/fxa-jira-feature-description` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mozilla/fxa-jira-feature-description`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mozilla/fxa-jira-feature-description/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: mozilla (https://skillmd.com/u/mozilla)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mozilla/fxa-jira-feature-description

---


# FXA Jira Description

Draft a Jira description for an FXA task, and optionally file the ticket via the Atlassian MCP. Do not create, edit, or suggest changes to any source files.

## Step 1: Gather Context

If a planning doc, epic description, or tech spec was provided, read it first and infer what, why, packages, and constraints before asking anything.

Required information:
- **What:** What is being built or changed, in one sentence
- **Why:** Motivation — user need, requirement, bug, or tech debt
- **Packages:** Which specific package(s) will be modified (e.g. `fxa-auth-server`, `libs/accounts/passkey`)
- **Constraints:** Feature flag, breaking change, migration, L10n — or none

If all four are clear from provided context, proceed directly to Step 2. Otherwise ask for only what is missing in a single message. Also invite related PRs, tickets, existing approach notes, design mockups, or flow diagrams that would add useful context.

## Step 2: Research

Search only the packages identified in Step 1. Find the most relevant existing patterns: similar feature, nearby route, equivalent component. Expand to the broader repo only if nothing relevant is found there.

Identify:
- Key files an implementer will need to touch
- The closest existing reference implementation to follow
- Whether tests, metrics, or security events apply (see Step 3)

Incorporate findings directly into the draft — do not list them separately or ask for confirmation. Surface genuine blockers as Open Questions.

## Step 3: Output

**Design:** *(Figma link if applicable. Note that all copy, strings, and visual specs should be taken from the latest Figma file — do not reproduce design details here as they may change before implementation. Omit if no design involved.)*

**Background:**
Why this is needed and what it enables. 3 sentences at most.

**Acceptance Criteria:**
Observable, testable outcomes. Each item verifiable without reading the code. One line each. Include criteria for tests, metrics emission, and security events where applicable to this task.

**Implementation Steps:**
Up to 7 numbered steps, one or two lines each. Describe what must be true when the step is done and name the nearest existing pattern to follow — not a keystroke-level plan. Keep file paths out of these steps; they belong in **Key Reference Files**, and code moves between drafting and pickup. No code snippets.

**Tests:**
What needs to be tested. Unit, integration, and snapshot coverage expectations. Reference the nearest existing test file as a pattern. Omit if covered inline above.

**Metrics & Security Events:** *(omit if not applicable)*
Any StatsD metrics or security events (`log.info`, `request.emitMetricsEvent`, `customs` checks) that should be emitted. Reference the nearest equivalent for naming conventions.

**Key Reference Files:** *(accurate as of drafting; verify before starting, since files get moved and renamed)*
Specific files the implementer should read before starting. One line each, no more than 6.

**Out of Scope:** *(omit if not needed)*

**Open Questions:** *(omit if none)*

## Step 4: Optionally file the ticket via Atlassian MCP

After producing the draft (Step 3), check whether the Atlassian MCP is available in the current session (look for `mcp__atlassian__createJiraIssue` in the available tools). If not available, stop — the user files the ticket manually using the drafted description.

If available, ask the user via `AskUserQuestion` whether to file now:

- "File now via Atlassian MCP (Recommended)"
- "Skip — I'll file manually"

If the user picks "Skip", stop and output the draft. If "File now", call `mcp__atlassian__createJiraIssue` with:

- `cloudId`: `mozilla-hub.atlassian.net` (the Atlassian MCP accepts the site hostname directly; fall back to `getAccessibleAtlassianResources` if the call ever rejects this form).
- `projectKey`: `FXA`
- `issueTypeName`: `Task`
- `summary`: the one-line "what" sentence from Step 1 / the leading description sentence
- `description`: the full drafted body from Step 3 (Background, AC, Implementation Steps, etc.)
- `contentFormat`: `markdown`

Surface the returned `FXA-N` key and the issue URL. That key is this skill's return value when invoked inline by another skill (e.g. `/fxa-pr-open` uses it to populate the `Closes:` line).

## Guidelines

- Do not create, edit, or suggest changes to any source files. Filing a Jira ticket via the MCP (Step 4) is not a source file change.
- Implementation Steps should give enough detail to start work without follow-up questions — patterns to follow and outcomes to hit, not prose and not a file-by-file script
- Do not include design details (copy, colours, layout, component specifics) — note that the implementer should refer to the latest Figma file
- Omit redundant or obvious acceptance criteria
- Follow `CLAUDE.md` section 9 on writing style, and make one cut pass before presenting the draft. A ticket the assignee skims and understands beats a complete one they don't read; when in doubt, drop the section rather than shortening every line in it
- Include Tests, Metrics & Security Events sections only when relevant to the task type
- If motivation or scope remain unclear after asking, flag as an Open Question rather than assuming