@kodrunhq/opencode-autopilot 1.10.0 → 1.12.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/config.ts

@@ -2,7 +2,13 @@ import { randomBytes } from "node:crypto";
 import { readFile, rename, writeFile } from "node:fs/promises";
 import { dirname, join } from "node:path";
 import { z } from "zod";
-import { fallbackConfigSchema, fallbackDefaults } from "./orchestrator/fallback/fallback-config";
+import {
+	fallbackConfigSchema,
+	fallbackConfigSchemaV6,
+	fallbackDefaults,
+	fallbackDefaultsV6,
+	testModeDefaults,
+} from "./orchestrator/fallback/fallback-config";
 import { AGENT_REGISTRY, ALL_GROUP_IDS } from "./registry/model-groups";
 import { ensureDir, isEnoentError } from "./utils/fs-helpers";
 import { getGlobalConfigDir } from "./utils/paths";
@@ -149,10 +155,37 @@ const pluginConfigSchemaV5 = z
 		}
 	});
 
-// Export aliases updated to v5
-export const pluginConfigSchema = pluginConfigSchemaV5;
+type PluginConfigV5 = z.infer<typeof pluginConfigSchemaV5>;
 
-export type PluginConfig = z.infer<typeof pluginConfigSchemaV5>;
+// --- V6 schema ---
+
+const pluginConfigSchemaV6 = z
+	.object({
+		version: z.literal(6),
+		configured: z.boolean(),
+		groups: z.record(z.string(), groupModelAssignmentSchema).default({}),
+		overrides: z.record(z.string(), agentOverrideSchema).default({}),
+		orchestrator: orchestratorConfigSchema.default(orchestratorDefaults),
+		confidence: confidenceConfigSchema.default(confidenceDefaults),
+		fallback: fallbackConfigSchemaV6.default(fallbackDefaultsV6),
+		memory: memoryConfigSchema.default(memoryDefaults),
+	})
+	.superRefine((config, ctx) => {
+		for (const groupId of Object.keys(config.groups)) {
+			if (!ALL_GROUP_IDS.includes(groupId as (typeof ALL_GROUP_IDS)[number])) {
+				ctx.addIssue({
+					code: z.ZodIssueCode.custom,
+					path: ["groups", groupId],
+					message: `Unknown group id "${groupId}". Expected one of: ${ALL_GROUP_IDS.join(", ")}`,
+				});
+			}
+		}
+	});
+
+// Export aliases updated to v6
+export const pluginConfigSchema = pluginConfigSchemaV6;
+
+export type PluginConfig = z.infer<typeof pluginConfigSchemaV6>;
 
 export const CONFIG_PATH = join(getGlobalConfigDir(), "opencode-autopilot.json");
 
@@ -228,7 +261,7 @@ function migrateV3toV4(v3Config: PluginConfigV3): PluginConfigV4 {
 	};
 }
 
-function migrateV4toV5(v4Config: PluginConfigV4): PluginConfig {
+function migrateV4toV5(v4Config: PluginConfigV4): PluginConfigV5 {
 	return {
 		version: 5 as const,
 		configured: v4Config.configured,
@@ -241,6 +274,19 @@ function migrateV4toV5(v4Config: PluginConfigV4): PluginConfig {
 	};
 }
 
+function migrateV5toV6(v5Config: PluginConfigV5): PluginConfig {
+	return {
+		version: 6 as const,
+		configured: v5Config.configured,
+		groups: v5Config.groups,
+		overrides: v5Config.overrides,
+		orchestrator: v5Config.orchestrator,
+		confidence: v5Config.confidence,
+		fallback: { ...v5Config.fallback, testMode: testModeDefaults },
+		memory: v5Config.memory,
+	};
+}
+
 // --- Public API ---
 
 export async function loadConfig(configPath: string = CONFIG_PATH): Promise<PluginConfig | null> {
@@ -248,49 +294,61 @@ export async function loadConfig(configPath: string = CONFIG_PATH): Promise<Plug
 		const raw = await readFile(configPath, "utf-8");
 		const parsed = JSON.parse(raw);
 
-		// Try v5 first
+		// Try v6 first
+		const v6Result = pluginConfigSchemaV6.safeParse(parsed);
+		if (v6Result.success) return v6Result.data;
+
+		// Try v5 and migrate to v6
 		const v5Result = pluginConfigSchemaV5.safeParse(parsed);
-		if (v5Result.success) return v5Result.data;
+		if (v5Result.success) {
+			const migrated = migrateV5toV6(v5Result.data);
+			await saveConfig(migrated, configPath);
+			return migrated;
+		}
 
-		// Try v4 and migrate to v5
+		// Try v4 → v5 → v6
 		const v4Result = pluginConfigSchemaV4.safeParse(parsed);
 		if (v4Result.success) {
-			const migrated = migrateV4toV5(v4Result.data);
+			const v5 = migrateV4toV5(v4Result.data);
+			const migrated = migrateV5toV6(v5);
 			await saveConfig(migrated, configPath);
 			return migrated;
 		}
 
-		// Try v3 → v4 → v5
+		// Try v3 → v4 → v5 → v6
 		const v3Result = pluginConfigSchemaV3.safeParse(parsed);
 		if (v3Result.success) {
 			const v4 = migrateV3toV4(v3Result.data);
-			const migrated = migrateV4toV5(v4);
+			const v5 = migrateV4toV5(v4);
+			const migrated = migrateV5toV6(v5);
 			await saveConfig(migrated, configPath);
 			return migrated;
 		}
 
-		// Try v2 → v3 → v4 → v5
+		// Try v2 → v3 → v4 → v5 → v6
 		const v2Result = pluginConfigSchemaV2.safeParse(parsed);
 		if (v2Result.success) {
 			const v3 = migrateV2toV3(v2Result.data);
 			const v4 = migrateV3toV4(v3);
-			const migrated = migrateV4toV5(v4);
+			const v5 = migrateV4toV5(v4);
+			const migrated = migrateV5toV6(v5);
 			await saveConfig(migrated, configPath);
 			return migrated;
 		}
 
-		// Try v1 → v2 → v3 → v4 → v5
+		// Try v1 → v2 → v3 → v4 → v5 → v6
 		const v1Result = pluginConfigSchemaV1.safeParse(parsed);
 		if (v1Result.success) {
 			const v2 = migrateV1toV2(v1Result.data);
 			const v3 = migrateV2toV3(v2);
 			const v4 = migrateV3toV4(v3);
-			const migrated = migrateV4toV5(v4);
+			const v5 = migrateV4toV5(v4);
+			const migrated = migrateV5toV6(v5);
 			await saveConfig(migrated, configPath);
 			return migrated;
 		}
 
-		return pluginConfigSchemaV5.parse(parsed); // throw with proper error
+		return pluginConfigSchemaV6.parse(parsed); // throw with proper error
 	} catch (error: unknown) {
 		if (isEnoentError(error)) return null;
 		throw error;
@@ -313,13 +371,13 @@ export function isFirstLoad(config: PluginConfig | null): boolean {
 
 export function createDefaultConfig(): PluginConfig {
 	return {
-		version: 5 as const,
+		version: 6 as const,
 		configured: false,
 		groups: {},
 		overrides: {},
 		orchestrator: orchestratorDefaults,
 		confidence: confidenceDefaults,
-		fallback: fallbackDefaults,
+		fallback: fallbackDefaultsV6,
 		memory: memoryDefaults,
 	};
 }

package/src/health/checks.ts

@@ -1,7 +1,13 @@
-import { access } from "node:fs/promises";
+import { Database } from "bun:sqlite";
+import { access, readFile, stat } from "node:fs/promises";
+import { join } from "node:path";
 import type { Config } from "@opencode-ai/plugin";
+import { parse } from "yaml";
 import { loadConfig } from "../config";
+import { DB_FILE, MEMORY_DIR } from "../memory/constants";
 import { AGENT_NAMES } from "../orchestrator/handlers/types";
+import { detectProjectStackTags, filterSkillsByStack } from "../skills/adaptive-injector";
+import { loadAllSkills } from "../skills/loader";
 import { getAssetsDir, getGlobalConfigDir } from "../utils/paths";
 import type { HealthResult } from "./types";
 
@@ -123,3 +129,178 @@ export async function assetHealthCheck(
 		});
 	}
 }
+
+/**
+ * Check skill loading status per detected project stack.
+ * Reports which stacks are detected and how many skills match.
+ * Accepts optional skillsDir for testability (defaults to global config skills dir).
+ */
+export async function skillHealthCheck(
+	projectRoot: string,
+	skillsDir?: string,
+): Promise<HealthResult> {
+	try {
+		const tags = await detectProjectStackTags(projectRoot);
+		const resolvedSkillsDir = skillsDir ?? join(getGlobalConfigDir(), "skills");
+		const allSkills = await loadAllSkills(resolvedSkillsDir);
+		const filtered = filterSkillsByStack(allSkills, tags);
+
+		const stackLabel = tags.length > 0 ? tags.join(", ") : "none";
+		return Object.freeze({
+			name: "skill-loading",
+			status: "pass" as const,
+			message: `Detected stacks: [${stackLabel}], ${filtered.size}/${allSkills.size} skills matched`,
+			details: Object.freeze([...filtered.keys()]),
+		});
+	} catch (error: unknown) {
+		const msg = error instanceof Error ? error.message : String(error);
+		return Object.freeze({
+			name: "skill-loading",
+			status: "fail" as const,
+			message: `Skill check failed: ${msg}`,
+		});
+	}
+}
+
+/**
+ * Check memory DB health: existence, readability, observation count.
+ * Does NOT call getMemoryDb() to avoid creating an empty DB as a side effect.
+ * Uses readonly DB access for safe inspection.
+ * Accepts optional baseDir for testability (defaults to global config dir).
+ */
+export async function memoryHealthCheck(baseDir?: string): Promise<HealthResult> {
+	const resolvedBase = baseDir ?? getGlobalConfigDir();
+	const dbPath = join(resolvedBase, MEMORY_DIR, DB_FILE);
+
+	try {
+		await access(dbPath);
+	} catch (error: unknown) {
+		const code = (error as NodeJS.ErrnoException).code;
+		if (code === "ENOENT") {
+			return Object.freeze({
+				name: "memory-db",
+				status: "pass" as const,
+				message: `Memory DB not yet initialized -- will be created on first memory capture`,
+			});
+		}
+		const msg = error instanceof Error ? error.message : String(error);
+		return Object.freeze({
+			name: "memory-db",
+			status: "fail" as const,
+			message: `Memory DB inaccessible: ${msg}`,
+		});
+	}
+
+	try {
+		const fileStat = await stat(dbPath);
+		const sizeKB = (fileStat.size / 1024).toFixed(1);
+
+		if (fileStat.size === 0) {
+			return Object.freeze({
+				name: "memory-db",
+				status: "fail" as const,
+				message: `Memory DB exists but is empty (0 bytes)`,
+			});
+		}
+
+		const db = new Database(dbPath, { readonly: true });
+		try {
+			const row = db.query("SELECT COUNT(*) as count FROM observations").get() as {
+				count: number;
+			} | null;
+			const count = row?.count ?? 0;
+			return Object.freeze({
+				name: "memory-db",
+				status: "pass" as const,
+				message: `Memory DB exists (${count} observation${count !== 1 ? "s" : ""}, ${sizeKB}KB)`,
+			});
+		} finally {
+			db.close();
+		}
+	} catch (error: unknown) {
+		const msg = error instanceof Error ? error.message : String(error);
+		return Object.freeze({
+			name: "memory-db",
+			status: "fail" as const,
+			message: `Memory DB read error: ${msg}`,
+		});
+	}
+}
+
+/** Expected command files that should exist in the commands directory. */
+const EXPECTED_COMMANDS: readonly string[] = Object.freeze([
+	"oc-tdd",
+	"oc-review-pr",
+	"oc-brainstorm",
+	"oc-write-plan",
+	"oc-stocktake",
+	"oc-update-docs",
+	"oc-new-agent",
+	"oc-new-skill",
+	"oc-new-command",
+	"oc-quick",
+	"oc-review-agents",
+]);
+
+/**
+ * Check command accessibility: file existence and valid YAML frontmatter.
+ * Verifies each expected command file exists and has a non-empty description.
+ */
+export async function commandHealthCheck(targetDir?: string): Promise<HealthResult> {
+	const dir = targetDir ?? getGlobalConfigDir();
+	const missing: string[] = [];
+	const invalid: string[] = [];
+
+	await Promise.all(
+		EXPECTED_COMMANDS.map(async (name) => {
+			const filePath = join(dir, "commands", `${name}.md`);
+			try {
+				const content = await readFile(filePath, "utf-8");
+				const fmMatch = content.match(/^---\r?\n([\s\S]*?)\r?\n---/);
+				if (!fmMatch) {
+					invalid.push(`${name}: no frontmatter`);
+					return;
+				}
+				try {
+					const parsed = parse(fmMatch[1]);
+					if (
+						parsed === null ||
+						typeof parsed !== "object" ||
+						typeof parsed.description !== "string" ||
+						parsed.description.trim().length === 0
+					) {
+						invalid.push(`${name}: missing or empty description`);
+					}
+				} catch {
+					invalid.push(`${name}: invalid YAML frontmatter`);
+				}
+			} catch (error: unknown) {
+				const code = (error as NodeJS.ErrnoException).code;
+				if (code === "ENOENT") {
+					missing.push(name);
+				} else {
+					invalid.push(`${name}: ${error instanceof Error ? error.message : String(error)}`);
+				}
+			}
+		}),
+	);
+
+	missing.sort();
+	invalid.sort();
+	const issues = [...missing.map((n) => `missing: ${n}`), ...invalid];
+
+	if (issues.length === 0) {
+		return Object.freeze({
+			name: "command-accessibility",
+			status: "pass" as const,
+			message: `All ${EXPECTED_COMMANDS.length} commands accessible`,
+		});
+	}
+
+	return Object.freeze({
+		name: "command-accessibility",
+		status: "fail" as const,
+		message: `${issues.length} command issue(s) found`,
+		details: Object.freeze(issues),
+	});
+}

package/src/health/runner.ts

@@ -1,5 +1,12 @@
 import type { Config } from "@opencode-ai/plugin";
-import { agentHealthCheck, assetHealthCheck, configHealthCheck } from "./checks";
+import {
+	agentHealthCheck,
+	assetHealthCheck,
+	commandHealthCheck,
+	configHealthCheck,
+	memoryHealthCheck,
+	skillHealthCheck,
+} from "./checks";
 import type { HealthReport, HealthResult } from "./types";
 
 /**
@@ -31,6 +38,7 @@ export async function runHealthChecks(options?: {
 	openCodeConfig?: Config | null;
 	assetsDir?: string;
 	targetDir?: string;
+	projectRoot?: string;
 }): Promise<HealthReport> {
 	const start = Date.now();
 
@@ -38,9 +46,19 @@ export async function runHealthChecks(options?: {
 		configHealthCheck(options?.configPath),
 		agentHealthCheck(options?.openCodeConfig ?? null),
 		assetHealthCheck(options?.assetsDir, options?.targetDir),
+		skillHealthCheck(options?.projectRoot ?? process.cwd()),
+		memoryHealthCheck(options?.targetDir),
+		commandHealthCheck(options?.targetDir),
 	]);
 
-	const fallbackNames = ["config-validity", "agent-injection", "asset-directories"];
+	const fallbackNames = [
+		"config-validity",
+		"agent-injection",
+		"asset-directories",
+		"skill-loading",
+		"memory-db",
+		"command-accessibility",
+	];
 	const results: readonly HealthResult[] = Object.freeze(
 		settled.map((outcome, i) => settledToResult(outcome, fallbackNames[i])),
 	);