council

Name: council
Author: warpdotdev

146stars1forks

How to install council?

warpdotdev/common-skills/council

$npx -y skills add warpdotdev/common-skills --skill council

Installs into the current project.

Summary

Run a model-diverse subagent council to investigate the same problem from multiple perspectives, compare findings, and produce a final recommendation. Use this skill whenever the user asks for a council, second opinions, multiple agents/models to evaluate one question, parallel i

Files · 1

View on GitHub

SKILL.md

1	# Council
2
3	Use this skill to coordinate multiple subagents investigating the same question, with different models first and different assigned perspectives second, then synthesize their reports into one recommendation.
4
5	This skill is best for judgment-heavy tasks: architecture tradeoffs, risky bug fixes, code review red-teaming, rollout decisions, incident analysis, and “is this alternative worth pursuing?” questions.
6
7	## Workflow
8
9	### 1. Frame the council question
10
11	State the decision the council should answer in one sentence. Identify:
12
13	- the competing options or hypothesis under review;
14	- the codebase, branch, PR, issue, design, or artifact to inspect;
15	- whether agents should be read-only or may make code changes;
16	- the final decision criteria, such as correctness, risk, implementation cost, testability, rollout safety, or product behavior.
17
18	If the user’s request is ambiguous, ask only the minimum clarification needed. Otherwise choose sensible defaults and proceed.
19
20	### 2. Choose council members
21
22	Prioritize model diversity. A council should not default to three agents on the same model with different angles; use that only when the available launch configuration cannot provide multiple useful models, or when the user explicitly asks for one model. If model diversity is unavailable, say so briefly before falling back to perspective-only diversity.
23
24	Preferred default roster for a three-member council:
25
26	- Opus 4.7 or the strongest available Claude/Opus reasoning model: architecture, correctness, and edge-case analysis.
27	- GPT 5.5 or the strongest available GPT/Codex model: implementation-grounded review, feasibility, and test strategy.
28	- An open-source model such as Kimi 2.6, GLM 5.1, or the strongest available OSS/local model: contrarian critique, hidden assumptions, and alternative framing.
29
30	If one of these exact models is unavailable in the active harness, use the closest available model from that family and note the substitution. If no open-source model is available, use a third distinct frontier model if possible; otherwise use the strongest remaining model with a deliberately adversarial or specialist angle.
31
32	Assign both a model and an angle to each member. Avoid making the angles redundant with the models; for example, do not ask all members to do general architecture review. Useful angle combinations include:
33
34	- architect/correctness reviewer;
35	- implementation/testability reviewer;
36	- red-team, security, performance, or product-risk reviewer;
37	- contrarian “argue against the obvious solution” reviewer.
38
39	When different children need different models, launch them in separate `run_agents` calls because model selection is run-wide. If the requested model resolves differently than expected, treat the resolved launch settings as authoritative and continue unless they make the task infeasible.
40
41	When using non-default harnesses, choose valid model IDs for that harness. For example, Claude Code may expose `claude-opus-4-7`, Codex may expose `gpt-5.5`, and open-source models depend on the currently configured local or remote provider. Do not invent unsupported model IDs; if a desired model is not available, select the closest supported substitute and preserve the intended angle diversity.
42
43	For read-only investigations, keep all children in the same checkout and explicitly tell them not to edit files. For implementation or prototyping councils, give each local child its own git worktree and branch so they cannot collide.
44
45	### 3. Brief before launching
46
47	For explicit orchestration requests, briefly tell the user which council members you plan to launch and what each will investigate, then wait for approval before calling `run_agents`.
48
49	The shared brief should include:
50
51	- repository path or artifact location;
52	- current branch or base context;
53	- the exact question to answer;
54	- relevant background and known concerns;
55	- required files/symbols to inspect, if known;
56	- constraints, especially read-only/no commits/no PRs;
57	- expected report format.
58
59	Keep launch prompts short enough that task titles stay compact. If a long brief causes launch validation issues, launch with a minimal prompt and send the full brief to the child agents immediately afterward.
60
61	### 4. Ask for structured reports
62
63	Ask every council member to return:
64
65	1. exact file paths, symbols, docs, or evidence inspected;
66	2. the current behavior or current implementation;
67	3. the alternative being evaluated;
68	4. correctness risks and edge cases;
69	5. implementation and testing cost;
70	6. recommendation: keep current approach, pursue alternative, or use a hybr

People who liked this also viewed

6 picks

Type

council

146stars1forks

View on GitHub

How to install council?

warpdotdev/common-skills/council

$npx -y skills add warpdotdev/common-skills --skill council

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Council
2
3	Use this skill to coordinate multiple subagents investigating the same question, with different models first and different assigned perspectives second, then synthesize their reports into one recommendation.
4
5	This skill is best for judgment-heavy tasks: architecture tradeoffs, risky bug fixes, code review red-teaming, rollout decisions, incident analysis, and “is this alternative worth pursuing?” questions.
6
7	## Workflow
8
9	### 1. Frame the council question
10
11	State the decision the council should answer in one sentence. Identify:
12
13	- the competing options or hypothesis under review;
14	- the codebase, branch, PR, issue, design, or artifact to inspect;
15	- whether agents should be read-only or may make code changes;
16	- the final decision criteria, such as correctness, risk, implementation cost, testability, rollout safety, or product behavior.
17
18	If the user’s request is ambiguous, ask only the minimum clarification needed. Otherwise choose sensible defaults and proceed.
19
20	### 2. Choose council members
21
22	Prioritize model diversity. A council should not default to three agents on the same model with different angles; use that only when the available launch configuration cannot provide multiple useful models, or when the user explicitly asks for one model. If model diversity is unavailable, say so briefly before falling back to perspective-only diversity.
23
24	Preferred default roster for a three-member council:
25
26	- Opus 4.7 or the strongest available Claude/Opus reasoning model: architecture, correctness, and edge-case analysis.
27	- GPT 5.5 or the strongest available GPT/Codex model: implementation-grounded review, feasibility, and test strategy.
28	- An open-source model such as Kimi 2.6, GLM 5.1, or the strongest available OSS/local model: contrarian critique, hidden assumptions, and alternative framing.
29
30	If one of these exact models is unavailable in the active harness, use the closest available model from that family and note the substitution. If no open-source model is available, use a third distinct frontier model if possible; otherwise use the strongest remaining model with a deliberately adversarial or specialist angle.
31
32	Assign both a model and an angle to each member. Avoid making the angles redundant with the models; for example, do not ask all members to do general architecture review. Useful angle combinations include:
33
34	- architect/correctness reviewer;
35	- implementation/testability reviewer;
36	- red-team, security, performance, or product-risk reviewer;
37	- contrarian “argue against the obvious solution” reviewer.
38
39	When different children need different models, launch them in separate `run_agents` calls because model selection is run-wide. If the requested model resolves differently than expected, treat the resolved launch settings as authoritative and continue unless they make the task infeasible.
40
41	When using non-default harnesses, choose valid model IDs for that harness. For example, Claude Code may expose `claude-opus-4-7`, Codex may expose `gpt-5.5`, and open-source models depend on the currently configured local or remote provider. Do not invent unsupported model IDs; if a desired model is not available, select the closest supported substitute and preserve the intended angle diversity.
42
43	For read-only investigations, keep all children in the same checkout and explicitly tell them not to edit files. For implementation or prototyping councils, give each local child its own git worktree and branch so they cannot collide.
44
45	### 3. Brief before launching
46
47	For explicit orchestration requests, briefly tell the user which council members you plan to launch and what each will investigate, then wait for approval before calling `run_agents`.
48
49	The shared brief should include:
50
51	- repository path or artifact location;
52	- current branch or base context;
53	- the exact question to answer;
54	- relevant background and known concerns;
55	- required files/symbols to inspect, if known;
56	- constraints, especially read-only/no commits/no PRs;
57	- expected report format.
58
59	Keep launch prompts short enough that task titles stay compact. If a long brief causes launch validation issues, launch with a minimal prompt and send the full brief to the child agents immediately afterward.
60
61	### 4. Ask for structured reports
62
63	Ask every council member to return:
64
65	1. exact file paths, symbols, docs, or evidence inspected;
66	2. the current behavior or current implementation;
67	3. the alternative being evaluated;
68	4. correctness risks and edge cases;
69	5. implementation and testing cost;
70	6. recommendation: keep current approach, pursue alternative, or use a hybr

People who liked this also viewed

6 picks

Type