opencastle 0.27.3 → 0.29.0

package/src/orchestrator/prompts/generate-convoy.prompt.md

@@ -37,8 +37,8 @@ The output file must conform to the following schema. Fields marked **(required)
 | `gates` | array of strings | no | — | Shell commands run after all tasks complete; each must exit 0 |
 | `gate_retries` | integer ≥ 0 | no | `0` | How many times to retry failing gates with an auto-fix task |
 | `guard` | object | no | — | Post-convoy guard configuration (see Guard below) |
-| `hooks` | array of Hook | no | — | Post-convoy lifecycle hooks (see Hooks below) |
-| `watch` | object | no | — | Watch mode configuration for continuous re-runs (see Watch below) |
+| `hooks` | array of Hook | no | — | Post-convoy lifecycle hooks. Use `post_convoy` hooks for notifications or cleanup scripts after the run completes. |
+| `watch` | object | no | — | Watch mode configuration for continuous re-runs. Set this when the goal is a recurring workflow (e.g. nightly sync, CI re-run on file change). |
 | `tasks` | list | **yes** | — | Non-empty list of task objects |
 | `depends_on_convoy` | list of strings | no | — | (version 2 only) Other convoy spec names to run before this one |
 
@@ -49,31 +49,21 @@ All fields are optional. Values are merged into each task unless the task overri
 | Field | Type | Default | Description |
 |-------|------|---------|-------------|
 | `timeout` | duration | `30m` | Default task timeout (`<n><s\|m\|h>`) |
-| `model` | string | — | AI model override for all tasks |
 | `max_retries` | integer | `1` | Default max retry attempts |
 | `agent` | string | `developer` | Default agent role |
-| `adapter` | string | — | Default adapter override |
-| `gates` | array of strings | — | Per-task gate commands run after adapter success |
+| `gates` | array of strings | — | Gate commands run after every task completes (use for project-wide lint/type-check) |
 | `review` | `auto` \| `fast` \| `panel` \| `none` | — | Review level for completed tasks |
-| `reviewer_model` | string | — | Model used for reviews |
-| `review_budget` | integer | — | Max review token budget |
-| `on_review_budget_exceeded` | `skip` \| `downgrade` \| `stop` | — | Action when review budget exhausted |
-| `max_concurrent_reviews` | integer | — | Parallel review limit |
-| `review_heuristics` | object | — | Auto-routing rules (see Review Heuristics below) |
-| `detect_drift` | boolean | — | Enable drift detection on streaming adapters |
-| `on_dispute` | `continue` \| `stop` | — | Behavior on panel disputes |
-| `on_exhausted` | `dlq` \| `skip` \| `stop` | — | Action when max_retries exhausted |
-| `escalate_to` | string | — | Agent for DLQ escalation |
-| `inject_lessons` | boolean | — | Auto-inject relevant lessons from LESSONS-LEARNED.md into prompts |
-| `track_discovered_issues` | boolean | — | Enable discovered issues tracking in prompts |
-| `avoid_weak_agents` | boolean | — | Skip assigning agents to tasks matching their weak areas |
-| `max_swarm_concurrency` | integer (1–50) | `8` | Max parallel tasks in swarm mode (`concurrency: auto`) |
-| `built_in_gates` | object | — | Built-in gate configuration (see Built-in Gates below) |
-| `browser_test` | object | — | Default browser test gate config (see Browser Test below) |
-| `circuit_breaker` | object | — | Circuit breaker config (see Circuit Breaker below) |
-| `mcp_servers` | array of MCPServer | — | MCP servers available to tasks |
-| `mcp_approve_all` | boolean | — | Auto-approve all MCP tool calls |
-| `mcp_server_approval_timeout` | number | — | Timeout (seconds) for MCP approval prompts |
+| `review_heuristics` | object | — | Auto-routing rules (see Review Heuristics below). Use to automatically assign `panel` review for security-sensitive paths or agents. |
+| `detect_drift` | boolean | — | Enable drift detection on streaming adapters. Set `true` for long-running (>1h) tasks on streaming adapters to catch scope creep early. |
+| `on_exhausted` | `dlq` \| `skip` \| `stop` | — | Action when max_retries exhausted. Use `dlq` for critical tasks in unattended overnight runs so failures are tracked. |
+| `escalate_to` | string | — | Agent for DLQ escalation (e.g. `architect`). Pair with `on_exhausted: dlq`. |
+| `inject_lessons` | boolean | — | Auto-inject relevant lessons from LESSONS-LEARNED.md into prompts. **Always set `true`.** |
+| `track_discovered_issues` | boolean | — | Enable discovered issues tracking in prompts. **Always set `true`.** |
+| `avoid_weak_agents` | boolean | — | Skip assigning agents to tasks matching their weak areas. **Always set `true`.** |
+| `max_swarm_concurrency` | integer (1–50) | `8` | Max parallel tasks in swarm mode. Only relevant when `concurrency: auto`. |
+| `built_in_gates` | object | — | Built-in gate configuration (see Built-in Gates below). Enable `secret_scan: true` for any task writing auth/config/env files; `dependency_audit: true` when the run adds new packages. |
+| `browser_test` | object | — | Default browser test gate config (see Browser Test below). Set when the goal involves UI changes. |
+| `circuit_breaker` | object | — | Circuit breaker config (see Circuit Breaker below). Set for long multi-agent runs to prevent cascading failures. |
 
 ### Built-in Gates
 
@@ -161,6 +151,13 @@ Enables continuous re-execution triggered by file changes, cron, or git push.
 | `cron` | `schedule` (5-field cron) | Re-run on cron schedule |
 | `git-push` | `branch` | Re-run when new commits are pushed |
 
+### Content Research Rule
+
+When writing task `prompt` fields that involve creating content about real-world people, places, organizations, or topics — **include an explicit instruction in the prompt** telling the agent to search the internet first using any available web search or fetch tools (e.g. `fetch_webpage`, web search MCP). Agents must never fabricate bios, descriptions, histories, statistics, or any factual claims. If web search is unavailable, the prompt should instruct the agent to use placeholder text clearly marked as `[NEEDS RESEARCH]` rather than inventing content.
+
+Example prompt suffix to include when content research is needed:
+> "Before writing any content about [topic], search the internet for accurate information. Do not make up facts, descriptions, or biographical details. Use verified sources only."
+
 ### Task Fields
 
 | Field | Type | Required | Default | Description |
@@ -170,21 +167,19 @@ Enables continuous re-execution triggered by file changes, cron, or git push.
 | `agent` | string | no | `developer` | Agent role hint (see Agent Roster below) |
 | `description` | string | no | same as `id` | Short human label shown in progress output |
 | `depends_on` | list of ids | no | `[]` | Task ids that must finish before this one starts |
-| `files` | list of globs | no | `[]` | File scope the agent is allowed to modify |
+| `files` | list of paths | no | `[]` | File scope the agent is allowed to modify. Must be plain file paths or directory paths. **Glob patterns (`*`, `?`, `**`) are not allowed** — use a plain directory path (e.g., `components/`) to cover a whole directory. |
 | `timeout` | duration | no | `30m` | Max wall time (`<number><s\|m\|h>`, e.g. `10m`, `1h`) |
-| `max_retries` | integer | no | from `defaults` or `1` | Max retry attempts for this task |
-| `model` | string | no | — | AI model override for this task |
-| `adapter` | string | no | — | Per-task adapter override |
-| `gates` | list of strings | no | — | Per-task gate commands run after adapter success |
+| `max_retries` | integer | no | from `defaults` or `1` | Max retry attempts for this task. Override to `3` for high-risk tasks (DB migrations, security changes) or `0` for tasks that must not auto-retry. |
+| `gates` | list of strings | no | — | Per-task gate commands when this task needs specific validation beyond global `gates` (e.g. a task-specific test suite or a schema diff check). |
 | `review` | `auto` \| `fast` \| `panel` \| `none` | no | from `defaults` | Review level for this task |
-| `detect_drift` | boolean | no | — | Enable drift detection (streaming adapters only) |
-| `persistent` | boolean | no | — | Enable persistent agent identity across convoy runs |
-| `steps` | list of TaskStep | no | — | Multi-step sub-prompts (see Steps below) |
-| `hooks` | list of Hook | no | — | Per-task lifecycle hooks |
-| `outputs` | list of TaskOutput | no | — | Named artifacts this task produces |
-| `inputs` | list of TaskInput | no | — | Named artifacts this task consumes from upstream tasks |
-| `browser_test` | object | no | — | Per-task browser test config (same schema as defaults) |
-| `built_in_gates` | object | no | — | Per-task built-in gates override |
+| `detect_drift` | boolean | no | — | Enable drift detection (streaming adapters only). Set `true` for long (>1h) streaming-adapter tasks to catch scope creep. |
+| `persistent` | boolean | no | — | Enable persistent agent identity across convoy runs. Set `true` for research, exploration, or multi-session implementation tasks where the agent's accumulated discoveries and decisions should be available in future convoy runs targeting the same workstream. Omit (defaults to `false`) for short, self-contained tasks. |
+| `steps` | list of TaskStep | no | — | Multi-step sub-prompts. Use when a task has distinct sequential phases that need intermediate gates (e.g. step 1: generate migration, gate: dry-run; step 2: apply migration). |
+| `hooks` | list of Hook | no | — | Per-task lifecycle hooks. Uncommon at task level; prefer top-level `hooks` for post-convoy actions. |
+| `outputs` | list of TaskOutput | no | — | Named artifacts this task produces (used with `inputs` for explicit artifact passing between tasks). |
+| `inputs` | list of TaskInput | no | — | Named artifacts this task consumes from upstream tasks. |
+| `browser_test` | object | no | — | Per-task browser test config. Set when only this task's output requires visual/a11y validation. |
+| `built_in_gates` | object | no | — | Per-task built-in gates override. Use to enable `secret_scan: true` for specific tasks writing credentials or keys. |
 
 ### Task Steps
 
@@ -218,18 +213,6 @@ Tasks can produce named artifacts and consume artifacts from upstream tasks.
 | `name` | string | **yes** | Artifact name from the source task |
 | `as` | string | no | Rename the artifact in the consuming task |
 
-### MCP Server Config
-
-| Field | Type | Required | Description |
-|-------|------|----------|-------------|
-| `name` | string | **yes** | Server identifier |
-| `type` | string | **yes** | Server type (e.g. `stdio`, `http`) |
-| `local` | boolean | no | Whether the server runs locally |
-| `command` | string | no | Command to start the server |
-| `args` | list of strings | no | Arguments for the command |
-| `url` | string | no | URL for HTTP-based servers |
-| `config` | object | no | Additional server configuration |
-
 ### Agent Roster
 
 Available values for the `agent` field:
@@ -263,9 +246,16 @@ For each workstream, break it down into the smallest meaningful unit of work tha
 
 1. **Single responsibility** — each task does exactly one thing.
 2. **Self-contained prompt** — the `prompt` field must contain everything the agent needs: objective, file paths, constraints, acceptance criteria. The agent has no other context.
-3. **Explicit file scopes** — list every directory or file the task may touch in `files`. This prevents conflicts between parallel tasks.
-4. **Appropriate agent** — pick the agent whose speciality matches the task (e.g., `testing-expert` for tests, `database-engineer` for migrations).
-5. **Realistic timeouts** — default 30 m is fine for most tasks; use `1h` for large refactors or test suites; use `10m` for small docs or config changes.
+3. **Explicit file scopes** — list every directory or file the task may touch in `files`. Use plain paths only: exact file paths (e.g., `app/page.tsx`) or directory paths with a trailing slash (e.g., `app/about/`). **Glob patterns (`*`, `?`, `**`) are not allowed** — the engine rejects them.
+
+4. **No partition conflicts** — two tasks may not share a `files` entry if they run in parallel (same phase). Resolve conflicts by either:
+   - **Specificity**: replace a broad directory path with the specific files each task actually creates (e.g., instead of both tasks claiming `components/`, one gets `components/Hero.tsx` and the other gets `components/ProjectCard.tsx`)
+   - **Sequencing**: add a `depends_on` edge from the later task to the earlier one, so they run in different phases
+
+   > **Common mistake:** multiple tasks all depending on a single `setup` task will run in parallel and conflict if they share a directory like `components/`, `app/globals.css`, or `app/layout.tsx`. Always use specific file paths or sequence conflicting tasks.
+
+5. **Appropriate agent** — pick the agent whose speciality matches the task (e.g., `testing-expert` for tests, `database-engineer` for migrations).
+6. **Realistic timeouts** — default 30 m is fine for most tasks; use `1h` for large refactors or test suites; use `10m` for small docs or config changes.
 
 ### 3. Define the Dependency Graph (DAG)
 
@@ -287,12 +277,20 @@ For each workstream, break it down into the smallest meaningful unit of work tha
 - `on_failure` — use `continue` (default) when tasks are independent so one failure doesn't waste the whole run. Use `stop` when every subsequent task depends on success.
 - `adapter` — **omit this field** to let the CLI auto-detect the first available adapter. Only set explicitly if the user requests a specific adapter.
 - `branch` — derive from the goal, e.g., `feat/auth-refactor`. Use a descriptive branch name.
-- `defaults` — set sensible defaults for timeout, max_retries, and review. Enable `inject_lessons: true` for self-improving runs, `track_discovered_issues: true` for issue discovery, and `avoid_weak_agents: true` to route around known weaknesses. Model can be left unset for auto-detection.
+- `defaults` — always include `inject_lessons: true`, `track_discovered_issues: true`, and `avoid_weak_agents: true`. Omit `model` and `adapter` to allow auto-detection.
 - `gates` — include standard validation gates (lint, type-check, test) unless the user specifies otherwise.
 - `gate_retries` — set to 1–2 if you want the engine to auto-fix gate failures by spawning a fix-up task.
 - `guard` — enable for post-convoy compliance checks (observability, cleanup, cost reporting).
-- For security-sensitive or database migration tasks, use `review: panel` or set `review_heuristics.panel_paths` to target critical paths.
-- For long-running or unreliable tasks, configure `circuit_breaker` with a `fallback_agent`.
+- `review` / `review_heuristics` — use `review: fast` as the default. Upgrade to `panel` for security, auth, and database migration tasks. Use `review_heuristics.panel_paths` to auto-escalate specific file patterns (e.g. `db/migrations/`, `libs/auth/`) without setting per-task overrides.
+- `built_in_gates` — set `secret_scan: true` in `defaults.built_in_gates` whenever the run touches auth, config, or env files. Set `dependency_audit: true` when adding new packages.
+- `on_exhausted` + `escalate_to` — set `on_exhausted: dlq` and `escalate_to: architect` in `defaults` for unattended overnight runs so exhausted tasks are queued for human review rather than silently skipped.
+- `detect_drift` — set `detect_drift: true` in `defaults` for runs with tasks longer than 1h on streaming adapters.
+- `circuit_breaker` — configure with a `fallback_agent` for long multi-agent runs to prevent one flaky agent from stalling the whole convoy.
+- `persistent` — set `persistent: true` on individual tasks that do research, codebase exploration, or long implementation work where the agent's accumulated discoveries should persist across future convoy runs (e.g. a Researcher task mapping the auth system, or a Database Engineer task discovering schema quirks). Omit for short, self-contained tasks.
+- `steps` — use on a task when it has distinct sequential phases that need intermediate validation gates between them (e.g. generate migration → dry-run gate → apply migration). Do not use `steps` just to split a large prompt; use separate tasks instead.
+- Per-task `gates` — add to a task only when that specific task needs validation gates beyond the global `gates` (e.g. a dedicated test suite for a specific module, a schema diff command).
+- Per-task `max_retries` — override to `3` for high-risk tasks (DB migrations, security changes) or `0` when a task must not auto-retry (e.g. payment processing changes).
+- `hooks` — use top-level `post_convoy` hooks for notifications, changelog generation, or cleanup scripts that should run once after all tasks complete.
 
 ### 5. Write the Prompts
 
@@ -317,7 +315,8 @@ Before presenting the YAML, mentally verify:
 - [ ] Every task has a unique `id`
 - [ ] Every `depends_on` reference points to a valid `id` defined earlier in the list
 - [ ] No dependency cycles exist
-- [ ] No two parallel tasks share the same `files` entries (partition check)
+- [ ] No two parallel tasks share the same `files` entries — group tasks by phase and check each phase for overlaps; resolve with specific file paths or `depends_on` (see Step 2, rule 4)
+- [ ] No `files` entry contains `*`, `?`, or `**` — use plain file paths or directory paths (trailing `/`) only
 - [ ] Prompts are self-contained — an agent with zero context can execute them
 - [ ] Timeouts are reasonable for the scope of each task
 - [ ] `outputs`/`inputs` references are consistent (consuming task depends on producing task)
@@ -347,7 +346,9 @@ tasks:
     description: <short label>
     timeout: <duration>
     files:
-      - <glob>
+      - app/some-file.tsx
+      - components/Hero.tsx
+      - components/Button.tsx
     prompt: |
       <full self-contained instruction>
 
@@ -356,7 +357,8 @@ tasks:
       - <task-id>
     agent: <agent>
     files:
-      - <glob>
+      - app/other-file.tsx
+      - components/OtherComponent.tsx
     prompt: |
       <full self-contained instruction>
 

package/src/orchestrator/prompts/generate-prd.prompt.md

@@ -0,0 +1,126 @@
+---
+description: 'Generate a Product Requirements Document from a high-level feature prompt. Output feeds directly into the generate-convoy step.'
+agent: 'Team Lead (OpenCastle)'
+output: prd
+---
+
+<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .opencastle/ directory instead. -->
+
+# Generate PRD
+
+You are the Team Lead. Convert the feature request below into a structured Product Requirements Document (PRD). The PRD will be consumed by the `generate-convoy` step to produce an automated agent task spec, so every section must be **concrete**, **specific**, and **implementation-ready**.
+
+## Feature Request
+
+{{goal}}
+
+## Additional Context
+
+{{context}}
+
+---
+
+## Research Before Writing
+
+If the feature request involves a specific person, place, organization, topic, or any real-world subject you are not confident you have accurate knowledge about — **you MUST search the internet first** using any available web search or fetch tools (e.g. `fetch_webpage`, web search MCP, or similar). Use the search results to gather accurate facts, names, dates, descriptions, and other details.
+
+**Never fabricate or hallucinate content** about real-world subjects. If you cannot verify a claim through web search, state what is unknown rather than inventing plausible-sounding text. This applies to all content: bios, descriptions, histories, statistics, quotes, and any factual claims.
+
+## Required PRD Structure
+
+Produce the PRD in Markdown using **exactly** the sections below. Do not skip or merge sections. Do not wrap the output in a code fence — output raw Markdown starting directly with the `#` heading.
+
+---
+
+# [Feature Name] — PRD
+
+## Overview
+
+2–3 sentences: what this feature does, who benefits, and why it matters now.
+
+## Goals
+
+Numbered list of specific, measurable outcomes this feature must achieve. Each goal should be a single sentence with a clear success condition.
+
+1. …
+2. …
+
+## Non-Goals
+
+Explicit exclusions — what this work does **not** cover. If nothing is excluded, write "None."
+
+## User Stories & Acceptance Criteria
+
+For each primary scenario, write a user story + binary acceptance criteria. Criteria must be testable (pass/fail — no subjective language).
+
+**US-1: [Short title]**
+As a [user type], I want [action] so that [benefit].
+
+Acceptance criteria:
+- [ ] [Specific, testable condition]
+- [ ] [Another condition]
+
+*(Repeat for each user story)*
+
+## Technical Requirements
+
+Specific technical constraints the implementation must respect:
+- Libraries, framework versions to use or avoid
+- API contracts or interfaces that must not break
+- Performance thresholds (e.g., "<200 ms p95 latency")
+- Security requirements
+- Browser/platform compatibility
+
+## Implementation Scope
+
+List **every file and directory** that will be created, modified, or deleted. Use specific paths — not broad paths like `src/`. Group by concern.
+
+| Concern | Files / Directories |
+|---------|---------------------|
+| [Frontend components] | `components/feature/`, `app/feature/page.tsx` |
+| [API routes] | `app/api/feature/route.ts` |
+| [Database] | `db/migrations/add_feature.sql`, `db/schema.ts` |
+| [Shared types] | `types/feature.ts` |
+| [Tests] | `__tests__/feature.test.ts`, `e2e/feature.spec.ts` |
+| [Config / env] | `.env.example` |
+
+**File partition rules (important for parallel execution):**
+- No two concurrent workstreams may modify the same file
+- If two workstreams need the same file, they must be sequenced (Phase N+1 after Phase N)
+
+## Task Breakdown
+
+Decompose into the minimum number of phases. Tasks in the same phase run in parallel and **must not share any files**.
+
+```
+Phase 1 — Foundation (parallel, no dependencies):
+  - [Workstream A title]: [2-sentence description]
+    Files: [list exact files]
+  - [Workstream B title]: [2-sentence description]
+    Files: [list exact files]
+
+Phase 2 — Integration (depends on Phase 1):
+  - [Workstream C title]: [2-sentence description]
+    Files: [list exact files]
+    Depends on: Phase 1
+
+Phase 3 — Verification (depends on Phase 2):
+  - [Tests]: Run full test suite, achieve ≥ 95% coverage on new files
+  - [Documentation]: Update READMEs and changelogs
+```
+
+## Success Criteria
+
+Measurable, binary checks that confirm the feature is shippable:
+- [ ] All acceptance criteria in User Stories & Acceptance Criteria pass
+- [ ] TypeScript compiles with zero errors
+- [ ] Lint passes with zero warnings
+- [ ] Unit test coverage ≥ 95% on all new/changed files
+- [ ] [Feature-specific checks]
+
+## Risks & Open Questions
+
+- **[Risk title]**: [Description of the risk] — *Mitigation: [How to handle it]*
+- **[Open question]**: [What needs to be decided before implementation can start]
+
+If there are no risks or open questions, write "None identified."

package/src/orchestrator/prompts/validate-convoy.prompt.md

@@ -0,0 +1,89 @@
+---
+description: 'Validate a convoy YAML spec for schema correctness and logical soundness. Outputs VALID or INVALID with specific errors.'
+agent: 'Reviewer'
+output: validation
+---
+
+<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .opencastle/ directory instead. -->
+
+# Validate Convoy Spec
+
+You are a senior technical reviewer. Validate the convoy spec below against the schema rules and logical constraints. Be strict — a spec that passes this gate will be executed autonomously by AI agents.
+
+## Convoy Spec to Validate
+
+{{goal}}
+
+---
+
+## Validation Rules
+
+Evaluate **every rule** below. If ALL pass, respond `VALID`. If ANY fail, respond `INVALID` with specific, actionable errors.
+
+### Schema Requirements
+
+- [ ] `name` field is present (non-empty string)
+- [ ] `version` field is present (integer: `1` or `2`)
+- [ ] `tasks` list is present and contains at least one task
+- [ ] Every task has a unique `id` (lowercase, kebab-case, no spaces or special chars)
+- [ ] Every task has a non-empty `prompt` field
+- [ ] `on_failure` is `continue` or `stop` (if present; default `stop` is fine if absent)
+- [ ] `concurrency` is a positive integer or the string `"auto"` (if present)
+- [ ] `review` values are one of: `auto`, `fast`, `panel`, `none` (if present on task)
+- [ ] `agent` values are from the approved roster (if present on task):
+  `api-designer`, `architect`, `content-engineer`, `copywriter`, `data-expert`,
+  `database-engineer`, `developer`, `devops-expert`, `documentation-writer`,
+  `performance-expert`, `release-manager`, `researcher`, `security-expert`,
+  `seo-specialist`, `team-lead`, `testing-expert`, `ui-ux-expert`
+- [ ] `timeout` values match `<integer><s|m|h>` format (e.g., `30m`, `1h`, `90s`) (if present)
+
+### Files Constraint
+
+- [ ] No `files` entry contains glob patterns (`*`, `?`, `**`)
+- [ ] All `files` entries are plain file paths or directory paths (trailing `/` is allowed for directories)
+- [ ] No `files` entry is an absolute path (all paths must be relative to the repo root)
+
+### Dependency Graph
+
+- [ ] Every `depends_on` id references a real task `id` in the spec
+- [ ] No dependency cycles exist (A → B → A is a cycle; A → B → C → A is also a cycle)
+
+### Partition Conflicts
+
+Two tasks that can run in parallel (no `depends_on` edge between them) must not share any `files` entry.
+
+- [ ] Check every pair of tasks that lack a `depends_on` relationship — they must not share any file or directory path in their `files` lists
+
+### Prompt Quality
+
+- [ ] Each task `prompt` is self-contained: an agent with no surrounding context must be able to execute it
+- [ ] Each task `prompt` names the specific files to act on (not vague phrases like "the frontend" or "the codebase")
+- [ ] No task `prompt` is shorter than 2 sentences (one-liners are usually too vague)
+
+### Inputs / Outputs Consistency (if used)
+
+- [ ] Every `inputs[].from` references an existing task `id`
+- [ ] Every task referenced in an `inputs[].from` declares a matching `outputs[].name`
+- [ ] No consuming task runs before its producing task (must have `depends_on` edge or be in a later phase)
+
+---
+
+## Output Format
+
+If all checks pass:
+
+```
+VALID
+```
+
+If any check fails:
+
+```
+INVALID
+
+Errors:
+- [Rule category] / [task id if applicable]: [Specific problem] — Fix: [How to correct it]
+- [Rule category] / [task id if applicable]: [Another problem] — Fix: [How to correct it]
+```
+
+List only real failures. Do not list passing checks. Be specific — name the task id, the field, and the exact value that violates the rule.

package/src/orchestrator/prompts/validate-prd.prompt.md

@@ -0,0 +1,83 @@
+---
+description: 'Validate a PRD for completeness, clarity, and implementability before generating a convoy spec. Outputs VALID or INVALID with specific issues.'
+agent: 'Reviewer'
+output: validation
+---
+
+<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .opencastle/ directory instead. -->
+
+# Validate PRD
+
+You are a senior technical reviewer. Your job is to validate the PRD below against strict quality criteria before it is used to generate an automated convoy spec. A PRD that passes this gate will produce a clean, executable convoy spec. A PRD that fails will produce bad tasks.
+
+Be strict. Do not pass a PRD with vague language or missing sections just because it "looks mostly right."
+
+## PRD to Validate
+
+{{goal}}
+
+---
+
+## Validation Checklist
+
+Evaluate **every item** below. If ALL items pass, respond `VALID`. If ANY item fails, respond `INVALID` with a specific, actionable issue list.
+
+### Required Sections
+
+- [ ] `Overview` section is present and non-empty (at least 2 sentences)
+- [ ] `Goals` section is present with at least one numbered, specific goal
+- [ ] `Non-Goals` section is present (may say "None" but must not be missing)
+- [ ] `User Stories & Acceptance Criteria` section is present with at least one user story
+- [ ] Each user story has associated acceptance criteria (not just the story itself)
+- [ ] `Technical Requirements` section is present and non-empty
+- [ ] `Implementation Scope` section is present with a table or list of specific files/directories
+- [ ] `Task Breakdown` section is present with at least one phase and workstream
+- [ ] `Success Criteria` section is present with at least 3 measurable checks
+- [ ] `Risks & Open Questions` section is present (may say "None identified")
+
+### Acceptance Criteria Quality
+
+- [ ] All acceptance criteria can be evaluated as pass/fail (no subjective language like "looks good", "feels responsive", "is clean")
+- [ ] No criterion uses modal verbs that imply optionality ("should", "might", "could", "may")
+- [ ] No criterion references undefined external systems without explaining what they are
+
+### Implementation Scope Quality
+
+- [ ] Scope lists **specific** file names or subdirectory names — not broad paths like `src/` or `the frontend`
+- [ ] Scope table does not use glob patterns (`*`, `**`)
+- [ ] Every concern area has at least one specific file or directory
+
+### Task Breakdown Quality
+
+- [ ] Each workstream lists the exact files it will modify
+- [ ] No two parallel workstreams (same phase) claim the same file
+- [ ] Phases have explicit dependency declarations (`depends on: Phase N`)
+- [ ] No circular dependencies
+
+### Language Quality
+
+- [ ] No undefined acronyms or jargon used without explanation
+- [ ] No conflicting requirements (e.g., "must be fast AND run full suite on every change")
+- [ ] Section content is not placeholder/template text (e.g., "2–3 sentences about…", "Description here")
+
+---
+
+## Output Format
+
+If the PRD passes every check above, respond with **exactly**:
+
+```
+VALID
+```
+
+If the PRD fails one or more checks, respond with:
+
+```
+INVALID
+
+Issues:
+- [Section name]: [Specific problem] — Fix: [What the author must change]
+- [Section name]: [Another problem] — Fix: [What the author must change]
+```
+
+List only real failures. Do not list items that passed.

package/dist/cli/convoy/log-merge.test.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=log-merge.test.d.ts.map

package/dist/cli/convoy/log-merge.test.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"log-merge.test.d.ts","sourceRoot":"","sources":["../../../src/cli/convoy/log-merge.test.ts"],"names":[],"mappings":""}