opencode-hive 1.0.2 → 1.0.4

package/README.md

@@ -165,6 +165,7 @@ Hive uses a config file at `~/.config/opencode/agent_hive.json`. You can customi
 | `dispatching-parallel-agents` | Use when facing 2+ independent tasks. Dispatches multiple agents to work concurrently on unrelated problems. |
 | `test-driven-development` | Use when implementing any feature or bugfix. Enforces write-test-first, red-green-refactor cycle. |
 | `systematic-debugging` | Use when encountering any bug or test failure. Requires root cause investigation before proposing fixes. |
+| `code-reviewer` | Use when reviewing implementation changes against an approved plan or task to catch missing requirements, YAGNI, dead code, and risky patterns. |
 | `verification-before-completion` | Use before claiming work is complete. Requires running verification commands and confirming output before success claims. |
 
 #### Available MCPs
@@ -178,7 +179,7 @@ Hive uses a config file at `~/.config/opencode/agent_hive.json`. You can customi
 
 ### Per-Agent Skills
 
-Each agent can have specific skills enabled. If configured, only those skills are available:
+Each agent can have specific skills enabled. If configured, only those skills appear in `hive_skill()`:
 
 ```json
 {
@@ -205,7 +206,7 @@ Note: Wildcards like `["*"]` are **not supported** - use explicit skill names or
 
 ### Auto-load Skills
 
-Use `autoLoadSkills` to automatically inject skills into an agent's system prompt (in addition to any skills selected by the agent).
+Use `autoLoadSkills` to automatically inject skills into an agent's system prompt at session start.
 
 ```json
 {
@@ -221,6 +222,14 @@ Use `autoLoadSkills` to automatically inject skills into an agent's system promp
 }
 ```
 
+**How `skills` and `autoLoadSkills` interact:**
+
+- `skills` controls what appears in `hive_skill()` — the agent can manually load these on demand
+- `autoLoadSkills` injects skills unconditionally at session start — no manual loading needed
+- These are **independent**: a skill can be auto-loaded but not appear in `hive_skill()`, or vice versa
+- Both only support Hive's built-in skills (not OpenCode base skills from the `skill()` tool)
+- User `autoLoadSkills` are **merged** with defaults (use global `disableSkills` to remove defaults)
+
 **Default auto-load skills by agent:**
 
 | Agent | autoLoadSkills default |

package/dist/agents/hygienic.d.ts

@@ -4,7 +4,7 @@
  * Inspired by Momus from OmO (Greek god of satire who found fault in everything).
  * Reviews plans for documentation gaps, NOT design decisions.
  */
-export declare const HYGIENIC_BEE_PROMPT = "# Hygienic (Consultant/Reviewer/Debugger)\n\nNamed after Momus - finds fault in everything. Reviews DOCUMENTATION, not DESIGN.\n\n## Core Mandate\n\nReview plan WITHIN the stated approach. Question DOCUMENTATION gaps, NOT design decisions.\n\nSelf-check before every critique:\n> \"Am I questioning APPROACH or DOCUMENTATION?\"\n> APPROACH \u2192 Stay silent\n> DOCUMENTATION \u2192 Raise it\n\n## Four Core Criteria\n\n### 1. Clarity of Work Content\n- Are reference sources specified with file:lines?\n- Can the implementer find what they need?\n\n### 2. Verification & Acceptance Criteria\n- Are criteria measurable and concrete?\n- Red flags: \"should work\", \"looks good\", \"properly handles\"\n\n### 3. Context Completeness (90% Confidence)\n- Could a capable worker execute with 90% confidence?\n- What's missing that would drop below 90%?\n\n### 4. Big Picture & Workflow\n- Is the WHY clear (not just WHAT and HOW)?\n- Does the flow make sense?\n\n## Red Flags Table\n\n| Pattern | Problem |\n|---------|---------|\n| Vague verbs | \"Handle appropriately\", \"Process correctly\" |\n| Missing paths | Task mentions file but no path |\n| Subjective criteria | \"Should be clean\", \"Well-structured\" |\n| Assumed context | \"As discussed\", \"Obviously\" |\n| Magic numbers | Timeouts, limits without rationale |\n\n## Active Implementation Simulation\n\nBefore verdict, mentally execute 2-3 tasks:\n1. Pick a representative task\n2. Simulate: \"I'm starting this task now...\"\n3. Where do I get stuck? What's missing?\n4. Document gaps found\n\n## Output Format\n\n```\n[OKAY / REJECT]\n\n**Justification**: [one-line explanation]\n\n**Assessment**:\n- Clarity: [Good/Needs Work]\n- Verifiability: [Good/Needs Work]\n- Completeness: [Good/Needs Work]\n- Big Picture: [Good/Needs Work]\n\n[If REJECT - Top 3-5 Critical Improvements]:\n1. [Specific gap with location]\n2. [Specific gap with location]\n3. [Specific gap with location]\n```\n\n## When to OKAY vs REJECT\n\n| Situation | Verdict |\n|-----------|---------|\n| Minor gaps, easily inferred | OKAY with notes |\n| Design seems suboptimal | OKAY (not your call) |\n| Missing file paths for key tasks | REJECT |\n| Vague acceptance criteria | REJECT |\n| Unclear dependencies | REJECT |\n| Assumed context not documented | REJECT |\n\n## Iron Laws\n\n**Never:**\n- Reject based on design decisions\n- Suggest alternative architectures\n- Block on style preferences\n- Review implementation (plans only)\n\n**Always:**\n- Self-check: approach vs documentation\n- Simulate 2-3 tasks before verdict\n- Cite specific locations for gaps\n- Focus on worker success, not perfection\n";
+export declare const HYGIENIC_BEE_PROMPT = "# Hygienic (Consultant/Reviewer/Debugger)\n\nNamed after Momus - finds fault in everything. Reviews DOCUMENTATION, not DESIGN.\n\n## Core Mandate\n\nReview plan WITHIN the stated approach. Question DOCUMENTATION gaps, NOT design decisions.\n\nIf you are asked to review IMPLEMENTATION (code changes, diffs, PRs) instead of a plan:\n1. Load `hive_skill(\"code-reviewer\")`\n2. Apply it and return its output format\n3. Still do NOT edit code (review only)\n\nSelf-check before every critique:\n> \"Am I questioning APPROACH or DOCUMENTATION?\"\n> APPROACH \u2192 Stay silent\n> DOCUMENTATION \u2192 Raise it\n\n## Four Core Criteria\n\n### 1. Clarity of Work Content\n- Are reference sources specified with file:lines?\n- Can the implementer find what they need?\n\n### 2. Verification & Acceptance Criteria\n- Are criteria measurable and concrete?\n- Red flags: \"should work\", \"looks good\", \"properly handles\"\n\n### 3. Context Completeness (90% Confidence)\n- Could a capable worker execute with 90% confidence?\n- What's missing that would drop below 90%?\n\n### 4. Big Picture & Workflow\n- Is the WHY clear (not just WHAT and HOW)?\n- Does the flow make sense?\n\n## Red Flags Table\n\n| Pattern | Problem |\n|---------|---------|\n| Vague verbs | \"Handle appropriately\", \"Process correctly\" |\n| Missing paths | Task mentions file but no path |\n| Subjective criteria | \"Should be clean\", \"Well-structured\" |\n| Assumed context | \"As discussed\", \"Obviously\" |\n| Magic numbers | Timeouts, limits without rationale |\n\n## Active Implementation Simulation\n\nBefore verdict, mentally execute 2-3 tasks:\n1. Pick a representative task\n2. Simulate: \"I'm starting this task now...\"\n3. Where do I get stuck? What's missing?\n4. Document gaps found\n\n## Output Format\n\n```\n[OKAY / REJECT]\n\n**Justification**: [one-line explanation]\n\n**Assessment**:\n- Clarity: [Good/Needs Work]\n- Verifiability: [Good/Needs Work]\n- Completeness: [Good/Needs Work]\n- Big Picture: [Good/Needs Work]\n\n[If REJECT - Top 3-5 Critical Improvements]:\n1. [Specific gap with location]\n2. [Specific gap with location]\n3. [Specific gap with location]\n```\n\n## When to OKAY vs REJECT\n\n| Situation | Verdict |\n|-----------|---------|\n| Minor gaps, easily inferred | OKAY with notes |\n| Design seems suboptimal | OKAY (not your call) |\n| Missing file paths for key tasks | REJECT |\n| Vague acceptance criteria | REJECT |\n| Unclear dependencies | REJECT |\n| Assumed context not documented | REJECT |\n\n## Iron Laws\n\n**Never:**\n- Reject based on design decisions\n- Suggest alternative architectures\n- Block on style preferences\n- Review implementation unless explicitly asked (default is plans only)\n\n**Always:**\n- Self-check: approach vs documentation\n- Simulate 2-3 tasks before verdict\n- Cite specific locations for gaps\n- Focus on worker success, not perfection\n";
 export declare const hygienicBeeAgent: {
     name: string;
     description: string;

package/dist/index.js

@@ -12336,7 +12336,7 @@ function tool(input) {
 }
 tool.schema = exports_external;
 // src/skills/registry.generated.ts
-var BUILTIN_SKILL_NAMES = ["brainstorming", "dispatching-parallel-agents", "executing-plans", "onboarding", "parallel-exploration", "systematic-debugging", "test-driven-development", "verification-before-completion", "writing-plans"];
+var BUILTIN_SKILL_NAMES = ["brainstorming", "code-reviewer", "dispatching-parallel-agents", "executing-plans", "onboarding", "parallel-exploration", "systematic-debugging", "test-driven-development", "verification-before-completion", "writing-plans"];
 var BUILTIN_SKILLS = [
   {
     name: "brainstorming",
@@ -12388,6 +12388,213 @@ Start by understanding the current project context, then ask questions one at a
 - **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`
+  },
+  {
+    name: "code-reviewer",
+    description: "Use when reviewing implementation changes against an approved plan or task (especially before merging or between Hive tasks) to catch missing requirements, YAGNI, dead code, and risky patterns",
+    template: `# Code Reviewer
+
+## Overview
+
+This skill teaches a reviewer to evaluate implementation changes for:
+- Adherence to the approved plan/task (did we build what we said?)
+- Correctness (does it work, including edge cases?)
+- Simplicity (YAGNI, dead code, over-abstraction)
+- Risk (security, performance, maintainability)
+
+**Core principle:** The best change is the smallest correct change that satisfies the plan.
+
+## Iron Laws
+
+- Review against the task/plan first. Code quality comes second.
+- Bias toward deletion and simplification. Every extra line is a liability.
+- Prefer changes that leverage existing patterns and dependencies.
+- Be specific: cite file paths and (when available) line numbers.
+- Do not invent requirements. If the plan/task is ambiguous, mark it and request clarification.
+
+## What Inputs You Need
+
+Minimum:
+- The task intent (1-3 sentences)
+- The plan/task requirements (or a link/path to plan section)
+- The code changes (diff or list of changed files)
+
+If available (recommended):
+- Acceptance criteria / verification steps from the plan
+- Test output or proof the change was verified
+- Any relevant context files (design decisions, constraints)
+
+## Review Process (In Order)
+
+### 1) Identify Scope
+
+1. List all files changed.
+2. For each file, state why it changed (what requirement it serves).
+3. Flag any changes that do not map to the task/plan.
+
+**Rule:** If you cannot map a change to a requirement, treat it as suspicious until justified.
+
+### 2) Plan/Task Adherence (Non-Negotiable)
+
+Create a simple checklist:
+- What the task says must happen
+- Evidence in code/tests that it happens
+
+Flag as issues:
+- Missing requirements (implemented behavior does not match intent)
+- Partial implementation with no follow-up task (TODO-driven shipping)
+- Behavior changes that are not in the plan/task
+
+### 3) Correctness Layer
+
+Review for:
+- Edge cases and error paths
+- Incorrect assumptions about inputs/types
+- Inconsistent behavior across platforms/environments
+- Broken invariants (e.g., state can become invalid)
+
+Prefer "fail fast, fail loud": invalid states should become clear errors, not silent fallbacks.
+
+### 4) Simplicity / YAGNI Layer
+
+Be ruthless and concrete:
+- Remove dead branches, unused flags/options, unreachable code
+- Remove speculative TODOs and "reserved for future" scaffolding
+- Remove comments that restate the code or narrate obvious steps
+- Inline one-off abstractions (helpers/classes/interfaces used once)
+- Replace cleverness with obvious code
+- Reduce nesting with guard clauses / early returns
+
+Prefer clarity over brevity:
+- Avoid nested ternary operators; use \`if/else\` or \`switch\` when branches matter
+- Avoid dense one-liners that hide intent or make debugging harder
+
+### 4b) De-Slop Pass (AI Artifacts / Style Drift)
+
+Scan the diff (not just the final code) for AI-generated slop introduced in this branch:
+- Extra comments that a human would not add, or that do not match the file's tone
+- Defensive checks or try/catch blocks that are abnormal for that area of the codebase
+  - Especially swallowed errors ("ignore and continue") and silent fallbacks
+  - Especially redundant validation in trusted internal codepaths
+- TypeScript escape hatches used to dodge type errors (\`as any\`, \`as unknown as X\`) without necessity
+- Style drift: naming, error handling patterns, logging style, and structure inconsistent with nearby code
+
+Default stance:
+- Prefer deletion over justification.
+- If validation is needed, do it at boundaries; keep internals trusting parsed inputs.
+- If a cast is truly unavoidable, localize it and keep the justification to a single short note.
+
+When recommending simplifications, do not accidentally change behavior. If the current behavior is unclear, request clarification or ask for a test that pins it down.
+
+**Default stance:** Do not add extensibility points without an explicit current requirement.
+
+### 5) Risk Layer (Security / Performance / Maintainability)
+
+Only report what you are confident about.
+
+Security checks (examples):
+- No secrets in code/logs
+- No injection vectors (shell/SQL/HTML) introduced
+- Authz/authn checks preserved
+- Sensitive data not leaked
+
+Performance checks (examples):
+- Avoid unnecessary repeated work (N+1 queries, repeated parsing, repeated filesystem hits)
+- Avoid obvious hot-path allocations or large sync operations
+
+Maintainability checks:
+- Clear naming and intent
+- Consistent error handling
+- API boundaries not blurred
+- Consistent with local file patterns (imports, export style, function style)
+
+### 6) Make One Primary Recommendation
+
+Provide one clear path to reach approval.
+Mention alternatives only when they have materially different trade-offs.
+
+### 7) Signal the Investment
+
+Tag the required follow-up effort using:
+- Quick (<1h)
+- Short (1-4h)
+- Medium (1-2d)
+- Large (3d+)
+
+## Confidence Filter
+
+Only report findings you believe are >=80% likely to be correct.
+If you are unsure, explicitly label it as "Uncertain" and explain what evidence would confirm it.
+
+## Output Format (Use This Exactly)
+
+---
+
+**Files Reviewed:** [list]
+
+**Plan/Task Reference:** [task name + link/path to plan section if known]
+
+**Overall Assessment:** [APPROVE | REQUEST_CHANGES | NEEDS_DISCUSSION]
+
+**Bottom Line:** 2-3 sentences describing whether it matches the task/plan and what must change.
+
+### Critical Issues
+- None | [file:line] - [issue] (why it blocks approval) + (recommended fix)
+
+### Major Issues
+- None | [file:line] - [issue] + (recommended fix)
+
+### Minor Issues
+- None | [file:line] - [issue] + (suggested fix)
+
+### YAGNI / Dead Code
+- None | [file:line] - [what to remove/simplify] + (why it is unnecessary)
+
+### Positive Observations
+- [at least one concrete good thing]
+
+### Action Plan
+1. [highest priority change]
+2. [next]
+3. [next]
+
+### Effort Estimate
+[Quick | Short | Medium | Large]
+
+---
+
+## Common Review Smells (Fast Scan)
+
+Task/plan adherence:
+- Adds features not mentioned in the plan/task
+- Leaves TODOs as the mechanism for correctness
+- Introduces new configuration modes/flags "for future"
+
+YAGNI / dead code:
+- Options/config that are parsed but not used
+- Branches that do the same thing on both sides
+- Comments like "reserved for future" or "we might need this"
+
+AI slop / inconsistency:
+- Commentary that restates code, narrates obvious steps, or adds process noise
+- try/catch that swallows errors or returns defaults without a requirement
+- \`as any\` used to silence type errors instead of fixing types
+- New helpers/abstractions with a single call site
+
+Correctness:
+- Silent fallbacks to defaults on error when the task expects a hard failure
+- Unhandled error paths, missing cleanup, missing returns
+
+Maintainability:
+- Abstractions used once
+- Unclear naming, "utility" grab-bags
+
+## When to Escalate
+
+Use NEEDS_DISCUSSION (instead of REQUEST_CHANGES) when:
+- The plan/task is ambiguous and multiple implementations could be correct
+- The change implies a product/architecture decision not documented
+- Fixing issues requires changing scope, dependencies, or public API`
   },
   {
     name: "dispatching-parallel-agents",
@@ -14535,6 +14742,11 @@ Named after Momus - finds fault in everything. Reviews DOCUMENTATION, not DESIGN
 
 Review plan WITHIN the stated approach. Question DOCUMENTATION gaps, NOT design decisions.
 
+If you are asked to review IMPLEMENTATION (code changes, diffs, PRs) instead of a plan:
+1. Load \`hive_skill("code-reviewer")\`
+2. Apply it and return its output format
+3. Still do NOT edit code (review only)
+
 Self-check before every critique:
 > "Am I questioning APPROACH or DOCUMENTATION?"
 > APPROACH → Stay silent
@@ -14612,7 +14824,7 @@ Before verdict, mentally execute 2-3 tasks:
 - Reject based on design decisions
 - Suggest alternative architectures
 - Block on style preferences
-- Review implementation (plans only)
+- Review implementation unless explicitly asked (default is plans only)
 
 **Always:**
 - Self-check: approach vs documentation
@@ -15556,7 +15768,7 @@ var DEFAULT_HIVE_CONFIG = {
     "hygienic-reviewer": {
       model: DEFAULT_AGENT_MODELS["hygienic-reviewer"],
       temperature: 0.3,
-      skills: ["systematic-debugging"],
+      skills: ["systematic-debugging", "code-reviewer"],
       autoLoadSkills: []
     }
   }
@@ -22891,6 +23103,30 @@ function formatSkillsXml(skills) {
 ${skillsXml}
 </available_skills>`;
 }
+function buildAutoLoadedSkillsContent(agentName, configService) {
+  const agentConfig = configService.getAgentConfig(agentName);
+  const autoLoadSkills = agentConfig.autoLoadSkills ?? [];
+  if (autoLoadSkills.length === 0) {
+    return "";
+  }
+  const skillTemplates = [];
+  for (const skillId of autoLoadSkills) {
+    const skill = BUILTIN_SKILLS.find((entry) => entry.name === skillId);
+    if (!skill) {
+      console.warn(`[hive] Unknown skill id "${skillId}" for agent "${agentName}"`);
+      continue;
+    }
+    skillTemplates.push(skill.template);
+  }
+  if (skillTemplates.length === 0) {
+    return "";
+  }
+  return `
+
+` + skillTemplates.join(`
+
+`);
+}
 function createHiveSkillTool(filteredSkills) {
   const base = `Load a Hive skill to get detailed instructions for a specific workflow.
 
@@ -23072,22 +23308,6 @@ To unblock: Remove .hive/features/${feature}/BLOCKED`;
   return {
     "experimental.chat.system.transform": async (input, output) => {
       output.system.push(HIVE_SYSTEM_PROMPT);
-      const agentInput = input;
-      const agentName = agentInput?.agent;
-      if (agentName && isHiveAgent(agentName)) {
-        const agentConfig = configService.getAgentConfig(agentName);
-        const autoLoadSkills = agentConfig.autoLoadSkills ?? [];
-        if (autoLoadSkills.length > 0) {
-          for (const skillId of autoLoadSkills) {
-            const skill = BUILTIN_SKILLS.find((entry) => entry.name === skillId);
-            if (!skill) {
-              console.warn("Unknown skill id", skillId);
-              continue;
-            }
-            output.system.push(skill.template);
-          }
-        }
-      }
       const activeFeature = resolveFeature();
       if (activeFeature) {
         const info = featureService.getInfo(activeFeature);
@@ -24042,11 +24262,12 @@ Make the requested changes, then call hive_request_review again.`;
     config: async (opencodeConfig) => {
       configService.init();
       const hiveUserConfig = configService.getAgentConfig("hive-master");
+      const hiveAutoLoadedSkills = buildAutoLoadedSkillsContent("hive-master", configService);
       const hiveConfig = {
         model: hiveUserConfig.model,
         temperature: hiveUserConfig.temperature ?? 0.5,
         description: "Hive (Hybrid) - Plans + orchestrates. Detects phase, loads skills on-demand.",
-        prompt: QUEEN_BEE_PROMPT,
+        prompt: QUEEN_BEE_PROMPT + hiveAutoLoadedSkills,
         permission: {
           question: "allow",
           skill: "allow",
@@ -24058,11 +24279,12 @@ Make the requested changes, then call hive_request_review again.`;
         }
       };
       const architectUserConfig = configService.getAgentConfig("architect-planner");
+      const architectAutoLoadedSkills = buildAutoLoadedSkillsContent("architect-planner", configService);
       const architectConfig = {
         model: architectUserConfig.model,
         temperature: architectUserConfig.temperature ?? 0.7,
         description: "Architect (Planner) - Plans features, interviews, writes plans. NEVER executes.",
-        prompt: ARCHITECT_BEE_PROMPT,
+        prompt: ARCHITECT_BEE_PROMPT + architectAutoLoadedSkills,
         permission: {
           edit: "deny",
           task: "deny",
@@ -24077,11 +24299,12 @@ Make the requested changes, then call hive_request_review again.`;
         }
       };
       const swarmUserConfig = configService.getAgentConfig("swarm-orchestrator");
+      const swarmAutoLoadedSkills = buildAutoLoadedSkillsContent("swarm-orchestrator", configService);
       const swarmConfig = {
         model: swarmUserConfig.model,
         temperature: swarmUserConfig.temperature ?? 0.5,
         description: "Swarm (Orchestrator) - Orchestrates execution. Delegates, spawns workers, verifies, merges.",
-        prompt: SWARM_BEE_PROMPT,
+        prompt: SWARM_BEE_PROMPT + swarmAutoLoadedSkills,
         permission: {
           question: "allow",
           skill: "allow",
@@ -24093,12 +24316,13 @@ Make the requested changes, then call hive_request_review again.`;
         }
       };
       const scoutUserConfig = configService.getAgentConfig("scout-researcher");
+      const scoutAutoLoadedSkills = buildAutoLoadedSkillsContent("scout-researcher", configService);
       const scoutConfig = {
         model: scoutUserConfig.model,
         temperature: scoutUserConfig.temperature ?? 0.5,
         mode: "subagent",
         description: "Scout (Explorer/Researcher/Retrieval) - Researches codebase + external docs/data.",
-        prompt: SCOUT_BEE_PROMPT,
+        prompt: SCOUT_BEE_PROMPT + scoutAutoLoadedSkills,
         permission: {
           edit: "deny",
           skill: "allow",
@@ -24106,23 +24330,25 @@ Make the requested changes, then call hive_request_review again.`;
         }
       };
       const foragerUserConfig = configService.getAgentConfig("forager-worker");
+      const foragerAutoLoadedSkills = buildAutoLoadedSkillsContent("forager-worker", configService);
       const foragerConfig = {
         model: foragerUserConfig.model,
         temperature: foragerUserConfig.temperature ?? 0.3,
         mode: "subagent",
         description: "Forager (Worker/Coder) - Executes tasks directly in isolated worktrees. Never delegates.",
-        prompt: FORAGER_BEE_PROMPT,
+        prompt: FORAGER_BEE_PROMPT + foragerAutoLoadedSkills,
         permission: {
           skill: "allow"
         }
       };
       const hygienicUserConfig = configService.getAgentConfig("hygienic-reviewer");
+      const hygienicAutoLoadedSkills = buildAutoLoadedSkillsContent("hygienic-reviewer", configService);
       const hygienicConfig = {
         model: hygienicUserConfig.model,
         temperature: hygienicUserConfig.temperature ?? 0.3,
         mode: "subagent",
         description: "Hygienic (Consultant/Reviewer/Debugger) - Reviews plan documentation quality. OKAY/REJECT verdict.",
-        prompt: HYGIENIC_BEE_PROMPT,
+        prompt: HYGIENIC_BEE_PROMPT + hygienicAutoLoadedSkills,
         permission: {
           edit: "deny",
           skill: "allow"
@@ -24133,6 +24359,9 @@ Make the requested changes, then call hive_request_review again.`;
       const allAgents = {};
       if (agentMode === "unified") {
         allAgents["hive-master"] = hiveConfig;
+        allAgents["scout-researcher"] = scoutConfig;
+        allAgents["forager-worker"] = foragerConfig;
+        allAgents["hygienic-reviewer"] = hygienicConfig;
       } else {
         allAgents["architect-planner"] = architectConfig;
         allAgents["swarm-orchestrator"] = swarmConfig;

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 ["brainstorming", "dispatching-parallel-agents", "executing-plans", "onboarding", "parallel-exploration", "systematic-debugging", "test-driven-development", "verification-before-completion", "writing-plans"];
+export declare const BUILTIN_SKILL_NAMES: readonly ["brainstorming", "code-reviewer", "dispatching-parallel-agents", "executing-plans", "onboarding", "parallel-exploration", "systematic-debugging", "test-driven-development", "verification-before-completion", "writing-plans"];
 /**
  * All builtin skill definitions.
  */

package/package.json

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

package/skills/code-reviewer/SKILL.md

@@ -0,0 +1,208 @@
+---
+name: code-reviewer
+description: Use when reviewing implementation changes against an approved plan or task (especially before merging or between Hive tasks) to catch missing requirements, YAGNI, dead code, and risky patterns
+---
+
+# Code Reviewer
+
+## Overview
+
+This skill teaches a reviewer to evaluate implementation changes for:
+- Adherence to the approved plan/task (did we build what we said?)
+- Correctness (does it work, including edge cases?)
+- Simplicity (YAGNI, dead code, over-abstraction)
+- Risk (security, performance, maintainability)
+
+**Core principle:** The best change is the smallest correct change that satisfies the plan.
+
+## Iron Laws
+
+- Review against the task/plan first. Code quality comes second.
+- Bias toward deletion and simplification. Every extra line is a liability.
+- Prefer changes that leverage existing patterns and dependencies.
+- Be specific: cite file paths and (when available) line numbers.
+- Do not invent requirements. If the plan/task is ambiguous, mark it and request clarification.
+
+## What Inputs You Need
+
+Minimum:
+- The task intent (1-3 sentences)
+- The plan/task requirements (or a link/path to plan section)
+- The code changes (diff or list of changed files)
+
+If available (recommended):
+- Acceptance criteria / verification steps from the plan
+- Test output or proof the change was verified
+- Any relevant context files (design decisions, constraints)
+
+## Review Process (In Order)
+
+### 1) Identify Scope
+
+1. List all files changed.
+2. For each file, state why it changed (what requirement it serves).
+3. Flag any changes that do not map to the task/plan.
+
+**Rule:** If you cannot map a change to a requirement, treat it as suspicious until justified.
+
+### 2) Plan/Task Adherence (Non-Negotiable)
+
+Create a simple checklist:
+- What the task says must happen
+- Evidence in code/tests that it happens
+
+Flag as issues:
+- Missing requirements (implemented behavior does not match intent)
+- Partial implementation with no follow-up task (TODO-driven shipping)
+- Behavior changes that are not in the plan/task
+
+### 3) Correctness Layer
+
+Review for:
+- Edge cases and error paths
+- Incorrect assumptions about inputs/types
+- Inconsistent behavior across platforms/environments
+- Broken invariants (e.g., state can become invalid)
+
+Prefer "fail fast, fail loud": invalid states should become clear errors, not silent fallbacks.
+
+### 4) Simplicity / YAGNI Layer
+
+Be ruthless and concrete:
+- Remove dead branches, unused flags/options, unreachable code
+- Remove speculative TODOs and "reserved for future" scaffolding
+- Remove comments that restate the code or narrate obvious steps
+- Inline one-off abstractions (helpers/classes/interfaces used once)
+- Replace cleverness with obvious code
+- Reduce nesting with guard clauses / early returns
+
+Prefer clarity over brevity:
+- Avoid nested ternary operators; use `if/else` or `switch` when branches matter
+- Avoid dense one-liners that hide intent or make debugging harder
+
+### 4b) De-Slop Pass (AI Artifacts / Style Drift)
+
+Scan the diff (not just the final code) for AI-generated slop introduced in this branch:
+- Extra comments that a human would not add, or that do not match the file's tone
+- Defensive checks or try/catch blocks that are abnormal for that area of the codebase
+  - Especially swallowed errors ("ignore and continue") and silent fallbacks
+  - Especially redundant validation in trusted internal codepaths
+- TypeScript escape hatches used to dodge type errors (`as any`, `as unknown as X`) without necessity
+- Style drift: naming, error handling patterns, logging style, and structure inconsistent with nearby code
+
+Default stance:
+- Prefer deletion over justification.
+- If validation is needed, do it at boundaries; keep internals trusting parsed inputs.
+- If a cast is truly unavoidable, localize it and keep the justification to a single short note.
+
+When recommending simplifications, do not accidentally change behavior. If the current behavior is unclear, request clarification or ask for a test that pins it down.
+
+**Default stance:** Do not add extensibility points without an explicit current requirement.
+
+### 5) Risk Layer (Security / Performance / Maintainability)
+
+Only report what you are confident about.
+
+Security checks (examples):
+- No secrets in code/logs
+- No injection vectors (shell/SQL/HTML) introduced
+- Authz/authn checks preserved
+- Sensitive data not leaked
+
+Performance checks (examples):
+- Avoid unnecessary repeated work (N+1 queries, repeated parsing, repeated filesystem hits)
+- Avoid obvious hot-path allocations or large sync operations
+
+Maintainability checks:
+- Clear naming and intent
+- Consistent error handling
+- API boundaries not blurred
+- Consistent with local file patterns (imports, export style, function style)
+
+### 6) Make One Primary Recommendation
+
+Provide one clear path to reach approval.
+Mention alternatives only when they have materially different trade-offs.
+
+### 7) Signal the Investment
+
+Tag the required follow-up effort using:
+- Quick (<1h)
+- Short (1-4h)
+- Medium (1-2d)
+- Large (3d+)
+
+## Confidence Filter
+
+Only report findings you believe are >=80% likely to be correct.
+If you are unsure, explicitly label it as "Uncertain" and explain what evidence would confirm it.
+
+## Output Format (Use This Exactly)
+
+---
+
+**Files Reviewed:** [list]
+
+**Plan/Task Reference:** [task name + link/path to plan section if known]
+
+**Overall Assessment:** [APPROVE | REQUEST_CHANGES | NEEDS_DISCUSSION]
+
+**Bottom Line:** 2-3 sentences describing whether it matches the task/plan and what must change.
+
+### Critical Issues
+- None | [file:line] - [issue] (why it blocks approval) + (recommended fix)
+
+### Major Issues
+- None | [file:line] - [issue] + (recommended fix)
+
+### Minor Issues
+- None | [file:line] - [issue] + (suggested fix)
+
+### YAGNI / Dead Code
+- None | [file:line] - [what to remove/simplify] + (why it is unnecessary)
+
+### Positive Observations
+- [at least one concrete good thing]
+
+### Action Plan
+1. [highest priority change]
+2. [next]
+3. [next]
+
+### Effort Estimate
+[Quick | Short | Medium | Large]
+
+---
+
+## Common Review Smells (Fast Scan)
+
+Task/plan adherence:
+- Adds features not mentioned in the plan/task
+- Leaves TODOs as the mechanism for correctness
+- Introduces new configuration modes/flags "for future"
+
+YAGNI / dead code:
+- Options/config that are parsed but not used
+- Branches that do the same thing on both sides
+- Comments like "reserved for future" or "we might need this"
+
+AI slop / inconsistency:
+- Commentary that restates code, narrates obvious steps, or adds process noise
+- try/catch that swallows errors or returns defaults without a requirement
+- `as any` used to silence type errors instead of fixing types
+- New helpers/abstractions with a single call site
+
+Correctness:
+- Silent fallbacks to defaults on error when the task expects a hard failure
+- Unhandled error paths, missing cleanup, missing returns
+
+Maintainability:
+- Abstractions used once
+- Unclear naming, "utility" grab-bags
+
+## When to Escalate
+
+Use NEEDS_DISCUSSION (instead of REQUEST_CHANGES) when:
+- The plan/task is ambiguous and multiple implementations could be correct
+- The change implies a product/architecture decision not documented
+- Fixing issues requires changing scope, dependencies, or public API