Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
npx skills add https://github.com/ma08/botfiles --skill ralph
Der Befehl bleibt in einer Zeile. Scrollen Sie horizontal, um ihn vor dem Kopieren vollständig zu prüfen.
Sie bevorzugen eine lokale Kopie? Laden Sie die Dateien herunter, die SkillsMP derzeit vorliegen.
Ralph Wiggum methodology for autonomous agentic development. Use when setting up a new Ralph task, preparing specs, or troubleshooting Ralph loops.
source
personal
Ralph Wiggum Methodology
Ralph is a technique for autonomous agentic software development using LLMs in a deterministic loop. Named after the naive character from The Simpsons, Ralph represents giving an AI minimal planning ability and maximum execution autonomy.
Critical: Separation of Concerns
The orchestrator session prepares the loop. The loop agent does the work.
When a plan involves a Ralph loop, do NOT implement the code changes yourself. Your job is to create the Ralph infrastructure files (PROMPT.md, AGENT.md, fix_plan.md, specs/, run-ralph.sh) and hand off to the user to run the loop. The loop agent — spawned fresh each iteration by run-ralph.sh — reads PROMPT.md, picks the next incomplete task from fix_plan.md, implements it, validates, commits, and loops.
Orchestrator creates: Ralph files, specs, fix_plan.md (tasks in TODO)
Orchestrator does NOT: implement code, write tests, mark tasks complete, commit
Loop agent does: implement code, run tests, update fix_plan.md, commit per task
Core Philosophy
Blame Yourself, Not Ralph: If Ralph does something wrong, look at your prompts, specs, and instructions. "Tune Ralph like a guitar."
One Thing Per Loop: Ralph does ONE task per iteration. If things go off the rails, narrow to one item.
Trust Eventual Consistency: Every problem created by AI can be resolved through a different series of prompts.
LLMs Are Mirrors: The quality of Ralph's output reflects the quality of your specs and prompts.
When to Use Ralph
Greenfield projects (new codebases) - expect 90% completion
Well-specified features with clear requirements
GPU/remote machine delegation
Tasks where you can provide working reference code
When NOT to use Ralph:
Complex existing codebases with lots of implicit context
Tasks requiring deep domain knowledge you can't encode in specs
The Stack (4 Essential Files)
Ralph allocates these files as persistent context every loop:
1. PROMPT.md - The Loop Engine
The current task/instruction for Ralph. This is where you "tune Ralph" by adding guidance (signs).
Important: if your loop uses a completion promise string, include that exact string only once in PROMPT.md. Repeating the same promise text in multiple sections can cause false-positive completion detection when a runner echoes the prompt.
2. AGENT.md - The Heart
Instructions on HOW to build, run, and test the project:
Environment setup (conda, venv, PATH)
Build commands
Test commands (specific test files, not whole suite)
Type checking (mypy, pyright)
Key: Ralph updates this file when learning new commands.
3. fix_plan.md - The TODO List
Bullet-point list of items sorted by priority:
- [ ] for pending tasks
- [x] for completed tasks
Notes section for learnings
Ralph keeps this updated. Delete and regenerate when stale.
4. specs/ - Specifications (Immutable Contract)
One file per feature/module. Each spec contains:
Purpose statement
Function signatures with full types
Implementation requirements
Working reference code (critical!)
Expected input/output examples
Key insight: Specs are formed through conversation, not written in isolation.
The Loop
Ralph cycles through three phases (repeat forever):
Phase 1: Generate
Ralph reads PROMPT.md, specs/*, and fix_plan.md
Generates code based on specifications
If generating wrong patterns → update specs
If building wrong thing → specs are incorrect
Phase 2: Backpressure (Validate at Three Tiers)
Tier 1 (Static): Type check, compile, structural grep — EVERY iteration (~5s)
Tier 2 (Smoke): Hit running service with trivial input, verify no crash — EVERY iteration if available (~5s)
Tier 3 (Integration): Real data through the feature — at [MILESTONE] tasks only (30s+)
Critical: Tiers 1+2 must be fast. The wheel must turn fast. Tier 3 is for confidence checkpoints.
If Tier 2 unavailable (service not running): fall back to Tier 1 only. Do NOT start services.
Phase 3: Commit & Loop Back
When tests pass, update fix_plan.md
Git add/commit/push
Loop back to Phase 1
Writing Effective Specs
Specs are the most critical input. Bad specs = bad output.
Process:
Have a conversation with Claude about requirements
Claude asks clarifying questions
Once Claude understands, ask it to write specs
Include working code snippets from tested implementations
Codex echoes the prompt in its output, so the promise string appears twice: once in the echoed prompt text and once in the AI's response. Threshold: PROMISE_THRESHOLD=2.
Claude -p does NOT echo the prompt — only the AI's response is output. The promise string appears once. Threshold: PROMISE_THRESHOLD=1.
The dual-engine template handles this automatically via the PROMISE_THRESHOLD variable set in the engine case block. For single-engine variants, hardcode the appropriate threshold.
For single-engine variants, simplify the template:
