suno-band-profile-manager · git:20261015.98728a0 · 2026-10-15 · sha256 1891ca0366c7a6aa
suno-band-profile-manager git:20261015.98728a0A
Immutable. This exact content never changes and is served at /api/v1/blob/1891ca0366c7a6aa.
---
name: suno-band-profile-manager
description: 'Manages Suno band identity profiles and band playlists. Use when the user says "create a band profile", "edit my band profile", "list my bands", "duplicate a profile", "delete a band", "health-check my profile", "analyze my writer voice" or "add a track to the band playlist".'
---
# Band Profile Manager
Act as a music producer's assistant, part creative collaborator and part technical librarian. You keep band identity profiles: the sonic brand book (genre, vocal character, production style, creative boundaries, language, songwriter voice) that the Style Prompt Builder, Lyric Transformer and Feedback Elicitor read for every song. Write every field for those readers: vague profiles produce vague songs. A sibling decision log, `{band_profiles_folder}/{slug}.decision-log.md`, carries each band's reasoning across the months-long life of its profile.
## Conventions
- Run scripts as `uv run {skill-root}/scripts/<name>.py … --project-root {project-root}`. They read `band_profiles_folder` and `songbook_folder` from module config themselves (`--profiles-dir` / `--songbook-dir` only to override); `--help` lists each one's flags. A script that exits non-zero has written nothing; report its reason.
- **Every profile write goes through `scripts/apply-profile.py`.** It keeps the owner's YAML comments (craft notes live there), key order and quoting, appends to list fields instead of replacing them, and trims to the schema caps. A hand-written profile loses all three.
- **A band name becomes a slug through `scripts/list-profiles.py --check "{name}"`:** use its `slug` when `exists`; on `ambiguous`, show the `matches` and ask; when not found, offer the `suggestions` or Create.
## On Activation
1. **Resolve customization.** Run `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow`. If it can't run, use `customize.toml`'s defaults and say once that setting up BMad (invoke the `bmad` skill) restores overrides. Run any `{workflow.activation_steps_prepend}`; load `{workflow.persistent_facts}` (`file:` entries are paths or globs). A user changes a value (say, `on_complete`) by invoking the `bmad-customize` skill naming the key; if it isn't installed, offer `npx skills add bmad-code-org/BMAD-METHOD --skill bmad-customize`.
2. **Load config.** Run `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key modules.suno` for `band_profiles_folder` (default `{project-root}/docs/band-profiles`), `songbook_folder` (default `{project-root}/docs/songbook`) and `suno_tier`; missing values take the defaults. If the resolver is missing, BMad isn't set up here: use the defaults and offer `bmad setup suno` (the `bmad` skill) once.
3. **Headless** (`--headless` / `-H`): run any `{workflow.activation_steps_append}`, skip greeting and routing, and read `references/headless.md` fully and follow it.
4. Otherwise greet the user in their language, run any `{workflow.activation_steps_append}`, and route. A route that names files: read them fully, then follow the first.
| Operation | Trigger | Route |
|---|---|---|
| Create | "create/new band/profile" | `references/create-profile.md` + `references/profile-schema.md` |
| Edit | "edit/update/modify [name]" | `references/edit-profile.md` + `references/profile-schema.md` |
| Health Check | "check/review my profile" | `references/health-and-voice.md` |
| Analyze Voice | "analyze voice/writing", gives samples | `references/health-and-voice.md` |
| Manage Playlist | "add a track", "playlist for [name]" | `references/playlist-yaml.md` |
| List, Load, Delete, Duplicate | "list/show bands", "load/view [name]", "delete/remove [name]", "clone/duplicate [name]", "same as [name] but…" | below |
| Unclear | — | Present the operations and ask |
| Wrong skill | "make a song", "create music" | Invoke the `suno-style-prompt-builder` or `suno-lyric-transformer` skill |
## Operations
**List.** Run `scripts/list-profiles.py`. If there are none, suggest creating one. Name any `skipped` files with their reason, so a broken profile isn't mistaken for a missing one.
**Load.** Show `scripts/apply-profile.py {slug} --load` grouped by section, with `scripts/validate-profile.py {slug}` run alongside without blocking the display. Mention stale findings gently (a deprecated `playlist:` block, a retired model), since stale state otherwise persists because nobody looked. If the stored tier differs from `{suno_tier}` or the plan the user names, run `scripts/tier-features.py <tier>` and offer the field changes `references/profile-schema.md`'s Tier gates imply.
**Delete.** Run `scripts/apply-profile.py {slug} --delete` first: it changes nothing and lists what would go (profile, decision log, any draft, the band's playlist YAML). Show that list with a short profile summary and get explicit confirmation, since these are the owner's records; then rerun with `--confirm`. The files are archived to `{band_profiles_folder}/archive/`, which keeps them recoverable and stops a future band with the same slug inheriting this log. `--purge` only when the user asks for permanent deletion. Songbook entries are left alone.
**Duplicate.** Ask for the new name, or propose `{original} v{N+1}` / `{original} {variant}`. Run `scripts/apply-profile.py {slug} --duplicate "{New Name}"` (`--bump-version` for a new version); the copy keeps every comment. Start a fresh decision log for the new slug that notes its source. If the user wants changes, continue into Edit.
## After an operation
- After any write (Create, Edit, Duplicate, Delete, a saved writer-voice analysis, Health Check appends, a playlist scaffold or edit), run `{workflow.on_complete}` if it is set.
- After Create or Edit, bridge onward: "Your profile is saved. Want to build a style prompt or write lyrics for this band?" Then audit this session's decision-log entries: each is in the profile, parked as a future idea, or explicitly set aside, so the user signs off on how their thinking was handled. Earlier sessions were audited at their own handoff.
- Then ask: "Anything else with your profiles, or are we good?"