batch-feature-dev

# 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. - `structure-flow` before placing any code; `mvvm-architecture` for the app side in `apps/*/src/mvvm/`. - `validate-changes` for validation. ## Workflow 1. Place the code. Intake every Jira ticket link, description, attachment, mockup, and constraint (fetch details with available Jira/Atlassian tools; ask if anything is inaccessible), then decide with `structure-flow` which layer and package own each concern of each ticket. Only screens composing `@features/*` and app-only code go to `apps/*/src/mvvm/`. Work several tickets need gets one owning package. 2. Before coding, produce a compact matrix: id/link, area, owning packages, UI impact, tests/screenshots, dependencies, shared work, blockers. Ask consolidated questions for missing mockups, conflicts, unclear copy, APIs, analytics, navigation, flags, and edge cases. 3. 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. 4. For each ticket/group, run full `feature-dev`, starting from the agreed placement. 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. 5. Validate affected scope with `validate-changes`, plus screenshots or manual visual checks for UI. Add a changeset with exact package names; use `create-pr` for draft PR and Slack message. 6. 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.