| name | harness-integration-stinger |
| description | Cross-harness capability integration for The Hive's four harnesses (Claude Code, Cursor, ChatGPT Codex, Claude Cowork). Covers per-harness component placement (rules, commands, agents, skills, plugins), the wiring-mechanism decision (hooks vs MCP vs native extension vs plain instruction file), hook/lifecycle events per harness, MCP registration per harness (JSON vs TOML, Cowork connector reachability), capability detection/graceful degradation, and portability (spec-six frontmatter, AGENTS.md baseline, plugin manifests). Includes a worked six-host case study. Use for \\\"wire this into Claude Code and Cursor\\\", \\\"add a hook event\\\", \\\"register an MCP server across harnesses\\\", \\\"audit a harness adapter\\\", \\\"will this work in Cowork\\\", or when harness-integration-worker-bee is invoked. Do NOT use for vector-store schema (vector-store-stinger), embeddings runtime (embeddings-runtime-stinger), MCP protocol internals (mcp-protocol-stinger), or CI/CD topology (ci-release-stinger). |
| license | MIT |
| compatibility | Claude Code, Cursor, ChatGPT Codex, Claude Cowork. |
| metadata | {"hive-tier":"stinger","hive-bee":"harness-integration-worker-bee","research-window":"2026-08-14 (broadening pass; reuses queen-bee-stinger 2026-08-14 research plus six new sources)","case-study":"Hivemind six-host installer (examples/case-study-hivemind-six-host-installer.md)"} |
harness-integration-stinger
The integration playbook for harness-integration-worker-bee. Encodes how to wire one capability (a skill, an agent, a hook-driven behavior, an MCP-backed tool) across The Hive's four harnesses - Claude Code, Cursor, ChatGPT Codex, Claude Cowork - from the first decision (which component type, which wiring mechanism) through capability detection, graceful degradation, portability, and distribution. Includes a full worked case study of a real six-host integration (Hivemind, a prior product this stinger originally documented) as a concrete example of every decision point answered end to end.
Quick navigation
| Task | Guide |
|---|
| Start here: what integration means, the four harnesses, the wiring-mechanism decision matrix | guides/00-decision-framework.md |
| Where does each component type (rules, commands, agents, skills, plugins) live, per harness | guides/01-component-placement.md |
| Wire hooks/lifecycle events, per harness, and know the real shared-event floor | guides/02-hook-lifecycle.md |
| Register an MCP server, per harness (JSON vs. TOML, cloud reachability) | guides/03-mcp-registration.md |
| Detect what a harness supports and degrade gracefully when it doesn't | guides/04-capability-detection-and-degradation.md |
| Keep a skill, rule, or tool contract portable (spec-six frontmatter, AGENTS.md, plugin manifests) | guides/05-portability-and-contracts.md |
| Ship through each harness's marketplace/install flow and its distribution gate | guides/06-distribution-and-audit.md |
| Worked example: a real six-host integration end to end | examples/case-study-hivemind-six-host-installer.md |
Critical directives
These are the non-negotiables. Violating any of them is the most common cause of a broken harness adapter. See the relevant guide for code patterns.
-
Keep the tool and command contract identical across every host. hivemind_search/hivemind_read/hivemind_index (plus hivemind_goal_add/hivemind_kpi_add on OpenClaw) must have the same name, args, and return shape everywhere. A drift in one host silently breaks cross-harness recall. Source: .
