本文へ移動
cccskills
無料GitHub で公開

band-agreement

Write the band agreement before the money or the breakup arrives — who owns the songs, how money splits (writing vs performing distinguished), who owns the name, what happens when someone quits, and the decision rules for offers — decided while everyone still shares a van. Use when a band asks 'how should we split money', 'who owns our songs', 'our drummer quit, what happens', or is about to record/release/sign anything. Produces a plain-language band agreement and the meeting script to agree it. Not legal advice — it's the conversation that makes the lawyer cheap later.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md6.8 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Band Agreement Skill

Bands don't break up over creative differences — they break up over the unspoken spreadsheet: the song one person wrote but everyone arranged, the name the founder feels they own, the gig money split evenly while one member books everything, the member who quit in March and wants royalties forever. Every one of those fights is cheap to decide before there's money and impossible after. This skill runs the deciding: the questions in the right order, the standard options for each (with what each choice means down the road), and a plain-language agreement the band actually signs — plus the honest line that when real money or a real contract shows up, an hour with a music lawyer turns this document from "our deal" into "our deal, watertight."

What This Skill Produces

  • The band agreement, one-to-two pages in plain language: songs, splits, the name, spending, decisions, exits — every section a decision, not a description
  • The options menu per hard question (songwriting splits, name ownership, departed-member rights) with the honest tradeoffs of each standard choice
  • A band-meeting script: raising this without it feeling like a prenup ("it IS a prenup — that's why we're doing it now, while it's easy"), and the order that keeps the meeting friendly
  • The decision & spending rules: what needs everyone, what the bookings-person just decides, the band-fund basics
  • Lawyer-trigger flags: the events that upgrade this from document to legal matter (label interest, publishing deal, real recording budget, a member with a manager)

Required Inputs

Ask for (if not already provided):

  • The band: members, roles (who writes? who books? who fronts money?), how long together, what's released already
  • The current reality of songs: who's been writing, how arrangements happen, anything already registered anywhere
  • Money so far: gig fees, who's owed for gear/van/recording fronted
  • Any storm clouds already visible (the member half-out, the founder possessive of the name) — the agreement is written toward the real band, not the ideal one

Framework

  1. Songs first — writing and recording are different rights. The options, plainly: pure writer-split (whoever wrote it owns it) · band-split-everything (all songs equal, all members) · the common hybrid (writers keep the song; the band's recording of it is everyone's). Each has a future: pure-writer gets awkward when the bassist's riff made the song; band-split gets awkward when one person writes everything. Decide per-band, write it down, and note that registrations/collection societies formalize it later — flag, not asserted procedure.
  2. Money: distinguish the streams. Gig money (usually equal, minus the band fund) · recording income (follows the songs decision) · merch (band fund or equal) · the band fund itself: what goes in (a % of everything), what it pays (van, recording, the fronted gear debts — logged and repaid first), who can spend to what limit.
  3. The name. The fight nobody expects: options — the band owns it (majority of current members keep it if someone leaves) · the founder owns it (stated now, honestly) · nobody continues it without unanimous consent. Whichever, write the leaving-case explicitly.
  4. Exits, quit vs fired vs the band ends. The departed member's rights to: past recordings (usually keeps their share — they played on it), future income from old songs (follows the songs decision), the name (per #3), gear and the fund (bought-out how?). The 30-second version everyone can live with beats the perfect version nobody discusses.
  5. Decisions and offers. What needs everyone (signing anything, spending over £X, adding/removing members) vs what the doer decides (the bookings person confirms gigs inside agreed terms). And the offer rule: no member negotiates for the band alone; offers come to the group with 48 hours to read.
  6. The lawyer line, stated warmly. This document is the band's real agreement and worth signing as-is — AND the moment a label, publisher, real budget, or manager appears, it goes to a music lawyer to be made formal. Both halves true; the second is a flag this skill always raises and never fakes.

Output Format

## The [band name] agreement — v1, [date]
[Six sections, each a plain-language decision · signature-ish lines]

## The options you chose from (kept for the record)
[Per hard question: the menu + why this band picked what it picked]

## The meeting script
[The prenup-joke opener · question order · handling the possessive
founder / half-out member kindly]

## When this goes to a lawyer
[The trigger list — label/publishing/budget/manager — verify-local flag
on registrations and societies]

Quality Checks

  • Writing and recording rights are decided separately and explicitly
  • The name section answers the leaving-case by name
  • Fronted money (gear, van, recording) is logged with a repayment rule
  • Every section is a decision — zero "the band will discuss" placeholders
  • The not-legal-advice line and the lawyer triggers are present; society/registration mechanics are flagged, not asserted

Anti-Patterns

  • Do not default everything to equal-split without showing what equal costs the writers (or writer-split costs the arrangers) — informed beats harmonious-for-now
  • Do not write the founder's name-ownership in by assumption — it's the menu's most contested item; make it explicit either way
  • Do not let the agreement pretend the half-out member is all-in; write toward reality
  • Do not draft legalese — plain language the drummer reads beats clauses nobody does
  • Do not skip it because "we're friends" — the document is friendship insurance, and the meeting script says exactly that

Related

[[release-day-countdown]] for when the songs this protects go out; [[press-kit-epk]] for the band's outward face; [[roommate-agreement]] — same move, different shared dream; [[first-client-contract]] energy for solo artists dealing with venues.

Example Trigger Phrases

  • "How should we split money?"
  • "Who owns our songs?"
  • "Our drummer quit."
  • "What happens?"

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

Build or tailor an academic CV for faculty, postdoc, research or fellowship applications: publications, grants, teaching, supervision and service in the order the field expects, with consistent citations. Use when asked to write my academic CV, update my CV for a lectureship, tenure-track or postdoc application, format my publications list, or adapt my academic CV for an industry research role. Produces the full academic CV, a field-appropriate section order, a clean publications list in one citation style, and a two-page summary version when asked.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

mohitagw15856 のスキルをすべて見る

このスキルの問題を報告する