The defining feature
Most skill collections are 31 disconnected files. This one is a system: skills can convene panels of other skills to review high-stakes work before you ship it. A senior engineer reviewing their own code finds fewer bugs than they would in someone else's. Independence matters, especially for things that hit production.
So the rule is solo by default, panel by stakes. Routine work stays solo (no extra cost). The skill itself decides when the stakes warrant pulling in reviewers.
Triggers are observable, not vibes
A skill convenes a panel based on specific conditions it can detect from its inputs:
Code review: the diff touches auth, payments, migrations, webhooks, or secrets; more than 300 lines changed; more than 3 files; or you ask for a "deep review".DB migration: target table over 1M rows; a NOT NULL added to an existing column; a dropped or renamed column; foreign-key changes.API integration: the API is financial or auth-critical; webhooks are involved; aggressive rate limits.If none of those fire, the skill works alone.
How a panel runs
1.Chair: the skill you invoked. It holds the work and runs the protocol.2.Reviewers: related skills it pulls in. A code review on a payments diff convenes the security and performance audits.3.Round: each reviewer independently reviews the current draft and returns a verdict: Approve, Block (must fix, with specifics), or Concern (advisory).4.Convergence: the chair revises and re-runs until everyone approves, or it invokes a documented escape hatch.Approval models
Different work calls for different strictness, so each panel declares one:
Unanimous block-or-approve: any Block stops the ship. Used for migrations and security-sensitive code.Chair-with-vetoes: the chair decides, but a reviewer can veto in its area of authority.Advisory: reviewers raise concerns; the chair weighs them.The full mechanics ship in collaboration-protocol.md at the pack root, with a worked example.
