# Syncserver Jira Description

> Drafts a concise Jira description for a syncstorage-rs task. Gathers context via targeted interview, researches relevant patterns in the repo, then outputs a clean description ready for an engineer to hand to Claude for implementation.

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

---


# Syncserver Jira Description

Draft a Jira description for a syncstorage-rs task. Output the description only — 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, crates, 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
- **Crates:** Which specific crate(s) will be modified (e.g. `syncstorage-spanner`, `tokenserver-auth`, `syncserver`, `tokenserver-postgres`)
- **Constraints:** DB migration required, multi-backend impact (MySQL/Postgres/Spanner), breaking API change, feature flag, FxA contract change — 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, or architecture notes that would add useful context.

## Step 2: Research

Search only the crates identified in Step 1. Find the most relevant existing patterns: similar feature, nearby handler, equivalent DB query, related error type. Expand to the broader workspace only if nothing relevant is found there.

Identify:
- Key files an implementer will need to touch
- The closest existing reference implementation to follow
- Which database backends are affected and whether the change must be replicated across MySQL, PostgreSQL, and/or Spanner
- Whether new migrations are required (and which crates: `syncstorage-mysql`, `syncstorage-postgres`, `tokenserver-mysql`, `tokenserver-postgres`)
- Whether tests, metrics (Glean/StatsD), or Sentry error handling apply

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

## Step 3: Output

**Background:**
Why this is needed and what it enables. 2–4 sentences. Note which service is affected — Syncstorage (storage node), Tokenserver (node allocation + FxA auth), or both.

**Acceptance Criteria:**
Observable, testable outcomes. Each item verifiable without reading the code. Include criteria for tests, metrics emission, and Sentry error classification where applicable.

**Implementation Steps:**
Numbered steps with crate paths, file paths, trait/function names, and structural guidance. Reference the nearest existing pattern for each step. For multi-backend changes, call out which backends need matching implementations. No code snippets — file locations, types, and patterns only.

**Database Migrations:** *(omit if no schema changes)*
Which migration crates need new files (`syncstorage-mysql/migrations/`, `tokenserver-postgres/migrations/`, etc.). Reminder: never edit published migrations — add new `up.sql`/`down.sql` pairs only.

**Tests:**
What needs to be tested. Unit (`#[cfg(test)]` in the relevant crate), integration (`tools/integration_tests/` pytest — requires running server), and E2E (`tokenserver/test_e2e.py` — hits FxA staging, session-scoped) coverage expectations. Reference the nearest existing test file as a pattern.

**Metrics & Error Handling:** *(omit if not applicable)*
Any Glean metrics, StatsD counters, or Sentry event classifications that should be emitted or updated. Note whether new error variants should be routed to Sentry or suppressed as metrics (see `is_sentry_event()` pattern in `syncstorage-spanner/src/error.rs`).

**Key Reference Files:**
Specific files the implementer should read before starting. One line each.

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

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

## Guidelines

- Output the description only — no source file changes
- Implementation Steps should give enough detail to start work without follow-up questions — crate paths, file paths, and patterns, not prose
- Multi-backend tasks: always explicitly name which backends (MySQL / PostgreSQL / Spanner) need matching changes; do not say "all backends" without listing them
- Migration tasks: always reference the no-edit-published-migrations rule
- Omit redundant or obvious acceptance criteria
- Include Database Migrations, Metrics & Error Handling only when relevant
- If motivation or scope remain unclear after asking, flag as an Open Question rather than assuming
- Branch naming reminder for the assignee: Mozilla engineers use `type/description-STOR-####`; community contributors use `type/description-####`