---
name: songwhip-feature
description: >-
  Use when IMPLEMENTING a feature or change that spans multiple Songwhip
  services (e.g. "implement X across api and web", "add field Y to the shared
  type and update its consumers", "roll this change out to the fleet"). Drives
  the change as committed local feature branches via one git worktree and one
  subagent per repo, staged by dependency order. Write counterpart to the
  read-only songwhip-cross-repo skill.
license: MIT
metadata:
  author: songwhip
  version: '0.1.0'
---

# Songwhip Feature — Cross-Repo Implementation

Implement a single feature that spans multiple Songwhip services. Each repo gets
its own git worktree (off your local clone) and a focused subagent. Work is
**staged by dependency order**: shared/upstream packages change first and hand a
**contract** to the consumers that follow. Every subagent follows that repo's own
conventions (its `CLAUDE.md`/`AGENTS.md`, linters, and formatters) and TDD, runs
that repo's tests + lint, and **commits to a local `feat/<slug>` branch**.

**This skill writes code. It never pushes and never opens PRs.** You review the
committed branches locally, then push / PR yourself. For read-only search and
impact analysis, use `songwhip-cross-repo` instead.

## Prerequisites

- Local full clones of the target services (default location
  `~/Development/Songwhip/<repo>`). Missing clones are reported; you can choose to
  clone them.
- `git` (with `git worktree`) and `jq` on PATH.
- `GITHUB_PERSONAL_ACCESS_TOKEN` set if any missing clone needs to be cloned.

## When to Activate

Recommended first step: run `songwhip-cross-repo` impact analysis to determine the affected repos and change ordering, then use this skill to implement them.

- "Implement <feature> across <repos>"
- "Add <field/endpoint/type> to <shared package> and update its consumers"
- "Roll <change> out to the fleet"
- Any request to **make** (not just analyze) a coordinated change across services.

See `AGENTS.md` for the complete workflow.
