@syntesseraai/opencode-feature-factory 0.10.3 → 0.10.4

package/README.md

@@ -1,6 +1,6 @@
 # @syntesseraai/opencode-feature-factory
 
-OpenCode plugin that provides Feature Factory agents, skills, and pipeline commands.
+OpenCode plugin that provides Feature Factory agents, skills, and workflow MCP tools.
 
 ## Installation
 
@@ -19,144 +19,65 @@ OpenCode plugin that provides Feature Factory agents, skills, and pipeline comma
 npx @syntesseraai/opencode-feature-factory install
 ```
 
-This installer deploys to `~/.config/opencode/`:
+The installer deploys to `~/.config/opencode/`:
 
 - `agents/`
 - `skills/`
-- `command/`
 
 It also updates `~/.config/opencode/opencode.json` non-destructively by merging missing Feature Factory MCP entries and plugins without deleting existing user configuration.
 
 ## Install Behavior
 
-- **Always overwrites packaged assets**: installer unconditionally overwrites Feature Factory `agents`, `skills`, and `command` files on every install.
+- **Always overwrites packaged assets**: installer unconditionally overwrites Feature Factory `agents` and `skills` files on every install.
 - **`opencode.json` is non-destructive**: existing keys/values are preserved; only missing required plugin/MCP entries are added.
 - **Global scope**: assets are installed to `~/.config/opencode/` and shared across projects.
 
-## Agent Frontmatter Metadata
-
-All shipped Feature Factory agent manifests under `agents/*.md` include a `color` frontmatter field using a valid hex value.
-
-| Agent             | Color     |
-| ----------------- | --------- |
-| `feature-factory` | `#10b981` |
-| `planning`        | `#3b82f6` |
-| `building`        | `#22c55e` |
-| `reviewing`       | `#8b5cf6` |
-| `documenting`     | `#f97316` |
-| `ff-research`     | `#6366f1` |
-
-These colors are intentionally unique to avoid collisions in OpenCode agent UIs and logs.
-
-## Pipeline Entrypoint
-
-- Invoke `/pipeline/start <requirements-brief>` directly from any agent (e.g. `@building`).
-- There is no dedicated `@pipeline` intake agent; the command tree handles orchestration autonomously.
-- Orchestration is implemented by the command tree under `command/pipeline/` using subtask2 primitives (`return`, `parallel`, `loop`).
-- Orchestration wrapper commands (`/pipeline/start`, `/pipeline/*/run`, `/pipeline/complete`) pin `agent: general` to avoid recursive self-invocation before phase-specific delegation begins.
-- Coordinator and synthesis model defaults to ChatGPT 5.4 via frontmatter `model:` declarations in orchestrator commands.
-- All orchestrator commands include an explicit **orchestrator constraint**: they must NOT directly read, edit, modify, write, or create any code/config/repository files — they only dispatch sub-commands, pass structured data via `{as:name}` / `$RESULT[name]`, and evaluate gate/loop conditions.
-
 ## Tools
 
 The plugin exposes three MCP tools via the `feature-factory` agent:
 
-| Tool             | Description                                                                                                                                                                                                                                                                                       |
-| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `ff_pipeline`    | Full multi-model pipeline: planning → build → CI → review → documentation. Uses hardcoded per-role model defaults (see Model Routing below). Supports optional `worktree_isolation` / `worktree_parent_dir` for run-level git worktree isolation.                                                 |
-| `ff_mini_loop`   | Lightweight build → CI → review → documentation loop. **Does not hardcode model defaults** — all roles inherit the current session model when omitted. CI validation runs `ff-ci.sh` if present (up to 3 attempts with auto-fix). Supports optional `worktree_isolation` / `worktree_parent_dir`. |
-| `ff_list_models` | Read-only discovery tool. Queries the OpenCode SDK to list all available providers, models, capability badges, connected status, and defaults.                                                                                                                                                    |
+| Tool             | Description                                                                                                                                                                               |
+| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `ff_pipeline`    | Full multi-model workflow: planning -> build -> CI -> review -> documentation. Uses hardcoded per-role model defaults and supports optional `worktree_isolation` / `worktree_parent_dir`. |
+| `ff_mini_loop`   | Lightweight build -> CI -> review -> documentation loop. Model parameters inherit the current session model when omitted. Supports optional `worktree_isolation` / `worktree_parent_dir`. |
+| `ff_list_models` | Read-only discovery tool that lists available providers/models and defaults from the OpenCode SDK.                                                                                        |
 
 ### Mini-Loop Model Inheritance
 
-When `ff_mini_loop` model parameters are omitted, child sessions inherit the parent session's model (the SDK `model` field is omitted entirely from the prompt body). The `doc_model` has a cascade: if `build_model` is explicitly set but `doc_model` is not, the documentation step uses the same model as build. Users can call `ff_list_models` to discover available `provider/model` strings before overriding.
-
-## Command Tree
-
-- `/pipeline/start`
-- `/pipeline/planning/run`, `/pipeline/planning/plan`, `/pipeline/planning/synthesize`, `/pipeline/planning/gate`, `/pipeline/planning/confirm`
-- `/pipeline/building/run`, `/pipeline/building/breakdown`, `/pipeline/building/validate-batch`, `/pipeline/building/implement-batch`
-- `/pipeline/reviewing/run`, `/pipeline/reviewing/triage`, `/pipeline/reviewing/review`, `/pipeline/reviewing/synthesize`, `/pipeline/reviewing/gate`
-- `/pipeline/documentation/run`, `/pipeline/documentation/document`, `/pipeline/documentation/review`, `/pipeline/documentation/gate`
-- `/pipeline/complete`
-- `/mini-loop/start`
-- `/mini-loop/implementation/run`, `/mini-loop/implementation/build`, `/mini-loop/implementation/review`, `/mini-loop/implementation/gate`
-- `/mini-loop/documentation/run`, `/mini-loop/documentation/document`, `/mini-loop/documentation/review`, `/mini-loop/documentation/gate`
-- Mini-loop wrapper commands (`/mini-loop/start`, `/mini-loop/*/run`) also pin `agent: general` so they can be safely launched from any caller agent.
-
-## Model Routing
-
-Models are declared in each command's frontmatter (`model:` field). Multi-model fan-out targets (`plan.md`, `review.md`) use per-invocation `{model:...}` overrides since they are invoked multiple times with different models.
-
-| Role                    | Model                       | Commands                                                                    |
-| ----------------------- | --------------------------- | --------------------------------------------------------------------------- |
-| Orchestration/reasoning | `openai/gpt-5.4`            | All `run.md`, `start.md`, `complete.md`, gates, triage, synthesize, confirm |
-| Implementation          | `openai/gpt-5.3-codex`      | `implement-batch`, `build`, `document`                                      |
-| Architecture analysis   | `anthropic/claude-opus-4-6` | `breakdown`, review fan-out (opus slot)                                     |
-| Validation              | `opencode/gemini-3.1-pro`   | `validate-batch`, documentation review, review fan-out (gemini slot)        |
-| Multi-model fan-out     | per-invocation              | `plan.md`, `review.md`                                                      |
+When `ff_mini_loop` model parameters are omitted, child sessions inherit the parent session model (the SDK `model` field is omitted). The `doc_model` has a cascade: if `build_model` is set and `doc_model` is omitted, documentation uses `build_model`.
 
-- Pipeline stages pass intermediate artifacts with `{as:name}` and `$RESULT[name]` (minimal file persistence)
-- Planning fan-out (with architecture validation): opus, gemini, and codex models in parallel
-- Implementation: codex via frontmatter model declaration in `implement-batch.md`, with parallel `building` sub-agents per independent task within each batch
-- Review fan-out (with architecture validation): opus, gemini, and codex models in parallel
-- Rework path: `/pipeline/reviewing/run` re-enters implementation via `/pipeline/building/implement-batch` when gate status is `REWORK`
-- Documentation stage: codex updates documentation, gemini reviews docs, and orchestrator (`gpt-5.4`) supervises a bounded loop until approved
-- Documentation stage skill usage: codex pass loads `ff-todo-management`, `ff-mini-plan`; gemini review pass loads `ff-report-templates` and `ff-severity-classification`
+## Global Config Defaults
 
-## Quality Gates
+The plugin merges the following MCP servers into global OpenCode config when missing:
 
-- Planning approval: `>=75%` consensus.
-- Review approval: `>=95%` confidence and zero unresolved issues.
-- Documentation approval: documentation reviewer verdict `APPROVED` with zero unresolved documentation issues.
-- Planning loop confirmation: after 5 unsuccessful planning iterations, pipeline asks user whether to continue.
+- `jina-ai`
+- `gh_grep`
+- `context7`
+- `morph-mcp`
 
-## Async Progress Notifications
+`morph-mcp` is configured as:
 
-Both `ff_pipeline` and `ff_mini_loop` tools run asynchronously with real-time progress notifications:
-
-- **Immediate return**: Tools return instantly with a brief acknowledgment (e.g. `Pipeline started for: <summary>`), so the LLM can continue the conversation.
-- **Background orchestration**: The full pipeline or mini-loop runs in a detached `Promise`. All child session orchestration (fan-out, gates, loops) remains identical — it just executes after the tool returns.
-- **Progress updates via `promptAsync(noReply: true)`**: After each major phase completes, a structured notification is injected into the parent session as a visible chat message. These appear in the OpenCode TUI without triggering an LLM turn.
-- **Phase-by-phase visibility**: Users see updates for planning, building, CI validation (when `ff-ci.sh` present), each review iteration gate decision, each documentation iteration, and the final completion report.
-- **Error notifications**: If the background orchestration throws, a `# Pipeline: Error` or `# Mini-Loop: Error` notification is sent with the last phase and error message.
-- **`context.metadata()` retained**: All existing metadata calls remain in place for future-proofing (when OpenCode's TUI renders tool metadata natively).
-
-### Notification Format
-
-Pipeline notifications use plain-text markdown headers with phase START/END bracketing and per-iteration gate details:
-
-```
-# Pipeline: Reviewing — Iteration 2/10
-
-Status: APPROVED
-Confidence: 97%
-Unresolved Issues: 0
-Duration: 45.3s
-Feedback: N/A
+```json
+"morph-mcp": {
+  "type": "local",
+  "command": ["npx", "-y", "@morphllm/morphmcp"],
+  "environment": {
+    "MORPH_API_KEY": "{env:MORPH_API_KEY}"
+  }
+}
 ```
 
-Mini-loop notifications follow the same pattern:
+### Merge Outcomes
 
-```
-# Mini-Loop: Building — Iteration 1/10
-
-Status: REWORK
-Confidence: 82%
-Unresolved Issues: 2
-Duration: 23.1s
-Feedback: Fix type errors in handler.ts
-```
+`DEFAULT_MCP_SERVERS` currently includes 4 servers (`jina-ai`, `gh_grep`, `context7`, `morph-mcp`).
 
-Final reports use `# Pipeline: Complete` or `# Mini-Loop: Complete` headers containing the full markdown report. Errors use `# Pipeline: Error` or `# Mini-Loop: Error`.
+The merge behavior is additive and non-destructive:
 
-## Run Isolation
+- Empty or missing existing MCP config -> 4 servers after merge.
+- Existing config with 1 custom server and a customized `gh_grep` entry -> 5 servers after merge (custom + customized `gh_grep` + 3 missing defaults).
+- Existing server definitions are preserved and never overwritten by defaults.
 
-- Every `ff_pipeline` / `ff_mini_loop` invocation now creates a dedicated run parent session under the caller session.
-- All workflow child prompts and progress notifications are routed through that run parent session to keep caller context slim.
-- When `worktree_isolation: true`, the workflow runs in a dedicated detached git worktree directory.
-- Detached worktrees are cleaned up automatically after the background run finishes, exits early, or fails.
-- CI checks (`ff-ci.sh`) run against the resolved run directory (worktree when enabled, current directory otherwise).
+The plugin list is also merged non-destructively to ensure required companion plugins are present.
 
 ## Related Docs
 

package/agents/building.md

@@ -4,10 +4,10 @@ mode: primary
 color: '#22c55e'
 tools:
   read: true
-  write: true
-  edit: true
+  write: false
+  edit: false
+  edit_file: true
   bash: true
-  hashline_edit: true
   skill: true
   task: true
 permission:
@@ -34,23 +34,19 @@ You are the building specialist.
 - Do not rely on intermediate artifact files for pipeline progression.
 - Persist only when explicitly requested by the user.
 
-## Hashline Workflow (Required)
+## Editing Workflow (Required)
 
-File reads and edits use hashline-annotated tools. The `read` tool returns lines annotated with `#HL <line>:<hash>|<content>` and a `#HL REV:<hash>` header. Follow this workflow:
+Use Morph MCP `edit_file` for all implementation edits.
 
-1. **Always `read` before editing.** Note the `REV` value from the `#HL REV:<hash>` header — you need it for edits.
-2. **Use `hashline_edit`** for targeted, hash-referenced edits. Operations: `replace`, `delete`, `insert_before`, `insert_after`. Example:
-   ```json
-   { "path": "src/app.ts", "operation": "replace", "startRef": "5:a3f", "replacement": "const value = 2", "fileRev": "72c4946c" }
-   ```
-3. **Use built-in `edit`/`write`** for standard edits — hashline prefixes are automatically stripped before the tool executes.
-4. **After any edit/write**, re-read the file to get fresh refs before further edits.
-
-Never fabricate refs — always use exactly the refs returned by `read`.
+1. **Read before editing** to confirm current behavior and scope.
+2. **Apply changes with `edit_file`** for targeted replacements/insertions.
+3. **Re-read after edits** to verify the applied diff and avoid stale assumptions.
+4. **Avoid fallback editors** unless `edit_file` cannot express the required change.
 
 ## Semantic Code Search
 
 Use `cocoindex-code_search` for semantic code search when you need to:
+
 - Find implementations by meaning, not just text matching (e.g., "authentication logic", "database connection handling")
 - Locate related code without knowing exact names or keywords
 - Understand how features work across the codebase

package/agents/documenting.md

@@ -4,10 +4,10 @@ mode: primary
 color: '#f97316'
 tools:
   read: true
-  write: true
-  edit: true
+  write: false
+  edit: false
+  edit_file: true
   bash: false
-  hashline_edit: true
   skill: true
   task: true
 permission:
@@ -26,19 +26,14 @@ You are the documenting specialist.
 - Keep docs concise, consistent, and free of stale references.
 - Return a structured summary for documentation review.
 
-## Hashline Workflow (Required)
+## Editing Workflow (Required)
 
-File reads and edits use hashline-annotated tools. The `read` tool returns lines annotated with `#HL <line>:<hash>|<content>` and a `#HL REV:<hash>` header. Follow this workflow:
+Use Morph MCP `edit_file` for documentation updates.
 
-1. **Always `read` before editing.** Note the `REV` value — you need it for edits.
-2. **Use `hashline_edit`** for targeted, hash-referenced edits. Operations: `replace`, `delete`, `insert_before`, `insert_after`. Example:
-   ```json
-   { "path": "docs/FILE.md", "operation": "replace", "startRef": "5:a3f", "replacement": "Updated text", "fileRev": "72c4946c" }
-   ```
-3. **Use built-in `edit`/`write`** for standard edits — hashline prefixes are automatically stripped.
-4. **After any edit/write**, re-read the file to get fresh refs before further edits.
-
-Never fabricate refs — always use exactly the refs returned by `read`.
+1. **Read before editing** to confirm the current content and linked references.
+2. **Apply changes with `edit_file`** for precise doc updates.
+3. **Re-read after edits** to validate wording and cross-doc consistency.
+4. **Avoid fallback editors** unless `edit_file` cannot express the required change.
 
 ## Semantic Code Search
 

package/agents/feature-factory.md

@@ -7,7 +7,6 @@ tools:
   write: false
   edit: false
   bash: false
-  hashline_edit: false
   skill: true
   task: true
   ff_pipeline: true

package/agents/ff-research.md

@@ -7,7 +7,6 @@ tools:
   write: false
   edit: false
   bash: false
-  hashline_edit: false
   skill: true
   task: false
 permission:
@@ -28,6 +27,7 @@ You are the research specialist.
 You have access to powerful external research tools. **Use them proactively:**
 
 ### Web Search & Reading
+
 - **`jina-ai_search_web`** — Search the web for current information, docs, articles. Use for up-to-date library info, best practices, changelogs.
 - **`jina-ai_read_url`** — Read and extract content from any URL. Use to read official documentation, blog posts, READMEs.
 - **`jina-ai_expand_query`** — Expand search queries for broader coverage.
@@ -35,17 +35,21 @@ You have access to powerful external research tools. **Use them proactively:**
 - **`jina-ai_parallel_read_url`** — Read multiple URLs in parallel.
 
 ### Library Documentation
+
 - **`context7_resolve-library-id`** — Resolve a library name to a Context7 ID. Call this first before querying docs.
 - **`context7_query-docs`** — Query up-to-date library documentation with code examples. Excellent for API usage, configuration, and best practices.
 
 ### Code Examples
+
 - **`gh_grep_searchGitHub`** — Find real-world code examples from public GitHub repos. Search for literal code patterns (e.g., `useState(`, `import React from`), NOT keywords. Use to see how real projects implement specific patterns.
 
 ### Academic Papers
+
 - **`jina-ai_search_arxiv`** — Search arXiv for research papers (AI, CS, physics, math).
 - **`jina-ai_search_ssrn`** — Search SSRN for social science research.
 
 ### Semantic Code Search
+
 - **`cocoindex-code_search`** — Search the local codebase by meaning. Use to understand the project's existing patterns before recommending changes.
 
 ## Method

package/agents/planning.md

@@ -7,7 +7,6 @@ tools:
   write: false
   edit: false
   bash: false
-  hashline_edit: false
   skill: true
   task: true
 permission:
@@ -26,15 +25,16 @@ You are the planning specialist.
 - Identify risks, assumptions, and validation strategy.
 - Apply planning gate criteria and emit explicit status lines.
 
-## Hashline Workflow (Required)
+## Editing Guidance
 
-Use the `read` tool to inspect files. Lines are annotated with `#HL <line>:<hash>|<content>` and a `#HL REV:<hash>` header. Use these refs when planning edit operations — include the `startRef` values in your implementation steps so the builder can apply them directly.
+Implementation should prefer Morph MCP `edit_file` for code changes. In planning outputs, reference concrete files and intended edits, not line-hash references.
 
 You are a read-only agent — you do not write or edit files.
 
 ## Semantic Code Search
 
 Use `cocoindex-code_search` for semantic code search when planning:
+
 - Understand existing architecture by meaning (e.g., "authentication logic", "API routing")
 - Find related implementations before proposing changes
 - Verify assumptions about how code works
@@ -44,6 +44,7 @@ Prefer this over `grep` when searching by concept rather than exact text.
 ## External Research
 
 Use `@ff-research` for external/library uncertainty. The research agent has access to:
+
 - `jina-ai_search_web` / `jina-ai_read_url` for web search and documentation
 - `context7_query-docs` for library-specific documentation
 - `gh_grep_searchGitHub` for real-world code examples

package/agents/reviewing.md

@@ -7,7 +7,6 @@ tools:
   write: false
   edit: false
   bash: false
-  hashline_edit: false
   skill: true
   task: true
 permission:
@@ -26,15 +25,16 @@ You are the unified reviewing specialist.
 - Apply scope based on context: acceptance, code quality, security, architecture, documentation.
 - Return actionable findings with severity and confidence.
 
-## Hashline Workflow (Required)
+## File Review Guidance
 
-Use the `read` tool to inspect files. Lines are annotated with `#HL <line>:<hash>|<content>` and a `#HL REV:<hash>` header. Use these refs to cite specific lines in your review findings.
+Use the `read` tool to inspect files and cite standard line references in findings. Do not require hash-based line references.
 
 You are a read-only agent — you do not write or edit files.
 
 ## Semantic Code Search
 
 Use `cocoindex-code_search` for semantic code search when reviewing:
+
 - Search by meaning to find related code (e.g., "input validation", "access control checks")
 - Verify that implementations match architectural patterns across the codebase
 - Find similar code to check for consistency

package/bin/ff-deploy.js

@@ -3,7 +3,7 @@
 /**
  * Feature Factory Deployment Script
  *
- * Deploys skills, agents, and command files to the global OpenCode configuration directory.
+ * Deploys skills and agents to the global OpenCode configuration directory.
  * Run manually with: npx @syntesseraai/opencode-feature-factory
  */
 
@@ -18,13 +18,11 @@ const __dirname = dirname(__filename);
 const GLOBAL_CONFIG_DIR = join(homedir(), '.config', 'opencode');
 const SKILLS_DIR = join(GLOBAL_CONFIG_DIR, 'skills');
 const AGENTS_DIR = join(GLOBAL_CONFIG_DIR, 'agents');
-const COMMAND_DIR = join(GLOBAL_CONFIG_DIR, 'command');
 const GLOBAL_CONFIG_FILE = join(GLOBAL_CONFIG_DIR, 'opencode.json');
 
 const PACKAGE_ROOT = join(__dirname, '..');
 const SOURCE_SKILLS_DIR = join(PACKAGE_ROOT, 'skills');
 const SOURCE_AGENTS_DIR = join(PACKAGE_ROOT, 'agents');
-const SOURCE_COMMAND_DIR = join(PACKAGE_ROOT, 'command');
 
 // Check if running in interactive mode (has TTY)
 const isInteractive = process.stdin.isTTY && process.stdout.isTTY;
@@ -49,6 +47,13 @@ const DEFAULT_MCP_SERVERS = {
       CONTEXT7_API_KEY: '{env:CONTEXT7_API_KEY}',
     },
   },
+  'morph-mcp': {
+    type: 'local',
+    command: ['npx', '-y', '@morphllm/morphmcp'],
+    environment: {
+      MORPH_API_KEY: '{env:MORPH_API_KEY}',
+    },
+  },
 };
 
 const DEFAULT_PLUGINS = [
@@ -57,7 +62,6 @@ const DEFAULT_PLUGINS = [
   '@franlol/opencode-md-table-formatter@latest',
   '@spoons-and-mirrors/subtask2@latest',
   'opencode-pty@latest',
-  'opencode-hashline@latest',
 ];
 
 function getPackageBaseName(plugin) {
@@ -132,26 +136,6 @@ async function getFileNames(dir) {
   }
 }
 
-async function getMarkdownFileCount(dir) {
-  try {
-    const entries = await fs.readdir(dir, { withFileTypes: true });
-    let count = 0;
-
-    for (const entry of entries) {
-      const entryPath = join(dir, entry.name);
-      if (entry.isDirectory()) {
-        count += await getMarkdownFileCount(entryPath);
-      } else if (entry.isFile() && entry.name.endsWith('.md')) {
-        count += 1;
-      }
-    }
-
-    return count;
-  } catch {
-    return 0;
-  }
-}
-
 async function updateMCPConfig() {
   if (isInteractive) {
     console.log('\n🔧 MCP Configuration Update');
@@ -292,7 +276,6 @@ async function deploy() {
     await ensureDir(GLOBAL_CONFIG_DIR);
     await ensureDir(SKILLS_DIR);
     await ensureDir(AGENTS_DIR);
-    await ensureDir(COMMAND_DIR);
 
     // Get existing skills/agents for reporting
     const existingSkills = await getDirectoryNames(SKILLS_DIR);
@@ -333,22 +316,11 @@ async function deploy() {
       }
     }
 
-    // Deploy command files
-    if (isInteractive) {
-      console.log('\n⌨️  Deploying Commands...');
-    }
-    await copyDir(SOURCE_COMMAND_DIR, COMMAND_DIR);
-    const commandsCount = await getMarkdownFileCount(SOURCE_COMMAND_DIR);
-    if (isInteractive) {
-      console.log(`  ✅ pipeline commands (${commandsCount} files) (overwritten)`);
-    }
-
     // Summary
     if (isInteractive) {
       console.log('\n✨ Deployment Complete!');
       console.log(`   Skills: ${skills.length} deployed`);
       console.log(`   Agents: ${agents.length} deployed`);
-      console.log(`   Commands: ${commandsCount} deployed`);
       console.log(`   Location: ${GLOBAL_CONFIG_DIR}`);
       console.log('\n📝 Next Steps:');
       console.log('   - Restart OpenCode or run /reload to load new agents');

package/dist/index.js

@@ -45,8 +45,8 @@ export const FeatureFactoryPlugin = async (input) => {
     const qualityGateHooks = await StopQualityGateHooksPlugin(input).catch(() => ({}));
     // Tool registry: workflow tools (ff_pipeline, ff_mini_loop) powered by
     // the SDK client for programmatic session orchestration.
-    // The old ff-* artifact tools were removed; these replace the subtask2
-    // command-based workflow with TypeScript-driven orchestration.
+    // The old ff-* artifact tools were removed; orchestration is fully
+    // TypeScript-driven via these workflow tools.
     const workflowTools = createWorkflowTools(input.client);
     // Merge workflow tools with any existing tools from quality gate hooks
     const existingTools = qualityGateHooks.tool ?? {};

package/dist/mcp-config.d.ts

@@ -22,12 +22,20 @@ export declare const DEFAULT_MCP_SERVERS: {
             readonly CONTEXT7_API_KEY: "{env:CONTEXT7_API_KEY}";
         };
     };
+    readonly 'morph-mcp': {
+        readonly type: "local";
+        readonly command: readonly ["npx", "-y", "@morphllm/morphmcp"];
+        readonly environment: {
+            readonly MORPH_API_KEY: "{env:MORPH_API_KEY}";
+        };
+    };
 };
 export interface MCPServerConfig {
     type: 'local' | 'remote';
-    command?: string;
+    command?: string[];
     url?: string;
     headers?: Record<string, string>;
+    environment?: Record<string, string>;
     enabled?: boolean;
 }
 export interface MCPServers {

package/dist/mcp-config.js

@@ -22,6 +22,13 @@ export const DEFAULT_MCP_SERVERS = {
             CONTEXT7_API_KEY: '{env:CONTEXT7_API_KEY}',
         },
     },
+    'morph-mcp': {
+        type: 'local',
+        command: ['npx', '-y', '@morphllm/morphmcp'],
+        environment: {
+            MORPH_API_KEY: '{env:MORPH_API_KEY}',
+        },
+    },
 };
 /**
  * Merge MCP servers, preserving existing servers and adding new ones.

package/dist/plugin-config.js

@@ -10,7 +10,6 @@ export const DEFAULT_PLUGINS = [
     '@franlol/opencode-md-table-formatter@latest',
     '@spoons-and-mirrors/subtask2@latest',
     'opencode-pty@latest',
-    'opencode-hashline@latest',
 ];
 /**
  * Extract the base package name from a plugin specifier, stripping the

package/dist/tools/mini-loop.js

@@ -9,7 +9,7 @@
  * to the parent session via `promptAsync(noReply: true)`.
  */
 import { tool } from '@opencode-ai/plugin/tool';
-import { promptSession, notifyParent, createRunParentSession, evaluateMiniLoopImplGate, evaluateMiniLoopDocGate, parseModelString, } from '../workflow/orchestrator.js';
+import { promptSession, notifyParent, evaluateMiniLoopImplGate, evaluateMiniLoopDocGate, parseModelString, } from '../workflow/orchestrator.js';
 import { miniBuildPrompt, miniReviewPrompt, documentPrompt, docReviewPrompt, ciFixPrompt, } from './prompts.js';
 import { parseMiniReview, parseDocReview } from './parsers.js';
 import { ciScriptExists, runCI } from '../workflow/ci-runner.js';
@@ -75,10 +75,10 @@ export function createMiniLoopTool(client) {
                 enabled: args.worktree_isolation,
                 parentDirectory: args.worktree_parent_dir,
             });
-            const runContext = await createRunParentSession(client, callerSessionId, {
-                title: `ff-mini-loop-run-${runDirectoryContext.runId}`,
+            const runContext = {
+                sessionId: callerSessionId,
                 directory: runDirectoryContext.runDirectory,
-            });
+            };
             // Fire-and-forget: run orchestration in background
             let lastPhase = 'init';
             const asyncOrchestration = async () => {
@@ -429,7 +429,7 @@ export function createMiniLoopTool(client) {
             });
             // Return immediately with acknowledgment
             const summary = requirements.length > 120 ? requirements.slice(0, 120) + '...' : requirements;
-            return `Mini-loop started for: ${summary}\n\nRun session: ${runContext.sessionId}\nRun directory: ${runDirectoryContext.runDirectory}\nWorktree isolation: ${runDirectoryContext.worktreeEnabled ? 'enabled' : 'disabled'}\nYou will receive progress updates as each phase completes.`;
+            return `Mini-loop started for: ${summary}\n\nRun directory: ${runDirectoryContext.runDirectory}\nWorktree isolation: ${runDirectoryContext.worktreeEnabled ? 'enabled' : 'disabled'}\nYou will receive progress updates as each phase completes.`;
         },
     });
 }

package/dist/tools/pipeline.js

@@ -11,7 +11,7 @@
  * to the parent session via `promptAsync(noReply: true)`.
  */
 import { tool } from '@opencode-ai/plugin/tool';
-import { fanOut, promptSession, notifyParent, createRunParentSession, evaluatePlanningGate, evaluateReviewGate, evaluateDocGate, PLANNING_MODELS, REVIEW_MODELS, ORCHESTRATOR_MODEL, BUILD_MODEL, DOC_MODEL, VALIDATE_MODEL, DOC_REVIEW_MODEL, parseModelString, parseNamedModels, } from '../workflow/orchestrator.js';
+import { fanOut, promptSession, notifyParent, evaluatePlanningGate, evaluateReviewGate, evaluateDocGate, PLANNING_MODELS, REVIEW_MODELS, ORCHESTRATOR_MODEL, BUILD_MODEL, DOC_MODEL, VALIDATE_MODEL, DOC_REVIEW_MODEL, parseModelString, parseNamedModels, } from '../workflow/orchestrator.js';
 import { planningPrompt, synthesisPrompt, breakdownPrompt, validateBatchPrompt, implementBatchPrompt, triagePrompt, reviewPrompt, reviewSynthesisPrompt, documentPrompt, docReviewPrompt, ciFixPrompt, } from './prompts.js';
 import { ciScriptExists, runCI } from '../workflow/ci-runner.js';
 import { cleanupWorktree, resolveRunDirectory } from '../workflow/run-isolation.js';
@@ -104,10 +104,10 @@ export function createPipelineTool(client) {
                 enabled: args.worktree_isolation,
                 parentDirectory: args.worktree_parent_dir,
             });
-            const runContext = await createRunParentSession(client, callerSessionId, {
-                title: `ff-pipeline-run-${runDirectoryContext.runId}`,
+            const runContext = {
+                sessionId: callerSessionId,
                 directory: runDirectoryContext.runDirectory,
-            });
+            };
             // Fire-and-forget: run full orchestration in background
             let lastPhase = 'init';
             const asyncOrchestration = async () => {
@@ -710,7 +710,7 @@ export function createPipelineTool(client) {
             });
             // Return immediately with acknowledgment
             const summary = requirements.length > 120 ? requirements.slice(0, 120) + '...' : requirements;
-            return `Pipeline started for: ${summary}\n\nRun session: ${runContext.sessionId}\nRun directory: ${runDirectoryContext.runDirectory}\nWorktree isolation: ${runDirectoryContext.worktreeEnabled ? 'enabled' : 'disabled'}\nYou will receive progress updates as each phase completes.`;
+            return `Pipeline started for: ${summary}\n\nRun directory: ${runDirectoryContext.runDirectory}\nWorktree isolation: ${runDirectoryContext.worktreeEnabled ? 'enabled' : 'disabled'}\nYou will receive progress updates as each phase completes.`;
         },
     });
 }

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "@syntesseraai/opencode-feature-factory",
-  "version": "0.10.3",
+  "version": "0.10.4",
   "type": "module",
   "description": "OpenCode plugin for Feature Factory agents - provides sub-agents and skills for validation, review, security, and architecture assessment",
   "license": "MIT",
@@ -15,7 +15,6 @@
     "assets",
     "skills",
     "agents",
-    "command",
     "bin"
   ],
   "keywords": [

package/command/mini-loop/documentation/document.md

@@ -1,15 +0,0 @@
----
-description: Write documentation pass for mini-loop
-subtask: true
-agent: documenting
-model: openai/gpt-5.3-codex
----
-
-Update repository documentation for the approved mini-loop implementation from `$ARGUMENTS`.
-
-Requirements:
-
-1. Reflect shipped behavior and operational steps exactly.
-2. Apply prior documentation rework feedback when present.
-3. Keep updates concise and cross-link impacted docs when needed.
-4. Return a concise documentation update report with changed docs and rationale.

package/command/mini-loop/documentation/gate.md

@@ -1,16 +0,0 @@
----
-description: Apply documentation mini-loop gate
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Read the latest documentation review input from `$ARGUMENTS` and apply this gate exactly:
-
-- APPROVED only when `CONFIDENCE` is strictly `>95`, `CHANGE_REQUESTED=NO`, and `UNRESOLVED_DOCUMENTATION_ISSUES=0`
-- REWORK when not approved and iteration < 5
-- ESCALATE when iteration == 5 and still not approved
-
-Output exactly one line:
-
-`MINI_LOOP_DOCUMENTATION_GATE=APPROVED|REWORK|ESCALATE`

package/command/mini-loop/documentation/review.md

@@ -1,17 +0,0 @@
----
-description: Review documentation pass for mini-loop
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Review the latest mini-loop documentation pass from `$ARGUMENTS`.
-
-Required output fields:
-
-1. `CHANGE_REQUESTED=YES|NO`
-2. `UNRESOLVED_DOCUMENTATION_ISSUES=<integer>`
-3. `CONFIDENCE=<0-100>`
-4. concise documentation rework instructions when change is requested
-
-Return a deterministic structured documentation review result with no file persistence.

package/command/mini-loop/documentation/run.md

@@ -1,16 +0,0 @@
----
-description: Run documentation mini-loop until gate passes
-subtask: false
-agent: general
-model: openai/gpt-5.4
-loop:
-  max: 5
-  until: documentation gate is APPROVED
-return:
-  - /mini-loop/documentation/document {as:mini-doc-pass} $ARGUMENTS
-  - /mini-loop/documentation/review {as:mini-doc-review} $RESULT[mini-doc-pass]
-  - /mini-loop/documentation/gate $RESULT[mini-doc-review]
-  - If `MINI_LOOP_DOCUMENTATION_GATE=REWORK`, continue loop with prior documentation review feedback included in the next documentation pass.
----
-
-Reply with only: "Documentation phase started"

package/command/mini-loop/implementation/build.md

@@ -1,15 +0,0 @@
----
-description: Build implementation pass for mini-loop
-subtask: true
-agent: building
-model: openai/gpt-5.3-codex
----
-
-Implement the current mini-loop requirements from `$ARGUMENTS`.
-
-Requirements:
-
-1. Apply requested code rework when present.
-2. Add or update tests for behavioral changes.
-3. Run lint/typecheck/tests only for impacted scope.
-4. Return a concise implementation report with changed files, tests run, and known open issues.

package/command/mini-loop/implementation/gate.md

@@ -1,16 +0,0 @@
----
-description: Apply implementation mini-loop gate
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Read the latest implementation review input from `$ARGUMENTS` and apply this gate exactly:
-
-- APPROVED only when `CONFIDENCE` is strictly `>95`, `CHANGE_REQUESTED=NO`, and `UNRESOLVED_BLOCKING_ISSUES=0`
-- REWORK when not approved and iteration < 10
-- ESCALATE when iteration == 10 and still not approved
-
-Output exactly one line:
-
-`MINI_LOOP_IMPLEMENTATION_GATE=APPROVED|REWORK|ESCALATE`

package/command/mini-loop/implementation/review.md

@@ -1,17 +0,0 @@
----
-description: Review implementation pass for mini-loop
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Review the latest mini-loop implementation output from `$ARGUMENTS`.
-
-Required output fields:
-
-1. `CHANGE_REQUESTED=YES|NO`
-2. `UNRESOLVED_BLOCKING_ISSUES=<integer>`
-3. `CONFIDENCE=<0-100>`
-4. concise rework instructions when change is requested
-
-Return a deterministic structured review result with no file persistence.

package/command/mini-loop/implementation/run.md

@@ -1,16 +0,0 @@
----
-description: Run implementation mini-loop until gate passes
-subtask: false
-agent: general
-model: openai/gpt-5.4
-loop:
-  max: 10
-  until: implementation gate is APPROVED
-return:
-  - /mini-loop/implementation/build {as:mini-impl-build} $ARGUMENTS
-  - /mini-loop/implementation/review {as:mini-impl-review} $RESULT[mini-impl-build]
-  - /mini-loop/implementation/gate $RESULT[mini-impl-review]
-  - If `MINI_LOOP_IMPLEMENTATION_GATE=REWORK`, continue loop with prior review feedback included in the next build input.
----
-
-Reply with only: "Implementation phase started"

package/command/mini-loop/start.md

@@ -1,11 +0,0 @@
----
-description: Mini-loop two-stage workflow entrypoint
-subtask: false
-agent: general
-model: openai/gpt-5.4
-return:
-  - /mini-loop/implementation/run {as:implementation-phase} $ARGUMENTS
-  - /mini-loop/documentation/run $RESULT[implementation-phase]
----
-
-Reply with only: "Mini-loop started"

package/command/pipeline/building/breakdown.md

@@ -1,18 +0,0 @@
----
-description: Break final plan into atomic tasks
-subtask: true
-agent: building
-model: anthropic/claude-opus-4-6
----
-
-Read the approved final plan from `$ARGUMENTS` and produce atomic tasks.
-
-Each task must include:
-
-- task id
-- title and description
-- target files
-- dependencies
-- acceptance criteria
-
-Return structured `TASKS` output (no file persistence).

package/command/pipeline/building/implement-batch.md

@@ -1,26 +0,0 @@
----
-description: Implement validated batches with Codex
-subtask: true
-agent: building
-model: openai/gpt-5.3-codex
----
-
-Read `BATCHES` input from `$ARGUMENTS` and implement each batch.
-
-Execution strategy:
-
-1. Process batches in dependency order — a batch may only start after all batches it depends on have completed.
-2. Within each batch, launch **parallel sub-agents** (type: `building`) — one per task — for tasks that have no mutual dependency edges. Use concurrent tool calls to maximize throughput.
-3. Tasks within the same batch that share file targets or have explicit dependency edges must run sequentially.
-4. Wait for all tasks in a batch to complete before starting the next batch.
-
-For each task (inside its sub-agent):
-
-1. implement code changes
-2. add/update tests
-3. run lint/typecheck/tests for impacted scope
-4. return a structured completion report (no file persistence)
-
-After all batches complete, merge the per-task completion reports into a single `IMPLEMENTATION_REPORT` output.
-
-This command performs implementation only; reviewing is triggered by `/pipeline/building/run` and by rework flow.

package/command/pipeline/building/run.md

@@ -1,13 +0,0 @@
----
-description: Run build phase from approved plan
-subtask: false
-agent: general
-model: openai/gpt-5.4
-return:
-  - /pipeline/building/breakdown {as:build-tasks} $ARGUMENTS
-  - /pipeline/building/validate-batch {as:build-batches} $RESULT[build-tasks]
-  - /pipeline/building/implement-batch {as:build-implementation} $RESULT[build-batches]
-  - /pipeline/reviewing/run {as:review-phase} $RESULT[build-implementation]
----
-
-Reply with only: "Building phase started"

package/command/pipeline/building/validate-batch.md

@@ -1,17 +0,0 @@
----
-description: Validate task batches for architecture and dependencies
-subtask: true
-agent: building
-model: opencode/gemini-3.1-pro
----
-
-Read `TASKS` input from `$ARGUMENTS` and create dependency-safe batches.
-
-For each batch:
-
-1. validate architecture and codebase fit
-2. confirm or adjust file targets
-3. flag architectural risks
-4. mark whether tasks can run in parallel
-
-Return structured `BATCHES` output (no file persistence).

package/command/pipeline/complete.md

@@ -1,13 +0,0 @@
----
-description: Finalize pipeline run and summarize outcomes
-subtask: true
-agent: general
-model: openai/gpt-5.4
----
-
-Finalize the pipeline run.
-
-1. Summarize accepted plan, implemented tasks, review outcomes, and assumptions.
-2. Prefer result-based handoff; persist only final user-requested artifacts.
-3. Clear transient pipeline agent context files.
-4. Return concise completion report to user.

package/command/pipeline/documentation/document.md

@@ -1,22 +0,0 @@
----
-description: Documentation write/update pass
-subtask: true
-agent: documenting
-model: openai/gpt-5.3-codex
----
-
-Document the approved code changes and update repository documentation.
-
-Before writing docs, load these skills:
-
-- `ff-todo-management`
-- `ff-mini-plan`
-
-Requirements:
-
-1. Use the latest approved review outputs and implementation artifacts as source of truth.
-2. Update all affected docs so behavior and operational steps match shipped code.
-3. If this is a rework iteration, incorporate documentation reviewer feedback from the previous documentation review.
-4. Summarize what docs were changed and why.
-
-Return a structured documentation update summary (no file persistence).

package/command/pipeline/documentation/gate.md

@@ -1,20 +0,0 @@
----
-description: Apply documentation approval gate
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Read the latest documentation review input from `$ARGUMENTS` and apply gate exactly:
-
-Skill requirements:
-
-- ChatGPT gate supervisor should keep gate decisions explicit and iteration-aware.
-
-- APPROVED when verdict is `APPROVED` and unresolved documentation issues count is `0`
-- REWORK when verdict is `REWORK_REQUIRED` and iteration < 5
-- ESCALATE when iteration == 5 and still not approved
-
-Output one status line:
-
-`DOCUMENTATION_GATE=APPROVED|REWORK|ESCALATE`

package/command/pipeline/documentation/review.md

@@ -1,22 +0,0 @@
----
-description: Documentation review pass
-subtask: true
-agent: reviewing
-model: opencode/gemini-3.1-pro
----
-
-Review the latest Codex documentation pass for completeness, correctness, and repository doc consistency.
-
-Before reviewing docs, load these skills:
-
-- `ff-report-templates`
-- `ff-severity-classification`
-
-Required output:
-
-1. verdict `APPROVED` or `REWORK_REQUIRED`
-2. unresolved documentation issues (if any)
-3. explicit rework instructions
-4. confidence score (0-100)
-
-Return a structured documentation review result (no file persistence).

package/command/pipeline/documentation/run.md

@@ -1,16 +0,0 @@
----
-description: Run documentation loop after review approval
-subtask: false
-agent: general
-model: openai/gpt-5.4
-loop:
-  max: 5
-  until: documentation updates are approved by documentation reviewer with zero unresolved documentation issues
-return:
-  - /pipeline/documentation/document {as:doc-pass} $ARGUMENTS
-  - /pipeline/documentation/review {as:doc-review} $RESULT[doc-pass]
-  - /pipeline/documentation/gate $RESULT[doc-review]
-  - If `DOCUMENTATION_GATE=REWORK`, continue loop with review feedback for the next document pass.
----
-
-Reply with only: "Documentation phase started"

package/command/pipeline/planning/confirm.md

@@ -1,18 +0,0 @@
----
-description: Confirm whether pipeline can proceed after planning
-subtask: true
-agent: planning
-model: openai/gpt-5.4
----
-
-Read the planning output in `$ARGUMENTS` and decide whether the pipeline may proceed.
-
-Rules:
-
-1. If `PLANNING_GATE=APPROVED`, return:
-   - `PLANNING_PROCEED=YES`
-   - The approved `FINAL_PLAN` content for build input.
-2. If `PLANNING_GATE=REWORK` or `PLANNING_GATE=BLOCKED`, return:
-   - `PLANNING_PROCEED=NO`
-   - A short `USER_CONFIRMATION_REQUIRED` section explaining why continuation needs explicit user confirmation.
-3. Do not invent missing gate values.

package/command/pipeline/planning/gate.md

@@ -1,24 +0,0 @@
----
-description: Apply planning consensus gate
-subtask: true
-agent: planning
-model: openai/gpt-5.4
----
-
-Apply the planning gate to the synthesized consensus input passed in `$ARGUMENTS`:
-
-- `>=75`: APPROVED
-- `50-74`: REWORK
-- `<50`: BLOCKED
-
-Actions:
-
-1. If APPROVED, return the accepted final plan in a `FINAL_PLAN` section.
-2. If REWORK, return explicit divergence feedback so the next planning loop iteration re-plans with clear deltas.
-3. If BLOCKED, return explicit user-decision-needed rationale.
-
-Always include one status line in your final output:
-
-`PLANNING_GATE=APPROVED|REWORK|BLOCKED`
-
-If APPROVED, include a `FINAL_PLAN` section that becomes input to the build phase.

package/command/pipeline/planning/plan.md

@@ -1,25 +0,0 @@
----
-description: Generate one model-specific planning proposal
-subtask: true
-agent: planning
----
-
-Create a comprehensive implementation plan from the current pipeline requirements.
-
-Input format:
-
-- Prefix includes model tag as `[MODEL_TAG:<tag>]`
-- Remaining content is the requirements brief
-
-Requirements brief:
-
-$ARGUMENTS
-
-Return a structured proposal (no file persistence) with these sections:
-
-1. `MODEL_TAG`
-2. `REQUIREMENTS_SUMMARY`
-3. `ARCHITECTURE_VALIDATION`
-4. `IMPLEMENTATION_STEPS`
-5. `RISKS_AND_MITIGATIONS`
-6. `TESTING_AND_VALIDATION_STRATEGY`

package/command/pipeline/planning/run.md

@@ -1,15 +0,0 @@
----
-description: Execute one planning iteration
-subtask: false
-agent: general
-model: openai/gpt-5.4
-parallel:
-  - /pipeline/planning/plan {model:anthropic/claude-opus-4-6 && as:plan-opus} [MODEL_TAG:opus] $ARGUMENTS
-  - /pipeline/planning/plan {model:opencode/gemini-3.1-pro && as:plan-gemini} [MODEL_TAG:gemini] $ARGUMENTS
-  - /pipeline/planning/plan {model:openai/gpt-5.3-codex && as:plan-codex} [MODEL_TAG:codex] $ARGUMENTS
-return:
-  - /pipeline/planning/synthesize {as:plan-consensus} $RESULT[plan-opus] $RESULT[plan-gemini] $RESULT[plan-codex]
-  - /pipeline/planning/gate $RESULT[plan-consensus]
----
-
-Reply with only: "Planning phase started"

package/command/pipeline/planning/synthesize.md

@@ -1,22 +0,0 @@
----
-description: Synthesize planning consensus
-subtask: true
-agent: planning
-model: openai/gpt-5.4
----
-
-Synthesize the three model outputs from planning fan-out:
-
-- `$RESULT[plan-opus]`
-- `$RESULT[plan-gemini]`
-- `$RESULT[plan-codex]`
-
-Produce a consensus report (no file persistence).
-
-Required output sections:
-
-1. `CONSENSUS_SCORE` (0-100)
-2. `AGREED_ELEMENTS`
-3. `DIVERGENT_ELEMENTS`
-4. `SYNTHESIZED_PLAN`
-5. `OPEN_QUESTIONS`

package/command/pipeline/reviewing/gate.md

@@ -1,16 +0,0 @@
----
-description: Apply review approval gate
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Read the synthesized review input from `$ARGUMENTS` and apply gate exactly:
-
-- APPROVED when confidence `>=95` and unresolved issues count is `0`
-- REWORK when below threshold and iteration < 10
-- ESCALATE when iteration == 10 and still not approved
-
-Output one status line:
-
-`REVIEW_GATE=APPROVED|REWORK|ESCALATE`

package/command/pipeline/reviewing/review.md

@@ -1,20 +0,0 @@
----
-description: Generate one model-specific review report
-subtask: true
-agent: reviewing
----
-
-Review the current task from triage brief for correctness, quality, architecture validity, testing, security, and edge cases.
-
-Input format:
-
-- Prefix includes model tag as `[MODEL_TAG:<tag>]`
-- Remaining content is optional additional brief context
-
-Context brief:
-
-$ARGUMENTS
-
-Classify findings as critical/high/medium/low and include confidence score.
-
-Return a structured review report (no file persistence).

package/command/pipeline/reviewing/run.md

@@ -1,21 +0,0 @@
----
-description: Run review loop for completed tasks
-subtask: false
-agent: general
-model: openai/gpt-5.4
-loop:
-  max: 10
-  until: all tasks in the active batch are approved with confidence >=95 and zero unresolved issues
-return:
-  - /pipeline/reviewing/triage {as:review-brief} $ARGUMENTS
-parallel:
-  - /pipeline/reviewing/review {model:anthropic/claude-opus-4-6 && as:review-opus} [MODEL_TAG:opus] $RESULT[review-brief]
-  - /pipeline/reviewing/review {model:opencode/gemini-3.1-pro && as:review-gemini} [MODEL_TAG:gemini] $RESULT[review-brief]
-  - /pipeline/reviewing/review {model:openai/gpt-5.3-codex && as:review-codex} [MODEL_TAG:codex] $RESULT[review-brief]
-return:
-  - /pipeline/reviewing/synthesize {as:review-synthesis} $RESULT[review-opus] $RESULT[review-gemini] $RESULT[review-codex]
-  - /pipeline/reviewing/gate $RESULT[review-synthesis]
-  - If `REVIEW_GATE=REWORK`, invoke `/pipeline/building/implement-batch` to apply fixes before the next loop iteration.
----
-
-Reply with only: "Reviewing phase started"

package/command/pipeline/reviewing/synthesize.md

@@ -1,18 +0,0 @@
----
-description: Synthesize independent reviews into one report
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Read the three review inputs passed in `$ARGUMENTS` (reviewer, architect, developer) and synthesize a single authoritative output.
-
-Required output:
-
-1. overall confidence (0-100)
-2. consolidated deduplicated findings
-3. unresolved issues list
-4. verdict `APPROVED` or `REWORK_REQUIRED`
-5. explicit rework instructions when needed
-
-Return a structured synthesis report (no file persistence).

package/command/pipeline/reviewing/triage.md

@@ -1,16 +0,0 @@
----
-description: Build review brief from implementation outputs
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Prepare a review brief for the current completed task or rework output.
-
-Include:
-
-- summary of implemented changes
-- files changed
-- focus areas and risk points
-
-Return a structured `REVIEW_BRIEF` output (no file persistence).

package/command/pipeline/start.md

@@ -1,14 +0,0 @@
----
-description: Pipeline workflow entrypoint
-subtask: false
-agent: general
-model: openai/gpt-5.4
-return:
-  - /pipeline/planning/run {as:planning-phase && loop:5 && until:planning gate is APPROVED or planning gate is BLOCKED and waiting for user confirmation} $ARGUMENTS
-  - /pipeline/planning/confirm {as:planning-decision} $RESULT[planning-phase]
-  - /pipeline/building/run {as:build-phase} $RESULT[planning-decision]
-  - /pipeline/documentation/run $RESULT[build-phase]
-  - /pipeline/complete
----
-
-Reply with only: "Workflow started"