[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-2092":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":9,"languages":9,"totalLinesOfCode":9,"stars":10,"forks":11,"watchers":12,"openIssues":13,"contributorsCount":13,"subscribersCount":13,"size":13,"stars1d":13,"stars7d":14,"stars30d":15,"stars90d":13,"forks30d":13,"starsTrendScore":13,"compositeScore":16,"rankGlobal":9,"rankLanguage":9,"license":17,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":20,"hasPages":18,"topics":21,"createdAt":9,"pushedAt":9,"updatedAt":22,"readmeContent":23,"aiSummary":24,"trendingCount":13,"starSnapshotCount":13,"syncStatus":25,"lastSyncTime":26,"discoverSource":27},2092,"design-council","sjsyrek\u002Fdesign-council","sjsyrek","Claude Code plugin: convene 11 role-specialized peer agents to debate a technical decision in real time, with the invoking Claude acting as CEO.",null,161,15,1,0,3,19,3.61,"MIT License",false,"main",true,[],"2026-06-12 02:00:37","# Design Council\n\n> Convene a parallel team of specialist Claude agents with independent contexts — they argue your call, partition the work, and ship it.\n\n## What problem it solves\n\nA single context, no matter how capable, evaluates a cross-cutting design decision from one vantage point. \"Should this API paginate cursor-style or offset-style?\" touches integration, performance, security, docs, and product — and the answer you get depends on which hat you happened to be wearing when asked. Iterating with the same context doesn't fix this: each turn inherits the prior framing.\n\nDesign Council spawns each seat as an **independent Claude agent with its own context**. They don't inherit yours. The `security-engineer` has no cached rationale for the principal-engineer's architecture; the `accessibility-specialist` doesn't share the `performance-engineer`'s priors about batching. Disagreement is structural, not simulated. The CEO's job is to route the disagreement productively and write the decision down.\n\n## How it works\n\n0. **Plan card (you confirm before anything spawns).** The CEO shows a one-screen card: mode (debate \u002F review), roster with per-seat model, rough token\u002Fwall-clock budget, and the drafted opening question. You reply `go`, `swap X for Y`, `drop X`, `add X`, or `abort`.\n1. **Brief (single context, yours).** The CEO gathers binding constraints from `CLAUDE.md`, referenced specs, and the project's memory system (including beads if detected). **Skill self-audit runs here too:** the CEO greps auto-memory and prior decision logs for entries about the council skill itself; any memory that contradicts the skill's own prescriptions wins (memory is written after real failures, so it's ground truth). Everything lands **once** in `~\u002F.claude\u002Fcouncils\u002F\u003Cslug>\u002Fbrief.md` — every seat's spawn prompt points to that path, so prompt caching hits across parallel spawns (~7–12k tokens saved per 8-seat council).\n2. **Convene (parallel fan-out).** In one multi-tool-call message, the CEO spawns every seat via `TeamCreate` + `Agent(... run_in_background: true, team_name: ...)`. Every spawn prompt inlines the four delivery rules (handshake, SendMessage-only, final-via-SendMessage, idle-summary-short).\n3. **Handshake verify (Phase 2.5).** The CEO counts incoming handshake DMs, inspects team config for empty `tmuxPaneId`s, remediates silent-spawn failures, and emits a structured `HANDSHAKE: N\u002FN ok | verdict=PROCEED` line.\n4. **Cross-talk (peer DMs, bounded).** Seats post opening verdicts (`APPROVE` \u002F `CONCERNS` \u002F `BLOCK`), then DM each other directly via `SendMessage` to argue the live disagreements. The CEO routes — pairs disagreers, invites tiebreakers, forces narrowing questions, bridges converged tracks. Hard cap of 3 rounds. Review mode skips cross-talk by default.\n5. **Arbitrate (CEO writes).** For every disagreement cross-talk didn't resolve, the CEO writes a 3–5 sentence decision with rationale engaging the loser's argument. Strategic \u002F budget \u002F legal \u002F cross-team calls escalate to the user.\n6. **Log + teardown.** The CEO posts the draft decision log to chat for your `save` \u002F `amend` \u002F `discard`. On save: `~\u002F.claude\u002Fcouncils\u002F\u003Cyyyy-mm-dd>-\u003Cslug>\u002Flog.md` (outside any project repo). Includes opening prompt, roster, resolved disagreements, arbitration decisions, deferred items with tracker IDs, and an execution plan with file-ownership mapping. Team shuts down via `shutdown_request`; `TeamDelete` removes the shared task list.\n\n**Stop early** at any phase by saying \"stop the council\" — the CEO broadcasts shutdown, saves a partial log with `status: halted`, and cleans up.\n\n## Benefits\n\n- **Genuine parallelism.** Independent contexts reasoning concurrently, not sequential turns. Wall-clock cost ≈ slowest seat, not sum of seats.\n- **Structurally independent perspectives.** Each seat is a separate Claude with its own context — no priming bleeds across roles.\n- **Direct peer debate.** `SendMessage` lets seats argue with each other without round-tripping through the CEO, which is how real cross-discipline reviews work.\n- **Cheap fan-out via prompt cache.** The shared `brief.md` pattern means identical constraints hit the 5-minute prompt cache across every spawn, recovering meaningful tokens on constraint-heavy projects.\n- **Durable artifact outside any repo.** Decision logs are portable — they outlive branch pivots, repo renames, and migrations. `~\u002F.claude\u002Fcouncils\u002F` is per-user artifact space.\n- **Merge-conflict-aware execution plan.** Phase 5 closes with file-ownership mapping so parallel implementers — spawned as fresh agents with `isolation: \"worktree\"` after teardown — can ship the decision without colliding. See `references\u002Fimplementation-handoff.md` for the full playbook (including why `git checkout \u003CSHA> -- \u003Cfiles>` beats `cherry-pick` for mixed-base handoffs).\n\n## Tradeoffs\n\n- **Token cost.** 8+ parallel contexts, each receiving a role brief + opening prompt + `Read` of the shared brief, then 1–3 cross-talk rounds. Expect roughly **10–20×** the tokens of a single-context review. This is why the \"Do not invoke\" list is explicit: small decisions don't earn the cost.\n- **Orchestration latency.** Even parallel, each round ends only when the last-to-respond seat is in. Debates where one seat goes deep on research dominate wall-clock.\n- **Not a substitute for domain expertise.** Seats are strong generalists shaped by their role briefs, not replacements for a named SME. Use the `domain-expert` opt-in or escalate to a human for narrowly technical calls.\n- **Silent-promise risk on DEFER.** A deferred decision without a tracker item decays to nothing. The Phase 5 silent-promise guard catches this when a tracker is detected; without one, the prose entry in the log is the only handle.\n\n## When to invoke\n\nBoth conditions must hold:\n\n- Decision or review crosses **≥2 specialist domains**, AND\n- Output must **survive handoff** — a decision log, tracker items, or an execution plan.\n\nNatural trigger phrases: \"convene the council\", \"design debate\", \"council review\", \"get the team together\", \"run a design review\", \"debate this design\".\n\n**Do not invoke** for simple bug fixes, single-specialist questions, library\u002Ftool picks, or pure exploration (→ `Explore`). The token cost isn't earned.\n\n## Default roster (size matches decision shape)\n\n**Full 11 seats:** `principal-engineer` · `platform-engineer` · `integration-engineer` · `test-engineer` · `qa-engineer` · `security-engineer` · `performance-engineer` · `product-manager` · `ui-ux-designer` · `accessibility-specialist` · `technical-writer`\n\n**Opt-ins** (CEO adds based on decision shape): `devops-engineer` · `sre-engineer` · `finops-engineer` · `legal-compliance` · `domain-expert` · `historian`\n\n**Dynamic sizing is the default.** No runtime UI → drop `ui-ux-designer` + `accessibility-specialist`. No user input \u002F no infra → drop `security-engineer` + `platform-engineer` too. Internal-tooling decisions often land on 4–6 seats. The plan card (Phase 0) shows the chosen roster; you can adjust before spawn.\n\n## Model defaults (surfaced up-front)\n\n- **Opus** for synthesis-heavy seats (`principal-engineer`, `product-manager`, `technical-writer`, `historian`).\n- **Sonnet** for analytical seats (`test-engineer`, `performance-engineer`, `platform-engineer`, `qa-engineer`).\n- **All-Opus** when the user frames the task as \"high quality bar\" or \"ship to production.\"\n\nThe plan card displays the chosen models per seat so you never discover them mid-debate.\n\n## Slash command\n\n```\n\u002Fdesign-council:design-council [decision-or-focus]\n```\n\nOptional argument: the decision or codebase area to debate (e.g. `\u002Fdesign-council:design-council should we extract the billing service into its own repo?`). Without the argument, the CEO asks for the focus before drafting the Phase 0 plan card. Trigger phrases (\"convene the council\", \"design debate\", etc.) also work for proactive invocation.\n\n## Integrations\n\n### Beads\n\nWhen the invoking project uses [beads](https:\u002F\u002Fgithub.com\u002Fgastownhall\u002Fbeads), this skill automatically:\n\n- Includes `bd memories`, `bd ready`, and `bd show \u003Cid>` output in the Phase 1 brief.\n- Translates Phase 4 `DEFER` decisions into `bd create` commands before Phase 5 teardown.\n- Closes the primary bead under debate during teardown (with `--force` if beads flags a known dependency-inversion).\n- Records filed bead IDs in the decision log frontmatter (`primary-tracker-id`, `linked-tracker-ids`).\n\nDetection: `.beads\u002F` at the invoking project's git root, OR `bd` on `$PATH`. Concretely: `test -d .beads || command -v bd`.\n\nWhen no tracker is detected, deferred items remain prose in the decision log and no tracker commands are run. The protocol is strictly additive — beads is never required. See `skills\u002Fdesign-council\u002Freferences\u002Ftracker-integration.md` for the adapter contract used to wire new trackers.\n\n### Split-pane observability\n\nTo watch seats debate in real time, run Claude Code inside **tmux** or **iTerm2** and set `\"teammateMode\": \"tmux\"` (or the default `\"auto\"`) in your Claude Code `settings.json`. Each seat renders in its own pane. Without a split-pane-capable terminal, seats still run — they just share the main pane and you cycle through them with Shift+Down.\n\nThis is a Claude Code harness setting, not a plugin requirement.\n\n## Installation\n\n```\n\u002Fplugin marketplace add sjsyrek\u002Fclaude-plugins\n\u002Fplugin install design-council@sjsyrek\n```\n\nThe marketplace lives at [sjsyrek\u002Fclaude-plugins](https:\u002F\u002Fgithub.com\u002Fsjsyrek\u002Fclaude-plugins) and points at this repo. To pin a version, clone this repo at a tag (e.g., `v0.2.0`) and load via `\u002Fplugin marketplace add \u003Clocal-path>` pointing at a checkout with its own `.claude-plugin\u002Fmarketplace.json`.\n\n## Runtime requirements\n\n- `TeamCreate` \u002F `TeamDelete` — team lifecycle + shared task list\n- `Agent` with `name`, `run_in_background`, `team_name`, `model` — spawns each seat as a peer\n- `SendMessage` — CEO-to-seat and seat-to-seat DMs, plus broadcast\n- `TaskCreate` — shared task list\n\nSome of these are deferred tools in Claude Code; they're resolved at spawn time.\n\n## Decision log location\n\n`~\u002F.claude\u002Fcouncils\u002F\u003Cyyyy-mm-dd>-\u003Cslug>\u002Flog.md` — per-user artifact space, **not** plugin-owned. The shared brief artifact lives alongside at `~\u002F.claude\u002Fcouncils\u002F\u003Cslug>\u002Fbrief.md`.\n\n## Version history\n\nSee [CHANGELOG.md](.\u002FCHANGELOG.md).\n\n## License\n\nMIT\n","Design Council 是一个Claude代码插件，旨在通过召集11个具有独立上下文的专家角色代理来实时辩论技术决策。其核心功能包括让每个角色如安全工程师、性能工程师等作为独立的Claude代理参与讨论，不共享彼此的背景信息，从而确保从多角度全面评估决策。该工具特别适用于需要跨领域考量的技术设计场景，比如API设计时需同时考虑集成、性能、安全性等因素的情况。它通过结构化的分歧处理流程，帮助团队更有效地达成共识并记录决策过程。",2,"2026-06-11 02:48:01","CREATED_QUERY"]