본문으로 건너뛰기
cccskills
무료GitHub에 공개

collaboration-contract

Start a cross-team project with the collaboration contract that prevents the classic collisions — who decides what, how work flows between teams, the communication channels and cadence, and what done means — agreed before the first collision instead of during it. Use when asked kick off this cross-team project right, our two teams keep colliding, define how we'll work with the other team, or set up the partnership before we start. Produces the one-page contract: decision rights, interfaces, cadence, and the done-definition.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md5.8 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Collaboration Contract Skill

Cross-team projects fail at the seams: each team runs on its own invisible rules (working-agreements are per-team; the seam has none), decision rights are assumed differently ("we thought design signed off; they thought we did"), and handoffs bounce because "done" meant different things. The collaboration contract is the seam's rulebook, one page, agreed at kickoff while everyone still likes each other: who decides what (the decision-rights table), how work crosses the boundary (the interface), how the teams talk (channel + cadence), and what done means per handoff — cheap to write on day one, expensive to reverse-engineer during the first fight.

What This Skill Produces

  • The decision-rights table — the project's likely decisions × who decides / who's consulted, the ambiguous ones forced now
  • The interface spec — how work moves between teams: the handoff format, the request path, the done-definition per handoff type
  • The communication layer — the shared channel, the sync cadence (as light as the project allows), the escalation path with names
  • The friction protocol — what happens at the first collision: the two-lead conversation before anything ascends

Required Inputs

Ask for these if not provided:

  • The project and the teams — what's being built/done, which teams, their prior history (a scarred partnership needs the contract more and trusts it less — the tone adjusts)
  • The likely decisions — the calls this project will force (scope, priority conflicts, quality bars, launch timing); the table pre-decides the deciders, and the awkward ones ("who wins when priorities conflict?") are exactly the ones to force now
  • The handoff shapes — what actually crosses the seam (designs → build? data → analysis? approvals?); each shape gets its done-definition
  • The leads — the two humans who own the seam; the contract is theirs to sign and theirs to enforce

Framework: The Contract Rules

  1. Force the ambiguous decisions now: the table lists the project's foreseeable calls with a decider each — and the ones both teams assume they own are the ones the kickoff must settle ("tie-breaks on priority: [name]"). Every ambiguity left standing is a scheduled fight with interest.
  2. Interfaces are formats plus done-definitions: each handoff type gets its shape ("designs arrive as [format] with states covered; 'done' = the checklist passes") — because bounced handoffs are almost always definition mismatches, not quality failures. The runbook-writer verify-per-step logic, applied to seams.
  3. Cadence as light as survivable: one shared channel, one short sync at the necessary frequency (not the reassuring one — meeting-cost-meter math doubles across two teams), and the asks flowing per async-update-format shapes between syncs. The contract names it all so nobody invents parallel channels in week two.
  4. The friction protocol de-escalates by design: first collision → the two leads talk within 48h, before either escalates upward ("no surprising each other's managers" is the clause that saves partnerships) → unresolved after a real attempt → the named tie-breaker. Written while calm, the protocol converts the first fight from a relationship event into a process event.
  5. The contract is one page and revisited once: kickoff-signed, then reviewed at the first milestone ("which clause did we violate? fix it or change it" — the working-agreements revisit logic) — a living page, not a treaty. Longer contracts don't get read; unrevisited ones drift into fiction exactly when needed.

Output Format

Collaboration Contract: [project] — [team A] × [team B]

Decision Rights

DecisionDecidesConsultedNotes
[The forced-ambiguity rows marked ✓ settled]

Interfaces

[Per handoff type: format · done-definition · the request path]

Communication

[The channel · the sync (cadence + length) · between-syncs format · escalation names]

Friction Protocol

[48h two-lead talk first · no-surprise-escalation clause · the tie-breaker · milestone review date]

Quality Checks

  • The both-teams-assume-they-own decisions were forced and settled
  • Every handoff type carries a done-definition
  • The cadence is justified by need, not reassurance
  • The no-surprise-escalation clause is explicit with the 48h talk first
  • The milestone review is dated

Anti-Patterns

  • Do not skip the contract because the teams get along — the contract is why they'll keep getting along
  • Do not leave "who wins priority conflicts" unassigned — that's the fight, pre-scheduled
  • Do not accept vibe-based done — bounced handoffs are definition gaps wearing quality-complaint costumes
  • Do not escalate surprises — the 48h clause is the partnership's real load-bearing wall
  • Do not write three pages — one page gets signed and remembered; three get filed and violated

Example Trigger Phrases

  • "Kick off this cross-team project right."
  • "Our two teams keep colliding."
  • "Define how we'll work with the other team."
  • "Set up the partnership before we start."

리뷰

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

댓글

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

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

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. 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월 21일 업데이트

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월 21일 업데이트

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월 21일 업데이트

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월 21일 업데이트

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월 21일 업데이트

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월 21일 업데이트

mohitagw15856의 스킬 모두 보기

이 스킬의 문제 신고