/board-of-directors
Simulate a 5-member expert board deliberation for major decisions. Use when evaluating plans, architecture choices, feature designs, or any decision requiring multi-perspective expert analysis. Triggers: 'board review', 'get expert opinions', 'board meeting', 'director
$ npx -y skills add Ibrahim-3d/orchestrator-supaconductor --skill board-of-directors --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/board-of-directors
Context preview
The summary Claude sees to decide when to auto-load this skill.
Simulate a 5-member expert board deliberation for major decisions. Use when evaluating plans, architecture choices, feature designs, or any decision requiring multi-perspective expert analysis. Triggers: 'board review', 'get expert opinions', 'board meeting', 'director
SKILL.md
board-of-directors.SKILL.mdname: board-of-directors
description: "Simulate a 5-member expert board deliberation for major decisions. Use when evaluating plans, architecture choices, feature designs, or any decision requiring multi-perspective expert analysis. Triggers: 'board review', 'get expert opinions', 'board meeting', 'director evaluation', 'consensus review'."
Board of Directors Simulation
Simulates a 5-member expert board that deliberates, debates, and reaches consensus on major decisions. Each director brings domain expertise and can challenge other directors' opinions.
The Board
| Role | Domain | Evaluates | |------|--------|-----------| | **Chief Architect (CA)** | Technical | System design, patterns, scalability, tech debt, code quality | | **Chief Product Officer (CPO)** | Product | User value, market fit, feature priority, scope, usability | | **Chief Security Officer (CSO)** | Security | Vulnerabilities, compliance, data protection, risk assessment | | **Chief Operations Officer (COO)** | Execution | Feasibility, timeline, resources, process, deployment | | **Chief Experience Officer (CXO)** | Experience | UX/UI, accessibility, user journey, design consistency |
When to Invoke the Board
- **Track Planning** — Before starting major tracks
- **Architecture Decisions** — ADRs, system design choices
- **Feature Evaluation** — New feature proposals
- **Risk Assessment** — Security or operational concerns
- **Conflict Resolution** — When leads disagree
Deliberation Protocol
Phase 1: Individual Assessment (Parallel)
Each director reviews the proposal independently:
DISPATCH via Task tool (all 5 in parallel):
- CA: Evaluate technical aspects
- CPO: Evaluate product aspects
- CSO: Evaluate security aspects
- COO: Evaluate operational aspects
- CXO: Evaluate experience aspects
Each director outputs:
{
"director": "CA",
"verdict": "APPROVE" | "CONCERNS" | "REJECT",
"score": 1-10,
"key_points": ["..."],
"concerns": ["..."],
"questions_for_board": ["Question for CPO about...", "Challenge to COO on..."]
}Phase 2: Board Discussion (Sequential via Message Bus)
Directors respond to each other's questions and challenges:
MESSAGE BUS: conductor/tracks/{track}/.message-bus/board/
1. Post all Phase 1 assessments to board/assessments.json
2. Each director reads others' assessments
3. Directors post rebuttals/responses to board/discussion.jsonl
4. Max 3 rounds of discussionDiscussion message format:
{
"from": "CA",
"to": "CPO",
"type": "CHALLENGE" | "AGREE" | "QUESTION" | "CLARIFY",
"message": "Regarding your concern about scope...",
"changes_my_verdict": true | false
}Phase 3: Final Vote
After discussion, each director casts final vote:
{
"director": "CA",
"final_verdict": "APPROVE" | "REJECT",
"confidence": 0.0-1.0,
"conditions": ["Must add rate limiting", "Needs load testing"],
"dissent_noted": false
}Phase 4: Board Resolution
Aggregate votes and produce board decision:
| Scenario | Resolution | |----------|------------| | 5-0 or 4-1 APPROVE | **APPROVED** — Proceed with any conditions noted | | 3-2 APPROVE | **APPROVED WITH REVIEW** — Proceed but schedule follow-up | | 3-2 REJECT | **REJECTED** — Address major concerns first | | 4-1 or 5-0 REJECT | **REJECTED** — Significant rework needed | | 2-2-1 (tie with abstain) | **Chief Architect (CA) casts tiebreaking vote** based on technical merit |
Phase 5: Persist Decision (MANDATORY)
After reaching resolution, you MUST persist the decision to files:
1. Create directory: Use run_shell_command `mkdir -p conductor/tracks/{trackId}/.message-bus/board/` 2. write_file `resolution.md` with the Board Output Format (below) 3. write_file `session-{timestamp}.json`:
{"session_id": "...", "verdict": "...", "vote_summary": {...}, "conditions": [...], "timestamp": "..."}Then return ONLY this concise summary to the orchestrator:
{"verdict": "APPROVED|REJECTED|ESCALATE", "conditions": ["..."], "vote": "4-1"}Orchestrator Integration
Invoke Board from Conductor
async function invokeBoardReview(proposal: string, context: object) {
// 1. Initialize board message bus
await initBoardMessageBus(trackId);
// 2. Phase 1: Parallel assessment
const assessments = await Promise.all([
Task({
description: "CA board assessment",
prompt: `You are the Chief Architect on the Board of Directors.
PROPOSAL: ${proposal}
CONTEXT: ${JSON.stringify(context)}
Follow the directors/chief-architect.md profile.
Output your assessment as JSON.`
}),
Task({ description: "CPO board assessment", ... }),
Task({ description: "CSO board assessment", ... }),
Task({ description: "COO board assessment", ... }),
Task({ description: "CXO board assessment", ... })
]);
// 3. Phase 2: Discussion rounds
await runBoardDiscussion(assessments, maxRounds: 3);
// 4. Phase 3: Final vote
const votes = await collectFinalVotes();
// 5. Phase 4: Resolution
return aggregateBoardDecision(votes);
}Board Output Format
## Board of Directors Resolution
**Proposal**: [Brief description]
**Session**: [timestamp]
**Verdict**: APPROVED | APPROVED WITH REVIEW | REJECTED | ESCALATE
### Vote Summary
| Director | Vote | Confidence | Key Condition |
|----------|------|------------|---------------|
| CA | APPROVE | 0.9 | Add caching layer |
| CPO | APPROVE | 0.8 | Validate with usability check |
| CSO | CONCERNS→APPROVE | 0.7 | Security audit before launch |
| COO | APPROVE | 0.85 | Need 2-week buffer |
| CXO | APPROVE | 0.95 | Accessibility is solid |
**Final: 5-0 APPROVE**
### Conditions for Approval
1. Add caching layer for API responses (CA)
2. Complete security audit before production (CSO)
3. Buffer timeline by 2 weeks (COO)
### Discussion Highlights
- CA challenged CPO on scope creep → CPO agreed to defer Phase 2
Read more
name: board-of-directors description: "Simulate a 5-member expert board deliberation for major decisions. Use when evaluating plans, architecture choices, feature designs, or any decision requiring multi-perspective expert analysis. Triggers: 'board review', 'get expert opinions', 'board meeting', 'director evaluation', 'consensus review'."
Board of Directors Simulation
Simulates a 5-member expert board that deliberates, debates, and reaches consensus on major decisions. Each director brings domain expertise and can challenge other directors' opinions.
The Board
| Role | Domain | Evaluates | |------|--------|-----------| | **Chief Architect (CA)** | Technical | System design, patterns, scalability, tech debt, code quality | | **Chief Product Officer (CPO)** | Product | User value, market fit, feature priority, scope, usability | | **Chief Security Officer (CSO)** | Security | Vulnerabilities, compliance, data protection, risk assessment | | **Chief Operations Officer (COO)** | Execution | Feasibility, timeline, resources, process, deployment | | **Chief Experience Officer (CXO)** | Experience | UX/UI, accessibility, user journey, design consistency |
When to Invoke the Board
- **Track Planning** — Before starting major tracks
- **Architecture Decisions** — ADRs, system design choices
- **Feature Evaluation** — New feature proposals
- **Risk Assessment** — Security or operational concerns
- **Conflict Resolution** — When leads disagree
Deliberation Protocol
Phase 1: Individual Assessment (Parallel)
Each director reviews the proposal independently:
DISPATCH via Task tool (all 5 in parallel): - CA: Evaluate technical aspects - CPO: Evaluate product aspects - CSO: Evaluate security aspects - COO: Evaluate operational aspects - CXO: Evaluate experience aspects
Each director outputs:
{
"director": "CA",
"verdict": "APPROVE" | "CONCERNS" | "REJECT",
"score": 1-10,
"key_points": ["..."],
"concerns": ["..."],
"questions_for_board": ["Question for CPO about...", "Challenge to COO on..."]
}Phase 2: Board Discussion (Sequential via Message Bus)
Directors respond to each other's questions and challenges:
MESSAGE BUS: conductor/tracks/{track}/.message-bus/board/
1. Post all Phase 1 assessments to board/assessments.json
2. Each director reads others' assessments
3. Directors post rebuttals/responses to board/discussion.jsonl
4. Max 3 rounds of discussionDiscussion message format:
{
"from": "CA",
"to": "CPO",
"type": "CHALLENGE" | "AGREE" | "QUESTION" | "CLARIFY",
"message": "Regarding your concern about scope...",
"changes_my_verdict": true | false
}Phase 3: Final Vote
After discussion, each director casts final vote:
{
"director": "CA",
"final_verdict": "APPROVE" | "REJECT",
"confidence": 0.0-1.0,
"conditions": ["Must add rate limiting", "Needs load testing"],
"dissent_noted": false
}Phase 4: Board Resolution
Aggregate votes and produce board decision:
| Scenario | Resolution | |----------|------------| | 5-0 or 4-1 APPROVE | **APPROVED** — Proceed with any conditions noted | | 3-2 APPROVE | **APPROVED WITH REVIEW** — Proceed but schedule follow-up | | 3-2 REJECT | **REJECTED** — Address major concerns first | | 4-1 or 5-0 REJECT | **REJECTED** — Significant rework needed | | 2-2-1 (tie with abstain) | **Chief Architect (CA) casts tiebreaking vote** based on technical merit |
Phase 5: Persist Decision (MANDATORY)
After reaching resolution, you MUST persist the decision to files:
1. Create directory: Use run_shell_command `mkdir -p conductor/tracks/{trackId}/.message-bus/board/` 2. write_file `resolution.md` with the Board Output Format (below) 3. write_file `session-{timestamp}.json`:
{"session_id": "...", "verdict": "...", "vote_summary": {...}, "conditions": [...], "timestamp": "..."}Then return ONLY this concise summary to the orchestrator:
{"verdict": "APPROVED|REJECTED|ESCALATE", "conditions": ["..."], "vote": "4-1"}Orchestrator Integration
Invoke Board from Conductor
async function invokeBoardReview(proposal: string, context: object) {
// 1. Initialize board message bus
await initBoardMessageBus(trackId);
// 2. Phase 1: Parallel assessment
const assessments = await Promise.all([
Task({
description: "CA board assessment",
prompt: `You are the Chief Architect on the Board of Directors.
PROPOSAL: ${proposal}
CONTEXT: ${JSON.stringify(context)}
Follow the directors/chief-architect.md profile.
Output your assessment as JSON.`
}),
Task({ description: "CPO board assessment", ... }),
Task({ description: "CSO board assessment", ... }),
Task({ description: "COO board assessment", ... }),
Task({ description: "CXO board assessment", ... })
]);
// 3. Phase 2: Discussion rounds
await runBoardDiscussion(assessments, maxRounds: 3);
// 4. Phase 3: Final vote
const votes = await collectFinalVotes();
// 5. Phase 4: Resolution
return aggregateBoardDecision(votes);
}Board Output Format
## Board of Directors Resolution **Proposal**: [Brief description] **Session**: [timestamp] **Verdict**: APPROVED | APPROVED WITH REVIEW | REJECTED | ESCALATE ### Vote Summary | Director | Vote | Confidence | Key Condition | |----------|------|------------|---------------| | CA | APPROVE | 0.9 | Add caching layer | | CPO | APPROVE | 0.8 | Validate with usability check | | CSO | CONCERNS→APPROVE | 0.7 | Security audit before launch | | COO | APPROVE | 0.85 | Need 2-week buffer | | CXO | APPROVE | 0.95 | Accessibility is solid | **Final: 5-0 APPROVE** ### Conditions for Approval 1. Add caching layer for API responses (CA) 2. Complete security audit before production (CSO) 3. Buffer timeline by 2 weeks (COO) ### Discussion Highlights - CA challenged CPO on scope creep → CPO agreed to defer Phase 2
Multi-agent orchestration system for Claude Code with parallel execution, automated quality gates, Board of Directors, and bundled Superpowers skills
Repo: Ibrahim-3d/orchestrator-supaconductor
Other skills on orchestrator-supaconductor.
- /agent-factory
Creates specialized worker agents dynamically from templates. Use when orchestrator needs to spawn task-specific workers for parallel execution. Handles agent lifecycle: create -> execute -> cleanup.
Open skill - /brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Open skill - /business-docs-sync
Ensures all business strategy, pricing, and product documents stay synchronized when product decisions change during any track execution or evaluation.
Open skill - /conductor-orchestrator
Master coordinator for the Evaluate-Loop workflow v3. Supports GOAL-DRIVEN entry, PARALLEL execution via worker agents, BOARD OF DIRECTORS deliberation, and message bus coordination. Dispatches specialized workers dynamically, monitors via message bus, aggregates results. Uses
Open skill - /context-driven-development
Use this skill when working with Conductor's context-driven development methodology, managing project context artifacts, or understanding the relationship between product.md, tech-stack.md, and workflow.md files.
Open skill - /context-loader
Load project context efficiently for Conductor workflows. Use when starting work on a track, implementing features, or needing project context without consuming excessive tokens.
Open skill

