9thlevelsoftware/legion/board-of-directors

Input: topic (string — the proposal or question for the board to deliberate)
Output: confirmed board members (list of 3-5 agent-ids with assigned evaluation lenses)
 
Step 1: Extract domain signals from the topic
  Parse the topic text and extract:
  - Languages mentioned (e.g., TypeScript, Python, Rust)
  - Frameworks mentioned (e.g., React, Laravel, Next.js)
  - Phase type indicators (engineering, design, marketing, testing, product, infrastructure)
  - Keywords for semantic matching (e.g., "scalability", "security", "migration", "UX")
  Combine into a composite task description for the recommendation algorithm.
 
Step 2: Score all agents using agent-registry Section 3 (4-layer scoring)
  Pass the composite task description to the recommendation engine:
  - Layer 1 (Semantic): Map topic keywords to normalized concepts, match against agent task_types
  - Layer 2 (Heuristic): Break ties with exact/partial task-type, specialty, and division alignment
  - Layer 3 (Metadata): Boost agents whose frontmatter review_strengths, languages, frameworks,
    or artifact_types match the extracted domain signals
  - Layer 4 (Memory): If .planning/memory/OUTCOMES.md exists, apply memory boost and archetype
    boost for agents with strong track records on matching task types
 
Step 3: Select top candidates
  - Read board.default_size from settings.json (default: 5)
  - Read board.min_size from settings.json (default: 3)
  - Take the top N agents from the scored list (N = board.default_size)
  - Diversity rule: no more than 2 agents from the same division. If 3+ agents from one
    division score highest, keep the top 2 and pull the next-highest from a different division.
  - For each candidate, extract their review_strengths from agent frontmatter — these become
    the agent's evaluation lenses for Phase 1.
 
Step 4: Under-population handling
  If fewer than board.min_size agents qualify (score above zero after 4-layer scoring):
  - Warn user: "Only {count} agents scored above zero for topic '{topic}'.
    Minimum board size is {board.min_size}."
  - Present options via AskUserQuestion:
    a) "Proceed with smaller board" — allowed only if count >= 2 (absolute floor).
       If count < 2: this option is not offered. Display: "Cannot form a board with
       fewer than 2 members. Broaden the topic or manually select agents."
    b) "Manually select additional agents" — show the full agent catalog grouped by
       division, let user pick agents to add to the board.
  - If user opts for (a) with count >= 2: proceed with the smaller board.
  - If user opts for (b): add selected agents, skip scoring for manual additions.
 
Step 5: Present candidates to user for confirmation
  Display via AskUserQuestion:
 
  ## Board of Directors — {topic}
 
  **Board Size**: {count} members (from settings.board.default_size = {default_size})
  **Topic**: {topic}
 
  | # | Agent | Division | Evaluation Lenses | Score |
  |---|-------|----------|-------------------|-------|
  | 1 | {agent-id} | {division} | {review_strengths from frontmatter} | {total score} |
  | 2 | {agent-id} | {division} | {review_strengths from frontmatter} | {total score} |
  | ... | ... | ... | ... | ... |
 
  **Why this board**: {1-2 sentence rationale linking topic signals to selected agents}
 
  Options:
  - "Convene this board" (Recommended)
  - "Replace a member" — swap one agent for an alternative from the ranked list
  - "Add a member" — add one more agent (up to board.default_size if currently under-sized)
  - "Remove a member" — drop one agent (must stay at or above board.min_size)
  - "Other" — enter custom agent IDs manually
 
  If user selects "Replace a member": show which member to replace and the next-ranked alternatives
  If user selects "Add a member": show the next-ranked agent not already on the board
  If user selects "Remove a member": show which member to remove, confirm board stays >= board.min_size
  If user selects "Other": accept custom agent IDs, validate each exists, assign default evaluation
    lenses from their frontmatter review_strengths
 
Step 6: Lock the board
  - Record the confirmed board members, their evaluation lenses, and the topic
  - This board composition is fixed for all 5 phases — no changes mid-deliberation

Input: confirmed board members, topic, proposal context
Output: one assessment per board member in the standardized format
 
Step 1: Construct assessment prompts
  For each board member:
  a. Load the agent's full personality file from {AGENTS_DIR}/{agent-id}.md
     (AGENTS_DIR resolved via workflow-common Agent Path Resolution Protocol)
  b. Extract the agent's review_strengths from frontmatter — these are the
     evaluation lenses for this member's assessment
  c. Construct the assessment prompt:
 
  """
  {PERSONALITY_CONTENT — full agent .md file, no truncation}
 
  ---
 
  # Board of Directors — Independent Assessment
 
  You are serving on a Board of Directors convened to evaluate the following proposal.
  Assess it independently — do not assume other board members agree or disagree with you.
 
  ## Topic
  {topic}
 
  ## Proposal Context
  {proposal details, relevant files, architecture description, or decision context}
 
  ## Your Evaluation Lenses
  You must evaluate through each of these lenses (from your review_strengths):
  {For each review_strength:}
  - {strength}: Score 1-10 and provide analysis
 
  ## Assessment Output Format
 
  You MUST produce your assessment in this exact format:
 
  ## Assessment: {Your Agent Name}
  ### Verdict: APPROVE | CONCERNS | REJECT
  ### Score: {1-10 overall}
  ### Evaluation (by review_strengths):
  - {strength_1}: {score}/10 — {analysis}
  - {strength_2}: {score}/10 — {analysis}
  ### Red Flags: {auto-reject triggers — issues so severe they warrant immediate rejection, or "None"}
  ### Concerns: {bulleted list of specific issues, or "None"}
  ### Recommendations: {bulleted list of specific improvements, or "None"}
  ### Questions for Other Board Members: {specific challenges or questions you want other
    members to address from their expertise, or "None"}
  """
 
Step 2: Dispatch assessments (parallel)
  Dispatch-aware routing for each board member:
 
  a. Check if the board member's primary task type matches an external CLI's
     capabilities (e.g., design-ux-architect might map to a CLI with strong
     ui_design capabilities). If a cli-dispatch skill is available and the
     member's task type matches an external CLI's strengths, dispatch via
     cli-dispatch. Otherwise, spawn as an internal Claude Code agent.
 
  b. All assessments run in parallel:
     - If adapter.parallel_execution is true: spawn all board member agents simultaneously
     - If adapter.parallel_execution is false: execute sequentially
 
  c. Model tier: model_execution (domain-specific evaluation)
 
Step 3: Collect assessments with timeout
  - Timeout: settings.board.assessment_timeout_ms (default: 300000ms / 5 minutes)
  - For each spawned agent, wait up to the timeout for their assessment
  - If an assessment is not received within the timeout:
    - Log: "Board member {agent-id} timed out after {timeout}ms. Proceeding without
      their assessment."
    - Do NOT retry — proceed with available assessments
  - Minimum threshold: at least 2 completed assessments required
    - If fewer than 2 assessments received: abort the board meeting
    - Report: "Board meeting aborted — only {count} of {total} assessments received.
      Minimum 2 required. Check agent availability and retry."
 
Step 4: Parse and validate assessments
  For each received assessment:
  - Verify the output contains all required sections (Verdict, Score, Evaluation,
    Red Flags, Concerns, Recommendations, Questions)
  - If any section is missing: log a warning but accept the assessment as-is
  - Extract the Verdict (APPROVE, CONCERNS, or REJECT) for use in Phase 3
  - Extract Questions for Other Board Members for use in Phase 2

Input: all Phase 1 assessments, board member list
Output: discussion transcript with position shifts tracked
 
Rationale for internal execution:
  Phase 2 runs INTERNALLY (Claude Code agents or inline) rather than dispatching
  to external CLIs. External dispatch would mean rounds x board_members CLI calls
  (e.g., 2 rounds x 5 members = 10+ invocations), which is cost-prohibitive and
  slow. External CLI assessments from Phase 1 are the authoritative domain input;
  Phase 2 discussion refines and synthesizes based on those findings.
 
Step 1: Read settings
  - Number of rounds: settings.board.discussion_rounds (default: 2)
  - Model tier: model_planning (higher capability for cross-perspective reasoning)
 
Step 2: Compile discussion context
  Build the shared context that all board members receive:
 
  """
  ## Board Assessments Summary
 
  {For each board member's Phase 1 assessment:}
  ### {Agent Name} — Verdict: {VERDICT}, Score: {score}/10
  **Key concerns**: {bulleted concerns}
  **Recommendations**: {bulleted recommendations}
  **Questions for the board**: {questions from Phase 1}
  """
 
Step 3: Execute discussion rounds
  For each round (1 to discussion_rounds):
 
  a. Construct the discussion prompt for each board member:
 
  """
  {PERSONALITY_CONTENT — full agent .md file}
 
  ---
 
  # Board of Directors — Discussion Round {round} of {total_rounds}
 
  You are participating in a board discussion about: {topic}
 
  ## All Board Assessments
  {compiled discussion context from Step 2, updated with prior round messages}
 
  {If round > 1:}
  ## Prior Discussion (Round {round - 1})
  {All messages from the previous round}
 
  ## Your Phase 1 Assessment
  {This member's own Phase 1 assessment — reminder of their initial position}
 
  ## Discussion Instructions
 
  Respond to the other board members' assessments and any questions directed at you.
  You may use one or more of these message types:
 
  - **CHALLENGE**: You disagree with another member's assessment. State which member,
    which point, and why you disagree. Provide evidence or reasoning.
  - **AGREE**: You endorse another member's position. State which member and which
    point. Add supporting evidence if you have it.
  - **QUESTION**: You need clarification from another member. State which member and
    what you need to understand.
  - **CLARIFY**: You are responding to a question directed at you. Provide a clear answer.
  - **SHIFT**: You have changed your position based on the discussion. State your
    original position, what changed it, and your new position. This directly
    influences your Phase 3 vote.
 
  ## Output Format
 
  For each message, use this format: