These are production pipeline prompts we use daily with t0ggles Crew. Each example includes the full prompt, recommended agent setup, and scheduling configuration.
All three pipelines work together as a chain: Planning produces a plan file, Development implements it, and Review checks the result. You can use them independently or wire them together with After Pipeline scheduling.
For larger tasks, see the Phased Development section at the bottom - it breaks implementation into numbered phases with a review after each one.
The planning agent researches the codebase and produces a structured implementation plan for a task. It works directly on the main branch since it only creates markdown files.
Start by checking out the main branch (git checkout master or main) and pulling the latest code (git pull).
Take a task assigned to you from To-Do status. If there are no such tasks, exit without making changes. Never take tasks and never look into tasks not assigned to your bot user or in other projects.
Once a task is taken, assign yourself to it and move it to In Progress status.
This work is about planning - research the codebase thoroughly, then write a clear, actionable implementation plan covering: scope, affected files, technical approach, and acceptance criteria. Do NOT use Claude Code's plan mode (EnterPlanMode/ExitPlanMode). Write the plan directly as a markdown file. As this task affects only newly created MD files, work in main branch, and commit exactly to main branch too, no pull requests needed here.
Save the plan to the docs/plans/ folder (create it if needed) as <projectKey>-<taskKey>-<short-description>.md (e.g. T0GGLES-32-add-dark-mode.md), then commit and push.
Add a task comment summarizing what was done and the path to the plan file.
Finally, move the task to In Review and assign it to Claude Reviewer.
If you cannot complete the task, add a comment explaining what went wrong and move the task back to To-Do.
After completing all steps, switch back to the main branch (if it wasn't) (git checkout master or main) so the workspace is ready for the next run.docs/plans/The development agent implements tasks by creating feature branches, writing code, running type checks, and opening pull requests.
Start by checking out the main branch (git checkout master or main) and pulling the latest code (git pull).
Take a task assigned to you from To-Do status. If there are no such tasks, exit without making changes. Never take tasks and never look into tasks not assigned to your bot user or in other projects.
Once a task is taken, assign yourself to it and move it to In Progress status.
Read the task description and all comments carefully - they contain important context, references to plan files, and other relevant notes. If a plan file is referenced, follow it closely.
Create a new branch from main named <projectKey>-<taskKey>-<short-description> (e.g. T0GGLES-32-add-dark-mode) for your work. Implement the changes and run `npm run check-types` to ensure there are no type errors. Fix any issues before proceeding.
Commit your changes, push the branch, and open a Pull Request against master (or main) with a clear description of what was done and why.
Add a task comment summarizing the work done and linking to the PR.
Finally, move the task to In Review and assign it to Claude Reviewer.
If you cannot complete the task, add a comment explaining what went wrong and move the task back to To-Do.
After completing all steps, switch back to the main branch (git checkout master or main) so the workspace is ready for the next run.
npm run check-types to verify no type errorsThe review agent checks both plan files and pull requests. It makes direct fixes when needed rather than just leaving feedback.
Start by checking out the main branch (git checkout master or main) and pulling the latest code (git pull).
Take a task assigned to you from In Review status. If there are no such tasks, exit without making changes. Never take tasks and never look into tasks not assigned to your bot user or in other projects.
Once a task is taken, assign yourself to it and read the task description and all comments carefully - they contain important context about what was done and where to look.
Determine what type of work needs reviewing:
If it's a plan (a single file in docs/plans/): Review the plan for clarity, completeness, correctness, and feasibility. Make any necessary improvements directly in the file. Commit and push your changes.
If it's a Pull Request: Check out the PR branch. Review the code for correctness, code quality, and consistency with the existing codebase. Make any necessary fixes directly and commit them to the same branch. Push your changes.
If the PR has merge conflicts, resolve them before proceeding with the review.
Add a task comment with a review summary covering: what was reviewed, what changes you made (if any), and your overall assessment.
Finally, assign the task to John Doe (john@example.com).
If you cannot complete the task, add a comment explaining what went wrong and move the task back to To-Do.
After completing all steps, switch back to the main branch (git checkout master or main) so the workspace is ready for the next run.
Don't forget to replace John Doe (john@example.com) with the actual name and email of the person you want to assign the task to.
The most powerful setup chains all three pipelines so tasks flow automatically through planning, development, and review.
This gives you human checkpoints at steps 4 and 7 while automating everything in between.
For large, complex tasks, implementing everything in a single pipeline run can be unreliable. The phased development approach breaks implementation into numbered phases, with a review after each one. This keeps diffs small, catches issues early, and lets the agent stay focused on one piece at a time.
This requires two pipelines: a Phased Developer that implements one phase per run, and a Phased Reviewer that reviews each phase and routes the task back for the next one.
Start by checking out the main branch (git checkout master or main) and pulling the latest code (git pull).
Take a task assigned to you from To-Do status. If there are no such tasks, exit without making changes. Never take tasks and never look into tasks not assigned to your bot user or in other projects.
Once a task is taken, assign yourself to it and move it to In Progress status.
Read the task description and all comments carefully. The task description or a referenced plan file should contain numbered implementation phases (Phase 1, Phase 2, etc.).
Check the task comments for any previous "Phase X completed" comments to determine which phase to work on next. If no phase comments exist, start with Phase 1. If all phases are already completed, add a comment noting this and move the task to In Review - do not make any changes.
IMPORTANT: Every single phase must go through the full cycle: To-Do → In Progress → In Review → (back to To-Do for next phase). Never skip the review step. Never implement more than one phase per run.
IMPORTANT: Implement ONLY the next incomplete phase. Do not work on subsequent phases.
Check if a branch named <projectKey>-<taskKey>-<short-description> already exists:
- If it exists, check it out and pull the latest changes (a previous phase was already worked on).
- If it does not exist, create it from main.
Implement the changes for the current phase only. Run `npm run check-types` to ensure there are no type errors. Fix any issues before proceeding.
Commit your changes and push the branch.
Check if a Pull Request already exists for this branch:
- If yes, add a comment to the PR describing what this phase implemented.
- If no, open a new Pull Request against master (or main) with a clear description.
Add a task comment in this exact format: "Phase X/N completed: <brief summary of what was done in this phase>" where X is the current phase number and N is the total number of phases. Include a link to the PR.
If this is the LAST phase, add an additional note: "All phases completed. Ready for final review."
Move the task to In Review and assign it to Claude Reviewer - do this after EVERY phase, not just the last one. Each phase must be reviewed before the next one begins.
If you cannot complete the phase, add a comment explaining what went wrong and move the task back to To-Do.
After completing all steps, switch back to the main branch (git checkout master or main) so the workspace is ready for the next run.Start by checking out the main branch (git checkout master or main) and pulling the latest code (git pull).
Take a task assigned to you from In Review status. If there are no such tasks, exit without making changes. Never take tasks and never look into tasks not assigned to your bot user or in other projects.
Once a task is taken, assign yourself to it and read the task description and all comments carefully - they contain important context about what was done and where to look.
Check the task comments for "Phase X/N completed" markers to determine if this is a phased task.
--- IF THIS IS A PHASED TASK ---
Check out the PR branch and pull the latest changes. Review ONLY the work done in the current phase (the most recent "Phase X/N completed" comment describes what was implemented). Look at the commits since the previous phase review for the scope of changes.
Review the phase for correctness, code quality, and consistency with the existing codebase and the overall plan. Make any necessary fixes directly and commit them to the same branch. Push your changes.
If the PR has merge conflicts, resolve them before proceeding.
Add a task comment with a review summary covering: what was reviewed in this phase, what changes you made (if any), and your assessment.
Then determine the next action:
- If this is NOT the last phase (X < N): Move the task back to To-Do and reassign it to Claude Phased Developer. Add a note: "Phase X reviewed and approved. Ready for Phase X+1."
- If this IS the last phase (X = N, or "All phases completed" is noted): Do a final review considering the complete implementation across all phases. If everything looks good, assign the task to John Doe (john@example.com).
- If the phase has issues that need rework: Move the task back to To-Do and reassign it to the original developer. Add a clear comment describing what needs to be fixed. Note that Phase X needs rework - do NOT advance to the next phase.
--- IF THIS IS A REGULAR (NON-PHASED) TASK ---
Determine what type of work needs reviewing:
If it's a plan (a single file in docs/plans/): Review the plan for clarity, completeness, correctness, and feasibility. Make any necessary improvements directly in the file. Commit and push your changes.
If it's a Pull Request: Check out the PR branch. Review the code for correctness, code quality, and consistency with the existing codebase. Make any necessary fixes directly and commit them to the same branch. Push your changes.
If the PR has merge conflicts, resolve them before proceeding with the review.
Add a task comment with a review summary covering: what was reviewed, what changes you made (if any), and your overall assessment.
Finally, assign the task to John Doe (john@example.com).
--- END ---
If you cannot complete the task, add a comment explaining what went wrong and move the task back to To-Do.
After completing all steps, switch back to the main branch (git checkout master or main) so the workspace is ready for the next run.
Don't forget to replace John Doe (john@example.com) and Claude Phased Developer with the actual names and emails of your team member and bot user.
For phased tasks:
For regular tasks:
Falls back to standard review behavior - reviews plans or PRs and assigns to a human.
Breaking large tasks into phases and reviewing each one has several advantages:
The task description or plan file should define the phases. For example:
Phase 1: Add database schema and migration
Phase 2: Implement backend API endpoints
Phase 3: Build frontend components
Phase 4: Add tests and documentation
The phased chain runs largely on autopilot - you set it up once and it cycles through all phases with a review between each one. You only step in at the end for a final review and merge.