القائمة
Use this to update the status of a ralph loop status for any iterative workflow. Controls whether to continue iterating, complete successfully, or escalate when blocked.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use this skill to add comments or notes to an existing task. Comments help track progress, document decisions, or explain issues.
You MUST use this anytime you want to ask the user a question or feel like something is unclear. If you think you want to use the AskUserQuestion tool, first invoke this skill, we may have a different way of asking the user a question.
You MUST use this skill in order to create, update, edit, or build artifacts or files. Artifacts can be of any type but are typically markdown files.
Use this skill to create a new task for tracking work within the current ticket. Tasks help break down work into smaller trackable units.
Use this skill to create a new ticket in the current project. Use this to convert a brainstorm into a formal ticket for tracking development work.
Use this skill to retrieve details of a specific task by its ID. Returns the task's description, status, comments, and other metadata.
| name | potato:update-ralph-loop |
| description | Use this to update the status of a ralph loop status for any iterative workflow. Controls whether to continue iterating, complete successfully, or escalate when blocked. |
When your review is complete, call the ralph_loop_dock immediately. Not after cleanup. Not after one more check. Immediately.
Review done → ralph_loop_dock() → Nothing else
ralph_loop_dock({
approved: boolean, // true = work is good, false = needs revision
feedback?: string // REQUIRED when approved=false
})
Call ralph_loop_dock({ approved: true }) when:
Call ralph_loop_dock({ approved: false, feedback: "..." }) when work needs revision.
Your feedback is injected into the next iteration. The builder will see exactly what you wrote. Be specific. Be actionable.
| Bad Feedback | Good Feedback |
|---|---|
| "Needs work" | "Missing error handling for network timeouts in fetchUser()" |
| "Tests incomplete" | "No tests for edge case: empty input array in processItems()" |
| "Not quite right" | "Button placement violates design spec - should be right-aligned per mockup" |
If you cannot approve AND revision won't help (missing requirements, need user input, fundamental design question), still call:
ralph_loop_dock({
approved: false,
feedback:
"BLOCKED: Cannot proceed without user clarification on auth strategy",
});
The system handles escalation. Your job is to signal.
These thoughts mean you're avoiding the tool:
| Thought | Reality |
|---|---|
| "I'll just note this in the code" | Notes don't signal the orchestrator. Call the tool. |
| "The exit code will handle it" | Exit codes lose your feedback. Call the tool. |
| "I need to do one more thing first" | Review is done when review is done. Call the tool now. |
| "This is obvious, no feedback needed" | If rejected, feedback is required. Always explain why. |
ralph_loop_dock exactly once at the end of your reviewapproved: false, explain what's wrongYour feedback directly shapes the next iteration. Make it count.