plasminds/team-skills

Agent-team skills for Claude Code. Instead of one model giving one opinion, these skills dispatch a team of agents, each in its own isolated context. The agents debate with evidence, a gate kills speculative work, and you, the CEO, make the final call on a local HTML decision page. A review can be handed on from there: the owner of the branch you reviewed gets a page to decide on alone.
## The skills
| Skill | What it does |
| team-scan | Project → .council/project-profile.md (stack, conventions, tools, expected load, limits). Read by every skill. |
| team-council | Decision before code. PO, CTO, UX, Philosopher, Wildcard debate; PO synthesis; decision recorded. |
| team-council-plan | Decision → implementation plan, reviewed by CTO, PO, UX. |
| team-kickoff | New project: vision → scan → council → brief, profile, CLAUDE.md. |
| team-refactor | Structure review by 5 blind lenses, Minimalist gate. One behavior-preserving step per commit, behind characterization tests. |
| team-review | Diff or module review by 4 blind lenses; a Verifier refutes each finding. Output: a forge review or test-first fixes. |
| team-ceo-view | Gate → one HTML page: a three-pane console: the list of cards with rails for what refines or follows what, the current card (arguments tagged Biz or Tech, your choice), and its evidence (trade-offs, numbers, diff, how each fix gets done, figures after diagram-design); what agents settled alone, reopenable. Send to Claude returns your answers; Share (reviews) hands the gate to the branch owner. |
| team-protocol | Shared rules every skill loads: dispatch, agent contract, bridge, scope, handoff, execution. |
## Which skill?
| Skill | Question | When |
| team-council | Which way do we go? | Before the code exists |
| team-council-plan | How do we carry out the decision? | After a council decision, before the code |
| team-refactor | Is this code shaped for the next change? | Code exists; fixes preserve behavior |
| team-review | Can this change merge as is? | Code exists; fixes change behavior |
The fix decides the lane (the full rule). A fix that changes behavior (a bug, a hole, a swallowed error, a missing test for new or changed behavior, a gap with the request, a slow path) is team-review's; a named, behavior-preserving refactoring, and the characterization tests that pin unchanged behavior before it, are team-refactor's. Each skill hunts only in its lane; what an agent stumbles on in the other one goes to a short hand-off list (For team-review, For team-refactor), unverified and without a decision, and the other skill takes the list in from the record: /team-review sends a refactor's suspected bugs straight to the verifier, and /team-refactor refactors what a review flagged. To review and refactor a whole branch, ask for a sweep: every zone is reviewed, and only the zones a review flags are refactored.
## How they fit together
Everything a run produces is plain Markdown in your project, under .council/ except the plan, so it can be committed and diffed:
.council/
├── project-profile.md # team-scan
├── decisions/YYYY-MM-DD-.md # team-council; team-kickoff's project brief