Get the FREE Ultimate OpenClaw Setup Guide →

board-of-directors

Scanned
npx machina-cli add skill Ibrahim-3d/conductor-orchestrator-superpowers/board-of-directors --openclaw
Files (1)
SKILL.md
7.4 KB

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

RoleDomainEvaluates
Chief Architect (CA)TechnicalSystem design, patterns, scalability, tech debt, code quality
Chief Product Officer (CPO)ProductUser value, market fit, feature priority, scope, usability
Chief Security Officer (CSO)SecurityVulnerabilities, compliance, data protection, risk assessment
Chief Operations Officer (COO)ExecutionFeasibility, timeline, resources, process, deployment
Chief Experience Officer (CXO)ExperienceUX/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 discussion

Discussion 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:

ScenarioResolution
5-0 or 4-1 APPROVEAPPROVED — Proceed with any conditions noted
3-2 APPROVEAPPROVED WITH REVIEW — Proceed but schedule follow-up
3-2 REJECTREJECTED — Address major concerns first
4-1 or 5-0 REJECTREJECTED — Significant rework needed
2-2-1 (tie with abstain)ESCALATE — User makes final call

Phase 5: Persist Decision (MANDATORY)

After reaching resolution, you MUST persist the decision to files:

  1. Create directory: Use Bash mkdir -p conductor/tracks/{trackId}/.message-bus/board/
  2. Write resolution.md with the Board Output Format (below)
  3. Write 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
- CSO raised auth concern → CA proposed token rotation solution
- CXO praised accessibility approach, no concerns

### Dissenting Opinions
None recorded.

---
*Board session complete. Proceed with implementation.*

Director Skills

Each director has specialized evaluation criteria. See:

  • directors/chief-architect.md — Technical excellence
  • directors/chief-product-officer.md — Product value
  • directors/chief-security-officer.md — Security posture
  • directors/chief-operations-officer.md — Execution reality
  • directors/chief-experience-officer.md — User experience

Quick Invocation

For rapid board review without full deliberation:

/board-review [proposal]

Returns: Quick assessment from each director (no discussion phase)

For full deliberation:

/board-meeting [proposal]

Returns: Full 4-phase deliberation with discussion

Integration with Evaluate-Loop

The board can be invoked at key checkpoints:

CheckpointBoard Involvement
EVALUATE_PLANFull board meeting for major tracks
EVALUATE_EXECUTIONQuick review for implementation quality
Pre-LaunchSecurity + Operations deep dive
Post-MortemAll directors analyze what went wrong

Message Bus Structure

.message-bus/board/
├── session-{timestamp}.json    # Session metadata
├── assessments.json            # Phase 1 outputs
├── discussion.jsonl            # Phase 2 messages
├── votes.json                  # Phase 3 final votes
└── resolution.md               # Phase 4 board decision

Source

git clone https://github.com/Ibrahim-3d/conductor-orchestrator-superpowers/blob/master/skills/board-of-directors/SKILL.mdView on GitHub

Overview

Simulates a five-member board (CA, CPO, CSO, COO, CXO) that deliberates major decisions. It enables multi-perspective analysis across architecture, product, security, operations, and UX, helping teams reach consensus before committing to a plan.

How This Skill Works

Phase 1 gathers independent assessments from each director in parallel, returning verdicts, scores, key_points, concerns, and questions. Phase 2 enables a structured, up-to-three-round discussion via a message bus to address challenges and input. Phase 3 collects final votes, Phase 4 resolves the decision, and Phase 5 persists the outcome to resolution.md and a timestamped session JSON.

When to Use It

  • 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

Quick Start

  1. Step 1: Prepare the proposal and assemble the five directors (CA, CPO, CSO, COO, CXO) with their domains.
  2. Step 2: Run Phase 1 assessments in parallel and begin Phase 2 discussions (up to three rounds) to address concerns.
  3. Step 3: Cast final votes, resolve the decision, and persist the outcome to resolution.md and session-*.json.

Best Practices

  • Clearly define each director's domain and evaluation criteria (CA, CPO, CSO, COO, CXO).
  • Use standardized Phase 1 outputs with fields: director, verdict, score, key_points, concerns, questions_for_board.
  • Enforce a maximum of 3 rounds for Phase 2 discussions on the message bus.
  • Capture conditions and dissent in Phase 3 and Phase 4, and address them in the final resolution.
  • Persist the final decision to conductor/tracks/{trackId}/.message-bus/board/ with resolution.md and session-*.json.

Example Use Cases

  • Evaluating a new payment feature architecture for performance and security.
  • Choosing a cloud deployment design with security, scalability, and ops considerations.
  • Prioritizing a feature set for a Q2 release balancing user value and scope.
  • Assessing security vulnerabilities and compliance for a data migration.
  • Resolving conflicts between product usability and technical debt during a redesign.

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers