Menu
Shared patterns for modifying an existing Ralph project environment. Load when adding tasks, pivoting project direction, or revising objectives.
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
Deep project initialization using the Architect-Builder pattern. Use for large projects (20+ tasks, multiple domains) where a single task breakdown would be unwieldy or exceed context limits.
Detailed Ralph execution guidance. Load when running the Ralph autonomous loop to get step-by-step implementation protocol.
Creates AGENTS.md, prd.json, and progress.log to initialize the Ralph environment. Use when setting up a new project for autonomous execution.
Add a new task to an existing Ralph project. Use when requirements change during execution.
Deep initialization for large projects using Architect-Builder pattern.
Initialize Ralph environment. Creates AGENTS.md, prd.json, progress.log from a project description.
| name | ralph-project-ops |
| description | Shared patterns for modifying an existing Ralph project environment. Load when adding tasks, pivoting project direction, or revising objectives. |
Load this skill when modifying an existing Ralph environment (add-task, pivot, revise).
Before any modification, read all three files:
prd.json — note highest task ID, status counts (pending/in-progress/complete/cancelled)AGENTS.md — understand current stack, standards, and commandsprogress.log — understand execution history and what has already shippedWhen adding new tasks, continue from the highest existing task ID:
task-007, new tasks are task-008, task-009, ...Valid statuses and their semantics:
| Status | Meaning |
|---|---|
pending | Not started, eligible for Ralph execution |
in-progress | Currently being worked on |
complete | Done, verified, committed |
cancelled | No longer needed — kept for traceability |
Never delete tasks from prd.json. Mark them cancelled instead. Deletion breaks the correlation between progress.log entries and task IDs, and destroys git history traceability.
When objectives change, categorize affected existing tasks:
pending tasks — may be kept, cancelled, or have acceptance criteria revisedin-progress tasks — warn the user before modifying; Ralph may be mid-executioncomplete tasks — if their output is invalidated by the change, create a new corrective task (e.g., "Revise user model per new authentication requirements") rather than un-completing themcancelled tasks — can be re-activated by setting back to pending if relevant againAppend to progress.log for every project-level change:
[YYYY-MM-DD HH:MM:SS] [PROJECT-OP] add-task: Added task-XXX "Title" (priority: high, deps: [task-003])
[YYYY-MM-DD HH:MM:SS] [PROJECT-OP] pivot: Switched from REST to GraphQL — 4 tasks cancelled, 6 tasks added
[YYYY-MM-DD HH:MM:SS] [PROJECT-OP] revise: Updated AGENTS.md security section; revised acceptance criteria for task-005
When modifying AGENTS.md: