Docs / Prompt Templates

Brainstorm

Collaborative brainstorm to explore requirements, approaches, and trade-offs BEFORE committing to a plan. Use when the task has ambiguity, multiple valid approaches, or significant design decisions.

When to use

When a task has ambiguity, multiple valid approaches, or design decisions to make before implementation. Use this before reaching for an implementation prompt.

What it does

Runs a structured brainstorm — clarifies the problem, explores the solution space, generates alternatives, evaluates trade-offs, and defines scope before any code is written. The report it ends with is the input for implement-feature.

Implement Feature

Implement a change in this session — a feature, a roadmap item or a small follow-up — planned to its size, built with tests, verified, reviewed, and delivered as a pull request.

When to use

For any change you want made now. A change in one area the Team Lead makes itself; one across the API, the UI and the data it splits into tasks for the specialist agents, each with the files it may change. Work you want planned into parallel tasks and run unattended is Convoy.

What it does

1. Understands it — the goal and what done means, from your request, a tracker issue it names, the Project Context, lessons, known issues and the code
2. Plans it to its size — does a small change itself; splits a larger one by area and dependency
3. Builds it — with the tests, following the project's conventions and the skill for each domain
4. Verifies it — the project's tests, lint and build; a UI change in a browser; a review by an agent that did not write it, and a panel of three for auth, payments, migrations or deleting data
5. Delivers it — a branch and a pull request, never main, with what changed and how it was checked

Bug Fix

Reproduce a bug, find its root cause, fix it with a regression test, verify it and open a pull request — in this session.

When to use

When something is broken. It reproduces the bug before changing anything, rather than jumping straight to editing code.

What it does

1. Reproduces it — a failing test when it can write one, otherwise the exact steps; a UI bug in a browser. It asks for what is missing rather than fix by guessing
2. Finds the root cause — and names it; hiding the symptom does not count
3. Fixes it — the smallest change, with a regression test that fails without it
4. Verifies and delivers — the project's checks, a review, a pull request; a lesson when the cause will come up again

Resolve PR Comments

Resolve GitHub PR review comments by reading them, grouping by file, and applying fixes systematically.

When to use

When a pull request has review comments that need to be addressed. Reads, groups, and resolves comments systematically rather than ad-hoc. It reads the comments with the gh CLI, so gh must be signed in.

What it does

1. Gather PR comments — reads all review comments from GitHub
2. Group by file — organises comments into file-level batches
3. Classify — marks each as must-fix, should-fix, or discussion
4. Delegate fixes — sends batches to appropriate specialist agents, shared types and utilities first, never two agents on one file
5. Verify and push — a secret scan, lint, tests and build, a check that only the commented files changed, and a mandatory fast review; then it commits and pushes to the same branch. Discussion comments are summarised for you, not fixed

Bootstrap Customizations

Checks what opencastle init read from the code into .opencastle/, and fills in the "Still to describe" list at the end of each file — architecture, access rules, test conventions, environments — by reading the code.

When to use

Once, right after opencastle init, on an existing codebase. Skip it in an empty project: there is nothing to read yet.

What it does

init writes .opencastle/project.instructions.md and stack/*-config.md from the code: the stack with versions, the structure, commands, routes and API endpoints, models and migrations, environment variable names and the test setup. What it cannot read from files, each file lists at its end under Still to describe. This prompt checks what init wrote, then reads the code to answer that list, and says what only a person can fill in.

Create Skill

Scaffold a new team skill with proper frontmatter and structure. Use when adding a new domain skill to the AI configuration.

When to use

When your team has knowledge every assistant should load on demand — a deploy runbook, a review checklist, the rules for one part of your stack.

What it does

Checks the compiled skills and the available integrations for overlap, names the skill, and writes .opencastle/skills/<name>/SKILL.md. The next npx opencastle sync compiles it for every assistant in the project. A team skill with the same name as one of OpenCastle's replaces it.

Convoy

Plan work as tasks that agents run in parallel, each in its own git worktree, for the experimental convoy engine. Your assistant runs the planner and shows you the plan; you start the run.

When to use

For work that splits into several tasks with separate files: a feature across the API, the UI and the tests, or one change repeated across modules. A change in a few files is faster with Implement Feature, and the prompt says so.

What it does

1. Checks it fits — that the work splits into tasks, and is committed: every task starts from the last commit
2. Runs the planner — npx opencastle convoy "<task>" --dry-run, which reads the repository, changes nothing, and writes the spec to .opencastle/convoys/
3. Shows you the plan — each task, its agent, what it waits for and its files, and anything that looks wrong
4. Hands it over — you run npx opencastle convoy run <spec>; the work lands on a branch of its own

1. Size the work

Sizes the work, first on your request, while the plan from the request and the PRD are written at the same time. A change sized low, and not split into groups, keeps the plan from the request, and the PRD is stopped. Larger work keeps the PRD and this sizing, unless it splits the work into groups: then the PRD is sized again beside its review, so each group can name its phases.

2. Write the PRD

Turns a request that is not small into a product requirements document, written to .opencastle/prds/<name>.prd.md and named after its title.

3. Review the PRD

Checks that the PRD has every required section and is consistent enough to plan from. Runs beside the plan from the PRD, or beside a second sizing when the work is split into groups; a PRD that fails is fixed and planned again. Answers with a JSON verdict: valid, or the issues to fix.

4. Fix the PRD

Rewrites the PRD to fix what its review found. Runs only when the review fails, up to two rounds.

5. Plan the tasks

Turns the request, or the PRD, into a JSON task plan. The CLI folds a task that only writes tests into the task it tests, checks the plan in code — ids, dependencies, cycles, file paths, and tasks that could run at once on the same files — and writes .opencastle/convoys/<name>.convoy.yml.

6. Review the plan

Reviews a plan that will run without a person reading it first (--yes): tasks that run in parallel on the same files, missing dependencies, and missing or redundant tasks. Answers with a JSON verdict: valid, or the issues to fix.

7. Fix the plan

Returns JSON patches for the problems the code checks or the review found; the CLI applies them. Up to two rounds after the checks, one after a review.