opencastle 0.27.2 → 0.28.0

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.