Understanding the OpenClaw b3ehive Skill: A Multi‑Agent Competition
Framework for Code Generation
The OpenClaw project introduces a novel approach to automated software
development called the b3ehive skill. This skill is designed to harness
the power of multiple AI agents working in parallel, each with a distinct
focus—simplicity, speed, and robustness—to produce a final solution that is
objectively the best among competing implementations. By following a PCTF
(Purpose, Task, Chain, Format) compliant process, b3ehive transforms a raw
task description into a polished, winning piece of code accompanied by
detailed reports that justify the selection.
Purpose: Enabling Competitive Code Generation
The primary purpose of the b3ehive skill is to enable competitive code
generation where three isolated AI agents implement the same functionality,
evaluate each other objectively, and deliver the optimal solution through
data‑driven selection. Rather than relying on a single model’s output, the
framework creates a mini‑tournament of ideas. Each agent is prompted to solve
the same task but with a different emphasis, ensuring a diverse set of
candidate solutions. The competitive environment encourages agents to push the
boundaries of their respective focuses, ultimately surfacing strengths that
might be missed in a solitary generation attempt.
Task Definition: Inputs, Outputs, and Success Criteria
In the b3ehive workflow, the task definition is explicit. The input consists
of a task_description string that outlines the coding problem and an
optional constraints object that may specify language, time/space
complexity, or other requirements. The expected output includes three
deliverables: a final_solution directory containing the winning
implementation, a comparison_report markdown file that analyses all three
approaches, and a decision_rationale markdown file that explains why the
winner was selected. Success criteria are concrete and measurable: the final
solution must be runnable, the comparison report must contain objective
metrics, the decision rationale must justify the selection, all three agent
implementations must be documented, and evaluation scores must be numeric and
justified.
Chain Flow: Four Phases of Competition
The b3ehive skill operates through a clearly defined chain flow divided into
four phases. In Phase 1: Parallel Spawn , the user task triggers the
simultaneous creation of three agent workspaces—run_a, run_b, and run_c. Each
agent receives a prompt template that defines its role as an "Expert Software
Engineer" and assigns a focus: Simplicity for Agent A, Speed for Agent B, and
Robustness for Agent C. The agents must produce a runnable implementation, a
completed checklist, a summary of their unique approach, and ensure their code
differs from the others. Phase 2: Cross‑Evaluation follows, where each
agent evaluates the other two. Using an evaluator prompt template, Agent A
assesses Agents B and C, Agent B evaluates A and C, and Agent C evaluates A
and B. Evaluations are performed across five dimensions—simplicity, speed,
stability, corner cases, and maintainability—each weighted according to the
configuration (20 %, 25 %, 25 %, 20 %, 10 %). Evaluators must provide
objective, data‑driven arguments, citing specific code snippets and delivering
numeric scores. In Phase 3: Objective Scoring , each agent scores itself
and its peers. The scoring prompt asks agents to allocate points to each
dimension, provide justifications, and conclude with a recommendation about
which implementation is best. This self‑and‑peer scoring step ensures that
agents reflect on their own strengths and weaknesses while still considering
competitor performance. Finally, Phase 4: Final Delivery aggregates the
scorecards. A decision logic function calculates score margins; if the winner
leads by more than 15 points, a single winner is chosen. If the margin is
between 5 and 15 points, a hybrid solution combining the top two
implementations is considered. If the scores are extremely close (margin ≤ 5),
the simplest implementation is selected to reduce complexity risk. The phase
outputs the final solution directory, a comprehensive comparison report, and a
transparent decision rationale.
Format Specifications: Directory Structure and File Types
The b3ehive skill enforces a strict directory structure to keep the workflow
organized and reproducible. Under a workspace root, each agent has its own
subdirectory (run_a, run_b, run_c) containing:
-
implementation/– the agent’s runnable code files -
Checklist.md– a markdown checklist with[x]boxes indicating completion of required items -
SUMMARY.md– a narrative describing the agent’s unique approach and competitive advantages -
evaluation/– markdown files evaluating the other two agents (e.g., EVALUATION_B.md, EVALUATION_C.md) -
SCORECARD.md– the agent’s self‑scoring and peer‑scoring results
After evaluation phases, the workspace includes a final/ directory for the
winning solution, a COMPARISON_REPORT.md file that consolidates all six
evaluation reports, and a DECISION_RATIONALE.md file that explains the
selection logic. All markdown files follow plain‑text conventions, making them
easy to read, version‑control, and audit.
Linter & Validation: Ensuring Quality Gates
Quality is enforced through automated pre‑commit checks and runtime
assertions. A lint script (scripts/lint.sh) verifies that each agent’s
directory contains the required files, that the checklist is fully checked,
and that the code compiles and passes tests. Language‑specific checks can be
added as needed. Runtime assertions, encoded in Python‑like pseudocode,
confirm that each phase has completed successfully before proceeding to the
next. For example, after Phase 1 the system asserts that all three
implementation directories exist and that every Checklist.md is complete.
After Phase 2 it checks that six evaluation reports exist and contain numeric
scores. These validation steps guarantee that the workflow cannot advance with
incomplete or erroneous outputs, thereby preserving the integrity of the
competition.
Configuration: Tuning the b3ehive Skill
The skill is configurable via a YAML‑like block that defines agent count,
model choice, thinking depth, and focus areas. In the default configuration,
three agents use the openai-proxy/gpt-5.3-codex model with high thinking
depth, and their focuses are simplicity, speed, and robustness. Evaluation
weights are set to sum to 100 % (simplicity 20, speed 25, stability 25,
corner_cases 20, maintainability 10). The delivery strategy can be set to
auto, best, or hybrid, with a threshold of 15 points determining a clear
winner. Quality gates include linting, testing, and a coverage threshold of 80
%. Adjusting these parameters allows teams to tailor the competition to
specific domains, such as favoring speed for performance‑critical code or
robustness for safety‑critical systems.
Usage: Running a b3ehive Competition
To employ the b3ehive skill, a user invokes it with a task description, for
example: b3ehive "Create a REST API endpoint that validates user input and The skill then orchestrates the four phases
returns a JSON response."
automatically, producing a workspace with all intermediate artifacts and the
final solution. Users can inspect the COMPARISON_REPORT.md to see how each
agent performed on each dimension, read the DECISION_RATIONALE.md to
understand the trade‑offs that led to the winner, and examine the winning
implementation in the final/ directory. Because the process is fully
transparent and reproducible, teams can trust that the selected solution is
the result of a fair, evidence‑based competition rather than an opaque
heuristic.
Why b3ehive Matters for AI‑Assisted Development
The b3ehive skill addresses several limitations of single‑model code
generation. First, it mitigates model bias by encouraging diverse solution
strategies. Second, it provides built‑in validation through cross‑evaluation,
reducing the likelihood of subtle bugs or performance issues slipping through.
Third, the structured reporting creates a knowledge artifact that can be used
for training, auditing, or future prompt engineering. Finally, the competitive
framework aligns incentives: each agent strives to excel in its assigned
focus, which drives higher quality outputs than a cooperative or
non‑competitive setting would. In practice, organizations have reported that
b3ehive‑generated solutions exhibit fewer runtime errors, better adherence to
complexity constraints, and clearer documentation compared to outputs from a
standard generative model. The skill’s emphasis on objective, data‑driven
decision‑making also makes it suitable for regulated industries where
explainability is required.
Conclusion
The OpenClaw b3ehive skill represents a sophisticated, PCTF‑compliant system
for turning a simple task description into a high‑quality code solution
through a multi‑agent competition. By defining clear purposes, tasks, chain
flows, formats, and validation mechanisms, b3ehive ensures that the process is
transparent, repeatable, and outcome‑focused. Whether you are seeking the
simplest possible implementation, the fastest algorithm, or the most robust
piece of software, b3ehive provides a principled way to let specialized AI
agents compete, evaluate, and ultimately deliver the best possible answer. As
AI‑assisted development continues to evolve, frameworks like b3ehive will play
a pivotal role in raising the bar for code quality, reliability, and
trustworthiness.
Skill can be found at:
https://github.com/openclaw/skills/tree/main/skills/weiyangzen/b3ehive/SKILL.md
Top comments (0)