Batch Feature Dev
Deliver ticket batches as coordinated PRs while keeping each ticket scoped and reviewable.
Load First
Read relevant skills before entering their phase:
feature-dev per ticket or coupled group.git-conventions before branch, commit, rebase, or push work.create-changeset before changesets; create-pr for draft PRs.ldls-native or ldls-web before Lumen UI work.mvvm-architecture before app feature code.run-tests for validation.
Workflow
- Intake every Jira ticket link, description, attachment, mockup, and constraint. Fetch details with available Jira/Atlassian tools; ask if anything is inaccessible.
- Before coding, produce a compact matrix: id/link, area, UI impact, tests/screenshots, dependencies, shared work, blockers. Ask consolidated questions for missing mockups, conflicts, unclear copy, APIs, analytics, navigation, flags, and edge cases.
- Branch via
git-conventions. Start unrelated tickets from updated develop; chain only for real dependencies, target the previous branch, and state it in the PR. For shared groundwork, prefer one small foundation PR plus dependent PRs.
- For each ticket/group, run full
feature-dev. Treat tickets and mockups as source of truth; ask on conflicts; use Lumen components; add only English source translations; keep shared utilities owned and justified.
- Validate affected scope with lint, relevant tests, typecheck, and screenshots or manual visual checks for UI. Add a changeset with exact package names; use
create-pr for draft PR and Slack message.
- Handoff each PR with ticket, branch, target, URL, changeset, validation results, screenshots/status, risks, and follow-ups. After the batch, summarize dependency graph and review order.
Stop When
Pause for missing ticket/mockup details, incompatible tickets, product/design decisions, meaningless validation, or changed chaining strategy.
1---2name: batch-feature-dev3description: Handle batches of Jira tickets through shared analysis, per-ticket feature-dev, Lumen UI guardrails, changesets, and draft PRs. Use when the user provides multiple Jira tickets or asks to deliver tickets one by one with PRs.4---56# Batch Feature Dev78Deliver ticket batches as coordinated PRs while keeping each ticket scoped and reviewable.910## Load First1112Read relevant skills before entering their phase:1314- `feature-dev` per ticket or coupled group.15- `git-conventions` before branch, commit, rebase, or push work.16- `create-changeset` before changesets; `create-pr` for draft PRs.17- `ldls-native` or `ldls-web` before Lumen UI work.18- `mvvm-architecture` before app feature code.19- `run-tests` for validation.2021## Workflow22231. Intake every Jira ticket link, description, attachment, mockup, and constraint. Fetch details with available Jira/Atlassian tools; ask if anything is inaccessible.242. Before coding, produce a compact matrix: id/link, area, UI impact, tests/screenshots, dependencies, shared work, blockers. Ask consolidated questions for missing mockups, conflicts, unclear copy, APIs, analytics, navigation, flags, and edge cases.253. Branch via `git-conventions`. Start unrelated tickets from updated `develop`; chain only for real dependencies, target the previous branch, and state it in the PR. For shared groundwork, prefer one small foundation PR plus dependent PRs.264. For each ticket/group, run full `feature-dev`. Treat tickets and mockups as source of truth; ask on conflicts; use Lumen components; add only English source translations; keep shared utilities owned and justified.275. Validate affected scope with lint, relevant tests, typecheck, and screenshots or manual visual checks for UI. Add a changeset with exact package names; use `create-pr` for draft PR and Slack message.286. Handoff each PR with ticket, branch, target, URL, changeset, validation results, screenshots/status, risks, and follow-ups. After the batch, summarize dependency graph and review order.2930## Stop When3132Pause for missing ticket/mockup details, incompatible tickets, product/design decisions, meaningless validation, or changed chaining strategy.
ledgerhq