opencode-hive 1.0.5 → 1.0.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-hive",
-  "version": "1.0.5",
+  "version": "1.0.7",
   "type": "module",
   "description": "OpenCode plugin for Agent Hive - from vibe coding to hive coding",
   "license": "MIT WITH Commons-Clause",

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

@@ -11,6 +11,19 @@ When you have multiple unrelated failures (different test files, different subsy
 
 **Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.
 
+## Prerequisite: Check Runnable Tasks
+
+Before dispatching, use `hive_status()` to get the **runnable** list — tasks whose dependencies are all satisfied.
+
+**Only dispatch tasks that are runnable.** Never start tasks with unmet dependencies.
+
+Only `done` satisfies dependencies (not `blocked`, `failed`, `partial`, `cancelled`).
+
+**Ask the operator first:**
+- Use `question()`: "These tasks are runnable and independent: [list]. Execute in parallel?"
+- Record the decision with `hive_context_write({ name: "execution-decisions", content: "..." })`
+- Proceed only after operator approval
+
 ## When to Use
 
 ```dot
@@ -71,6 +84,13 @@ hive_exec_start({ task: "03-fix-race-condition-tests" })
 // All three run concurrently in isolated worktrees
 ```
 
+Parallelize by issuing multiple task() calls in the same assistant message.
+
+```typescript
+task({ subagent_type: 'scout-researcher', prompt: 'Investigate failure A' })
+task({ subagent_type: 'scout-researcher', prompt: 'Investigate failure B' })
+```
+
 ### 4. Review and Integrate
 
 When agents return:

package/skills/executing-plans/SKILL.md

@@ -21,28 +21,39 @@ Load plan, review critically, execute tasks in batches, report for review betwee
 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**
+### Step 2: Identify Runnable Tasks
 
-For each task:
-1. Mark as in_progress
+Use `hive_status()` to get the **runnable** list — tasks with all dependencies satisfied.
+
+Only `done` satisfies dependencies (not `blocked`, `failed`, `partial`, `cancelled`).
+
+**When 2+ tasks are runnable:**
+- **Ask the operator** via `question()`: "Multiple tasks are runnable: [list]. Run in parallel, sequential, or a specific subset?"
+- Record the decision with `hive_context_write({ name: "execution-decisions", content: "..." })` for future reference
+
+**When 1 task is runnable:** Proceed directly.
+
+### Step 3: Execute Batch
+
+For each task in the batch:
+1. Mark as in_progress via `hive_exec_start()`
 2. Follow each step exactly (plan has bite-sized steps)
 3. Run verifications as specified
 4. Mark as completed
 
-### Step 3: Report
+### Step 4: Report
 When batch complete:
 - Show what was implemented
 - Show verification output
 - Say: "Ready for feedback."
 
-### Step 4: Continue
+### Step 5: Continue
 Based on feedback:
 - Apply changes if needed
 - Execute next batch
 - Repeat until complete
 
-### Step 5: Complete Development
+### Step 6: Complete Development
 
 After all tasks complete and verified:
 - Announce: "I'm using the finishing-a-development-branch skill to complete this work."

package/skills/parallel-exploration/SKILL.md

@@ -1,20 +1,24 @@
 ---
 name: parallel-exploration
-description: Use when you need parallel, read-only exploration via hive_hive_background_task (Scout fan-out)
+description: Use when you need parallel, read-only exploration with hive_background_* or task() (Scout fan-out)
 ---
 
-# Parallel Exploration (Background Scout Fan-Out)
+# Parallel Exploration (Scout Fan-Out)
 
 ## Overview
 
 When you need to answer "where/how does X work?" across multiple domains (codebase, tests, docs, OSS), investigating sequentially wastes time. Each investigation is independent and can happen in parallel.
 
-**Core principle:** Decompose into independent sub-questions, spawn one `hive_hive_background_task` per sub-question, collect results asynchronously.
+**Core principle:** Decompose into independent sub-questions, spawn one task per sub-question, collect results asynchronously.
 
 **Safe in Planning mode:** This is read-only exploration. It is OK to use during exploratory research even when there is no feature, no plan, and no approved tasks.
 
 **This skill is for read-only research.** For parallel implementation work, use `hive_skill("dispatching-parallel-agents")` with `hive_exec_start`.
 
+**Two valid execution paths:**
+- **Path A (Hive background tools):** Use `hive_background_task`, `hive_background_output`, `hive_background_cancel` when available.
+- **Path B (Task mode):** Use native `task()` for delegation when background tools are not registered.
+
 ## When to Use
 
 **Default to this skill when:**
@@ -57,6 +61,7 @@ Split your investigation into 2-4 independent sub-questions. Good decomposition:
 Launch all tasks before waiting for any results:
 
 ```typescript
+// Path A: Hive background tools (when available)
 // Fan-out: spawn all tasks first
 hive_background_task({
   agent: "scout-researcher",
@@ -89,6 +94,37 @@ hive_background_task({
 })
 ```
 
+```typescript
+// Path B: Task mode (native task tool)
+// Parallelize by issuing multiple task() calls in the same assistant message.
+task({
+  subagent_type: 'scout-researcher',
+  description: 'Find hive_background_task implementation',
+  prompt: `Where is hive_background_task implemented and registered?
+    - Find the tool definition
+    - Find the plugin registration
+    - Return file paths with line numbers`,
+});
+
+task({
+  subagent_type: 'scout-researcher',
+  description: 'Analyze background task concurrency',
+  prompt: `How does background task concurrency/queueing work?
+    - Find the manager/scheduler code
+    - Document the concurrency model
+    - Return file paths with evidence`,
+});
+
+task({
+  subagent_type: 'scout-researcher',
+  description: 'Find parent notification mechanism',
+  prompt: `How does parent notification work for background tasks?
+    - Where is the notification built?
+    - How is it sent to the parent session?
+    - Return file paths with evidence`,
+});
+```
+
 **Key points:**
 - Use `agent: "scout-researcher"` for read-only exploration
 - Use `sync: false` to return immediately (non-blocking)
@@ -109,6 +145,7 @@ You'll receive a `<system-reminder>` notification when each task completes.
 When notified of completion, retrieve results:
 
 ```typescript
+// Path A: Hive background tools
 // Get output from completed task
 hive_background_output({
   task_id: "task-abc123",
@@ -147,6 +184,7 @@ Combine results from all tasks:
 Cancel tasks that are no longer needed:
 
 ```typescript
+// Path A: Hive background tools
 // Cancel specific task
 hive_background_cancel({ task_id: "task-abc123" })
 
@@ -209,6 +247,7 @@ Return:
 
 **Fan-out:**
 ```typescript
+// Path A: Hive background tools
 // Task 1: Implementation
 hive_background_task({
   agent: "scout-researcher",
@@ -234,6 +273,28 @@ hive_background_task({
 })
 ```
 
+```typescript
+// Path B: Task mode (native task tool)
+// Parallelize by issuing multiple task() calls in the same assistant message.
+task({
+  subagent_type: 'scout-researcher',
+  description: 'Find hive_background_task implementation',
+  prompt: 'Where is hive_background_task implemented? Find tool definition and registration.',
+});
+
+task({
+  subagent_type: 'scout-researcher',
+  description: 'Analyze concurrency model',
+  prompt: 'How does background task concurrency work? Find the manager/scheduler.',
+});
+
+task({
+  subagent_type: 'scout-researcher',
+  description: 'Find notification mechanism',
+  prompt: 'How are parent sessions notified of task completion?',
+});
+```
+
 **Results:**
 - Task 1: Found `background-tools.ts` (tool definition), `index.ts` (registration)
 - Task 2: Found `manager.ts` with concurrency=3 default, queue-based scheduling
@@ -258,6 +319,13 @@ hive_background_task({ ..., sync: false })  // Returns immediately
 // ... later, collect results with hive_background_output
 ```
 
+```typescript
+// GOOD (task mode): Spawn all in the same assistant message
+task({ ... });
+task({ ... });
+task({ ... });
+```
+
 **Too many tasks (diminishing returns):**
 - 2-4 tasks: Good parallelization
 - 5+ tasks: Overhead exceeds benefit, harder to synthesize
@@ -281,6 +349,7 @@ hive_background_task({ ..., sync: false })  // Returns immediately
 
 After using this pattern, verify:
 - [ ] All tasks spawned before collecting any results (true fan-out)
-- [ ] Received notifications for completed tasks
-- [ ] Successfully retrieved output with `hive_background_output`
+- [ ] Received notifications for completed tasks (Path A)
+- [ ] Successfully retrieved output with `hive_background_output` (Path A)
+- [ ] Verified `task()` fan-out pattern used when in task mode (Path B)
 - [ ] Synthesized findings into coherent answer

package/skills/writing-plans/SKILL.md

@@ -13,9 +13,9 @@ Assume they are a skilled developer, but know almost nothing about our toolset o
 
 **Announce at start:** "I'm using the writing-plans skill to create the implementation plan."
 
-**Context:** This should be run in a dedicated worktree (created by brainstorming skill).
+**Context:** Planning is read-only. Use `hive_feature_create` + `hive_plan_write` and avoid worktrees during planning.
 
-**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`
+**Save plans to:** `hive_plan_write` (writes to `.hive/features/<feature>/plan.md`)
 
 ## Bite-Sized Task Granularity
 
@@ -26,66 +26,92 @@ Assume they are a skilled developer, but know almost nothing about our toolset o
 - "Run the tests and make sure they pass" - step
 - "Commit" - step
 
-## Plan Document Header
+## Plan Structure
 
-**Every plan MUST start with this header:**
+**Every plan MUST follow this structure:**
 
-```markdown
-# [Feature Name] Implementation Plan
+````markdown
+# [Feature Name]
 
-> **For Claude:** REQUIRED SUB-SKILL: Use hive_skill:executing-plans to implement this plan task-by-task.
+## Discovery
 
-**Goal:** [One sentence describing what this builds]
+### Original Request
+- "{User's exact words}"
 
-**Architecture:** [2-3 sentences about approach]
+### Interview Summary
+- {Point}: {Decision}
 
-**Tech Stack:** [Key technologies/libraries]
+### Research Findings
+- `{file:lines}`: {Finding}
 
 ---
-```
 
-## Task Structure
+## Non-Goals (What we're NOT building)
+- {Explicit exclusion}
 
-```markdown
-### Task N: [Component Name]
+---
 
-**Files:**
-- Create: `exact/path/to/file.py`
-- Modify: `exact/path/to/existing.py:123-145`
-- Test: `tests/exact/path/to/test.py`
+## Tasks
 
-**Step 1: Write the failing test**
+### 1. Task Name
 
-```python
-def test_specific_behavior():
-    result = function(input)
-    assert result == expected
-```
+Use the Task Structure template below for every task.
+````
 
-**Step 2: Run test to verify it fails**
 
-Run: `pytest tests/path/test.py::test_name -v`
-Expected: FAIL with "function not defined"
+## Task Structure
 
-**Step 3: Write minimal implementation**
+The **Depends on** annotation declares task execution order:
+- **Depends on**: none — No dependencies; can run immediately or in parallel
+- **Depends on**: 1 — Depends on task 1
+- **Depends on**: 1, 3 — Depends on tasks 1 and 3
 
-```python
-def function(input):
-    return expected
-```
+Always include **Depends on** for each task. Use `none` to enable parallel starts.
 
-**Step 4: Run test to verify it passes**
+````markdown
+### N. Task Name
 
-Run: `pytest tests/path/test.py::test_name -v`
-Expected: PASS
+**Depends on**: none
 
-**Step 5: Commit**
+**Files:**
+- Create: `exact/path/to/file.py`
+- Modify: `exact/path/to/existing.py:123-145`
+- Test: `tests/exact/path/to/test.py`
 
-```bash
-git add tests/path/test.py src/path/file.py
-git commit -m "feat: add specific feature"
-```
-```
+**What to do**:
+- Step 1: Write the failing test
+  ```python
+  def test_specific_behavior():
+      result = function(input)
+      assert result == expected
+  ```
+- Step 2: Run test to verify it fails
+  - Run: `pytest tests/path/test.py::test_name -v`
+  - Expected: FAIL with "function not defined"
+- Step 3: Write minimal implementation
+  ```python
+  def function(input):
+      return expected
+  ```
+- Step 4: Run test to verify it passes
+  - Run: `pytest tests/path/test.py::test_name -v`
+  - Expected: PASS
+- Step 5: Commit
+  ```bash
+  git add tests/path/test.py src/path/file.py
+  git commit -m "feat: add specific feature"
+  ```
+
+**Must NOT do**:
+- {Task guardrail}
+
+**References**:
+- `{file:lines}` — {Why this reference matters}
+
+**Verify**:
+- [ ] Run: `{command}` → {expected}
+- [ ] {Additional acceptance criteria}
+````
 
 ## Remember
 - Exact file paths always
@@ -96,18 +122,17 @@ git commit -m "feat: add specific feature"
 
 ## Execution Handoff
 
-After saving the plan, offer execution choice:
-
-**"Plan complete and saved to `docs/plans/<filename>.md`. Two execution options:**
+After saving the plan, ask whether to consult Hygienic (Consultant/Reviewer/Debugger) before offering execution choice.
 
-**1. Subagent-Driven (this session)** - I dispatch fresh subagent per task, review between tasks, fast iteration
+Plan complete and saved to `.hive/features/<feature>/plan.md`.
 
-**2. Parallel Session (separate)** - Open new session with executing-plans, batch execution with checkpoints
+Two execution options:
+1. Subagent-Driven (this session) - I dispatch fresh subagent per task, review between tasks, fast iteration
+2. Parallel Session (separate) - Open new session with executing-plans, batch execution with checkpoints
 
-**Which approach?"**
+Which approach?
 
 **If Subagent-Driven chosen:**
-- **REQUIRED SUB-SKILL:** Use hive_skill:subagent-driven-development
 - Stay in this session
 - Fresh subagent per task + code review