@kodrunhq/opencode-autopilot 0.1.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 kodrunhq
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1 @@
+# @kodrunhq/opencode-autopilot

package/assets/agents/placeholder-agent.md

@@ -0,0 +1,13 @@
+---
+description: A placeholder agent installed by opencode-autopilot to verify the plugin is working
+mode: all
+permission:
+  read: allow
+  edit: deny
+  bash: deny
+  webfetch: deny
+  task: deny
+---
+You are a placeholder agent installed by the opencode-autopilot plugin. Your purpose is to confirm the plugin's asset installation is working correctly.
+
+When invoked, explain that you are a placeholder and suggest the user explore other agents provided by the opencode-autopilot plugin.

package/assets/commands/configure.md

@@ -0,0 +1,17 @@
+---
+description: Configure the opencode-autopilot plugin -- assign models to agents
+---
+The opencode-autopilot plugin supports configuration for model mapping. You can assign specific models to each agent provided by the plugin by editing the config file at `~/.config/opencode/opencode-autopilot.json`.
+
+The config file uses this format:
+```json
+{
+  "version": 1,
+  "configured": true,
+  "models": {
+    "agent-name": "provider/model-id"
+  }
+}
+```
+
+Note: An interactive configuration tool will be added in a future phase to automate this process.

package/assets/commands/new-agent.md

@@ -0,0 +1,16 @@
+---
+description: Create a new OpenCode agent from within this session
+---
+The user wants to create a new OpenCode agent. Gather the following information conversationally before calling the tool:
+
+1. **name** (required): Agent name in lowercase with hyphens (e.g., "code-reviewer", "test-helper"). Must be 1-64 characters, alphanumeric with hyphens only.
+2. **description** (required): A clear description of what the agent does (max 500 characters).
+3. **mode** (optional, default: "subagent"): One of "primary" (main agent), "subagent" (invoked via @mention), or "all" (both).
+4. **model** (optional): Model identifier to use (e.g., "anthropic/claude-sonnet-4-20250514"). Omit for model-agnostic agents.
+5. **temperature** (optional): Temperature setting from 0.0 to 1.0. Omit for default.
+
+Once you have all the required information, call the `oc_create_agent` tool with the collected parameters. The tool will validate the name, generate the agent file, and write it to the correct location.
+
+After creation, remind the user to restart OpenCode and suggest they edit the generated file to customize the system prompt.
+
+$ARGUMENTS

package/assets/commands/new-command.md

@@ -0,0 +1,15 @@
+---
+description: Create a new OpenCode command from within this session
+---
+The user wants to create a new OpenCode slash command. Gather the following information conversationally before calling the tool:
+
+1. **name** (required): Command name in lowercase with hyphens (e.g., "review", "deploy-check"). Must be 1-64 characters, alphanumeric with hyphens only. Cannot conflict with built-in commands (init, undo, redo, share, help, config, compact, clear, cost, login, logout, bug).
+2. **description** (required): A clear description of what the command does when invoked (max 500 characters).
+3. **agent** (optional): Agent to use when running this command (e.g., "code-reviewer").
+4. **model** (optional): Model override for this command.
+
+Once you have all the required information, call the `oc_create_command` tool with the collected parameters. The tool will validate the name, generate the command file, and write it to the correct location.
+
+After creation, remind the user to restart OpenCode and suggest they edit the generated file to customize the command instructions. Mention that they can use `$ARGUMENTS` for user input and `@filename` to include file content.
+
+$ARGUMENTS

package/assets/commands/new-skill.md

@@ -0,0 +1,15 @@
+---
+description: Create a new OpenCode skill from within this session
+---
+The user wants to create a new OpenCode skill. Gather the following information conversationally before calling the tool:
+
+1. **name** (required): Skill name in lowercase with hyphens (e.g., "typescript-patterns", "api-design"). Must be 1-64 characters, alphanumeric with hyphens only.
+2. **description** (required): A clear description of what the skill provides to the AI agent (max 1024 characters).
+3. **license** (optional): License for the skill (e.g., "MIT").
+4. **compatibility** (optional): Compatibility target (e.g., "opencode").
+
+Once you have all the required information, call the `oc_create_skill` tool with the collected parameters. The tool will validate the name, create the skill directory, and write the SKILL.md file.
+
+After creation, remind the user to restart OpenCode and suggest they edit the generated SKILL.md to add domain knowledge, rules, and examples.
+
+$ARGUMENTS

package/assets/commands/review-pr.md

@@ -0,0 +1,49 @@
+---
+description: Review a GitHub PR with structured, actionable feedback
+agent: pr-reviewer
+---
+Review the pull request specified by $ARGUMENTS.
+
+Before running any commands, validate that $ARGUMENTS is a valid PR identifier (a number or a URL). If it contains shell metacharacters or does not look like a PR reference, ask the user to provide a valid PR number.
+
+First, gather the PR context:
+
+1. Run `gh pr view $ARGUMENTS` to get the PR title, description, author, and status
+2. Run `gh pr diff $ARGUMENTS` to get the full diff
+3. If the diff is large, run `gh pr diff $ARGUMENTS --name-only` first to identify changed files, then review them in logical groups
+
+Then analyze the PR against these dimensions:
+
+- **Correctness:** Does the code do what the PR description claims? Are there logic errors, off-by-one bugs, or missing edge cases?
+- **Security:** Are there hardcoded secrets, unsanitized inputs, missing auth checks, or injection vulnerabilities?
+- **Code quality:** Does the code follow the coding-standards skill? Check naming, file size, function size, error handling, immutability, and separation of concerns.
+- **Testing:** Are there tests for new functionality? Do existing tests still cover the changed code paths?
+- **Performance:** Are there N+1 queries, unnecessary allocations, missing indexes, or unbounded loops?
+
+Provide your review in this structure:
+
+## Summary
+
+What the PR does in 2-3 sentences.
+
+## Findings
+
+List issues by severity. For each finding, include the file, line range, what is wrong, and a suggested fix.
+
+- **CRITICAL** -- Must fix before merge (security vulnerabilities, data loss, crashes)
+- **HIGH** -- Should fix before merge (logic errors, missing error handling, broken edge cases)
+- **MEDIUM** -- Consider fixing (code quality, naming, minor refactoring opportunities)
+- **LOW** -- Nit-level suggestions (style, optional improvements)
+
+If no issues are found at a severity level, omit that level.
+
+## Positive Notes
+
+What the PR does well -- good patterns, clean abstractions, thorough tests.
+
+## Verdict
+
+One of:
+- **APPROVE** -- No critical or high issues. Ready to merge.
+- **REQUEST_CHANGES** -- Has critical or high issues that must be addressed.
+- **NEEDS_DISCUSSION** -- Architectural or design concerns that need team input.

package/assets/skills/coding-standards/SKILL.md

@@ -0,0 +1,327 @@
+---
+name: coding-standards
+description: Universal coding standards and best practices for code review and generation. Covers naming, file organization, error handling, immutability, and separation of concerns.
+---
+
+# Coding Standards
+
+Universal, language-agnostic coding standards. Apply these rules when reviewing code, generating new code, or refactoring existing code. Every rule is opinionated and actionable.
+
+## 1. Naming Conventions
+
+**DO:** Use descriptive, intention-revealing names. Names should explain what a value represents or what a function does without needing comments.
+
+- Variables: nouns that describe the value (`userCount`, `activeOrders`, `maxRetries`)
+- Functions: verbs that describe the action (`fetchUser`, `calculateTotal`, `validateInput`)
+- Booleans: questions that read naturally (`isActive`, `hasPermission`, `shouldRetry`, `canEdit`)
+- Constants: UPPER_SNAKE_CASE for true constants (`MAX_RETRIES`, `DEFAULT_TIMEOUT`)
+- Use consistent casing per convention: camelCase for variables/functions, PascalCase for types/classes
+
+**DON'T:**
+
+- Use single-letter variables outside of trivial loops (`x`, `d`, `t`)
+- Use abbreviations that are not universally understood (`usr`, `mgr`, `btn`, `cfg`)
+- Use generic names that convey no meaning (`data`, `info`, `temp`, `stuff`, `result`)
+- Use negated booleans (`isNotValid` -- use `isValid` and negate at the call site)
+- Encode types in names (`strName`, `arrItems`, `iCount`)
+
+```
+// DO
+remainingAttempts = maxRetries - failedAttempts
+isEligibleForDiscount = orderTotal > minimumThreshold
+
+// DON'T
+x = r - f
+flag = t > m
+```
+
+## 2. File Organization
+
+**DO:** Keep files focused on a single concern. One module should do one thing well.
+
+- Target 200-400 lines per file. Hard maximum of 800 lines.
+- Organize by feature or domain, not by file type (group `user/` together, not `controllers/` + `models/` + `services/`)
+- Place related files close together in the directory tree
+- One exported class or primary function per file
+- Index files (barrel exports) for public API surfaces only
+
+**DON'T:**
+
+- Mix unrelated functionality in a single file
+- Create files with multiple independent classes or modules
+- Nest directories more than 4 levels deep
+- Put all utilities in a single `utils.ts` grab-bag file
+
+```
+// DO: Organize by feature
+user/
+  create-user.ts
+  validate-user.ts
+  user-repository.ts
+  user.test.ts
+
+// DON'T: Organize by type
+controllers/
+  user-controller.ts
+  order-controller.ts
+services/
+  user-service.ts
+  order-service.ts
+```
+
+## 3. Function Design
+
+**DO:** Write small functions that do exactly one thing.
+
+- Target under 50 lines per function. If longer, extract sub-functions.
+- Maximum 3-4 levels of nesting. Extract nested logic into named functions.
+- Limit parameters to 3. Use an options object for more.
+- Return early for guard clauses and error conditions.
+- Pure functions where possible -- same input always produces same output.
+
+**DON'T:**
+
+- Write functions that handle multiple unrelated responsibilities
+- Use deeply nested if/else chains or switch statements with complex logic
+- Pass boolean flags that change behavior (`processOrder(order, true, false)`)
+- Rely on side effects that are not obvious from the function name
+
+```
+// DO: Early return for guard clauses
+function getDiscount(customer) {
+  if (!customer) return 0
+  if (!customer.isActive) return 0
+  if (customer.orders < 10) return 0.05
+  return 0.15
+}
+
+// DON'T: Deep nesting
+function getDiscount(customer) {
+  if (customer) {
+    if (customer.isActive) {
+      if (customer.orders >= 10) {
+        return 0.15
+      } else {
+        return 0.05
+      }
+    }
+  }
+  return 0
+}
+```
+
+## 4. Error Handling
+
+**DO:** Handle errors explicitly at every level. Every error path deserves deliberate treatment.
+
+- Catch errors as close to the source as possible
+- Provide user-friendly messages in UI-facing code
+- Log detailed context (operation, input values, stack) on the server side
+- Use typed or domain-specific error classes to distinguish error categories
+- Fail fast -- validate inputs before processing
+
+**DON'T:**
+
+- Silently swallow errors with empty catch blocks
+- Use exceptions for control flow (expected conditions should use return values)
+- Expose internal error details (stack traces, SQL queries) to end users
+- Log errors without enough context to reproduce the issue
+- Catch generic exceptions when you can catch specific ones
+
+```
+// DO: Explicit handling with context
+try {
+  user = await fetchUser(userId)
+} catch (error) {
+  logger.error("Failed to fetch user", { userId, error })
+  throw new UserNotFoundError(userId)
+}
+
+// DON'T: Silent swallow
+try {
+  user = await fetchUser(userId)
+} catch (error) {
+  // ignore
+}
+```
+
+## 5. Immutability
+
+**DO:** Create new objects instead of mutating existing ones. Immutable data prevents hidden side effects and makes code easier to reason about.
+
+- Use spread operators, `map`, `filter`, `reduce` to derive new values
+- Treat function arguments as read-only
+- Use `readonly` modifiers or frozen objects where the language supports it
+- Return new objects from update functions
+
+**DON'T:**
+
+- Reassign function parameters
+- Use `push`, `splice`, `pop` on arrays shared across boundaries
+- Modify objects passed into a function from the caller's scope
+- Use mutable global state
+
+**Exception:** Mutation is acceptable when an API explicitly requires it (e.g., OpenCode config hooks, database transaction builders, stream writers).
+
+```
+// DO: Return new object
+function addItem(cart, item) {
+  return {
+    ...cart,
+    items: [...cart.items, item],
+    total: cart.total + item.price,
+  }
+}
+
+// DON'T: Mutate in place
+function addItem(cart, item) {
+  cart.items.push(item)
+  cart.total += item.price
+  return cart
+}
+```
+
+## 6. Separation of Concerns
+
+**DO:** Keep distinct responsibilities in distinct layers. Each layer should be independently testable.
+
+- Data access (repositories, API clients) separate from business logic
+- Business logic separate from presentation and formatting
+- Define interfaces at layer boundaries
+- Infrastructure concerns (logging, caching, auth) as cross-cutting middleware, not inline code
+
+**DON'T:**
+
+- Mix HTTP/request handling with business rules
+- Put database queries inside UI rendering code
+- Scatter validation logic across multiple layers (validate once at the boundary)
+- Hard-code infrastructure dependencies inside business logic
+
+```
+// DO: Layered
+orderRepository.save(order)          // data access
+orderService.calculateTotal(order)   // business logic
+orderView.formatSummary(order)       // presentation
+
+// DON'T: Mixed concerns
+function handleOrderRequest(req, res) {
+  db.query("INSERT INTO orders ...")  // data access in handler
+  total = items.reduce(...)           // business logic in handler
+  res.send("<h1>" + total + "</h1>")  // presentation in handler
+}
+```
+
+## 7. DRY (Don't Repeat Yourself)
+
+**DO:** Extract shared logic when you see the same pattern duplicated 3 or more times.
+
+- Create utility functions for repeated operations
+- Use composition to share behavior between modules
+- Centralize constants and configuration values
+
+**DON'T:**
+
+- Over-abstract before duplication exists (YAGNI -- You Aren't Gonna Need It)
+- Create abstractions for things that are only superficially similar
+- Use inheritance as the primary mechanism for code reuse (prefer composition)
+- Extract "shared" code that is actually used in only one place
+
+```
+// DO: Extract after 3+ duplications
+function formatCurrency(amount, currency) {
+  return `${currencySymbol(currency)}${amount.toFixed(2)}`
+}
+
+// DON'T: Premature abstraction
+// Creating a CurrencyFormatterFactory when you have one format
+class CurrencyFormatterFactory {
+  create(locale, options) { ... }
+}
+```
+
+## 8. Input Validation
+
+**DO:** Validate all external data at system boundaries. Never trust input from users, APIs, files, or environment variables.
+
+- Use schema-based validation (Zod, JSON Schema, etc.) for structured input
+- Validate as early as possible -- fail fast with clear error messages
+- Sanitize strings that will be used in HTML, SQL, or shell commands
+- Define allowed values explicitly (allowlists over blocklists)
+
+**DON'T:**
+
+- Trust external data without validation
+- Validate deep inside business logic instead of at the boundary
+- Use blocklists for security-sensitive input (always use allowlists)
+- Accept arbitrary types and check with `typeof` throughout the code
+
+```
+// DO: Schema validation at boundary
+schema = object({
+  email: string().email(),
+  age: number().int().min(0).max(150),
+})
+validated = schema.parse(requestBody)
+
+// DON'T: Ad-hoc checks scattered everywhere
+if (typeof input.email === "string" && input.email.includes("@")) {
+  if (typeof input.age === "number" && input.age > 0) {
+    // ... buried validation
+  }
+}
+```
+
+## 9. Constants and Configuration
+
+**DO:** Use named constants and configuration files for values that may change or carry meaning.
+
+- Named constants for magic numbers and strings (`MAX_RETRIES = 3`, not just `3`)
+- Environment variables or config files for deployment-specific values
+- Group related constants in a dedicated module
+- Document units in constant names (`TIMEOUT_MS = 5000`, `MAX_FILE_SIZE_BYTES = 10485760`)
+
+**DON'T:**
+
+- Hardcode URLs, API keys, timeouts, or limits in application code
+- Use magic numbers without explanation (`if (retries > 3)` -- why 3?)
+- Store secrets in source code or config files committed to version control
+- Scatter the same constant value across multiple files
+
+```
+// DO: Named constants with units
+CACHE_TTL_SECONDS = 300
+MAX_UPLOAD_SIZE_BYTES = 10 * 1024 * 1024
+API_BASE_URL = config.get("api.baseUrl")
+
+// DON'T: Magic values
+setTimeout(callback, 300000)
+if (file.size > 10485760) { ... }
+fetch("https://api.example.com/v2/users")
+```
+
+## 10. Code Comments
+
+**DO:** Comment the WHY, not the WHAT. Code should be readable enough that the "what" is obvious. Comments explain intent, trade-offs, and non-obvious decisions.
+
+- Explain why a non-obvious approach was chosen over the obvious one
+- Document edge cases and their handling rationale
+- Use JSDoc/docstrings for public API surfaces (parameters, return values, exceptions)
+- Mark temporary workarounds with `TODO(reason):` and a tracking reference
+
+**DON'T:**
+
+- Write comments that restate what the code does (`// increment counter` above `counter++`)
+- Leave commented-out code in the codebase (use version control instead)
+- Write comments that will become stale when the code changes
+- Use comments as a substitute for clear naming and structure
+
+```
+// DO: Explain why
+// Rate limit is 100/min per API docs. We use 80 to leave headroom
+// for background jobs that share the same API key.
+MAX_REQUESTS_PER_MINUTE = 80
+
+// DON'T: Restate the code
+// Set the max requests to 80
+MAX_REQUESTS_PER_MINUTE = 80
+```

package/package.json

@@ -0,0 +1,52 @@
+{
+	"name": "@kodrunhq/opencode-autopilot",
+	"version": "0.1.0",
+	"description": "Curated agents, skills, and commands for the OpenCode AI coding CLI — autonomous orchestrator, multi-agent code review, model fallback, and in-session asset creation tools.",
+	"main": "src/index.ts",
+	"keywords": [
+		"opencode",
+		"opencode-plugin",
+		"ai",
+		"agents",
+		"code-review",
+		"orchestrator",
+		"model-fallback"
+	],
+	"license": "MIT",
+	"repository": {
+		"type": "git",
+		"url": "git+https://github.com/kodrunhq/opencode-autopilot.git"
+	},
+	"homepage": "https://github.com/kodrunhq/opencode-autopilot#readme",
+	"bugs": {
+		"url": "https://github.com/kodrunhq/opencode-autopilot/issues"
+	},
+	"author": "kodrunhq",
+	"publishConfig": {
+		"access": "public",
+		"provenance": true
+	},
+	"devDependencies": {
+		"@biomejs/biome": "^2.4.10",
+		"@opencode-ai/plugin": "^1.3.8",
+		"@types/bun": "^1.3.11",
+		"typescript": "^6.0.2"
+	},
+	"peerDependencies": {
+		"@opencode-ai/plugin": ">=1.3.0"
+	},
+	"files": [
+		"src/",
+		"assets/"
+	],
+	"scripts": {
+		"test": "bun test",
+		"lint": "biome check .",
+		"format": "biome format . --write",
+		"prepublishOnly": "bun test && bunx tsc --noEmit"
+	},
+	"type": "module",
+	"dependencies": {
+		"yaml": "^2.8.3"
+	}
+}

package/src/agents/autopilot.ts

@@ -0,0 +1,42 @@
+import type { AgentConfig } from "@opencode-ai/sdk";
+
+export const autopilotAgent: Readonly<AgentConfig> = Object.freeze({
+	description:
+		"Tell me what to build and I'll handle research, architecture, planning, implementation, review, and delivery -- fully autonomous.",
+	mode: "all",
+	maxSteps: 50,
+	prompt: `You are the autopilot agent. You drive a multi-phase SDLC pipeline using the oc_orchestrate tool.
+
+## Loop
+
+1. Call oc_orchestrate with your initial idea (first turn) or with the result from the previous agent.
+2. Parse the JSON response.
+3. If action is "dispatch": call the named agent with the provided prompt, then pass its output back to oc_orchestrate via the result parameter.
+4. If action is "dispatch_multi": call each agent in the agents array (in parallel if appropriate). As each agent finishes, call oc_orchestrate again with that agent's full output as the result parameter. Do NOT combine multiple agents' outputs into a single result.
+5. If action is "complete": report the summary to the user. You are done.
+6. If action is "error": report the error to the user. Stop.
+
+## Rules
+
+- NEVER skip calling oc_orchestrate. It is the single source of truth for pipeline state.
+- NEVER make pipeline decisions yourself. Always defer to oc_orchestrate.
+- ALWAYS pass the full agent output back as the result parameter.
+- Do not attempt to run phases out of order.
+- Do not retry a failed phase unless oc_orchestrate instructs you to.
+- If an agent dispatch fails, pass the error message back to oc_orchestrate as the result.
+
+## Example Turn Sequence
+
+Turn 1: oc_orchestrate(idea="Build a CLI tool")
+  -> {action:"dispatch", agent:"oc-researcher", prompt:"Research: Build a CLI tool", phase:"RECON"}
+Turn 2: @oc-researcher "Research: Build a CLI tool"
+  -> "Research findings: ..."
+Turn 3: oc_orchestrate(result="Research findings: ...")
+  -> {action:"dispatch", agent:"oc-challenger", prompt:"Challenge: ...", phase:"CHALLENGE"}
+... continues until action is "complete"`,
+	permission: {
+		edit: "allow",
+		bash: "allow",
+		webfetch: "allow",
+	} as const,
+});

package/src/agents/documenter.ts

@@ -0,0 +1,44 @@
+import type { AgentConfig } from "@opencode-ai/sdk";
+
+export const documenterAgent: Readonly<AgentConfig> = Object.freeze({
+	description:
+		"Creates and maintains documentation, READMEs, architecture diagrams, and developer guides",
+	mode: "subagent",
+	prompt: `You are a technical documentation specialist. Your job is to create polished, comprehensive documentation for codebases and projects.
+
+## Instructions
+
+1. Read the codebase to understand the project structure, public APIs, and conventions.
+2. Reference the coding-standards skill at ~/.config/opencode/skills/coding-standards/SKILL.md for conventions when documenting code patterns and style guidelines.
+3. Generate documentation that is accurate, well-organized, and immediately useful to developers.
+4. Create or edit documentation files directly — you have permission to modify existing docs.
+
+## Capabilities
+
+You can produce any of the following:
+
+- **README files** — project overview, installation, usage, contributing guidelines.
+- **Architecture documents** — system design, component relationships, data flow using Mermaid diagrams.
+- **API documentation** — endpoint references, type definitions, usage examples.
+- **Developer guides** — quickstart tutorials, setup instructions, troubleshooting.
+- **GitHub badges** — shields.io badge markdown for CI status, version, license, coverage.
+- **Changelogs** — structured release notes following Keep a Changelog format.
+
+## Output Format
+
+Write documentation as polished markdown. Use headings, lists, code blocks, tables, and Mermaid diagram blocks as appropriate. Documentation should be ready to commit without further editing.
+
+## Constraints
+
+- DO read source code thoroughly before writing documentation — accuracy is paramount.
+- DO reference existing conventions and coding-standards for consistency.
+- DO create new files or edit existing documentation files as needed.
+- DO NOT run shell commands.
+- DO NOT access the web.
+- DO NOT modify source code files — only documentation files (.md, .txt, diagrams).`,
+	permission: {
+		edit: "allow",
+		bash: "deny",
+		webfetch: "deny",
+	} as const,
+});

package/src/agents/index.ts

@@ -0,0 +1,49 @@
+import type { Config } from "@opencode-ai/plugin";
+import { autopilotAgent } from "./autopilot";
+import { documenterAgent } from "./documenter";
+import { metaprompterAgent } from "./metaprompter";
+import { pipelineAgents } from "./pipeline/index";
+import { prReviewerAgent } from "./pr-reviewer";
+import { researcherAgent } from "./researcher";
+
+const agents = {
+	researcher: researcherAgent,
+	metaprompter: metaprompterAgent,
+	documenter: documenterAgent,
+	"pr-reviewer": prReviewerAgent,
+	autopilot: autopilotAgent,
+} as const;
+
+export async function configHook(config: Config): Promise<void> {
+	if (!config.agent) {
+		config.agent = {};
+	}
+	for (const [name, agentConfig] of Object.entries(agents)) {
+		// Only set if not already defined — preserve user customizations (Pitfall 2)
+		if (config.agent[name] === undefined) {
+			// Mutation of config.agent is intentional: the OpenCode plugin configHook
+			// API requires mutating the provided Config object to register agents.
+			// We deep-copy agent config including nested permission to avoid shared references.
+			config.agent[name] = {
+				...agentConfig,
+				...(agentConfig.permission && { permission: { ...agentConfig.permission } }),
+			};
+		}
+	}
+
+	// Register pipeline agents (v2 orchestrator subagents)
+	for (const [name, agentConfig] of Object.entries(pipelineAgents)) {
+		if (config.agent[name] === undefined) {
+			config.agent[name] = {
+				...agentConfig,
+				...(agentConfig.permission && { permission: { ...agentConfig.permission } }),
+			};
+		}
+	}
+}
+
+export { autopilotAgent } from "./autopilot";
+export { documenterAgent } from "./documenter";
+export { metaprompterAgent } from "./metaprompter";
+export { prReviewerAgent } from "./pr-reviewer";
+export { researcherAgent } from "./researcher";