fix(skills): add proposer/executor roles for planning team spawns

Sprint 27 planning session exposed that discussion agents (Ozzie) can
unilaterally write decisions and modify the DB before consensus is
reached. Add step 8d-planning to /sprint-start that classifies agents
as proposers (analyze only) or executors (SI, Qatux — wait for
consensus). Also add planning to valid team branches.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

.claude/skills/sprint-start/SKILL.md

@@ -25,7 +25,8 @@ The current branch IS the team. Read it with:
 git branch --show-current
 ```
 
-Valid team branches: `server`, `client`, `copy`, `audio`, `visual`, `ci`.
+Valid team branches: `server`, `client`, `copy`, `audio`, `visual`, `ci`,
+`planning`.
 
 If on `main`, follow the **Main branch workflow** below instead of
 the team branch workflow (steps 2–8).
@@ -399,6 +400,68 @@ Task(
 )
 ```
 
+#### 8d-planning. Planning team variant — proposers vs executors
+
+When the team is `planning`, agents work in discussion mode, not
+implementation mode. The briefing typically defines discussion rounds
+(propose → review → execute). Most agents are **proposers** — they
+analyze and recommend. Only designated agents **execute** (write to
+files, modify DB).
+
+**Classify agents from the briefing:**
+- **Executor agents:** SI (project manager), Qatux (documenter).
+  These agents wait for consensus before writing anything.
+- **Proposer agents:** Everyone else (Gestalt, Tyre, Paula, Ozzie,
+  etc.). These agents analyze, propose, and discuss — they do NOT
+  write decision files, modify the DB, or create/delete tickets.
+
+**Add this block to proposer agent prompts** (replaces rules 3–5
+and the WORKFLOW section from the standard template):
+
+```
+    PLANNING TEAM RULES (replace standard rules 3-7 and WORKFLOW):
+
+    3. PROPOSE ONLY: You are a discussion participant. Your job is
+       to ANALYZE tickets, PROPOSE team assignments, and RECOMMEND
+       splits. You do NOT:
+       - Write or modify decision files (decisions/*.md)
+       - Run DB update/insert/delete commands
+       - Create, delete, or modify tickets
+       - Mark tasks as completed
+       Those actions belong to executor agents (SI, Qatux) after
+       the team lead confirms consensus.
+
+    4. OUTPUT FORMAT: Send your analysis to the team lead via
+       SendMessage. Structure it as:
+       - Your position on open questions (with rationale)
+       - Proposed team assignments (table format)
+       - Split candidates (if any)
+       - Sprint readiness assessment
+       Do NOT claim or work tasks. The team lead coordinates.
+
+    5. WAIT FOR CONSENSUS: Do not treat your own proposal as
+       decided. Other agents may disagree. The team lead calls
+       consensus and directs executors to implement it.
+```
+
+**Add this block to executor agent prompts** (appended after the
+standard rules):
+
+```
+    PLANNING TEAM RULES (additional):
+
+    8. WAIT FOR CONSENSUS: Do NOT execute DB changes, write
+       decision files, or create tickets until the team lead
+       explicitly tells you to. Your first message should confirm
+       you are ready and describe your execution plan. Then wait.
+
+    9. EXECUTE EXACTLY WHAT IS DIRECTED: When the team lead sends
+       you a list of changes, execute them precisely. Do not add
+       extra changes, reinterpret the instructions, or fill gaps
+       with your own judgment. If something is ambiguous, ask
+       before executing.
+```
+
 #### 8e. Report
 
 Output to the user: