@drunkcoding/agents-and-skills 0.0.24 → 0.0.25

package/.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "tech-graph",
       "source": "./plugins/tech-graph",
       "description": "6-step wizard for technical diagrams (SVG/PNG) via fireworks-tech-graph",
-      "version": "0.0.24",
+      "version": "0.0.25",
       "category": "diagram",
       "keywords": [
         "diagram",
@@ -26,7 +26,7 @@
       "name": "html-effectiveness",
       "source": "./plugins/html-effectiveness",
       "description": "Generate self-contained interactive HTML reports from 20 upstream templates via a conversational agent.",
-      "version": "0.0.24",
+      "version": "0.0.25",
       "category": "reports",
       "keywords": [
         "html",
@@ -41,7 +41,7 @@
       "name": "team-superpower",
       "source": "./plugins/team-superpower",
       "description": "Shape-adaptive engineering team that runs the Superpowers skill chain across up to 8 roles — designer, planner, software-architect, security-engineer, backend-developer, frontend-developer, qa-engineer, reviewer — driven by a `team-superpower` block in CLAUDE.md. Spawns 7 or 8 roles depending on stack (full-stack / be-only / fe-only), enforces contract sync between BE and FE, and gates the finish branch on CI green.",
-      "version": "0.0.24",
+      "version": "0.0.25",
       "category": "workflow",
       "keywords": [
         "agent-teams",
@@ -60,7 +60,7 @@
       "name": "plugin-validator",
       "source": "./plugins/plugin-validator",
       "description": "Orchestrated validator for Claude Code plugins — validates skills, agents, commands, and hooks across every plugin under plugins/**.",
-      "version": "0.0.24",
+      "version": "0.0.25",
       "category": "tooling",
       "keywords": [
         "validation",
@@ -76,7 +76,7 @@
       "name": "auto-power",
       "source": "./plugins/auto-power",
       "description": "Single-command hands-off pipeline wrapping obra/superpowers. Auto-answers safe clarifying questions during spec, then runs plan → arch+sec → impl → verify → review → ff-merge with no further touchpoints. Checkpointed and resumable; escalates only on substantive failures.",
-      "version": "0.0.24",
+      "version": "0.0.25",
       "category": "workflow",
       "keywords": [
         "superpowers",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@drunkcoding/agents-and-skills",
-  "version": "0.0.24",
+  "version": "0.0.25",
   "description": "Personal collection of Claude Code skills and agents, installable via `npx skills`.",
   "keywords": [
     "claude-code",

package/plugins/auto-power/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "auto-power",
   "displayName": "Auto Power",
-  "version": "0.0.24",
+  "version": "0.0.25",
   "description": "Single-command, hands-off pipeline that wraps obra/superpowers: auto-answers safe clarifying questions during spec, then runs plan → arch+sec → impl → verify → review → ff-merge with no further touchpoints. Checkpointed and resumable; escalates only on substantive failures (security, architecture, repeated QA fail, semantic conflict).",
   "author": {
     "name": "Steven Hoang"

package/plugins/html-effectiveness/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "html-effectiveness",
   "displayName": "HTML Effectiveness Reports",
-  "version": "0.0.24",
+  "version": "0.0.25",
   "description": "Generate self-contained interactive HTML reports from 20 upstream templates via a conversational agent.",
   "author": {
     "name": "Steven Hoang"

package/plugins/plugin-validator/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "plugin-validator",
   "displayName": "Plugin Validator",
-  "version": "0.0.24",
+  "version": "0.0.25",
   "description": "Orchestrated validator for Claude Code plugins — validates skills, agents, commands, and hooks across every plugin under plugins/**.",
   "author": {
     "name": "Steven Hoang"

package/plugins/team-superpower/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "team-superpower",
   "displayName": "Team Superpower",
-  "version": "0.0.24",
+  "version": "0.0.25",
   "description": "Shape-adaptive coordination layer that runs the obra/superpowers skill chain across a Claude Code agent team — one /team-feature command takes an idea through design, plan, pre-impl architecture+security gate, BE/FE implementation, QA gate, code review, CI gate, and finish with at most 3 owner touchpoints. Stack (full-stack / be-only / fe-only), test/build commands, contract sync between BE and FE, security checklist, and CI required checks are driven by a `team-superpower` block in the repo's CLAUDE.md.",
   "author": {
     "name": "Steven Hoang"

package/plugins/team-superpower/README.md

@@ -9,11 +9,11 @@ This plugin is *not* a fork of Superpowers. It consumes Superpowers skills
 as-installed and adds the orchestration: who runs which skill, when, and how
 teammates talk without bothering the owner.
 
-## Overview (v5)
+## Overview (v6)
 
 team-superpower runs **one Agent Teams team** per feature across all phases.
-The lead (orchestrator) is the sole spawner; a coordinating teammate
-(team-leader) requests spawns via `SPAWN_REQUEST`.
+The main session is the sole spawner; a coordinating teammate (team-leader)
+requests spawns via `SPAWN_REQUEST`.
 
 **Modes:**
 
@@ -52,13 +52,14 @@ security-engineer is only spawned when `security.domain ∈
 - Two slash commands: `/team-feature` and `/team-cleanup`. There is **no
   separate resume command in v5** — `/team-feature` auto-detects in-progress
   features.
-- **Eight agent roles**, each with a tightly-scoped system prompt:
+- **Seven agent roles** (v6 — the main session itself runs the lifecycle),
+  each with a tightly-scoped system prompt:
 
 ## Agents
 
 | Agent | Lifetime | Role |
 |---|---|---|
-| `orchestrator` | Whole feature | Lead session; sole spawner; SPAWN_REQUEST + RESTART_REQUEST handler; cleanup + push. |
+| _main session_ (the `/team-feature` invocation itself) | Whole feature | Sole spawner; mode pick, TeamCreate, SPAWN_REQUEST + RESTART_REQUEST handler, cleanup + push. |
 | `solution-architect` | Phase A only | Spec + arch-map. |
 | `feature-planner` | Phase A only | Plan (plan-phase grouped, waves). |
 | `security-engineer` | Phase A only (regulated domains only) | Regulatory + threat-model review. |
@@ -89,10 +90,10 @@ security-engineer is only spawned when `security.domain ∈
   - **Heartbeat file** at `docs/superpowers/sessions/<slug>.heartbeat` —
     touched at every phase boundary; cleanup refuses to wipe state while the
     heartbeat is fresh.
-  - **Automatic cleanup after `FINISH_DONE`** — the lead verifies all phases
-    complete, all commits in place, teammates idle, then runs the canonical
-    "clean up the team" primitive followed by a verification scan.
-  - **`/team-cleanup [slug]`** for the case where a previous lead crashed.
+  - **Automatic cleanup after `FINISH_DONE`** — the main session verifies all
+    phases complete, all commits in place, teammates idle, then runs the
+    canonical "clean up the team" primitive followed by a verification scan.
+  - **`/team-cleanup [slug]`** for the case where a previous main session crashed.
 - Templates seeded into your project on first use:
   `docs/superpowers/ESCALATION.md` (template + three worked examples),
   `docs/superpowers/README.md` (onboarding + troubleshooting), and
@@ -105,7 +106,7 @@ security-engineer is only spawned when `security.domain ∈
 | A — Analysis | `solution-architect` + `feature-planner` [+ `security-engineer`] | Spec, arch-map, plan, handover | Spec sign-off + plan approval (2 touchpoints) |
 | B–F — Implementation (one per plan-phase) | `team-leader` + `backend-developer` / `frontend-developer` | TDD commits per wave + phase-end leader review | `PHASE_COMPLETE` per plan-phase |
 | G — End-of-plan QC | `qc-engineer` | `<date>-<slug>-qc-report.md` | `QC_PASS` (max 3 rework rounds) |
-| H — Finish | `orchestrator` | Push + merge/PR/keep/discard | Owner decision (finish touchpoint) |
+| H — Finish | _main session_ | Push + merge/PR/keep/discard | Owner decision (finish touchpoint) |
 
 ## Requirements
 
@@ -220,7 +221,6 @@ plugins/team-superpower/
 ├── .claude-plugin/plugin.json
 ├── README.md
 ├── agents/
-│   ├── orchestrator.md
 │   ├── solution-architect.md
 │   ├── feature-planner.md
 │   ├── security-engineer.md
@@ -229,7 +229,7 @@ plugins/team-superpower/
 │   ├── frontend-developer.md
 │   └── qc-engineer.md
 ├── commands/
-│   ├── team-feature.md          # v5 single-team lifecycle + auto-resume
+│   ├── team-feature.md          # v6 single-session lifecycle + auto-resume
 │   └── team-cleanup.md
 ├── hooks/
 │   ├── hooks.json
@@ -259,7 +259,7 @@ owner. Every clarification is classified into one of three classes —
   reply → log + proceed; no consensus → escalate citing attempts.
 - **Architectural** — implementers send `ESCALATE class=architectural` to
   team-leader. If team-leader cannot resolve from arch-map, team-leader posts
-  `RESTART_REQUEST` to the orchestrator (recovery touchpoint, not counted
+  `RESTART_REQUEST` to the main session (recovery touchpoint, not counted
   against the 3-budget).
 
 Per-role rubrics live in each agent file under `agents/<role>.md`.

package/plugins/team-superpower/agents/backend-developer.md

@@ -29,7 +29,7 @@ Before claiming your first task — and on every resume — read the repo-root `
 
 Also read the free-form prose in CLAUDE.md (sections after the YAML block, e.g. `## Conventions`). Style rules, naming, and "we don't do X here" guidance live there. Apply them.
 
-If `CLAUDE.md` has no `team-superpower` block, halt and escalate to team-leader (see §Escalation). The orchestrator's phase 0 should have already produced `docs/superpowers/stack.detected.md` — work from that if so, otherwise escalate.
+If `CLAUDE.md` has no `team-superpower` block, halt and escalate to team-leader (see §Escalation). The main session's phase 0 should have already produced `docs/superpowers/stack.detected.md` — work from that if so, otherwise escalate.
 
 ## First-turn directive
 
@@ -46,7 +46,7 @@ If `model_actual` does not match the pinned alias `sonnet`, surface the mismatch
 
 ## Wave lifecycle (v5)
 
-Every task you claim carries a `wave:` line (e.g. `wave: 1.1`, `wave: 1.rework`, `wave: qc-rework`). team-leader composes the brief; the orchestrator TaskCreates from it.
+Every task you claim carries a `wave:` line (e.g. `wave: 1.1`, `wave: 1.rework`, `wave: qc-rework`). team-leader composes the brief; the main session TaskCreates from it.
 
 1. **At claim:** self-claim the next unclaimed unblocked task whose `Files:` set fits your backend scope. Read `wave:` from the task body. Log it on the first line of your work for the task (`"wave_claim: be-instance-N, task=<id>, wave=<W>"`) so team-leader can correlate parallel implementer instances.
 2. **Self-collision check before writing code:** look at every other in-progress backend task in the same wave (visible in the shared task list). If any of those tasks' `Files:` metadata overlaps with yours, HALT before writing. SendMessage team-leader: `WAVE_COLLISION wave=<W> tasks=[<your-task>, <other-task>] shared_files=[<overlap>]` and stop. team-leader will post `RESTART_REQUEST` if the collision cannot be resolved.

package/plugins/team-superpower/agents/frontend-developer.md

@@ -30,7 +30,7 @@ Before claiming your first task — and on every resume — read the repo-root `
 
 Also read the free-form prose in CLAUDE.md (`## Conventions`, project context). Apply those rules.
 
-If `CLAUDE.md` has no `team-superpower` block, halt and escalate to team-leader (see §Escalation). The orchestrator's phase 0 should have already produced `docs/superpowers/stack.detected.md` — work from that if so, otherwise escalate.
+If `CLAUDE.md` has no `team-superpower` block, halt and escalate to team-leader (see §Escalation). The main session's phase 0 should have already produced `docs/superpowers/stack.detected.md` — work from that if so, otherwise escalate.
 
 ### UI library rules
 
@@ -59,7 +59,7 @@ If `model_actual` does not match the pinned alias `sonnet`, surface the mismatch
 
 ## Wave lifecycle (v5)
 
-Every task you claim carries a `wave:` line (e.g. `wave: 1.1`, `wave: 1.rework`, `wave: qc-rework`). team-leader composes the brief; the orchestrator TaskCreates from it.
+Every task you claim carries a `wave:` line (e.g. `wave: 1.1`, `wave: 1.rework`, `wave: qc-rework`). team-leader composes the brief; the main session TaskCreates from it.
 
 1. **At claim:** self-claim the next unclaimed unblocked task whose `Files:` set fits your frontend scope. Read `wave:` from the task body. Log it on the first line of your work for the task (`"wave_claim: fe-instance-N, task=<id>, wave=<W>"`) so team-leader can correlate parallel implementer instances.
 2. **Self-collision check before writing code:** look at every other in-progress frontend task in the same wave (visible in the shared task list). If any of those tasks' `Files:` metadata overlaps with yours, HALT before writing. SendMessage team-leader: `WAVE_COLLISION wave=<W> tasks=[<your-task>, <other-task>] shared_files=[<overlap>]` and stop. team-leader will post `RESTART_REQUEST` if the collision cannot be resolved.

package/plugins/team-superpower/agents/qc-engineer.md

@@ -54,24 +54,24 @@ Write `docs/superpowers/reviews/YYYY-MM-DD-<slug>-qc-report.md` per spec §7.2 t
 ## Flagged assumptions
 - [✓] Assumption "RBAC uses Admin role" verified against ADR-0017.
 
-## Issues for orchestrator
+## Issues for main session
 <one block per blocking issue>
 ```
 
 ## On blocking issues (spec §7.3)
 
 1. For each blocking issue, TaskCreate with prefix `impl:rework-qc-<topic>` and body: violation desc + remediation guidance. Include `wave: qc-rework` and `Reworks: qc-issue-<n>` lines for hooks.
-2. Post `QC_REWORK_NEEDED <task-count>` to lead. Lead re-spawns team-leader to dispatch.
-3. Approve shutdown when lead requests it. You will be re-spawned after rework for a re-check.
+2. Post `QC_REWORK_NEEDED <task-count>` to main session (`to: main`). Main session re-spawns team-leader to dispatch.
+3. Approve shutdown when the main session requests it. You will be re-spawned after rework for a re-check.
 
 ## On pass
 
-1. Post `QC_PASS <slug>` to lead.
-2. Approve shutdown when lead requests it.
+1. Post `QC_PASS <slug>` to main session (`to: main`).
+2. Approve shutdown when the main session requests it.
 
 ## Round cap
 
-Max 3 QC rounds per feature (lead enforces). 4th round → owner escalation.
+Max 3 QC rounds per feature (main session enforces). 4th round → owner escalation.
 
 ## Also write AGENTS.suggestions.md
 

package/plugins/team-superpower/agents/team-leader.md

@@ -1,13 +1,13 @@
 ---
 name: team-leader
-description: "Use when phases B–F are active. Phase B–F coordinator teammate. Composes spawn briefs and posts SPAWN_REQUEST to lead. Runs phase-end SOLID/DRY/domain review. Cannot spawn teammates."
+description: "Use when phases B–F are active. Phase B–F coordinator teammate. Composes spawn briefs and posts SPAWN_REQUEST to the main session. Runs phase-end SOLID/DRY/domain review. Cannot spawn teammates."
 tools: Read, Write, Bash, Glob, Grep, mcp__gitnexus__impact, mcp__gitnexus__query, mcp__gitnexus__context, mcp__gitnexus__detect_changes
 model: opus
 ---
 
 # Team Leader (team-superpower v5)
 
-You are the team leader for implementation phases B–F. You are a **coordinating teammate**. You **CANNOT spawn teammates** — only the lead can (platform rule: "no nested teams"). You request spawns via `SPAWN_REQUEST` messages to the lead.
+You are the team leader for implementation phases B–F. You are a **coordinating teammate**. You **CANNOT spawn teammates** — only the main session can (platform rule: "no nested teams"). You request spawns via `SPAWN_REQUEST` messages to the main session.
 
 Set effort high at start of first turn: `/effort high` and report `effort_set: high`.
 
@@ -36,7 +36,7 @@ For each wave in the plan-phase:
    - `retrieval_budget: 2`
    - `Goal: <plain language>`
    - `Verification: <test command + expected outcome>`
-3. Post to lead:
+3. Post to main session (`SendMessage to: main`):
 
    ```
    SPAWN_REQUEST wave=<plan-phase>.<wave>
@@ -57,7 +57,7 @@ When an implementer SendMessages you `ESCALATE <task-id> class=... question=...
 
 - `class=tactical` (style, naming, local design): answer from arch-map + AGENTS.md. SendMessage the implementer with your answer.
 - `class=cross-role` (affects another implementer): SendMessage the affected peer with the context and a proposed coordination point.
-- `class=architectural` (changes arch-map / requires planner judgment / invalidates wave plan): post `RESTART_REQUEST <reason+task-id>` to lead. Do NOT attempt to reanswer. Do NOT downgrade legitimate architectural questions to tactical.
+- `class=architectural` (changes arch-map / requires planner judgment / invalidates wave plan): post `RESTART_REQUEST <reason+task-id>` to main session (`to: main`). Do NOT attempt to reanswer. Do NOT downgrade legitimate architectural questions to tactical.
 
 You MAY downgrade an over-eager `class=architectural` to tactical when the question is genuinely style/naming dressed up as architecture. Reply to implementer and proceed.
 
@@ -76,19 +76,19 @@ When the last wave's expected_tasks all complete:
 6. Monitor rework tasks.
 7. If a rework reveals an architectural issue: post `RESTART_REQUEST` instead of accepting the rework.
 8. Write phase-end review summary to `docs/superpowers/reviews/YYYY-MM-DD-<slug>-phase-<N>-leader-review.md`.
-9. Post `PHASE_COMPLETE <N>` to lead.
+9. Post `PHASE_COMPLETE <N>` to main session (`to: main`).
 
 ### 4. Plan completion
 
 After last plan-phase posts `PHASE_COMPLETE`:
 
 1. Shut down all implementers (SendMessage shutdown request to each, await approval).
-2. Post `PLAN_COMPLETE` to lead.
-3. Approve your own shutdown when lead requests it.
+2. Post `PLAN_COMPLETE` to main session (`to: main`).
+3. Approve your own shutdown when the main session requests it.
 
 ## Cannot
 
-- Spawn teammates (lead-only).
+- Spawn teammates (main-session-only).
 - Rewrite the plan (planner was disbanded; re-plan = RESTART_REQUEST).
 - Run TDD work yourself.
 - Verify lint/format/typecheck per task (implementer self-enforces; hook validates).

package/plugins/team-superpower/assets/ESCALATION.md

@@ -11,7 +11,7 @@ v5 replaces v4's peer mailbox + multi-class escalation gauntlet with a single ro
 | solution-architect / feature-planner (phase A)  | SendMessage **lead**                   | Touchpoint output is owner-facing; lead presents to owner.                                               |
 | qc-engineer (phase G)                           | SendMessage **lead**                   | `QC_REWORK_NEEDED <n>` or `QC_PASS <slug>`. Lead re-spawns team-leader for rework dispatch.              |
 | team-leader (phase B–F coordinator)             | SendMessage **lead** (`SPAWN_REQUEST` / `RESTART_REQUEST`) | Wave dispatch needs implementers; architectural escalation can't be resolved without owner touchpoint.   |
-| lead (orchestrator)                             | Owner touchpoint                       | Touchpoints 1–4 per spec §3.5 plus recovery touchpoints triggered by RESTART_REQUEST or 3+ QC rounds.    |
+| main session                                    | Owner touchpoint                       | Touchpoints 1–4 per spec §3.5 plus recovery touchpoints triggered by RESTART_REQUEST or 3+ QC rounds.    |
 
 ## Implementer → team-leader template (spec §6.4)
 

package/plugins/team-superpower/assets/SESSION_README.md

@@ -297,7 +297,6 @@ bash plugins/team-superpower/scripts/team-state.sh members <slug>
 | `BLOCKED_IDLE_team-leader_owes_implementer_escalate_reply` | An implementer sent ESCALATE that team-leader hasn't routed | Route it (tactical/cross-role/architectural) or escalate to owner |
 | `BLOCKED_IDLE_qc-engineer_awaiting_lead_ack` | qc-engineer posted QC_REWORK_NEEDED and lead hasn't replied | Lead acknowledges, files `impl:rework-*` via team-leader |
 | `BLOCKED_IDLE_phaseA_awaiting_owner_signoff` | analytics team sent HANDOVER_READY / SEC_PASSED / SEC_BLOCKED with no reply | Owner reviews and replies |
-| `BLOCKED_IDLE_orchestrator_unhandled_team-leader_request` | team-leader sent something the lead hasn't acted on | Lead acts (spawn / restart / route) |
 | `bad_prefix` on a new task | Lead created a task without the `impl:`/`review:`/`meta:`/`block:` prefix | Lead's bug — fix the task title |
 | `bad_subprefix` on `impl:*` | Missing `be-` / `fe-` / `rework-` / `contract-update-` sub-prefix | Re-emit with correct prefix |
 | `INVALID_WAVE_REFERENCE` on a new task | Wave metadata missing or not in `<plan-phase>.<wave>` / `<plan-phase>.rework` / `qc-rework` shape | Fix the wave metadata before re-creating |

package/plugins/team-superpower/commands/team-feature.md

@@ -1,13 +1,15 @@
 ---
-description: Launch a Superpowers-compliant agent team (v5 single-team lifecycle) to deliver a feature end-to-end with at most 3 owner touchpoints, with automatic cleanup after the finish phase.
+description: Launch a Superpowers-compliant agent team (v6 single-session lifecycle) to deliver a feature end-to-end with at most 3 owner touchpoints, with automatic cleanup after the finish phase.
 argument-hint: <one-line feature idea>
 ---
 
-You are the **lead** of the team-superpower v5 single-team lifecycle. You do not implement; you spawn an `orchestrator` agent and pass through the owner's launch message. The orchestrator runs the full lifecycle (mode pick, TeamCreate, phase A → H, SPAWN_REQUEST handling, RESTART_REQUEST handling, qc-engineer spawn, cleanup, push).
+You are the **main session** of the team-superpower v6 single-session lifecycle. The main session owns the full lifecycle directly — no separate lead/coordinator agent is spawned. You run mode pick, TeamCreate, phase A → H, SPAWN_REQUEST handling, RESTART_REQUEST handling, qc-engineer spawn, cleanup, push. You are the **sole spawner** for the team — no teammate can spawn (platform rule: "no nested teams").
 
-> **Lead model:** run this command in an **Opus** session. The lead carries cross-phase reasoning (mode pick, escalation triage, restart approval, finish-branch recovery). Teammates are pinned via their agent frontmatter — they spawn on their pinned model regardless of the lead's model. If the lead is started on Sonnet, halt and ask the owner to relaunch on Opus.
+> **Main-session model:** run this command in an **Opus** session. The main session carries cross-phase reasoning (mode pick, escalation triage, restart approval, finish-branch recovery). Teammates are pinned via their agent frontmatter — they spawn on their pinned model regardless of the main session's model. If the main session is started on Sonnet, halt and ask the owner to relaunch on Opus.
 >
-> **Lead thinking discipline:** adaptive. Use extended (high-effort) thinking for every gate decision, SPAWN_REQUEST classification, RESTART_REQUEST approval, escalation triage, FINISH_BLOCKED recovery, worktree cleanup branching. Routine heartbeats, SendMessage forwarding, and shared-task-list status reads may be quick.
+> **Thinking discipline:** adaptive. Use extended (high-effort) thinking for every gate decision, SPAWN_REQUEST classification, RESTART_REQUEST approval, escalation triage, FINISH_BLOCKED recovery, worktree cleanup branching. Routine heartbeats, SendMessage forwarding, and shared-task-list status reads may be quick.
+
+Set effort high at the start of your first turn: `/effort xhigh` and report `effort_set: xhigh`.
 
 Owner's feature request:
 
@@ -23,43 +25,17 @@ Before doing anything else, parse override flags from the owner's request. Token
 
 If any of these flags appear, strip them from `$ARGUMENTS` and treat the remainder as the actual launch message. Record the flags used in the checkpoint field `overrides_applied:`.
 
-## Your job
-
-You are a **conductor**. Spawn the orchestrator (see `plugins/team-superpower/agents/orchestrator.md`) with the owner's launch message and forward owner replies. Do not run Superpowers skills yourself — every skill is delegated to the correct teammate by the orchestrator.
-
 ## Required prechecks (run these first, in order)
 
-0. **Lead-model self-attestation.** State which model you are running on. If not Opus, halt and instruct the owner: "Lead must be on Opus. Relaunch with `claude --model opus` and rerun `/team-feature`."
-1. Confirm Superpowers plugin is installed: `claude plugin list | grep superpowers`. If missing, halt and instruct: `/plugin install superpowers@claude-plugins-official`. Capture version (`claude plugin list --json`) — orchestrator writes it to the checkpoint.
+0. **Main-session model self-attestation.** State which model you are running on. If not Opus, halt and instruct the owner: "Main session must be on Opus. Relaunch with `claude --model opus` and rerun `/team-feature`."
+1. Confirm Superpowers plugin is installed: `claude plugin list | grep superpowers`. If missing, halt and instruct: `/plugin install superpowers@claude-plugins-official`. Capture version (`claude plugin list --json`) — write it to the checkpoint.
 2. Confirm Claude Code version `2.1.32` or later: `claude --version`. If older, halt.
 3. Confirm `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is set. If not, halt and instruct the owner to add it to `~/.claude/settings.json` under `env`.
 4. Generate a kebab-case `<slug>` from the owner's request. Use it in every artifact filename. The team MUST be named exactly `superpower-<slug>` — every cleanup primitive depends on that convention.
 5. Create directories if missing: `docs/superpowers/{sessions,specs,plans,handovers,reviews}`.
 6. Seed `docs/superpowers/ESCALATION.md` from `${CLAUDE_PLUGIN_ROOT}/assets/ESCALATION.md` if not present. Seed `docs/superpowers/README.md` from `${CLAUDE_PLUGIN_ROOT}/assets/SESSION_README.md` if missing. Commit any seeded files.
 
-## Lead behavior (v5 — single-team lifecycle)
-
-You spawn the `orchestrator` agent type to perform all in-feature work; do not act as orchestrator yourself. Pass through to the orchestrator the full owner launch message (post-flag-strip), the slug, and the recorded `overrides_applied:`.
-
-The orchestrator handles: auto-resume detection (spec §8.13), mode pick, TeamCreate, phase-A spawn, phase transitions, SPAWN_REQUEST/RESTART_REQUEST handling, qc-engineer spawn, cleanup, push. See `plugins/team-superpower/agents/orchestrator.md` for full responsibilities.
-
-In team mode the orchestrator runs the single-team lifecycle (spec §3.1):
-
-1. `TeamCreate(superpower-<slug>)`.
-2. Spawn solution-architect + feature-planner (+ security-engineer if regulated).
-3. Phase A: spec sign-off → arch-map → plan approval → handover.
-4. Shut down solution-architect + feature-planner + security-engineer.
-5. Spawn team-leader.
-6. team-leader posts `SPAWN_REQUEST` per wave; orchestrator spawns implementers.
-7. Per plan-phase end: team-leader posts `PHASE_COMPLETE`; orchestrator acks.
-8. Final plan-phase: team-leader posts `PLAN_COMPLETE`; orchestrator shuts down the dev team.
-9. Spawn qc-engineer.
-10. qc-engineer posts `QC_PASS` or `QC_REWORK_NEEDED` (max `limits.max_qc_rounds`, default 3).
-11. On pass: push + cleanup + notify owner.
-
-There is **no architect standby**. Architecturally significant questions during phases B–F trigger `RESTART_REQUEST`, which presents a recovery touchpoint to the owner.
-
-## Auto-resume detection (orchestrator runs before mode pick)
+## Auto-resume detection (run before mode pick)
 
 On invocation, before picking mode, scan for in-progress features:
 
@@ -103,19 +79,19 @@ If none: skip to mode pick.
 
 For bug fix, typo, rename, version bump, single-file/≤10-line diff.
 
-The orchestrator does not TeamCreate. It runs the work itself: locates affected files, drafts a combined briefing (bug statement + diff preview + verification step), presents to owner for approval (touchpoint 1), applies the change, runs `test_command`, commits, pushes, notifies. See spec §9.1.
+No TeamCreate, no teammates. The main session runs the work itself: locates affected files, drafts a combined briefing (bug statement + diff preview + verification step), presents to owner for approval (touchpoint 1), applies the change, runs `test_command`, commits, pushes, notifies. See spec §9.1.
 
 ### Single-agent mode (1 touchpoint)
 
 For small enhancement, 1–3 files, no architecture impact.
 
-The orchestrator drafts a combined briefing (one-paragraph spec + one-task plan), presents to owner for combined approval (touchpoint 1). On approval: `TeamCreate`, spawn one implementer (Sonnet/medium). Implementer runs TDD, static checks, commits. Orchestrator shuts down implementer, spawns qc-engineer for a single round. On pass: push + cleanup + notify. On blocking after 3 rounds: recovery escalation. See spec §9.2.
+The main session drafts a combined briefing (one-paragraph spec + one-task plan), presents to owner for combined approval (touchpoint 1). On approval: `TeamCreate`, spawn exactly 1 implementer (Sonnet/medium). Implementer runs TDD, static checks, commits. Main session shuts down implementer, spawns qc-engineer for a single round. On pass: push + cleanup + notify. On blocking after 3 rounds: recovery escalation. See spec §9.2.
 
 ### Team mode (2 touchpoints + finish)
 
 For feature work spanning ≥2 modules or ≥4 files, or introducing a new component.
 
-The orchestrator runs the full single-team lifecycle above. Owner touchpoints: spec sign-off (after architect drives discussion), plan approval (after planner produces it), finish-branch decision (in phase H).
+The main session runs the full single-team lifecycle (below). Owner touchpoints: spec sign-off (after architect drives discussion), plan approval (after planner produces it), finish-branch decision (in phase H).
 
 #### Heuristic ladder (when `--mode` is not set)
 
@@ -133,7 +109,33 @@ Forced overrides:
 - **standard** (default) — adds the second implementer side when shape is full-stack (6).
 - **full** — adds security-engineer in phase A (7 lifetime).
 
-## SPAWN_REQUEST handling (orchestrator behavior)
+## Team-mode lifecycle (spec §3.1)
+
+1. `TeamCreate(superpower-<slug>)`.
+2. Spawn phase-A members:
+   - `solution-architect` (Opus / high)
+   - `feature-planner` (Sonnet / high)
+   - `security-engineer` IFF CLAUDE.md `security.domain` is one of `payments | healthcare | regulated`.
+3. Hand owner control. Architect drives spec discussion. **Touchpoint 1 = spec sign-off.**
+4. Architect produces arch-map. Planner produces plan. **Touchpoint 2 = plan approval.**
+5. Architect writes handover artefact at `docs/superpowers/handovers/YYYY-MM-DD-<slug>-handover.md`.
+6. Architect posts `HANDOVER_READY <slug>`.
+7. Main session shuts down planner, security-engineer, architect (SendMessage shutdown request; teammate approves and exits).
+8. Main session spawns `team-leader` (Opus / high). Spawn prompt names the handover path.
+9. Main session awaits messages from team-leader:
+   - `SPAWN_REQUEST wave=<id> roles_needed=<map> brief_path=<path> expected_tasks=<list>` → see "SPAWN_REQUEST handling" below.
+   - `PHASE_COMPLETE <N>` → ack; await next.
+   - `PLAN_COMPLETE` → shut down team-leader + all implementers. Transition to phase G.
+   - `RESTART_REQUEST <reason>` → see "RESTART_REQUEST handling" below.
+10. Phase G: spawn `qc-engineer` (Sonnet / high). Spawn prompt names spec + plan + handover paths.
+11. Await qc-engineer:
+    - `QC_PASS` → shut down qc-engineer. Phase H.
+    - `QC_REWORK_NEEDED <count>` → shut down qc-engineer; re-spawn team-leader for rework dispatch; loop back to step 9. Max `limits.max_qc_rounds` (default 3) QC rounds.
+12. Phase H: run finish-branch decision (below), then cleanup, then notify owner with final summary.
+
+There is **no architect standby**. Architecturally significant questions during phases B–F trigger `RESTART_REQUEST`, which presents a recovery touchpoint to the owner.
+
+## SPAWN_REQUEST handling
 
 When team-leader posts:
 
@@ -144,10 +146,10 @@ brief_path: .team-superpower/spawn-briefs/wave-<plan-phase>.<wave>.md
 expected_tasks: [<task-id-1>, <task-id-2>, ...]
 ```
 
-Orchestrator:
-1. Reads the brief file.
-2. `TaskCreate` for each expected_task. Title carries the `impl:` prefix per spec §8.2; metadata carries `wave: <plan-phase>.<wave>`; body excerpted from brief.
-3. Spawns the requested counts. Each implementer spawn prompt:
+Main session:
+1. Reads the brief file at `brief_path`.
+2. `TaskCreate` for each task-id in `expected_tasks`. Title carries the `impl:` prefix per spec §8.2; metadata carries `wave: <plan-phase>.<wave>` (so the TaskCreated hook accepts it); body excerpted from the brief.
+3. Spawns the requested `roles_needed` counts. Each implementer's spawn prompt:
 
    ```
    You are a <role> on team superpower-<slug>. Read the next unclaimed unblocked task in the shared task list at ~/.claude/tasks/superpower-<slug>/. Follow its brief: TDD (RED → GREEN → REFACTOR), then lint+format+typecheck (capture to .team-superpower/static-check-<task-id>.log), then commit per team format. After commit, self-claim next unclaimed unblocked task or shut down if none.
@@ -155,9 +157,9 @@ Orchestrator:
 
 4. Replies to team-leader: `SPAWN_DONE wave=<plan-phase>.<wave> agent_ids=[...]`.
 
-Concurrency cap: orchestrator refuses to spawn beyond `limits.max_concurrent_teammates` (default 5). Excess spawns are queued; reply notes `queued: <ids>`.
+Concurrency cap: refuse to spawn beyond `limits.max_concurrent_teammates` (default 5). Excess spawns are queued; reply notes `queued: <ids>`.
 
-## RESTART_REQUEST handling (orchestrator behavior)
+## RESTART_REQUEST handling
 
 When team-leader (or qc-engineer) posts `RESTART_REQUEST <reason>`:
 
@@ -182,7 +184,7 @@ Recovery touchpoints from RESTART_REQUEST do **not** count against the 3-touchpo
 
 ## Phase H — finish-branch and CI gate
 
-After QC pass, team-leader drives the finish-branch decision:
+After QC pass, the main session drives the finish-branch decision:
 
 1. Push the branch.
 2. If `ci.provider != none`: poll the CI provider for `ci.required_checks` up to `ci.poll_timeout_minutes` (default 20).
@@ -213,7 +215,7 @@ Retry cap: 3. After the 3rd failed retry the menu drops `retry` and forces a dif
 
 ## Automatic cleanup (runs after `FINISH_DONE`)
 
-Orchestrator runs cleanup immediately after `FINISH_DONE`:
+Main session runs cleanup immediately after `FINISH_DONE`:
 
 ### Step A — Verify safety preconditions
 
@@ -226,7 +228,7 @@ If any precondition fails, halt with the failed item and leave platform state in
 
 ### Step B — Shut down teammates gracefully
 
-For each remaining teammate: orchestrator requests shutdown via SendMessage; teammate approves and exits. If any teammate refuses, escalate; do not force.
+For each remaining teammate: request shutdown via SendMessage; teammate approves and exits. If any teammate refuses, escalate; do not force.
 
 ### Step C — Run the canonical team cleanup
 
@@ -264,7 +266,7 @@ Halt with the failure mode. The owner runs `/team-cleanup <slug>` from a fresh s
 
 ## Within-phase stall watchdog
 
-Orchestrator detects no SendMessage activity AND no shared-task-list transitions for `limits.phase_stall_minutes` (default 30) within the current phase: pings the most-recently-active teammate. If the next 30-minute window is also silent, surfaces a §7 escalation. Heartbeat-at-phase-boundaries alone does not catch silent hangs.
+The main session detects no SendMessage activity AND no shared-task-list transitions for `limits.phase_stall_minutes` (default 30) within the current phase: pings the most-recently-active teammate. If the next 30-minute window is also silent, surfaces a §7 escalation. Heartbeat-at-phase-boundaries alone does not catch silent hangs.
 
 ## Owner touchpoints (the ONLY allowed pings to the owner)
 
@@ -289,7 +291,7 @@ Anything else that reaches the owner MUST use the §7 escalation template in `as
 
 ## Checkpointing
 
-`docs/superpowers/sessions/YYYY-MM-DD-<slug>.md` is updated by the orchestrator at every phase boundary. Frontmatter carries `slug`, `mode`, `size`, `mode_reasoning`, `overrides_applied`, `superpowers_version`, `worktree_origin`, `cycle_restart_count`.
+`docs/superpowers/sessions/YYYY-MM-DD-<slug>.md` is updated by the main session at every phase boundary. Frontmatter carries `slug`, `mode`, `size`, `mode_reasoning`, `overrides_applied`, `superpowers_version`, `worktree_origin`, `cycle_restart_count`.
 
 Body sections:
 
@@ -302,16 +304,16 @@ Body sections:
 ## Closing      — final block written by Step E
 ```
 
-The orchestrator commits this file after every phase transition. If the orchestrator crashes, the feature lives in this file.
+The main session commits this file after every phase transition. If the main session crashes, the feature lives in this file.
 
 ## Hard rules
 
-1. **Lead never implements.** All feature work is delegated. The lead's only job is `Agent({type: "orchestrator", ...})` plus owner-reply pass-through.
-2. **Orchestrator is the sole spawner.** team-leader, qc-engineer, and implementers never call `Agent` themselves — they post `SPAWN_REQUEST` and let the orchestrator handle it. This honours the Claude Code Agent Teams "no nested teams" constraint.
+1. **Main session is the sole spawner.** team-leader, qc-engineer, and implementers never call `Agent` themselves — they post `SPAWN_REQUEST` and let the main session handle it. This honours the Claude Code Agent Teams "no nested teams" constraint.
+2. **Main session does not run phase work in team mode.** All feature implementation is delegated to teammates. In solo mode the main session does the work itself; in single-agent mode the main session spawns one implementer.
 3. **One team per feature.** A single `TeamCreate superpower-<slug>` runs the entire lifecycle. Membership rolls forward by spawn + shutdown across phases A–H.
 4. **No per-task QA loop.** Implementers self-enforce TDD + static checks; the `TaskCompleted` hook gates on `.team-superpower/static-check-<task-id>.log`.
 5. **Owner-touchpoint budget is sacred.** 3 in team mode, 1 in single-agent / solo. Recovery touchpoints are separate.
 6. **Restart cap is sacred.** 2 `RESTART_REQUEST` cycles per feature; a 3rd cycle escalates as "feature not tractable in this shape".
 7. **QC rounds cap is sacred.** 3 end-of-plan QC rounds; a 4th triggers owner escalation.
-8. **AGENTS.md is a read-only contract for agents.** The `TaskCompleted` hook rejects any commit that modifies it from inside a teammate; only the orchestrator may write it.
+8. **AGENTS.md is a read-only contract for agents.** The `TaskCompleted` hook rejects any commit that modifies it from inside a teammate; only the main session may write it.
 9. **No `--dangerously-skip-permissions`.** Hooks exist because Superpowers gates exist. Use the §7 escalation template instead.

package/plugins/team-superpower/hooks/teammate-idle.sh

@@ -4,7 +4,7 @@
 # Reads the hook event payload from stdin. Expected JSON fields:
 #   - mailbox: array of { from, kind, replied, ... } — recent SendMessage history
 #   - teammate: string (the idling teammate's role; one of
-#       orchestrator | team-leader | solution-architect | feature-planner |
+#       team-leader | solution-architect | feature-planner |
 #       security-engineer | backend-developer | frontend-developer | qc-engineer)
 #
 # v5 behaviour: routing depends on role.
@@ -16,7 +16,7 @@
 #
 #   team-leader:
 #     - block if SPAWN_REQUEST or RESTART_REQUEST has no SPAWN_DONE / RESTART_DONE
-#       reply from lead/orchestrator within heartbeat (must keep coordinating)
+#       reply from the main session within heartbeat (must keep coordinating)
 #     - block if any unanswered ESCALATE from an implementer (must route)
 #     - otherwise advisory tick
 #
@@ -26,12 +26,11 @@
 #
 #   solution-architect / feature-planner / security-engineer (phase A roles):
 #     - block if owner sign-off touchpoint message has no reply yet
-#     - otherwise advisory tick (shutdown is owner-driven via lead)
+#     - otherwise advisory tick (shutdown is owner-driven via the main session)
 #
-#   orchestrator (lead):
-#     - block if any unanswered SPAWN_REQUEST / RESTART_REQUEST inbound from
-#       team-leader (lead is the single spawner)
-#     - otherwise advisory tick (lead drives owner touchpoints separately)
+# v6 note: the lifecycle owner is the main session (the `/team-feature`
+# invocation itself), not a spawned coordinator teammate. The main session
+# is owner-visible by construction, so there is no orphan-main detection branch.
 #
 # Logs every invocation to .claude/hooks/log.jsonl in the project root for tuning.
 
@@ -114,12 +113,6 @@ case "$teammate" in
       warn="BLOCKED_IDLE_phaseA_awaiting_owner_signoff"
     fi
     ;;
-  orchestrator)
-    lead_inbound_pending="$(count_unanswered_from '^team-leader$')"
-    if [ "${lead_inbound_pending:-0}" -gt 0 ]; then
-      warn="BLOCKED_IDLE_orchestrator_unhandled_team-leader_request"
-    fi
-    ;;
   "")
     # Unknown role: fall back to legacy v4 behaviour (any unanswered non-lead inbound).
     legacy_unanswered="$(printf '%s' "$payload" | jq '[.mailbox[]? | select((.from // "") != "lead") | select((.replied // false) == false)] | length' 2>/dev/null || echo 0)"

package/plugins/tech-graph/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "tech-graph",
-  "version": "0.0.24",
+  "version": "0.0.25",
   "description": "Step-by-step wizard for generating technical diagrams as SVG+PNG.",
   "author": {
     "name": "steven"

package/plugins/team-superpower/agents/orchestrator.md

@@ -1,83 +0,0 @@
----
-name: orchestrator
-description: "Use when /team-feature launches. Lead session for team-superpower v5. Sole spawner. Coordinates phase transitions via spawn + shutdown. Responds to SPAWN_REQUEST and RESTART_REQUEST. Runs final cleanup + push."
-tools: Read, Write, Bash, Task, Glob, Grep, mcp__gitnexus__detect_changes, mcp__gitnexus__context
-model: opus
----
-
-# Orchestrator (team-superpower v5 lead)
-
-You are the lead session for a team-superpower v5 feature. You are the **sole spawner** for the team — no teammate can spawn. You also own the team lifecycle (TeamCreate → cleanup) and the final push.
-
-Set effort high at the start of your first turn: `/effort xhigh` and report `effort_set: xhigh`.
-
-## On invocation
-
-1. **Auto-detect resume** (spec §8.13).
-   - List `~/.claude/teams/*/config.json`. Match candidate slugs against worktree dir name and owner launch text.
-   - List `docs/superpowers/handovers/*-handover.md` files with no matching `docs/superpowers/reviews/*-qc-report.md`.
-   - List `docs/superpowers/plans/*.md` with incomplete `PHASE_COMPLETE` markers in `docs/superpowers/reviews/`.
-   - Check `git log --oneline <base>..HEAD` for partial plan-task commits.
-   - If any signal hits, present resume prompt per spec §8.13 and await owner choice.
-2. **Mode pick** via heuristic ladder (v3, unchanged):
-   - Solo: `fix typo`, `rename`, `bump version`, single file, ≤10 line diff.
-   - Single-agent: small enhancement, 1–3 files, no architecture impact.
-   - Team: feature work spanning ≥2 modules OR ≥4 files OR introducing new component.
-3. Branch per mode (spec §9).
-
-## Team mode — single-team lifecycle (spec §3.1)
-
-1. Slug from owner text. `TeamCreate(<slug>)`.
-2. Spawn phase-A members:
-   - `solution-architect` (Opus / high)
-   - `feature-planner` (Sonnet / high)
-   - `security-engineer` IFF CLAUDE.md `security.domain` is one of `payments | healthcare | regulated`.
-3. Hand owner control. Architect drives spec discussion. Touchpoint 1 = spec sign-off.
-4. Architect produces arch-map. Planner produces plan. Touchpoint 2 = plan approval.
-5. Architect writes handover artifact at `docs/superpowers/handovers/YYYY-MM-DD-<slug>-handover.md`.
-6. Architect posts `HANDOVER_READY <slug>`.
-7. Lead shuts down planner, security-engineer, architect (native: SendMessage shutdown request; teammate approves and exits).
-8. Lead spawns `team-leader` (Opus / high). Spawn prompt names the handover path.
-9. Lead awaits messages from team-leader:
-   - `SPAWN_REQUEST wave=<id> roles_needed=<map> brief_path=<path> expected_tasks=<list>` → see "SPAWN_REQUEST handling" below.
-   - `PHASE_COMPLETE <N>` → ack; await next.
-   - `PLAN_COMPLETE` → shut down team-leader + all implementers. Transition to phase G.
-   - `RESTART_REQUEST <reason>` → see "RESTART_REQUEST handling" below.
-10. Phase G: spawn `qc-engineer` (Sonnet / high). Spawn prompt names spec + plan + handover paths.
-11. Await qc-engineer:
-    - `QC_PASS` → shut down qc-engineer. Phase H.
-    - `QC_REWORK_NEEDED <count>` → shut down qc-engineer; re-spawn team-leader for rework dispatch; loop back to step 9. Max 3 QC rounds.
-12. Phase H: run `git push -u origin HEAD`. Run team cleanup (ask Claude to "Clean up the team"). Notify owner with final summary.
-
-## SPAWN_REQUEST handling (spec §3.4)
-
-1. Read the brief file at `brief_path`.
-2. For each task-id in `expected_tasks`, call TaskCreate with body excerpted from the brief. Prefix grammar: `impl:<wave>.<n>-<short-desc>` or `impl:rework-<orig>-<violation>`. Include `wave: <id>` line so the TaskCreated hook accepts it.
-3. Spawn the requested `roles_needed` counts. Each implementer's spawn prompt:
-
-   ```
-   You are a <role> on team <slug>. Read the next unclaimed unblocked task in the shared task list. Follow its brief: TDD (RED → GREEN → REFACTOR), run lint_command + format_command + typecheck_command, capture output to .team-superpower/static-check-<task-id>.log, then commit per the team commit format. After commit, self-claim next unclaimed unblocked task. Shut down when no claimable task remains.
-   ```
-
-4. Reply to team-leader: `SPAWN_DONE wave=<id> agent_ids=<list>`.
-
-## RESTART_REQUEST handling (spec §3.1)
-
-1. Count restarts for this feature (track in `.team-superpower/restart-count`). If ≥ `max_cycle_restarts` (default 2) from CLAUDE.md `limits`, escalate to owner: "Manual intervention required after 2 restarts."
-2. Otherwise present recovery touchpoint: "Cycle restart needed: <reason>. Approve restart from phase A?"
-3. On approval: increment restart counter. Shut down all current teammates. Re-spawn architect + planner (+ security if regulated). Hand them: existing spec + arch-map + plan + partial commits as input. Phase A re-runs with delta scope.
-
-## Solo + single-agent modes
-
-See spec §9.1 and §9.2. Solo: no TeamCreate, no teammates, orchestrator does the work in-session. Single-agent: TeamCreate, spawn 1 implementer, then qc-engineer; no team-leader, no architect.
-
-## Final cleanup
-
-Always lead-driven (`Clean up the team`). Teammates must NOT run cleanup.
-
-## House rules
-
-- You do NOT run phase work yourself in team mode.
-- You do NOT compose spawn briefs; team-leader does. You execute spawn from brief.
-- You do NOT verify code quality; team-leader (phase-end) and qc-engineer (end-of-plan) do.
-- You DO own all TeamCreate / spawn / shutdown / cleanup / push operations.