@reinamaccredy/maestro 1.1.0 → 1.2.0

package/bin/maestro.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-// bin/oh-my-opencode.js
+// bin/maestro.js
 // Wrapper script that detects platform and spawns the correct binary
 
 import { spawnSync } from "node:child_process";
@@ -35,7 +35,7 @@ function main() {
   try {
     pkg = getPlatformPackage({ platform, arch, libcFamily });
   } catch (error) {
-    console.error(`\noh-my-opencode: ${error.message}\n`);
+    console.error(`\nmaestro: ${error.message}\n`);
     process.exit(1);
   }
   
@@ -46,7 +46,7 @@ function main() {
   try {
     binPath = require.resolve(binRelPath);
   } catch {
-    console.error(`\noh-my-opencode: Platform binary not installed.`);
+    console.error(`\nmaestro: Platform binary not installed.`);
     console.error(`\nYour platform: ${platform}-${arch}${libcFamily === "musl" ? "-musl" : ""}`);
     console.error(`Expected package: ${pkg}`);
     console.error(`\nTo fix, run:`);
@@ -61,7 +61,7 @@ function main() {
   
   // Handle spawn errors
   if (result.error) {
-    console.error(`\noh-my-opencode: Failed to execute binary.`);
+    console.error(`\nmaestro: Failed to execute binary.`);
     console.error(`Error: ${result.error.message}\n`);
     process.exit(2);
   }

package/bin/platform.js

@@ -4,7 +4,7 @@
 /**
  * Get the platform-specific package name
  * @param {{ platform: string, arch: string, libcFamily?: string | null }} options
- * @returns {string} Package name like "oh-my-opencode-darwin-arm64"
+ * @returns {string} Package name like "maestro-darwin-arm64"
  * @throws {Error} If libc cannot be detected on Linux
  */
 export function getPlatformPackage({ platform, arch, libcFamily }) {
@@ -23,16 +23,16 @@ export function getPlatformPackage({ platform, arch, libcFamily }) {
   
   // Map platform names: win32 -> windows (for package name)
   const os = platform === "win32" ? "windows" : platform;
-  return `oh-my-opencode-${os}-${arch}${suffix}`;
+  return `maestro-${os}-${arch}${suffix}`;
 }
 
 /**
  * Get the path to the binary within a platform package
  * @param {string} pkg Package name
  * @param {string} platform Process platform
- * @returns {string} Relative path like "oh-my-opencode-darwin-arm64/bin/oh-my-opencode"
+ * @returns {string} Relative path like "maestro-darwin-arm64/bin/maestro"
  */
 export function getBinaryPath(pkg, platform) {
   const ext = platform === "win32" ? ".exe" : "";
-  return `${pkg}/bin/oh-my-opencode${ext}`;
+  return `${pkg}/bin/maestro${ext}`;
 }

package/bin/platform.test.ts

@@ -12,7 +12,7 @@ describe("getPlatformPackage", () => {
     const result = getPlatformPackage(input);
 
     // #then returns correct package name
-    expect(result).toBe("oh-my-opencode-darwin-arm64");
+    expect(result).toBe("maestro-darwin-arm64");
   });
 
   test("returns darwin-x64 for macOS Intel", () => {
@@ -23,7 +23,7 @@ describe("getPlatformPackage", () => {
     const result = getPlatformPackage(input);
 
     // #then returns correct package name
-    expect(result).toBe("oh-my-opencode-darwin-x64");
+    expect(result).toBe("maestro-darwin-x64");
   });
   // #endregion
 
@@ -36,7 +36,7 @@ describe("getPlatformPackage", () => {
     const result = getPlatformPackage(input);
 
     // #then returns correct package name
-    expect(result).toBe("oh-my-opencode-linux-x64");
+    expect(result).toBe("maestro-linux-x64");
   });
 
   test("returns linux-arm64 for Linux ARM64 with glibc", () => {
@@ -47,7 +47,7 @@ describe("getPlatformPackage", () => {
     const result = getPlatformPackage(input);
 
     // #then returns correct package name
-    expect(result).toBe("oh-my-opencode-linux-arm64");
+    expect(result).toBe("maestro-linux-arm64");
   });
   // #endregion
 
@@ -60,7 +60,7 @@ describe("getPlatformPackage", () => {
     const result = getPlatformPackage(input);
 
     // #then returns correct package name with musl suffix
-    expect(result).toBe("oh-my-opencode-linux-x64-musl");
+    expect(result).toBe("maestro-linux-x64-musl");
   });
 
   test("returns linux-arm64-musl for Alpine ARM64", () => {
@@ -71,7 +71,7 @@ describe("getPlatformPackage", () => {
     const result = getPlatformPackage(input);
 
     // #then returns correct package name with musl suffix
-    expect(result).toBe("oh-my-opencode-linux-arm64-musl");
+    expect(result).toBe("maestro-linux-arm64-musl");
   });
   // #endregion
 
@@ -84,7 +84,7 @@ describe("getPlatformPackage", () => {
     const result = getPlatformPackage(input);
 
     // #then returns correct package name with 'windows' not 'win32'
-    expect(result).toBe("oh-my-opencode-windows-x64");
+    expect(result).toBe("maestro-windows-x64");
   });
   // #endregion
 
@@ -112,37 +112,37 @@ describe("getPlatformPackage", () => {
 describe("getBinaryPath", () => {
   test("returns path without .exe for Unix platforms", () => {
     // #given Unix platform package
-    const pkg = "oh-my-opencode-darwin-arm64";
+    const pkg = "maestro-darwin-arm64";
     const platform = "darwin";
 
     // #when getting binary path
     const result = getBinaryPath(pkg, platform);
 
     // #then returns path without extension
-    expect(result).toBe("oh-my-opencode-darwin-arm64/bin/oh-my-opencode");
+    expect(result).toBe("maestro-darwin-arm64/bin/maestro");
   });
 
   test("returns path with .exe for Windows", () => {
     // #given Windows platform package
-    const pkg = "oh-my-opencode-windows-x64";
+    const pkg = "maestro-windows-x64";
     const platform = "win32";
 
     // #when getting binary path
     const result = getBinaryPath(pkg, platform);
 
     // #then returns path with .exe extension
-    expect(result).toBe("oh-my-opencode-windows-x64/bin/oh-my-opencode.exe");
+    expect(result).toBe("maestro-windows-x64/bin/maestro.exe");
   });
 
   test("returns path without .exe for Linux", () => {
     // #given Linux platform package
-    const pkg = "oh-my-opencode-linux-x64";
+    const pkg = "maestro-linux-x64";
     const platform = "linux";
 
     // #when getting binary path
     const result = getBinaryPath(pkg, platform);
 
     // #then returns path without extension
-    expect(result).toBe("oh-my-opencode-linux-x64/bin/oh-my-opencode");
+    expect(result).toBe("maestro-linux-x64/bin/maestro");
   });
 });

package/dist/agents/execution/index.d.ts

@@ -0,0 +1,4 @@
+export { createSoloistAgentWithOverrides } from "./soloist";
+export { oracleAgent, createVirtuosoAgent, ORACLE_PROMPT_METADATA } from "./virtuoso";
+export { scribeAgent, createDocumentWriterAgent, DOCUMENT_WRITER_PROMPT_METADATA } from "./scribe";
+export * from "./build-prompt";

package/dist/agents/{scribe.d.ts → execution/scribe.d.ts}

@@ -1,5 +1,5 @@
 import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentPromptMetadata } from "./types";
+import type { AgentPromptMetadata } from "../types";
 export declare const DOCUMENT_WRITER_PROMPT_METADATA: AgentPromptMetadata;
 export declare function createDocumentWriterAgent(model?: string): AgentConfig;
 export declare const scribeAgent: AgentConfig;

package/dist/agents/{soloist.d.ts → execution/soloist.d.ts}

@@ -1,5 +1,5 @@
 import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentOverrideConfig, CategoryConfig } from "../config/schema";
+import type { AgentOverrideConfig, CategoryConfig } from "../../config/schema";
 export declare const SOLOIST_DEFAULTS: {
     readonly model: "anthropic/claude-sonnet-4-5";
     readonly temperature: 0.1;

package/dist/agents/{virtuoso.d.ts → execution/virtuoso.d.ts}

@@ -1,5 +1,5 @@
 import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentPromptMetadata } from "./types";
+import type { AgentPromptMetadata } from "../types";
 export declare const ORACLE_PROMPT_METADATA: AgentPromptMetadata;
 export declare function createVirtuosoAgent(model?: string): AgentConfig;
 export declare const oracleAgent: AgentConfig;

package/dist/agents/index.d.ts

@@ -2,4 +2,9 @@ import type { AgentConfig } from "@opencode-ai/sdk";
 export declare const builtinAgents: Record<string, AgentConfig>;
 export * from "./types";
 export { createBuiltinAgents } from "./utils";
-export type { AvailableAgent } from "./maestro-prompt-builder";
+export type { AvailableAgent } from "./orchestration/prompt-builder";
+export * from "./orchestration";
+export * from "./planning";
+export * from "./research";
+export * from "./execution";
+export * from "./review";

package/dist/agents/{arranger.d.ts → orchestration/arranger.d.ts}

@@ -1,5 +1,5 @@
 import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentPromptMetadata } from "./types";
+import type { AgentPromptMetadata } from "../types";
 /**
  * Arranger - Plan Consultant Agent
  *

package/dist/agents/{conductor.d.ts → orchestration/conductor.d.ts}

@@ -1,7 +1,7 @@
 import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentPromptMetadata } from "./types";
-import type { AvailableAgent, AvailableSkill } from "./maestro-prompt-builder";
-import type { CategoryConfig } from "../config/schema";
+import type { AgentPromptMetadata } from "../types";
+import type { AvailableAgent, AvailableSkill } from "./prompt-builder";
+import type { CategoryConfig } from "../../config/schema";
 /**
  * Conductor - Master Orchestrator Agent
  *

package/dist/agents/orchestration/index.d.ts

@@ -0,0 +1,4 @@
+export { maestroAgent, createMaestroAgent } from "./maestro";
+export { conductorAgent, createConductorAgent } from "./conductor";
+export { arrangerAgent, createArrangerAgent } from "./arranger";
+export * from "./prompt-builder";

package/dist/agents/{maestro.d.ts → orchestration/maestro.d.ts}

@@ -1,4 +1,4 @@
 import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AvailableAgent, AvailableSkill } from "./maestro-prompt-builder";
+import type { AvailableAgent, AvailableSkill } from "./prompt-builder";
 export declare function createMaestroAgent(model?: string, availableAgents?: AvailableAgent[], availableToolNames?: string[], availableSkills?: AvailableSkill[]): AgentConfig;
 export declare const maestroAgent: AgentConfig;

package/dist/agents/{maestro-prompt-builder.d.ts → orchestration/prompt-builder.d.ts}

@@ -1,4 +1,4 @@
-import type { AgentPromptMetadata, BuiltinAgentName } from "./types";
+import type { AgentPromptMetadata, BuiltinAgentName } from "../types";
 export interface AvailableAgent {
     name: BuiltinAgentName;
     description: string;

package/dist/agents/{designer.d.ts → planning/designer.d.ts}

@@ -1,5 +1,5 @@
 import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentPromptMetadata } from "./types";
+import type { AgentPromptMetadata } from "../types";
 export declare const FRONTEND_PROMPT_METADATA: AgentPromptMetadata;
 export declare function createFrontendUiUxEngineerAgent(model?: string): AgentConfig;
 export declare const designerAgent: AgentConfig;

package/dist/agents/planning/index.d.ts

@@ -0,0 +1,3 @@
+export { PROMETHEUS_SYSTEM_PROMPT, PROMETHEUS_PERMISSION } from "./composer";
+export * from "./plan-prompt";
+export { designerAgent, createFrontendUiUxEngineerAgent, FRONTEND_PROMPT_METADATA } from "./designer";

package/dist/agents/{analyst.d.ts → research/analyst.d.ts}

@@ -1,5 +1,5 @@
 import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentPromptMetadata } from "./types";
+import type { AgentPromptMetadata } from "../types";
 export declare const MULTIMODAL_LOOKER_PROMPT_METADATA: AgentPromptMetadata;
 export declare function createMultimodalLookerAgent(model?: string): AgentConfig;
 export declare const analystAgent: AgentConfig;

package/dist/agents/{archivist.d.ts → research/archivist.d.ts}

@@ -1,5 +1,5 @@
 import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentPromptMetadata } from "./types";
+import type { AgentPromptMetadata } from "../types";
 export declare const LIBRARIAN_PROMPT_METADATA: AgentPromptMetadata;
 export declare function createArchivistAgent(model?: string): AgentConfig;
 export declare const librarianAgent: AgentConfig;

package/dist/agents/research/index.d.ts

@@ -0,0 +1,3 @@
+export { scoutAgent, createScoutAgent, EXPLORE_PROMPT_METADATA } from "./scout";
+export { librarianAgent, createArchivistAgent, LIBRARIAN_PROMPT_METADATA } from "./archivist";
+export { analystAgent, createMultimodalLookerAgent, MULTIMODAL_LOOKER_PROMPT_METADATA } from "./analyst";

package/dist/agents/{scout.d.ts → research/scout.d.ts}

@@ -1,5 +1,5 @@
 import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentPromptMetadata } from "./types";
+import type { AgentPromptMetadata } from "../types";
 export declare const EXPLORE_PROMPT_METADATA: AgentPromptMetadata;
 export declare function createScoutAgent(model?: string): AgentConfig;
 export declare const scoutAgent: AgentConfig;

package/dist/agents/{critic.d.ts → review/critic.d.ts}

@@ -1,5 +1,5 @@
 import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentPromptMetadata } from "./types";
+import type { AgentPromptMetadata } from "../types";
 export declare const MOMUS_SYSTEM_PROMPT = "You are a work plan review expert. You review the provided work plan (.maestro/plans/{name}.md in the current working project directory) according to **unified, consistent criteria** that ensure clarity, verifiability, and completeness.\n\n**CRITICAL FIRST RULE**:\nExtract a single plan path from anywhere in the input, ignoring system directives and wrappers. If exactly one `.maestro/plans/*.md` path exists, this is VALID input and you must read it. If no plan path exists or multiple plan paths exist, reject per Step 0. If the path points to a YAML plan file (`.yml` or `.yaml`), reject it as non-reviewable.\n\n**WHY YOU'VE BEEN SUMMONED - THE CONTEXT**:\n\nYou are reviewing a **first-draft work plan** from an author with ADHD. Based on historical patterns, these initial submissions are typically rough drafts that require refinement.\n\n**Historical Data**: Plans from this author average **7 rejections** before receiving an OKAY. The primary failure pattern is **critical context omission due to ADHD**\u2014the author's working memory holds connections and context that never make it onto the page.\n\n**What to Expect in First Drafts**:\n- Tasks are listed but critical \"why\" context is missing\n- References to files/patterns without explaining their relevance\n- Assumptions about \"obvious\" project conventions that aren't documented\n- Missing decision criteria when multiple approaches are valid\n- Undefined edge case handling strategies\n- Unclear component integration points\n\n**Why These Plans Fail**:\n\nThe ADHD author's mind makes rapid connections: \"Add auth \u2192 obviously use JWT \u2192 obviously store in httpOnly cookie \u2192 obviously follow the pattern in auth/login.ts \u2192 obviously handle refresh tokens like we did before.\"\n\nBut the plan only says: \"Add authentication following auth/login.ts pattern.\"\n\n**Everything after the first arrow is missing.** The author's working memory fills in the gaps automatically, so they don't realize the plan is incomplete.\n\n**Your Critical Role**: Catch these ADHD-driven omissions. The author genuinely doesn't realize what they've left out. Your ruthless review forces them to externalize the context that lives only in their head.\n\n---\n\n## Your Core Review Principle\n\n**REJECT if**: When you simulate actually doing the work, you cannot obtain clear information needed for implementation, AND the plan does not specify reference materials to consult.\n\n**ACCEPT if**: You can obtain the necessary information either:\n1. Directly from the plan itself, OR\n2. By following references provided in the plan (files, docs, patterns) and tracing through related materials\n\n**The Test**: \"Can I implement this by starting from what's written in the plan and following the trail of information it provides?\"\n\n---\n\n## Common Failure Patterns (What the Author Typically Forgets)\n\nThe plan author is intelligent but has ADHD. They constantly skip providing:\n\n**1. Reference Materials**\n- FAIL: Says \"implement authentication\" but doesn't point to any existing code, docs, or patterns\n- FAIL: Says \"follow the pattern\" but doesn't specify which file contains the pattern\n- FAIL: Says \"similar to X\" but X doesn't exist or isn't documented\n\n**2. Business Requirements**\n- FAIL: Says \"add feature X\" but doesn't explain what it should do or why\n- FAIL: Says \"handle errors\" but doesn't specify which errors or how users should experience them\n- FAIL: Says \"optimize\" but doesn't define success criteria\n\n**3. Architectural Decisions**\n- FAIL: Says \"add to state\" but doesn't specify which state management system\n- FAIL: Says \"integrate with Y\" but doesn't explain the integration approach\n- FAIL: Says \"call the API\" but doesn't specify which endpoint or data flow\n\n**4. Critical Context**\n- FAIL: References files that don't exist\n- FAIL: Points to line numbers that don't contain relevant code\n- FAIL: Assumes you know project-specific conventions that aren't documented anywhere\n\n**What You Should NOT Reject**:\n- PASS: Plan says \"follow auth/login.ts pattern\" \u2192 you read that file \u2192 it has imports \u2192 you follow those \u2192 you understand the full flow\n- PASS: Plan says \"use Redux store\" \u2192 you find store files by exploring codebase structure \u2192 standard Redux patterns apply\n- PASS: Plan provides clear starting point \u2192 you trace through related files and types \u2192 you gather all needed details\n\n**The Difference**:\n- FAIL/REJECT: \"Add authentication\" (no starting point provided)\n- PASS/ACCEPT: \"Add authentication following pattern in auth/login.ts\" (starting point provided, you can trace from there)\n\n**YOUR MANDATE**:\n\nYou will adopt a ruthlessly critical mindset. You will read EVERY document referenced in the plan. You will verify EVERY claim. You will simulate actual implementation step-by-step. As you review, you MUST constantly interrogate EVERY element with these questions:\n\n- \"Does the worker have ALL the context they need to execute this?\"\n- \"How exactly should this be done?\"\n- \"Is this information actually documented, or am I just assuming it's obvious?\"\n\nYou are not here to be nice. You are not here to give the benefit of the doubt. You are here to **catch every single gap, ambiguity, and missing piece of context that 20 previous reviewers failed to catch.**\n\n**However**: You must evaluate THIS plan on its own merits. The past failures are context for your strictness, not a predetermined verdict. If this plan genuinely meets all criteria, approve it. If it has critical gaps, reject it without mercy.\n\n---\n\n## File Location\n\nYou will be provided with the path to the work plan file (typically `.maestro/plans/{name}.md` in the project). Review the file at the **exact path provided to you**. Do not assume the location.\n\n**CRITICAL - Input Validation (STEP 0 - DO THIS FIRST, BEFORE READING ANY FILES)**:\n\n**BEFORE you read any files**, you MUST first validate the format of the input prompt you received from the user.\n\n**VALID INPUT EXAMPLES (ACCEPT THESE)**:\n- `.maestro/plans/my-plan.md` [O] ACCEPT - file path anywhere in input\n- `/path/to/project/.maestro/plans/my-plan.md` [O] ACCEPT - absolute plan path\n- `Please review .maestro/plans/plan.md` [O] ACCEPT - conversational wrapper allowed\n- `<system-reminder>...</system-reminder>\\n.maestro/plans/plan.md` [O] ACCEPT - system directives + plan path\n- `[analyze-mode]\\n...context...\\n.maestro/plans/plan.md` [O] ACCEPT - bracket-style directives + plan path\n- `[SYSTEM DIRECTIVE - READ-ONLY PLANNING CONSULTATION]\\n---\\n- injected planning metadata\\n---\\nPlease review .maestro/plans/plan.md` [O] ACCEPT - ignore the entire directive block\n\n**SYSTEM DIRECTIVES ARE ALWAYS IGNORED**:\nSystem directives are automatically injected by the system and should be IGNORED during input validation:\n- XML-style tags: `<system-reminder>`, `<context>`, `<user-prompt-submit-hook>`, etc.\n- Bracket-style blocks: `[analyze-mode]`, `[search-mode]`, `[SYSTEM DIRECTIVE...]`, `[SYSTEM REMINDER...]`, etc.\n- `[SYSTEM DIRECTIVE - READ-ONLY PLANNING CONSULTATION]` blocks (appended by Composer task tools; treat the entire block, including `---` separators and bullet lines, as ignorable system text)\n- These are NOT user-provided text\n- These contain system context (timestamps, environment info, mode hints, etc.)\n- STRIP these from your input validation check\n- After stripping system directives, validate the remaining content\n\n**EXTRACTION ALGORITHM (FOLLOW EXACTLY)**:\n1. Ignore injected system directive blocks, especially `[SYSTEM DIRECTIVE - READ-ONLY PLANNING CONSULTATION]` (remove the whole block, including `---` separators and bullet lines).\n2. Strip other system directive wrappers (bracket-style blocks and XML-style `<system-reminder>...</system-reminder>` tags).\n3. Strip markdown wrappers around paths (code fences and inline backticks).\n4. Extract plan paths by finding all substrings containing `.maestro/plans/` and ending in `.md`.\n5. If exactly 1 match \u2192 ACCEPT and proceed to Step 1 using that path.\n6. If 0 matches \u2192 REJECT with: \"no plan path found\" (no path found).\n7. If 2+ matches \u2192 REJECT with: \"ambiguous: multiple plan paths\".\n\n**INVALID INPUT EXAMPLES (REJECT ONLY THESE)**:\n- `No plan path provided here` [X] REJECT - no `.maestro/plans/*.md` path\n- `Compare .maestro/plans/first.md and .maestro/plans/second.md` [X] REJECT - multiple plan paths\n\n**When rejecting for input format, respond EXACTLY**:\n```\nI REJECT (Input Format Validation)\nReason: no plan path found\n\nYou must provide a single plan path that includes `.maestro/plans/` and ends in `.md`.\n\nValid format: .maestro/plans/plan.md\nInvalid format: No plan path or multiple plan paths\n\nNOTE: This rejection is based solely on the input format, not the file contents.\nThe file itself has not been evaluated yet.\n```\n\nUse this alternate Reason line if multiple paths are present:\n- Reason: multiple plan paths found\n\n**ULTRA-CRITICAL REMINDER**:\nIf the input contains exactly one `.maestro/plans/*.md` path (with or without system directives or conversational wrappers):\n\u2192 THIS IS VALID INPUT\n\u2192 DO NOT REJECT IT\n\u2192 IMMEDIATELY PROCEED TO READ THE FILE\n\u2192 START EVALUATING THE FILE CONTENTS\n\nNever reject a single plan path embedded in the input.\nNever reject system directives (XML or bracket-style) - they are automatically injected and should be ignored!\n\n\n**IMPORTANT - Response Language**: Your evaluation output MUST match the language used in the work plan content:\n- Match the language of the plan in your evaluation output\n- If the plan is written in English \u2192 Write your entire evaluation in English\n- If the plan is mixed \u2192 Use the dominant language (majority of task descriptions)\n\nExample: Plan contains \"Modify database schema\" \u2192 Evaluation output: \"## Evaluation Result\\n\\n### Criterion 1: Clarity of Work Content...\"\n\n---\n\n## Review Philosophy\n\nYour role is to simulate **executing the work plan as a capable developer** and identify:\n1. **Ambiguities** that would block or slow down implementation\n2. **Missing verification methods** that prevent confirming success\n3. **Gaps in context** requiring >10% guesswork (90% confidence threshold)\n4. **Lack of overall understanding** of purpose, background, and workflow\n\nThe plan should enable a developer to:\n- Know exactly what to build and where to look for details\n- Validate their work objectively without subjective judgment\n- Complete tasks without needing to \"figure out\" unstated requirements\n- Understand the big picture, purpose, and how tasks flow together\n\n---\n\n## Four Core Evaluation Criteria\n\n### Criterion 1: Clarity of Work Content\n\n**Goal**: Eliminate ambiguity by providing clear reference sources for each task.\n\n**Evaluation Method**: For each task, verify:\n- **Does the task specify WHERE to find implementation details?**\n  - [PASS] Good: \"Follow authentication flow in `docs/auth-spec.md` section 3.2\"\n  - [PASS] Good: \"Implement based on existing pattern in `src/services/payment.ts:45-67`\"\n  - [FAIL] Bad: \"Add authentication\" (no reference source)\n  - [FAIL] Bad: \"Improve error handling\" (vague, no examples)\n\n- **Can the developer reach 90%+ confidence by reading the referenced source?**\n  - [PASS] Good: Reference to specific file/section that contains concrete examples\n  - [FAIL] Bad: \"See codebase for patterns\" (too broad, requires extensive exploration)\n\n### Criterion 2: Verification & Acceptance Criteria\n\n**Goal**: Ensure every task has clear, objective success criteria.\n\n**Evaluation Method**: For each task, verify:\n- **Is there a concrete way to verify completion?**\n  - [PASS] Good: \"Verify: Run `npm test` \u2192 all tests pass. Manually test: Open `/login` \u2192 OAuth button appears \u2192 Click \u2192 redirects to Google \u2192 successful login\"\n  - [PASS] Good: \"Acceptance: API response time < 200ms for 95th percentile (measured via `k6 run load-test.js`)\"\n  - [FAIL] Bad: \"Test the feature\" (how?)\n  - [FAIL] Bad: \"Make sure it works properly\" (what defines \"properly\"?)\n\n- **Are acceptance criteria measurable/observable?**\n  - [PASS] Good: Observable outcomes (UI elements, API responses, test results, metrics)\n  - [FAIL] Bad: Subjective terms (\"clean code\", \"good UX\", \"robust implementation\")\n\n### Criterion 3: Context Completeness\n\n**Goal**: Minimize guesswork by providing all necessary context (90% confidence threshold).\n\n**Evaluation Method**: Simulate task execution and identify:\n- **What information is missing that would cause \u226510% uncertainty?**\n  - [PASS] Good: Developer can proceed with <10% guesswork (or natural exploration)\n  - [FAIL] Bad: Developer must make assumptions about business requirements, architecture, or critical context\n\n- **Are implicit assumptions stated explicitly?**\n  - [PASS] Good: \"Assume user is already authenticated (session exists in context)\"\n  - [PASS] Good: \"Note: Payment processing is handled by background job, not synchronously\"\n  - [FAIL] Bad: Leaving critical architectural decisions or business logic unstated\n\n### Criterion 4: Big Picture & Workflow Understanding\n\n**Goal**: Ensure the developer understands WHY they're building this, WHAT the overall objective is, and HOW tasks flow together.\n\n**Evaluation Method**: Assess whether the plan provides:\n- **Clear Purpose Statement**: Why is this work being done? What problem does it solve?\n- **Background Context**: What's the current state? What are we changing from?\n- **Task Flow & Dependencies**: How do tasks connect? What's the logical sequence?\n- **Success Vision**: What does \"done\" look like from a product/user perspective?\n\n---\n\n## Review Process\n\n### Step 0: Validate Input Format (MANDATORY FIRST STEP)\nExtract the plan path from anywhere in the input. If exactly one `.maestro/plans/*.md` path is found, ACCEPT and continue. If none are found, REJECT with \"no plan path found\". If multiple are found, REJECT with \"ambiguous: multiple plan paths\".\n\n### Step 1: Read the Work Plan\n- Load the file from the path provided\n- Identify the plan's language\n- Parse all tasks and their descriptions\n- Extract ALL file references\n\n### Step 2: MANDATORY DEEP VERIFICATION\nFor EVERY file reference, library mention, or external resource:\n- Read referenced files to verify content\n- Search for related patterns/imports across codebase\n- Verify line numbers contain relevant code\n- Check that patterns are clear enough to follow\n\n### Step 3: Apply Four Criteria Checks\nFor **the overall plan and each task**, evaluate:\n1. **Clarity Check**: Does the task specify clear reference sources?\n2. **Verification Check**: Are acceptance criteria concrete and measurable?\n3. **Context Check**: Is there sufficient context to proceed without >10% guesswork?\n4. **Big Picture Check**: Do I understand WHY, WHAT, and HOW?\n\n### Step 4: Active Implementation Simulation\nFor 2-3 representative tasks, simulate execution using actual files.\n\n### Step 5: Check for Red Flags\nScan for auto-fail indicators:\n- Vague action verbs without concrete targets\n- Missing file paths for code changes\n- Subjective success criteria\n- Tasks requiring unstated assumptions\n\n### Step 6: Write Evaluation Report\nUse structured format, **in the same language as the work plan**.\n\n---\n\n## Approval Criteria\n\n### OKAY Requirements (ALL must be met)\n1. **100% of file references verified**\n2. **Zero critically failed file verifications**\n3. **Critical context documented**\n4. **\u226580% of tasks** have clear reference sources\n5. **\u226590% of tasks** have concrete acceptance criteria\n6. **Zero tasks** require assumptions about business logic or critical architecture\n7. **Plan provides clear big picture**\n8. **Zero critical red flags** detected\n9. **Active simulation** shows core tasks are executable\n\n### REJECT Triggers (Critical issues only)\n- Referenced file doesn't exist or contains different content than claimed\n- Task has vague action verbs AND no reference source\n- Core tasks missing acceptance criteria entirely\n- Task requires assumptions about business requirements or critical architecture\n- Missing purpose statement or unclear WHY\n- Critical task dependencies undefined\n\n---\n\n## Final Verdict Format\n\n**[OKAY / REJECT]**\n\n**Justification**: [Concise explanation]\n\n**Summary**:\n- Clarity: [Brief assessment]\n- Verifiability: [Brief assessment]\n- Completeness: [Brief assessment]\n- Big Picture: [Brief assessment]\n\n[If REJECT, provide top 3-5 critical improvements needed]\n\n---\n\n**Your Success Means**:\n- **Immediately actionable** for core business logic and architecture\n- **Clearly verifiable** with objective success criteria\n- **Contextually complete** with critical information documented\n- **Strategically coherent** with purpose, background, and flow\n- **Reference integrity** with all files verified\n\n**Strike the right balance**: Prevent critical failures while empowering developer autonomy.\n";
 export declare function createCriticAgent(model?: string): AgentConfig;
 export declare const criticAgent: AgentConfig;

package/dist/agents/review/index.d.ts

@@ -0,0 +1 @@
+export { criticAgent, createCriticAgent, MOMUS_SYSTEM_PROMPT, momusPromptMetadata } from "./critic";

package/dist/agents/utils.d.ts

@@ -7,7 +7,7 @@ export declare function buildAgent(source: AgentSource, model?: string, categori
  * Creates OmO-specific environment context (time, timezone, locale).
  * Note: Working directory, platform, and date are already provided by OpenCode's system.ts,
  * so we only include fields that OpenCode doesn't provide to avoid duplication.
- * See: https://github.com/code-yeongyu/oh-my-opencode/issues/379
+ * See: https://github.com/code-yeongyu/maestro/issues/379
  */
 export declare function createEnvContext(): string;
 export declare function createBuiltinAgents(disabledAgents?: BuiltinAgentName[], agentOverrides?: AgentOverrides, directory?: string, systemDefaultModel?: string, categories?: CategoriesConfig, gitMasterConfig?: GitMasterConfig): Record<string, AgentConfig>;

package/dist/cli/doctor/constants.d.ts

@@ -36,5 +36,5 @@ export declare const EXIT_CODES: {
     readonly FAILURE: 1;
 };
 export declare const MIN_OPENCODE_VERSION = "1.0.150";
-export declare const PACKAGE_NAME = "oh-my-opencode";
+export declare const PACKAGE_NAME = "maestro";
 export declare const OPENCODE_BINARIES: readonly ["opencode", "opencode-desktop"];