بنقرة واحدة
council
多義的な意思決定・トレードオフ・go/no-go 判断のために、4 voice の合議を召集する。複数の妥当な path が存在し、選択前に構造化された反対意見が必要なときに使う。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
多義的な意思決定・トレードオフ・go/no-go 判断のために、4 voice の合議を召集する。複数の妥当な path が存在し、選択前に構造化された反対意見が必要なときに使う。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
作業の完了を宣言する前に使用。証拠なき完了宣言を防ぐ規律スキル。
AI agent の action space・tool 定義・observation format を設計し、completion rate を上げる。 agent harness を構築・最適化するときの語彙と判断軸を提供する。
AI agent 自身の failure (loop / drift / max tool call / 環境ズレ) に対する構造化 self-debug。 capture → diagnose → contained recovery → introspection report の 4 phase で、 retry blind を防ぎ human escalation の前に agent が自己修正する。
Chronistaとして活動するための包括的スキルセット。永続記憶、開発フロー、ドキュメント管理、インフラを統合。
Mac M-series で Rust binary を zigbuild で linux/amd64 に cross-compile → slim Dockerfile に COPY → docker buildx --push する開発ループ標準化。 sccache + zig cache + cargo target/ + buildx registry cache の多層 cache を仕込み、 2 回目以降は秒単位の image 更新を実現する。 GH Actions (cargo-chef + GHA cache 10 GiB 制限) からの脱却 path として使う。
コードレビューの実行手法と規律。スコープに応じて Quick / Standard / Deep モードを選択、team-bucciarati の Stand を観点別に dispatch。レビューする側 / 受ける側の両方をカバー。
| name | council |
| description | 多義的な意思決定・トレードオフ・go/no-go 判断のために、4 voice の合議を召集する。複数の妥当な path が存在し、選択前に構造化された反対意見が必要なときに使う。 |
| version | 1.0.0 |
| origin | ECC (Everything Claude Code) — chronista 適合 fork |
| tags | ["decision","council","ambiguity","multi-voice","second-opinion"] |
「不一致を可視化することが目的だ。一致は副産物にすぎない。」
Core principle: 単一視点で意思決定をするな。4 voice の合議で trade-off を表に出してから選べ。
判断軸が複数ある decision は、独走で決めるな
「これしかない」と思った瞬間こそ council を召集せよ。1 voice の確信は conversational anchoring の signal。
複数の妥当な path が存在し、明確な勝者がいない decision に使う:
| ❌ council を使うな | ✅ 代わりに |
|---|---|
| output が正しいか検証したい | santa-method (adversarial verification) |
| バグの根本原因を特定したい | systematic-debugging |
| 実装手順を分解したい | route (Survey → Plot → Compare → Choose) |
| コードのレビュー | code-review |
| 単純な事実確認 | 直接答える |
| 明白な実行タスク | やるだけ |
各 voice は 独立した subagent として召集する。会話履歴を渡さないことが anti-anchoring の核。
| Voice | レンズ | 強み |
|---|---|---|
| Architect | 正しさ・保守性・長期影響 | 構造的健全性 |
| Skeptic | 前提への挑戦・simplification | 質問そのものを疑う |
| Pragmatist | 出荷速度・user impact・運用 | 現実主義 |
| Critic | edge case・downside risk・failure mode | 落とし穴発見 |
Architect は in-context Claude が担い、 Skeptic / Pragmatist / Critic は Agent tool で fresh subagent 召集。これが anti-anchoring の mechanism。
Extract → Gather → Position → Convene → Synthesize → Present
番号でなく名前で参照する。
decision を 1 つの explicit prompt に絞る:
質問が曖昧なら、council 召集前に 1 つだけ clarifying question を user に投げる (一問一答原則)。
docs/design/05-08) と memory (mem_xxx) を引用context は 必要最小限。subagent に長すぎる context を渡すと anti-anchoring が崩れる。
外部 voice を読む前に、Architect (in-context Claude) として書き留める:
これを先にやることで、synthesize 時に外部 voice の単なる mirror にならない。
Skeptic / Pragmatist / Critic を Agent tool で同時起動。各 subagent に渡すのは:
You are the [ROLE] on a four-voice decision council.
Question:
[decision question]
Context:
[only the relevant snippets or constraints]
Respond with:
1. Position — 1-2 sentences
2. Reasoning — 3 concise bullets
3. Risk — biggest risk in your recommendation
4. Surprise — one thing the other voices may miss
Be direct. No hedging. Keep it under 300 words.
Architect 自身が synthesizer を兼ねるので、bias 防止 rule を守る:
## Council: [短い decision タイトル]
**Architect:** [1-2 文 position]
[1 行 why]
**Skeptic:** [1-2 文 position]
[1 行 why]
**Pragmatist:** [1-2 文 position]
[1 行 why]
**Critic:** [1-2 文 position]
[1 行 why]
### Verdict
- **Consensus:** [一致点]
- **Strongest dissent:** [最重要の反対]
- **Premise check:** [Skeptic は質問そのものに挑戦したか?]
- **Recommendation:** [統合された path]
スマホ画面で読める長さに収める。
council の verdict が 実態を変える decision なら memory に pin。全部記録するな: change something real な決定だけ。
| 状況 | 記録方法 |
|---|---|
| 設計判断 (Stand × Pane × Lane の分割等) | mcp__creo-memories__remember (category: design-decision、 tag: [council, decision-log]) |
| Council が initial position を変えた | reason 込みで relationReason に「council で X が補強されて Y → Z に変更」 |
| Phase / Linear issue 単位の go/no-go | Linear comment + memory 両方 |
記録するべき重要メタ:
「PP の semantic を view-only / 双方向 cmd / actor 独立 のどれにするか」を council:
vp show の延長で足りる→ Verdict: actor 独立採用、ただし Phase 8+ 機能 (Navigate / Subscribe) は scope 外。Critic の「Round 2 dep」は前提 phase 完了待ちでカバー。
「Phase X vs D シリーズ vs (P-a) どれ?」を council:
(P-a) (commit message 軽量、Phase 番号の意味論を汚さない)→ Verdict: D シリーズ採用、commit prefix は対応 Linear ID で統一。
| ❌ 悪い | ✅ 良い |
|---|---|
| 全 conversation 履歴を subagent に渡す | compact context のみ、anti-anchoring を死守 |
| 反対意見を verdict から消す | strongest dissent を必ず可視化 |
| 4 voice 全部 in-context (single LLM) でやる | 3 voice は fresh subagent で召集 |
| council を code review に使う | code-review or santa-method を使え |
| 全 council を memory に pin | "real change" を伴う decision だけ pin |
| 1 round で結論固定 | user が 2nd round 求めたら新質問で再召集 |
default は 1 round。user が更に深掘りしたい場合:
| スキル | 役割 | Council との関係 |
|---|---|---|
santa-method | adversarial 検証 (output の quality) | council は decision、santa は output 検証。直交 |
route | path 選択 (Survey → Plot → Compare → Choose) | route の Compare フェーズで council をネストして詳細議論可 |
spec-design-guide | 設計記録 | council 結論を ADR / docs/design に永続化 |
code-review | コード品質 | council は実装前 decision、code-review は実装後品質 |
systematic-debugging | バグ調査 | 別レイヤー、council は実装前 decision の領域 |
拘束 rule ではなく、迷ったら使う:
逆に発火しないケース:
| Phase | 主な活動 | 完了条件 |
|---|---|---|
| Extract | 質問の絞り込み | 1 sentence prompt 完成 |
| Gather | context 収集 | compact + 必要十分 |
| Position | Architect 初期 position | 3 reasons + 最大 risk 記述 |
| Convene | 3 voice 並列召集 | Skeptic/Pragmatist/Critic 各々 300 word 以内 |
| Synthesize | bias guard 付き統合 | strongest dissent 可視化 |
| Present | verdict 提示 | スマホ画面で読める長さ |
council (Everything Claude Code, affaan-m/everything-claude-code)mem_xxx で chronista-style 検索)santa-method, route, spec-design-guide