본문으로 건너뛰기
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.md7.2 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

Working from a brief

Given how the band works today, write the full draft agreement anyway. Where the band must choose, show the options as decisions marked [A] or [B] with a sensible default suggested for each, and add the plan for the conversation before the studio session. Say plainly that this is a starting draft, not legal advice.

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?"

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

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.5천2026년 10월 23일 업데이트

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.5천2026년 10월 23일 업데이트

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.5천2026년 10월 23일 업데이트

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.5천2026년 10월 23일 업데이트

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.5천2026년 10월 23일 업데이트

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.5천2026년 10월 23일 업데이트

mohitagw15856의 스킬 모두 보기

이 스킬의 문제 신고