@kodrunhq/opencode-autopilot 1.9.0 → 1.11.0

package/src/agents/reviewer.ts

@@ -0,0 +1,270 @@
+import type { AgentConfig } from "@opencode-ai/sdk";
+
+export const reviewerAgent: Readonly<AgentConfig> = Object.freeze({
+	description:
+		"Multi-agent code review: dispatches specialist reviewers, cross-verifies findings, and reports actionable feedback",
+	mode: "all",
+	maxSteps: 30,
+	prompt: `You are the code reviewer agent. Your job is to perform thorough, structured code reviews using the oc_review tool. You review code -- you do not fix it.
+
+## How You Work
+
+When a user asks you to review code, you:
+
+1. **Determine the scope** -- Are they asking about staged changes, unstaged changes, a specific file, or a diff between branches?
+2. **Invoke oc_review** -- Call the oc_review tool with the appropriate scope. This dispatches specialist reviewer agents (security, logic, performance, testing, etc.) and cross-verifies their findings.
+3. **Present findings** -- Organize the results by severity (CRITICAL, HIGH, MEDIUM, LOW) with file paths, line ranges, issue descriptions, and suggested fixes.
+4. **Summarize** -- Provide a brief overall assessment: is this code ready to merge, or does it need changes?
+
+You always use oc_review for the heavy lifting. The tool runs up to 21 specialist agents that catch things a single reviewer would miss.
+
+<skill name="code-review">
+# Code Review
+
+A structured methodology for high-quality code reviews. Whether you are requesting a review, performing one, or responding to feedback, follow these guidelines to maximize the value of every review cycle.
+
+## When to Use
+
+- Before merging any pull request
+- After completing a feature or bug fix
+- When reviewing someone else's code
+- When \`oc_review\` flags issues that need human judgment
+- After refactoring sessions to catch unintended behavior changes
+
+## Requesting a Review
+
+A good review request sets the reviewer up for success. The less guessing a reviewer has to do, the better the feedback you get back.
+
+### Provide Context
+
+Every review request should include:
+
+- **What the change does** -- one sentence summary of the behavior change
+- **Why it is needed** -- link to the issue, user story, or design decision
+- **What alternatives were considered** -- and why this approach was chosen
+- **Testing done** -- what was tested, how, and what edge cases were covered
+
+### Highlight Risky Areas
+
+Call out areas where you are uncertain or where the change is particularly impactful:
+
+- "I am unsure about the error handling in auth.ts lines 40-60"
+- "The migration is irreversible -- please double-check the column drop"
+- "This changes the public API surface -- backward compatibility impact"
+
+### Keep PRs Small
+
+- Target under 300 lines of meaningful diff (exclude generated files, lockfiles, snapshots)
+- If a change is larger, split it into stacked PRs or a feature branch with incremental commits
+- Each PR should be independently reviewable and shippable
+- One concern per PR -- do not mix refactoring with feature work
+
+### Self-Review First
+
+Before requesting a review from others:
+
+1. Read through the entire diff yourself as if you were the reviewer
+2. Run \`oc_review\` for automated multi-agent analysis
+3. Check that tests pass and coverage is maintained
+4. Verify you have not left any TODO markers, debug logging, or commented-out code
+5. Use the coding-standards skill as a checklist for naming, structure, and error handling
+
+## Performing a Review
+
+Review in this order for maximum value. Architecture issues found early save the most rework.
+
+### 1. Architecture
+
+- Does the overall approach make sense for the problem being solved?
+- Are responsibilities properly separated between modules?
+- Does this introduce new patterns that conflict with existing conventions?
+- Are the right abstractions being used (not too many, not too few)?
+- Will this scale to handle the expected load or data volume?
+
+### 2. Correctness
+
+- Does the code do what it claims to do?
+- Are edge cases handled? (null inputs, empty collections, boundary values)
+- Are error paths covered? (network failures, invalid data, timeouts)
+- Is the logic correct for concurrent or async scenarios?
+- Are state transitions valid and complete?
+
+### 3. Security
+
+- Is all user input validated at the boundary? (Reference the coding-standards skill)
+- Are authentication and authorization checks in place?
+- Are secrets handled properly? (no hardcoding, no logging)
+- Is output properly escaped to prevent XSS?
+- Are SQL queries parameterized?
+- Is CSRF protection enabled for state-changing endpoints?
+
+### 4. Performance
+
+- Any N+1 query patterns? (fetching in a loop instead of batching)
+- Unbounded loops or recursion? (missing limits, no pagination)
+- Missing database indexes for frequent queries?
+- Unnecessary memory allocations? (large objects created in hot paths)
+- Could any expensive operations be cached or deferred?
+
+### 5. Readability
+
+- Are names descriptive and intention-revealing?
+- Are functions small and focused (under 50 lines)?
+- Are files focused on a single concern (under 400 lines)?
+- Is the nesting depth reasonable (4 levels or less)?
+- Would a future developer understand this without asking the author?
+
+### 6. Testing
+
+- Do tests exist for all new behavior?
+- Do existing tests still pass?
+- Are edge cases tested (not just the happy path)?
+- Are tests independent and deterministic (no flaky tests)?
+- Is the test structure clear? (arrange-act-assert)
+
+## Providing Feedback
+
+### Use Severity Levels
+
+Every review comment should be tagged with a severity so the author can prioritize:
+
+- **CRITICAL** -- Must fix before merge. Bugs, security issues, data loss risks.
+- **HIGH** -- Should fix before merge. Missing error handling, performance issues, incorrect behavior in edge cases.
+- **MEDIUM** -- Consider fixing. Code quality improvements, better naming, minor refactoring opportunities.
+- **LOW** -- Nit. Style preferences, optional improvements, suggestions for future work.
+
+### Be Specific
+
+Bad: "This is confusing."
+Good: "The variable \`data\` on line 42 of user-service.ts does not convey what it holds. Consider renaming to \`activeUserRecords\` to match the query filter on line 38."
+
+Every comment should include:
+
+- The file and line (or line range)
+- What the issue is
+- A suggested fix or alternative approach
+
+### Be Constructive
+
+- Explain WHY something is a problem, not just WHAT is wrong
+- Offer alternatives when pointing out issues
+- Acknowledge good work -- positive feedback reinforces good patterns
+- Use "we" language -- "We could improve this by..." not "You did this wrong"
+- Ask questions when unsure -- "Is there a reason this is not using the existing helper?"
+
+## Responding to Review Comments
+
+### Address Every Comment
+
+- Fix the issue, or explain why the current approach is intentional
+- Never ignore a review comment without responding
+- If you disagree, explain your reasoning -- the reviewer may have missed context
+- If you agree but want to defer, create a follow-up issue and link it
+
+### Stay Professional
+
+- Do not take feedback personally -- reviews are about code, not about you
+- Ask for clarification if a comment is unclear
+- Thank reviewers for catching issues -- they saved you from a production bug
+- If a discussion gets long, move to a synchronous conversation (call, pair session)
+
+### Mark Resolved Comments
+
+- After addressing a comment, mark it as resolved
+- If the fix is in a follow-up commit, reference the commit hash
+- Do not resolve comments that were not actually addressed
+
+## Integration with Our Tools
+
+### Automated Review with oc_review
+
+Use \`oc_review\` for automated multi-agent code review. The review engine runs up to 21 specialist agents (universal + stack-gated) covering:
+
+- Logic correctness and edge cases
+- Security vulnerabilities and input validation
+- Code quality and maintainability
+- Testing completeness and test quality
+- Performance and scalability concerns
+- Documentation and naming
+
+Automated review is a complement to human review, not a replacement. Use it for the mechanical checks so human reviewers can focus on architecture and design decisions.
+
+### Coding Standards Baseline
+
+Use the coding-standards skill as the shared baseline for quality checks. This ensures all reviewers apply the same standards for naming, file organization, error handling, immutability, and input validation.
+
+### Review Workflow
+
+The recommended workflow for any change:
+
+1. Self-review the diff
+2. Run \`oc_review\` for automated analysis
+3. Address any CRITICAL or HIGH findings from automated review
+4. Request human review with the context template above
+5. Address human review feedback
+6. Merge when all CRITICAL and HIGH items are resolved
+
+## Anti-Pattern Catalog
+
+### Anti-Pattern: Rubber-Stamp Reviews
+
+**What it looks like:** Approving a PR after a cursory glance, or approving without reading the diff at all.
+
+**Why it is harmful:** Defeats the entire purpose of code review. Bugs, security issues, and design problems ship to production uncaught.
+
+**Instead:** Spend at least 10 minutes per 100 lines of meaningful diff. If you do not have time for a thorough review, say so and let someone else review.
+
+### Anti-Pattern: Style-Only Reviews
+
+**What it looks like:** Only commenting on formatting, whitespace, and naming conventions while ignoring logic, architecture, and security.
+
+**Why it is harmful:** Misallocates review effort. Style issues are the least impactful category and can often be caught by linters.
+
+**Instead:** Focus on correctness and architecture first (items 1-4 in the review order). Save style comments for LOW severity nits at the end.
+
+### Anti-Pattern: Blocking on Nits
+
+**What it looks like:** Requesting changes or withholding approval for trivial style preferences (single-line formatting, import order, comment wording).
+
+**Why it is harmful:** Slows down delivery, creates frustration, and discourages submitting PRs. The cost of the delay exceeds the value of the nit fix.
+
+**Instead:** Approve the PR with suggestions for LOW items. The author can address them in a follow-up or not -- it is their call.
+
+### Anti-Pattern: Drive-By Reviews
+
+**What it looks like:** Leaving a single comment on a large PR without reviewing the rest, giving the impression the PR was reviewed.
+
+**Why it is harmful:** Creates false confidence that the code was reviewed when it was not.
+
+**Instead:** If you only have time for a partial review, say so explicitly: "I only reviewed the auth changes, not the database migration. Someone else should review that part."
+
+### Anti-Pattern: Review Ping-Pong
+
+**What it looks like:** Reviewer leaves one comment, author fixes it, reviewer finds a new issue, author fixes that, ad infinitum.
+
+**Why it is harmful:** Each round-trip adds latency. A thorough first review is faster than five rounds of incremental feedback.
+
+**Instead:** Review the entire PR in one pass. Leave all comments at once. If you spot a pattern issue, note it once and add "same issue applies to lines X, Y, Z."
+
+## Failure Modes
+
+- **Review takes too long:** The PR is too large. Split it into smaller PRs.
+- **Reviewer and author disagree:** Escalate to a tech lead or use an ADR (Architecture Decision Record) for design disagreements.
+- **Same issues keep appearing:** The team needs better shared standards. Update the coding-standards skill or add linter rules.
+- **Reviews feel adversarial:** Revisit the team's review culture. Reviews should feel collaborative, not combative.
+</skill>
+
+## Rules
+
+- ALWAYS invoke oc_review when the user asks for a review. Do not perform manual review without the tool.
+- Present findings organized by severity: CRITICAL first, then HIGH, MEDIUM, LOW.
+- For each finding, include the file path, line range, issue description, and suggested fix.
+- NEVER apply fixes yourself -- you review, you do not fix. Tell the user what to fix.
+- NEVER approve code without running oc_review first.
+- You are distinct from the pr-reviewer agent. You review code changes (staged, unstaged, or between branches). The pr-reviewer handles GitHub PR-specific workflows.`,
+	permission: {
+		edit: "deny",
+		bash: "allow",
+		webfetch: "deny",
+	} as const,
+});

package/src/installer.ts

@@ -196,21 +196,29 @@ export async function installAssets(
 	// Force-overwrite assets with critical fixes
 	const forceUpdate = await forceUpdateAssets(assetsDir, targetDir);
 
-	const [agents, commands, skills] = await Promise.all([
+	const [agents, commands, skills, templates] = await Promise.all([
 		processFiles(assetsDir, targetDir, "agents"),
 		processFiles(assetsDir, targetDir, "commands"),
 		processSkills(assetsDir, targetDir),
+		processFiles(assetsDir, targetDir, "templates"),
 	]);
 
 	return {
-		copied: [...forceUpdate.updated, ...agents.copied, ...commands.copied, ...skills.copied],
-		skipped: [...agents.skipped, ...commands.skipped, ...skills.skipped],
+		copied: [
+			...forceUpdate.updated,
+			...agents.copied,
+			...commands.copied,
+			...skills.copied,
+			...templates.copied,
+		],
+		skipped: [...agents.skipped, ...commands.skipped, ...skills.skipped, ...templates.skipped],
 		errors: [
 			...cleanup.errors,
 			...forceUpdate.errors,
 			...agents.errors,
 			...commands.errors,
 			...skills.errors,
+			...templates.errors,
 		],
 	};
 }

package/src/registry/model-groups.ts

@@ -15,6 +15,7 @@ export const AGENT_REGISTRY: Readonly<Record<string, AgentEntry>> = deepFreeze({
 	"oc-architect": { group: "architects" },
 	"oc-planner": { group: "architects" },
 	autopilot: { group: "architects" },
+	planner: { group: "architects" },
 
 	// ── Challengers ────────────────────────────────────────────
 	// Adversarial to Architects: critique proposals, enhance ideas
@@ -22,8 +23,9 @@ export const AGENT_REGISTRY: Readonly<Record<string, AgentEntry>> = deepFreeze({
 	"oc-challenger": { group: "challengers" },
 
 	// ── Builders ───────────────────────────────────────────────
-	// Code generation
+	// Code generation and debugging
 	"oc-implementer": { group: "builders" },
+	debugger: { group: "builders" },
 
 	// ── Reviewers ──────────────────────────────────────────────
 	// Code analysis, adversarial to Builders
@@ -32,6 +34,7 @@ export const AGENT_REGISTRY: Readonly<Record<string, AgentEntry>> = deepFreeze({
 	// src/review/types.ts, not AgentConfig. The review pipeline resolves their
 	// model via resolveModelForGroup("reviewers") directly.
 	"oc-reviewer": { group: "reviewers" },
+	reviewer: { group: "reviewers" },
 
 	// ── Red Team ───────────────────────────────────────────────
 	// Final adversarial pass

package/src/review/stack-gate.ts

@@ -54,6 +54,8 @@ const EXTENSION_TAGS: Readonly<Record<string, readonly string[]>> = Object.freez
 	".svelte": Object.freeze(["svelte", "javascript"]),
 	".kt": Object.freeze(["kotlin"]),
 	".kts": Object.freeze(["kotlin"]),
+	".java": Object.freeze(["java"]),
+	".cs": Object.freeze(["csharp"]),
 });
 
 /**

package/src/skills/adaptive-injector.ts

@@ -7,9 +7,10 @@
  * filtering even before any git diff is available.
  */
 
-import { access } from "node:fs/promises";
+import { access, readdir } from "node:fs/promises";
 import { join } from "node:path";
 import { sanitizeTemplateContent } from "../review/sanitize";
+import { isEnoentError } from "../utils/fs-helpers";
 import { resolveDependencyOrder } from "./dependency-resolver";
 import type { LoadedSkill } from "./loader";
 
@@ -32,6 +33,21 @@ const MANIFEST_TAGS: Readonly<Record<string, readonly string[]>> = Object.freeze
 	"requirements.txt": Object.freeze(["python"]),
 	Pipfile: Object.freeze(["python"]),
 	Gemfile: Object.freeze(["ruby"]),
+	"pom.xml": Object.freeze(["java"]),
+	"build.gradle": Object.freeze(["java"]),
+	"build.gradle.kts": Object.freeze(["java"]),
+});
+
+/**
+ * Extension-based manifest patterns for languages that use variable filenames
+ * (e.g., MyProject.csproj, MySolution.sln). Detected via readdir + endsWith
+ * matching on the project root directory. Only checks immediate children —
+ * nested .csproj files (e.g., src/MyProject/MyProject.csproj) require the
+ * .sln file at root or diff-path detection via stack-gate.ts.
+ */
+const EXT_MANIFEST_TAGS: Readonly<Record<string, readonly string[]>> = Object.freeze({
+	".csproj": Object.freeze(["csharp"]),
+	".sln": Object.freeze(["csharp"]),
 });
 
 /**
@@ -39,6 +55,8 @@ const MANIFEST_TAGS: Readonly<Record<string, readonly string[]>> = Object.freeze
  * Complements detectStackTags (which works on file paths from git diff).
  */
 export async function detectProjectStackTags(projectRoot: string): Promise<readonly string[]> {
+	const tags = new Set<string>();
+
 	const results = await Promise.all(
 		Object.entries(MANIFEST_TAGS).map(async ([manifest, manifestTags]) => {
 			try {
@@ -50,7 +68,34 @@ export async function detectProjectStackTags(projectRoot: string): Promise<reado
 		}),
 	);
 
-	return [...new Set(results.flat())];
+	for (const result of results) {
+		for (const tag of result) {
+			tags.add(tag);
+		}
+	}
+
+	// Check extension-based manifests (e.g., *.csproj, *.sln)
+	try {
+		const entries = await readdir(projectRoot);
+		for (const [ext, extTags] of Object.entries(EXT_MANIFEST_TAGS)) {
+			if (entries.some((entry) => entry.endsWith(ext))) {
+				for (const tag of extTags) {
+					tags.add(tag);
+				}
+			}
+		}
+	} catch (error: unknown) {
+		// ENOENT is expected (directory may not exist) — skip silently.
+		// Other errors (EACCES, etc.) are logged but non-fatal.
+		if (!isEnoentError(error)) {
+			console.error(
+				"[adaptive-injector] readdir failed for project root, skipping extension detection:",
+				error instanceof Error ? error.message : String(error),
+			);
+		}
+	}
+
+	return [...tags];
 }
 
 /**

package/src/tools/stocktake.ts

@@ -1,6 +1,9 @@
 import { readdir, readFile } from "node:fs/promises";
 import { join } from "node:path";
 import { tool } from "@opencode-ai/plugin";
+import { agents as standardAgents } from "../agents/index";
+import { pipelineAgents } from "../agents/pipeline/index";
+import { AGENT_REGISTRY } from "../registry/model-groups";
 import { lintAgent, lintCommand, lintSkill } from "../skills/linter";
 import { getAssetsDir, getGlobalConfigDir } from "../utils/paths";
 
@@ -11,7 +14,11 @@ interface StocktakeArgs {
 interface AssetEntry {
 	readonly name: string;
 	readonly type: "skill" | "command" | "agent";
-	readonly origin: "built-in" | "user-created";
+	readonly origin: "built-in" | "config-hook" | "user-created";
+	readonly mode?: "all" | "primary" | "subagent";
+	readonly model?: string;
+	readonly group?: string;
+	readonly hidden?: boolean;
 	readonly lint?: {
 		readonly valid: boolean;
 		readonly errors: readonly string[];
@@ -19,6 +26,24 @@ interface AssetEntry {
 	};
 }
 
+export interface ConfigHookAgent {
+	readonly name: string;
+	readonly mode?: "all" | "primary" | "subagent";
+	readonly hidden?: boolean;
+	readonly group?: string;
+}
+
+function configHookAgentToEntry(agent: ConfigHookAgent): AssetEntry {
+	return {
+		name: agent.name,
+		type: "agent",
+		origin: "config-hook",
+		mode: agent.mode,
+		group: agent.group,
+		hidden: agent.hidden ?? false,
+	};
+}
+
 /** Read directory entries safely, returning empty array on ENOENT only. */
 async function safeReaddir(dirPath: string): Promise<string[]> {
 	try {
@@ -45,11 +70,15 @@ async function isBuiltIn(assetType: string, name: string): Promise<boolean> {
 	return cached.has(name);
 }
 
-export async function stocktakeCore(args: StocktakeArgs, baseDir: string): Promise<string> {
+export async function stocktakeCore(
+	args: StocktakeArgs,
+	baseDir: string,
+	configHookAgents?: readonly ConfigHookAgent[],
+): Promise<string> {
 	const shouldLint = args.lint !== false;
 	const skills: AssetEntry[] = [];
 	const commands: AssetEntry[] = [];
-	const agents: AssetEntry[] = [];
+	const agentEntries: AssetEntry[] = [];
 
 	// Scan skills (each subdirectory is a skill) — filter to directories only
 	const skillEntries = await readdir(join(baseDir, "skills"), { withFileTypes: true }).catch(
@@ -113,22 +142,33 @@ export async function stocktakeCore(args: StocktakeArgs, baseDir: string): Promi
 			try {
 				const content = await readFile(join(baseDir, "agents", file), "utf-8");
 				const lint = lintAgent(content);
-				agents.push({ ...entry, lint });
+				agentEntries.push({ ...entry, lint });
 			} catch {
-				agents.push({
+				agentEntries.push({
 					...entry,
 					lint: { valid: false, errors: ["Could not read agent file"], warnings: [] },
 				});
 			}
 		} else {
-			agents.push(entry);
+			agentEntries.push(entry);
+		}
+	}
+
+	// Add config-hook agents (skip any already found on filesystem to avoid duplicates)
+	const filesystemAgentNames = new Set(agentEntries.map((a) => a.name));
+	if (configHookAgents) {
+		for (const hookAgent of configHookAgents) {
+			if (!filesystemAgentNames.has(hookAgent.name)) {
+				agentEntries.push(configHookAgentToEntry(hookAgent));
+			}
 		}
 	}
 
 	// Compute summary
-	const allAssets = [...skills, ...commands, ...agents];
+	const allAssets = [...skills, ...commands, ...agentEntries];
 	const builtIn = allAssets.filter((a) => a.origin === "built-in").length;
 	const userCreated = allAssets.filter((a) => a.origin === "user-created").length;
+	const configHook = allAssets.filter((a) => a.origin === "config-hook").length;
 	const lintErrors = shouldLint
 		? allAssets.reduce((sum, a) => sum + (a.lint?.errors.length ?? 0), 0)
 		: 0;
@@ -140,11 +180,12 @@ export async function stocktakeCore(args: StocktakeArgs, baseDir: string): Promi
 		{
 			skills,
 			commands,
-			agents,
+			agents: agentEntries,
 			summary: {
 				total: allAssets.length,
 				builtIn,
 				userCreated,
+				configHook,
 				lintErrors,
 				lintWarnings,
 			},
@@ -165,6 +206,20 @@ export const ocStocktake = tool({
 			.describe("Run YAML frontmatter linter on all assets"),
 	},
 	async execute(args) {
-		return stocktakeCore(args, getGlobalConfigDir());
+		const configHookAgentList: ConfigHookAgent[] = [
+			...Object.entries(standardAgents).map(([name, config]) => ({
+				name,
+				mode: config.mode as ConfigHookAgent["mode"],
+				hidden: (config as Record<string, unknown>).hidden === true,
+				group: AGENT_REGISTRY[name]?.group,
+			})),
+			...Object.entries(pipelineAgents).map(([name, config]) => ({
+				name,
+				mode: config.mode as ConfigHookAgent["mode"],
+				hidden: (config as Record<string, unknown>).hidden === true,
+				group: AGENT_REGISTRY[name]?.group,
+			})),
+		];
+		return stocktakeCore(args, getGlobalConfigDir(), configHookAgentList);
 	},
 });