Menu
Ralph-Wiggum ticket loop — auto-implement all ready tk tickets with worker + reviewer cycle
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | ralph-wiggum |
| description | Ralph-Wiggum ticket loop — auto-implement all ready tk tickets with worker + reviewer cycle |
The Ralph-Wiggum loop automatically implements tk tickets one by one until all are closed. Each iteration: pick a ready ticket → implement → review → close (or retry with feedback).
Execute these steps in order. If any step fails, stop and report the error.
tk ready
If the output is empty (no tickets): You are done. Do nothing — no file changes means the loop converges and stops.
If tickets are listed: Pick the first one. Extract the ticket ID (e.g., PR-xxxx).
Run tk start <TICKET_ID> to mark it in_progress.
Check how many times this ticket has been reviewed:
tk notes <TICKET_ID>
Count reviews (lines containing "Gate:"). If the ticket has been reviewed 3 or more times, it is stuck — skip it and move to the next ticket:
tk add-note <TICKET_ID> "BLOCKED: Escalated after 3 review cycles. Requires human intervention."
Read the ticket file and any prior notes first:
tk show <TICKET_ID>
tk notes <TICKET_ID>
Then delegate implementation to the worker agent using the subagent tool:
subagent({
agent: "worker",
task: "Implement ticket <TICKET_ID>. Read the ticket at .tickets/<TICKET_ID>.md for full requirements and acceptance criteria.\n\nPRIOR ATTEMPTS — read these notes from previous iterations carefully:\n<tk notes output>\n\nIf this is a retry (notes show prior failures), reflect on what went wrong before coding:\n- What specific issues did the reviewer flag?\n- What approach was tried?\n- What must be done differently this time?\nDo NOT repeat the same failing approach.\n\nAfter implementing:\n1. Run `ty check` to lint — fix any errors\n2. Run `mypy src/` for type checking — fix any errors\n3. Run `pytest tests/ -x -v` to test — fix failures until all tests pass\n4. Re-run linters after any fixes\n\nDo NOT close the ticket. Just implement and verify.",
context: "fresh"
})
Wait for the worker to complete. If the worker fails or crashes, retry once. If it fails again, add a note and move to the next ticket.
Delegate the review to the rw-reviewer agent:
subagent({
agent: "rw-reviewer",
task: "Review the implementation of ticket <TICKET_ID>. The ticket file is at .tickets/<TICKET_ID>.md.\n\nVerify all acceptance criteria are met. Check code quality. Run git diff to see all changes.\n\nOutput your review in this exact format:\n\n## Gate: PASS | NITS | REVISE | ESCALATE\n\n### Findings\n\nFor each finding, use this format:\n- **[CRITICAL|HIGH|MEDIUM|LOW]** Title\n - File: <path>:<line>\n - Evidence: <concrete observation>\n - Remediation: <specific fix>\n\nIf Gate is PASS or NITS, briefly confirm acceptance criteria are met.\nIf Gate is REVISE, list only Critical and High findings.\nIf Gate is ESCALATE, explain why human intervention is needed.",
context: "fresh"
})
Parse the reviewer's output for the Gate line. Record a structured note with iteration context:
If Gate: PASS or NITS:
tk add-note <TICKET_ID> "Review #<N>: Gate: PASS. <brief summary of what was implemented>"
tk close <TICKET_ID>
If Gate: REVISE:
tk add-note <TICKET_ID> "Review #<N>: Gate: REVISE. Issues to fix:\n\n<paste Critical and High findings with file refs and remediation>"
Keep the ticket in_progress. The next loop iteration will pick it up again.
If Gate: ESCALATE:
tk add-note <TICKET_ID> "Review #<N>: Gate: ESCALATE. Reason: <explanation>. Requires human intervention."
Move to the next ticket. Do not retry automatically.
Report what happened this iteration (ticket ID, gate result, key findings). The loop will continue automatically if there are more tickets.
tk ready first — never assume which ticket to work oncontext: "fresh" for both subagents — they start cleantk ready is empty, do nothing — convergence stops the loop| Gate | Meaning | Action |
|---|---|---|
| PASS | All acceptance criteria met, no issues | Close ticket |
| NITS | Acceptance criteria met, minor polish items | Close ticket (nits are optional) |
| REVISE | Critical or High issues found | Feed back to worker, retry |
| ESCALATE | Fundamentally blocked, needs human | Skip ticket, note why |
| Command | Purpose |
|---|---|
tk ready | List tickets with all deps resolved (ready to work on) |
tk start <id> | Set ticket to in_progress |
tk close <id> | Set ticket to closed |
tk show <id> | Display ticket details |
tk notes <id> | Show ticket notes (prior iteration history) |
tk add-note <id> [text] | Append timestamped note |
tk blocked | List tickets with unresolved deps |
tk ls | List all open tickets |
tk dep tree <id> | Show dependency tree |
Create stunning, animation-rich HTML presentations from scratch or by converting PowerPoint files. Use when the user wants to build a presentation, convert a PPT/PPTX to web, or create slides for a talk/pitch. Helps non-designers discover their aesthetic through visual exploration rather than abstract choices.
Hugging Face Hub CLI (`hf`) for downloading, uploading, and managing models, datasets, spaces, buckets, repos, papers, jobs, and more on the Hugging Face Hub. Use when: handling authentication; managing local cache; managing Hugging Face Buckets; running or scheduling jobs on Hugging Face infrastructure; managing Hugging Face repos; discussions and pull requests; browsing models, datasets and spaces; reading, searching, or browsing academic papers; managing collections; querying datasets; configuring spaces; setting up webhooks; or deploying and managing HF Inference Endpoints. Make sure to use this skill whenever the user mentions 'hf', 'huggingface', 'Hugging Face', 'huggingface-cli', or 'hugging face cli', or wants to do anything related to the Hugging Face ecosystem and to AI and ML in general. Also use for cloud storage needs like training checkpoints, data pipelines, or agent traces. Use even if the user doesn't explicitly ask for a CLI command. Replaces the deprecated `huggingface-cli`.
Work inside a running marimo notebook's kernel — execute code, create cells, and build a notebook as an artifact. Use when the user wants to start a marimo notebook or work in an active marimo session.
Use br (beads_rust) as the local issue tracker for AI coding agents. Trigger when the user mentions issues, tickets, backlog, triage, dependencies, blocking, ready work, or any task involving tracking work items in a git repo. Also trigger when the user wants to plan work, pick next tasks, manage a dependency graph of issues, or coordinate across multiple agents. Use this skill for commands like br create, br ready, br close, br dep, br sync, and any br CLI interaction. Even if the user just says "what should I work on next" or "create a ticket for this", use this skill to ensure correct br usage patterns.
Design and implement practical AI agents using a production-oriented framework. Use this skill whenever the user wants to build an AI agent, decide whether a workflow should become an agent, choose between single-agent and multi-agent designs, define tools/instructions/guardrails, add human-in-the-loop controls, or scaffold an agentic workflow for real systems. Trigger for requests about agents, copilots, tool-using assistants, orchestration, handoffs, manager-worker patterns, agent guardrails, or productionizing multi-step LLM workflows even when the user does not explicitly ask for an “agent architecture.”
Generate or discover a CLI + AgentSkill for any REST API. Use when: user says 'create a CLI for X', 'wrap this API', 'search if a CLI exists', 'install an existing CLI', 'make a skill for X', 'publish my CLI', 'publish to npm', 'push to github'. Handles registry search, install, discovery, scaffolding, resource implementation, building, linking, skill generation, npm publishing, and GitHub publishing.