opencode-hive 0.9.0 → 1.0.0

package/dist/mcp/ast-grep.d.ts

@@ -0,0 +1,2 @@
+import type { LocalMcpConfig } from './types';
+export declare const astGrepMcp: LocalMcpConfig;

package/dist/mcp/context7.d.ts

@@ -0,0 +1,2 @@
+import type { RemoteMcpConfig } from './types';
+export declare const context7Mcp: RemoteMcpConfig;

package/dist/mcp/grep-app.d.ts

@@ -0,0 +1,2 @@
+import type { RemoteMcpConfig } from './types';
+export declare const grepAppMcp: RemoteMcpConfig;

package/dist/mcp/index.d.ts

@@ -0,0 +1,2 @@
+import type { McpConfig } from './types';
+export declare const createBuiltinMcps: (disabledMcps?: string[]) => Record<string, McpConfig>;

package/dist/mcp/types.d.ts

@@ -0,0 +1,12 @@
+export type RemoteMcpConfig = {
+    type: 'remote';
+    url: string;
+    headers?: Record<string, string>;
+    oauth?: boolean;
+};
+export type LocalMcpConfig = {
+    type: 'local';
+    command: string[];
+    environment?: Record<string, string>;
+};
+export type McpConfig = RemoteMcpConfig | LocalMcpConfig;

package/dist/mcp/websearch.d.ts

@@ -0,0 +1,2 @@
+import type { RemoteMcpConfig } from './types';
+export declare const websearchMcp: RemoteMcpConfig;

package/dist/skills/builtin.d.ts

@@ -1,7 +1,7 @@
 /**
  * Builtin Skills for Hive
  *
- * Following OMO-Slim pattern - skills are loaded from generated registry.
+ * Skills are loaded from the generated registry.
  * This file provides the infrastructure to load builtin skills.
  */
 import type { SkillDefinition, SkillLoadResult } from './types.js';

package/dist/skills/registry.generated.d.ts

@@ -7,7 +7,7 @@ import type { SkillDefinition } from './types.js';
 /**
  * List of builtin skill names.
  */
-export declare const BUILTIN_SKILL_NAMES: readonly ["hive", "hive-execution"];
+export declare const BUILTIN_SKILL_NAMES: readonly ["brainstorming", "dispatching-parallel-agents", "executing-plans", "systematic-debugging", "test-driven-development", "verification-before-completion", "writing-plans"];
 /**
  * All builtin skill definitions.
  */

package/dist/skills/types.d.ts

@@ -1,7 +1,7 @@
 /**
  * Hive Skill System Types
  *
- * Following OMO-Slim pattern for skill definitions.
+ * Skill definitions for Hive.
  */
 /**
  * Definition of a skill that can be loaded by agents.

package/dist/tools/background-tools.d.ts

@@ -0,0 +1,24 @@
+/**
+ * Background task tools for Hive worker delegation.
+ *
+ * Provides user-facing tools for spawning, monitoring, and cancelling
+ * background tasks that execute in separate OpenCode sessions.
+ *
+ * Tools:
+ * - background_task: Spawn a new background task
+ * - background_output: Get output from a running/completed task
+ * - background_cancel: Cancel running task(s)
+ */
+import { type ToolDefinition } from '@opencode-ai/plugin';
+import { BackgroundManager, type OpencodeClient } from '../background/index.js';
+/**
+ * Create background task tools.
+ *
+ * @param manager - The BackgroundManager instance for task lifecycle
+ * @param client - OpenCode client for session operations
+ */
+export declare function createBackgroundTools(manager: BackgroundManager, client: OpencodeClient): {
+    background_task: ToolDefinition;
+    background_output: ToolDefinition;
+    background_cancel: ToolDefinition;
+};

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-hive",
-  "version": "0.9.0",
+  "version": "1.0.0",
   "type": "module",
   "description": "OpenCode plugin for Agent Hive - from vibe coding to hive coding",
   "license": "MIT WITH Commons-Clause",
@@ -38,6 +38,12 @@
   "dependencies": {
     "simple-git": "^3.27.0"
   },
+  "optionalDependencies": {
+    "grep-mcp": "^1.1.0",
+    "@notprolands/ast-grep-mcp": "^1.1.1",
+    "@upstash/context7-mcp": "^2.1.0",
+    "exa-mcp-server": "^3.1.5"
+  },
   "devDependencies": {
     "hive-core": "workspace:*",
     "@opencode-ai/plugin": "^1.0.143",

package/skills/brainstorming/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: brainstorming
+description: "Use before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
+---
+
+# Brainstorming Ideas Into Designs
+
+## Overview
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
+
+## The Process
+
+**Understanding the idea:**
+- Check out the current project state first (files, docs, recent commits)
+- Ask questions one at a time to refine the idea
+- Prefer multiple choice questions when possible, but open-ended is fine too
+- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- Focus on understanding: purpose, constraints, success criteria
+
+**Exploring approaches:**
+- Propose 2-3 different approaches with trade-offs
+- Present options conversationally with your recommendation and reasoning
+- Lead with your recommended option and explain why
+
+**Presenting the design:**
+- Once you believe you understand what you're building, present the design
+- Break it into sections of 200-300 words
+- Ask after each section whether it looks right so far
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+## After the Design
+
+**Documentation:**
+- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
+- Commit the design document to git
+
+**Implementation (if continuing):**
+- Ask: "Ready to set up for implementation?"
+- Use `hive_skill:writing-plans` to create detailed implementation plan
+
+## Key Principles
+
+- **One question at a time** - Don't overwhelm with multiple questions
+- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs
+- **Explore alternatives** - Always propose 2-3 approaches before settling
+- **Incremental validation** - Present design in sections, validate each
+- **Be flexible** - Go back and clarify when something doesn't make sense

package/skills/dispatching-parallel-agents/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: dispatching-parallel-agents
+description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
+---
+
+# Dispatching Parallel Agents
+
+## Overview
+
+When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.
+
+**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.
+
+## When to Use
+
+```dot
+digraph when_to_use {
+    "Multiple failures?" [shape=diamond];
+    "Are they independent?" [shape=diamond];
+    "Single agent investigates all" [shape=box];
+    "One agent per problem domain" [shape=box];
+    "Can they work in parallel?" [shape=diamond];
+    "Sequential agents" [shape=box];
+    "Parallel dispatch" [shape=box];
+
+    "Multiple failures?" -> "Are they independent?" [label="yes"];
+    "Are they independent?" -> "Single agent investigates all" [label="no - related"];
+    "Are they independent?" -> "Can they work in parallel?" [label="yes"];
+    "Can they work in parallel?" -> "Parallel dispatch" [label="yes"];
+    "Can they work in parallel?" -> "Sequential agents" [label="no - shared state"];
+}
+```
+
+**Use when:**
+- 3+ test files failing with different root causes
+- Multiple subsystems broken independently
+- Each problem can be understood without context from others
+- No shared state between investigations
+
+**Don't use when:**
+- Failures are related (fix one might fix others)
+- Need to understand full system state
+- Agents would interfere with each other
+
+## The Pattern
+
+### 1. Identify Independent Domains
+
+Group failures by what's broken:
+- File A tests: Tool approval flow
+- File B tests: Batch completion behavior
+- File C tests: Abort functionality
+
+Each domain is independent - fixing tool approval doesn't affect abort tests.
+
+### 2. Create Focused Agent Tasks
+
+Each agent gets:
+- **Specific scope:** One test file or subsystem
+- **Clear goal:** Make these tests pass
+- **Constraints:** Don't change other code
+- **Expected output:** Summary of what you found and fixed
+
+### 3. Dispatch in Parallel
+
+```typescript
+// Using Hive tools for parallel execution
+hive_exec_start({ task: "01-fix-abort-tests" })
+hive_exec_start({ task: "02-fix-batch-tests" })
+hive_exec_start({ task: "03-fix-race-condition-tests" })
+// All three run concurrently in isolated worktrees
+```
+
+### 4. Review and Integrate
+
+When agents return:
+- Read each summary
+- Verify fixes don't conflict
+- Run full test suite
+- Integrate all changes with `hive_merge`
+
+## Agent Prompt Structure
+
+Good agent prompts are:
+1. **Focused** - One clear problem domain
+2. **Self-contained** - All context needed to understand the problem
+3. **Specific about output** - What should the agent return?
+
+```markdown
+Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
+
+1. "should abort tool with partial output capture" - expects 'interrupted at' in message
+2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed
+3. "should properly track pendingToolCount" - expects 3 results but gets 0
+
+These are timing/race condition issues. Your task:
+
+1. Read the test file and understand what each test verifies
+2. Identify root cause - timing issues or actual bugs?
+3. Fix by:
+   - Replacing arbitrary timeouts with event-based waiting
+   - Fixing bugs in abort implementation if found
+   - Adjusting test expectations if testing changed behavior
+
+Do NOT just increase timeouts - find the real issue.
+
+Return: Summary of what you found and what you fixed.
+```
+
+## Common Mistakes
+
+**❌ Too broad:** "Fix all the tests" - agent gets lost
+**✅ Specific:** "Fix agent-tool-abort.test.ts" - focused scope
+
+**❌ No context:** "Fix the race condition" - agent doesn't know where
+**✅ Context:** Paste the error messages and test names
+
+**❌ No constraints:** Agent might refactor everything
+**✅ Constraints:** "Do NOT change production code" or "Fix tests only"
+
+**❌ Vague output:** "Fix it" - you don't know what changed
+**✅ Specific:** "Return summary of root cause and changes"
+
+## When NOT to Use
+
+**Related failures:** Fixing one might fix others - investigate together first
+**Need full context:** Understanding requires seeing entire system
+**Exploratory debugging:** You don't know what's broken yet
+**Shared state:** Agents would interfere (editing same files, using same resources)
+
+## Real Example from Session
+
+**Scenario:** 6 test failures across 3 files after major refactoring
+
+**Failures:**
+- agent-tool-abort.test.ts: 3 failures (timing issues)
+- batch-completion-behavior.test.ts: 2 failures (tools not executing)
+- tool-approval-race-conditions.test.ts: 1 failure (execution count = 0)
+
+**Decision:** Independent domains - abort logic separate from batch completion separate from race conditions
+
+**Dispatch:**
+```
+Agent 1 → Fix agent-tool-abort.test.ts
+Agent 2 → Fix batch-completion-behavior.test.ts
+Agent 3 → Fix tool-approval-race-conditions.test.ts
+```
+
+**Results:**
+- Agent 1: Replaced timeouts with event-based waiting
+- Agent 2: Fixed event structure bug (threadId in wrong place)
+- Agent 3: Added wait for async tool execution to complete
+
+**Integration:** All fixes independent, no conflicts, full suite green
+
+**Time saved:** 3 problems solved in parallel vs sequentially
+
+## Key Benefits
+
+1. **Parallelization** - Multiple investigations happen simultaneously
+2. **Focus** - Each agent has narrow scope, less context to track
+3. **Independence** - Agents don't interfere with each other
+4. **Speed** - 3 problems solved in time of 1
+
+## Verification
+
+After agents return:
+1. **Review each summary** - Understand what changed
+2. **Check for conflicts** - Did agents edit same code?
+3. **Run full suite** - Verify all fixes work together
+4. **Spot check** - Agents can make systematic errors
+
+## Real-World Impact
+
+From debugging session (2025-10-03):
+- 6 failures across 3 files
+- 3 agents dispatched in parallel
+- All investigations completed concurrently
+- All fixes integrated successfully
+- Zero conflicts between agent changes

package/skills/executing-plans/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: executing-plans
+description: Use when you have a written implementation plan to execute in a separate session with review checkpoints
+---
+
+# Executing Plans
+
+## Overview
+
+Load plan, review critically, execute tasks in batches, report for review between batches.
+
+**Core principle:** Batch execution with checkpoints for architect review.
+
+**Announce at start:** "I'm using the executing-plans skill to implement this plan."
+
+## The Process
+
+### Step 1: Load and Review Plan
+1. Read plan file
+2. Review critically - identify any questions or concerns about the plan
+3. If concerns: Raise them with your human partner before starting
+4. If no concerns: Create TodoWrite and proceed
+
+### Step 2: Execute Batch
+**Default: First 3 tasks**
+
+For each task:
+1. Mark as in_progress
+2. Follow each step exactly (plan has bite-sized steps)
+3. Run verifications as specified
+4. Mark as completed
+
+### Step 3: Report
+When batch complete:
+- Show what was implemented
+- Show verification output
+- Say: "Ready for feedback."
+
+### Step 4: Continue
+Based on feedback:
+- Apply changes if needed
+- Execute next batch
+- Repeat until complete
+
+### Step 5: Complete Development
+
+After all tasks complete and verified:
+- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
+- **REQUIRED SUB-SKILL:** Use hive_skill:finishing-a-development-branch
+- Follow that skill to verify tests, present options, execute choice
+
+## When to Stop and Ask for Help
+
+**STOP executing immediately when:**
+- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
+- Plan has critical gaps preventing starting
+- You don't understand an instruction
+- Verification fails repeatedly
+
+**Ask for clarification rather than guessing.**
+
+## When to Revisit Earlier Steps
+
+**Return to Review (Step 1) when:**
+- Partner updates the plan based on your feedback
+- Fundamental approach needs rethinking
+
+**Don't force through blockers** - stop and ask.
+
+## Remember
+- Review plan critically first
+- Follow plan steps exactly
+- Don't skip verifications
+- Reference skills when plan says to
+- Between batches: just report and wait
+- Stop when blocked, don't guess