Guide
Build a Custom
Ralph Wiggum Loop
Use Margarita orchestration file to build a custom Ralph Wiggum loop tailored to your own specific workflow.
Margarita
Guide
Use Margarita orchestration file to build a custom Ralph Wiggum loop tailored to your own specific workflow.
Maybe you want it to post to JIRA after tasking out the implementation plan. Maybe you want to run a code quality analysis after each implementation step. With a single monolithic prompt, you have no way to inject custom logic or effects at specific points in the workflow.
custom-ralph.mgx file orchestrates the entire workflow. It prompts the
user for input, delegates task breakdown to a specialist template, then loops over each
task — injecting domain guidance and checking acceptance criteria on every iteration.
@state maxIterations = 5
@state tasks = []
// ── Phase 1: Get user input ───────────────────────────────
@effect input "What do you want to build?:" => userInput
// ── Phase 2: Break it into tasks ─────────────────────────
[[ use-case-task-breakdown.mg input=userInput ]]
@effect run
// ── Phase 3: Implement each task ─────────────────────────
for task in tasks:
@effect context clear
@state isDone = false
<<
Check the current state of the project and attempt to implement:
${task}
>>
// Add domain rules that help the loop run better.
[[ additional_guidance.mg ]]
<<
Mandatory last step: Once you're done check the acceptance criteria ${task.acceptanceCriteria}.
Set variable `isDone` = true ONLY if ALL criteria are met.
Set variable `isDone` = false if any criteria are not met.
>>
// Run the agent 5 times and try to complete the task.
for i in range(5):
@effect run
// If the agent says the task is done break and move onto the next task.
if isDone:
break.mg template is a focused prompt with a single job.
use-case-task-breakdown.mg decomposes the user's idea into an ordered
implementation plan with acceptance criteria. additional_guidance.mg injects
domain-specific rules into every iteration of the loop — no parameters needed.
Decomposes the user's idea into an ordered implementation plan. Included via
[[ use-case-task-breakdown.mg input=userInput ]]. Stores results in the
tasks state variable.
<<
Your task is to expand the following ask into a more detailed set of
requirements / task breakdown.
- The output should be a more detailed description of the task,
without implementation details.
- Consult AGENTS.md for code standards and best practices for
writing clear, actionable tasks.
- Ask any follow up questions to reduce ambiguity and ensure the
task is well defined.
- Keep the number of tasks to a small amount ideally 1-3.
- We should follow Red, Green, Refactor where possible.
Create a list to store the task breakdown. Each task should have
the following structure:
{
"task": "The refined feature description",
"acceptanceCriteria": [
"A specific, measurable outcome that indicates the task
is successfully implemented.",
"Another specific, measurable outcome..."
]
}
Store the list of tasks in the `tasks` state variable.
## This is the use case that should be broken down:
${input}
>>Domain-specific rules injected into every iteration of the implementation loop.
Included via [[ additional_guidance.mg ]] — no parameters needed.
<<
Here are some things to keep in mind:
- There is no SQL involved in the task list, so don't do any SQL
queries or database interactions.
- We should not commit to git or do any version control operations
as part of the task list.
- Don't add any temp files to docs. If you absolutely need to
create a temp file do it in the ./temp directory.
- If you get into a scenario where a criterion is not met but the
guidance forbids it, just set the task to done, but make a note
to the user.
- Use `make test` to run tests.
>>additional_guidance.mg, runs the agent, and breaks when
isDone is true — capped at five iterations per task.
for task in tasks:
// Fresh context for every task
@effect context clear
@state isDone = false
<< Check the current state of the project
and attempt to implement: ${task} >>
// Inject domain rules each iteration
[[ additional_guidance.mg ]]
<< Mandatory last step: check ${task.acceptanceCriteria}.
Set `isDone` = true ONLY if ALL criteria are met. >>
// Retry up to 5 times per task
for i in range(5):
@effect run
if isDone:
break
<<
Here are some things to keep in mind:
- No SQL queries or database interactions.
- No git commits or version control operations.
- Temp files go in ./temp, never in docs.
- If guidance prevents meeting a criterion,
mark the task done and note it for the user.
- Use `make test` to run tests.
>>@effect context clear resets accumulated history between phases. Each
specialist prompt sees only what it needs — preventing refinement noise from bleeding into
the implementation loop.
@state variables persist for the lifetime of the .mgx run.
The tasks list is written by the agent in the breakdown phase and read by
the loop in the next — no manual wiring needed.
[[ additional_guidance.mg ]] can be dropped into any iteration of the loop.
Domain constraints — no SQL, no git commits, where to put temp files — are expressed once
and applied consistently, without repeating them in every prompt.
Grab the example files from GitHub and start composing your own specialized prompt templates.