smart-ralph
This skill should be used when the user asks about "ralph arguments", "quick mode", "commit spec", "max iterations", "ralph state file", "prototype overlay", "execution modes", "ralph loop", "coordinator behavior", "delegate to subagent", or needs guidance on Ralph plugin argumen
Install
npx skills add https://github.com/tzachbon/smart-ralph/tree/main/plugins/ralph-specum/skills/smart-ralph
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install tzachbon-smart-ralph@llmmart
git clone https://github.com/tzachbon/smart-ralph.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole tzachbon/smart-ralph collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Smart Ralph
Core skill for all Ralph plugins. Defines common arguments, execution modes, shared behaviors, and coordinator delegation rules.
Common Arguments
All Ralph commands support these standard arguments:
| Argument | Short | Description | Default |
|---|---|---|---|
--quick |
Exact token that enables persistent non-interactive generation | false | |
--interactive |
Exact token that clears persistent quick mode | - | |
--commit |
-c |
Commit spec/feature files locally after generation | true (normal), false (quick) |
--no-commit |
Explicitly disable committing files | - | |
--max-task-iterations |
-m |
Max retries per failed task before stopping | 5 |
--fresh |
-f |
Force new spec/feature, overwrite if exists | false |
Argument precedence: --no-commit > --commit > mode default.
Execution Modes
Normal Mode (Interactive)
- Exact
--interactiveclears a prior authorized quick mode - No mode flag resets legacy quick state that lacks exact
--quickauthorization - User reviews artifacts between phases
- Phase transitions require explicit commands
- Each phase sets
awaitingApproval: true - Commits spec files by default
- Research and requirements may offer the optional prototype overlay
- The user owns prototype capture, verdict, handoff, and deletion decisions
Quick Mode (--quick)
- Only an exact
--quickargument token enables this mode -q, settings defaults, substrings, and natural-language requests do not enable it--quickwith--interactiveis an error- Skip all interactive prompts, interviews, and approval pauses
- Run the same phase agents (research, requirements, design, tasks) sequentially
- Agents receive a "be more opinionated" directive since there is no user feedback
- spec-reviewer validates each artifact (max 3 iterations)
- Run at most one agent-owned prototype request after requirements and before design
- Take over the oldest design-blocking prototype when one exists; otherwise choose the highest-risk grounded question
- Ask no prototype question or decision and continue to design after every outcome
- Immediately start execution after all phases complete
- Do NOT commit by default (use
--committo override) - Still delegate to subagents (delegation is mandatory)
State File
All Ralph plugins use .ralph-state.json for execution state. See references/state-file-schema.md for full schema.
Key fields: phase, taskIndex, totalTasks, taskIteration, maxTaskIterations, awaitingApproval, quickMode, quickAuthorization, phaseSkillLoad, phaseInterview, and optional activePrototypes.
Prototype is an overlay. phase remains one of the five main workflow phases and is never prototype. Resolve basePath before access, treat a missing activePrototypes map as empty, and route every mutation or deletion through hooks/scripts/locked-state.py. Read references/state-file-schema.md before changing state, resuming an overlay, or deciding whether execution state may be deleted.
Commit Behavior
When commitSpec is true:
- Stage spec/feature files after generation
- Commit with message:
chore(<plugin>): commit spec files before implementation - Keep the commit local unless a separate command and explicit authority permit a remote action
When commitSpec is false:
- Files remain uncommitted
- User can manually commit later
Prototype terminal records are spec artifacts, so commitSpec controls their local commit. Retained prototype source always receives a local commit on its isolated branch, independent of commitSpec. Neither path authorizes a push, remote branch, PR inclusion, issue mutation, or ticket comment.
Prototype Overlay
The coordinator follows this sequence:
- Resolve
basePath, reconcile candidates and finals, and reserve or resumeactivePrototypes.<id>under the state lock. Completion criterion: the main phase and unrelated fields are unchanged. - Keep source in an isolated sibling worktree or eligible scratch path. Completion criterion: the current checkout remains on its original branch and prototype files exist only in the recorded isolation path.
- Build and review one falsifiable question. Completion criterion: the reviewer passes the exact candidate bytes, source/run evidence, isolation, blocker, handoff, and
sourceDisposition. - Publish one immutable terminal record without overwrite, apply gate selection, restore the recorded return phase/task, then remove the active entry under lock. Completion criterion: downstream work sees only valid, non-superseded, gate-approved evidence.
Normal mode waits without a verdict or handoff timeout and keeps decisions with the user. Quick mode owns the one post-requirements request, can take over the oldest design blocker, uses reviewed receipts for eligible ephemeral cleanup, and always continues to design. Cancellation and interruption preserve source and publish reviewed terminal evidence before active-state removal.
Prototype source, records, cleanup receipts, and quarantines are local evidence. A remote push, branch publication, PR inclusion, issue write, or deletion outside the single quick ephemeral cleanup path requires separate explicit authority.
Task Execution Loop
Ralph Specum v3.0.0+ has a self-contained execution loop via the stop-hook. No external dependencies required.
Key signals:
TASK_COMPLETE- executor finished taskALL_TASKS_COMPLETE- coordinator ends loop
Error Handling
When taskIteration > maxTaskIterations: block task, suggest manual intervention.
If state file missing/invalid: output error, suggest re-running implement command.
Branch Management
All Ralph plugins follow consistent branch strategy:
- Check current branch before starting
- If on default branch (main/master): prompt for branch strategy
- If on feature branch: offer to continue or create new
- Exact
--quick: create a feature branch without prompting only when currently on the default branch; otherwise keep the current non-default branch. LegacyquickMode: truedoes not select this path.
Prototype isolation is separate from this feature-branch choice. Create or reuse a sibling worktree or eligible scratch path without checking out its branch in the current checkout. Retained and interrupted source remains available for recovery.
Coordinator Behavior
The main agent is a coordinator, not an implementer. Delegate all work to subagents.
Coordinator Responsibilities
- Parse user input and determine intent
- Read state files for context
- Delegate work to subagents via Task tool
- Report results to user
Do Not
- Write code, create files, or modify source directly
- Run implementation commands (npm, git commit, file edits)
- Perform research, analysis, or design directly
- Execute task steps from tasks.md
Delegation Mapping
| Work Type | Delegate To |
|---|---|
| Research | Research Team (parallel teammates) |
| Requirements | product-manager subagent |
| Design | architect-reviewer subagent |
| Task planning | task-planner subagent |
| Task execution | spec-executor subagent |
| Prototype building | prototype-builder background subagent |
Quick mode still requires delegation.
Files (smart-ralph)
-
references
-
state-file-schema.md 5.3 KB
# State File Schema Ralph plugins use `.ralph-state.json` to track execution state. ## Location ``` <resolved-basePath>/.ralph-state.json ``` Resolve `specRoot` and `basePath` before reading or writing state. Use `.claude/ralph-specum.local.md` `specs_dirs` when configured; use `./specs` only as the resolver fallback. Derive the state, lock, candidate, terminal record, context, and index paths from the resolved `basePath`. ## Schema ```json { "phase": "research|requirements|design|tasks|execution", "taskIndex": 0, "totalTasks": 0, "taskIteration": 1, "maxTaskIterations": 5, "awaitingApproval": false, "activePrototypes": { "risk-check": { "id": "risk-check", "stateRevision": 1, "status": "building", "triggerPhase": "requirements", "returnPhase": "design", "returnTaskIndex": null, "decisionOwner": "user|agent", "requestAttempt": 1, "builderExecutionAttempt": 1, "isolation": { "path": "/absolute/isolated/path", "branch": "local-prototype-branch", "baseCommit": "<commit>" } } } } ``` ## Field Definitions | Field | Type | Description | |-------|------|-------------| | `phase` | string | Current workflow phase | | `taskIndex` | number | 0-based index of current task | | `totalTasks` | number | Total tasks in tasks.md | | `taskIteration` | number | Current retry attempt (1-based) | | `maxTaskIterations` | number | Max retries before blocking | | `awaitingApproval` | boolean | Waiting for user to proceed | | `activePrototypes` | object, optional | Live prototype overlays keyed by immutable prototype ID | A missing `activePrototypes` field means an empty map. The helper creates the map on the first reservation and removes the field when the final active entry is removed. Prototype status is live lifecycle state such as `pending`, `isolating`, `building`, `reviewing`, `awaiting_verdict`, `handoff`, `blocked`, or `timed_out`; `removed` is a helper result, not a stored status. ## Phase Values | Phase | Description | |-------|-------------| | `research` | Research phase active | | `requirements` | Requirements gathering | | `design` | Technical design | | `tasks` | Task planning | | `execution` | Task execution loop | `prototype` is excluded from main phase values. It is valid only as terminal record frontmatter under `<basePath>/prototypes/<id>.md`. ## State Transitions ``` research -> requirements -> design -> tasks -> execution ``` Each phase sets `awaitingApproval: true` after completion (except quick mode). An overlay preserves the main phase. Its active entry records `triggerPhase`, `returnPhase`, and `returnTaskIndex`; terminal handoff restores those values or moves to the earliest artifact made stale by the selected evidence. ## Locked Mutations Use `plugins/ralph-specum/hooks/scripts/locked-state.py` for `merge`, `upsert-prototype`, `remove-prototype`, `claim-builder`, `heartbeat`, `renew-lease`, `release-lease`, `transition`, and `delete-state`. The helper locks `<basePath>/.ralph-state.lock`, preserves unknown fields, flushes replacement bytes, and atomically replaces state. Reads stay lock-free because replacement is atomic. Completion may call `delete-state` only when `activePrototypes` is empty. A lock timeout stops normal mutation. Quick mode retries once, leaves state unchanged if the retry fails, publishes a local failed `lock_timeout` record through the exclusive publisher path, and continues to design. ## Records And Gates Render candidates exclusively at `<basePath>/prototypes/.<prototype-id>.candidate.md`, review the exact bytes and source evidence, then publish `<basePath>/prototypes/<id>.md` without overwrite. Terminal records are immutable. A correction, conflict decision, cancellation, or changed conclusion creates a new ID and names prior records in `supersedes`. Downstream selection accepts only valid, non-superseded, `gateApproved` records. In normal mode, the user chooses whether validated or rejected evidence is included. In quick mode, the agent approves validated or rejected evidence; skipped, failed, and inconclusive records do not feed design. Active blockers and stale indexes stop only dependent work. Source remains in the recorded isolated path; the current checkout does not switch. Retained source gets a local isolated-branch commit. `commitSpec` controls local terminal-record commits. Pushes, remote branches, PR inclusion, issue writes, and other remote actions require separate explicit authority. ## Corruption Handling If state file missing or invalid JSON: 1. Output error with state file path 2. Suggest re-running the implement command 3. Do NOT continue execution For valid state with interrupted prototype publication, reconcile candidates and finals before dispatch. A valid final with a matching candidate or active entry completes idempotently; a mismatched candidate is quarantined; a malformed final is excluded; an active entry without a candidate resumes from its recorded status and isolation pointers. This recovery does not bypass the missing or invalid JSON guard. Preserve `.ralph-state.json` while any active prototype remains. ## Validation Coordinator validates state against tasks.md checkmarks. If `taskIndex` does not match the checked task count, repair the counter through a locked merge while preserving `activePrototypes` and unknown fields.
-
-
SKILL.md 7.6 KB
--- name: smart-ralph description: This skill should be used when the user asks about "ralph arguments", "quick mode", "commit spec", "max iterations", "ralph state file", "prototype overlay", "execution modes", "ralph loop", "coordinator behavior", "delegate to subagent", or needs guidance on Ralph plugin arguments, state management, delegation patterns, or execution loop behavior. Core behavioral skill for all Ralph Specum operations. version: 0.2.0 user-invocable: false --- # Smart Ralph Core skill for all Ralph plugins. Defines common arguments, execution modes, shared behaviors, and coordinator delegation rules. ## Common Arguments All Ralph commands support these standard arguments: | Argument | Short | Description | Default | |----------|-------|-------------|---------| | `--quick` | | Exact token that enables persistent non-interactive generation | false | | `--interactive` | | Exact token that clears persistent quick mode | - | | `--commit` | `-c` | Commit spec/feature files locally after generation | true (normal), false (quick) | | `--no-commit` | | Explicitly disable committing files | - | | `--max-task-iterations` | `-m` | Max retries per failed task before stopping | 5 | | `--fresh` | `-f` | Force new spec/feature, overwrite if exists | false | Argument precedence: `--no-commit` > `--commit` > mode default. ## Execution Modes ### Normal Mode (Interactive) - Exact `--interactive` clears a prior authorized quick mode - No mode flag resets legacy quick state that lacks exact `--quick` authorization - User reviews artifacts between phases - Phase transitions require explicit commands - Each phase sets `awaitingApproval: true` - Commits spec files by default - Research and requirements may offer the optional prototype overlay - The user owns prototype capture, verdict, handoff, and deletion decisions ### Quick Mode (`--quick`) - Only an exact `--quick` argument token enables this mode - `-q`, settings defaults, substrings, and natural-language requests do not enable it - `--quick` with `--interactive` is an error - Skip all interactive prompts, interviews, and approval pauses - Run the same phase agents (research, requirements, design, tasks) sequentially - Agents receive a "be more opinionated" directive since there is no user feedback - spec-reviewer validates each artifact (max 3 iterations) - Run at most one agent-owned prototype request after requirements and before design - Take over the oldest design-blocking prototype when one exists; otherwise choose the highest-risk grounded question - Ask no prototype question or decision and continue to design after every outcome - Immediately start execution after all phases complete - Do NOT commit by default (use `--commit` to override) - Still delegate to subagents (delegation is mandatory) ## State File All Ralph plugins use `.ralph-state.json` for execution state. See `references/state-file-schema.md` for full schema. Key fields: `phase`, `taskIndex`, `totalTasks`, `taskIteration`, `maxTaskIterations`, `awaitingApproval`, `quickMode`, `quickAuthorization`, `phaseSkillLoad`, `phaseInterview`, and optional `activePrototypes`. Prototype is an overlay. `phase` remains one of the five main workflow phases and is never `prototype`. Resolve `basePath` before access, treat a missing `activePrototypes` map as empty, and route every mutation or deletion through `hooks/scripts/locked-state.py`. Read [`references/state-file-schema.md`](references/state-file-schema.md) before changing state, resuming an overlay, or deciding whether execution state may be deleted. ## Commit Behavior When `commitSpec` is true: 1. Stage spec/feature files after generation 2. Commit with message: `chore(<plugin>): commit spec files before implementation` 3. Keep the commit local unless a separate command and explicit authority permit a remote action When `commitSpec` is false: - Files remain uncommitted - User can manually commit later Prototype terminal records are spec artifacts, so `commitSpec` controls their local commit. Retained prototype source always receives a local commit on its isolated branch, independent of `commitSpec`. Neither path authorizes a push, remote branch, PR inclusion, issue mutation, or ticket comment. ## Prototype Overlay The coordinator follows this sequence: 1. Resolve `basePath`, reconcile candidates and finals, and reserve or resume `activePrototypes.<id>` under the state lock. Completion criterion: the main phase and unrelated fields are unchanged. 2. Keep source in an isolated sibling worktree or eligible scratch path. Completion criterion: the current checkout remains on its original branch and prototype files exist only in the recorded isolation path. 3. Build and review one falsifiable question. Completion criterion: the reviewer passes the exact candidate bytes, source/run evidence, isolation, blocker, handoff, and `sourceDisposition`. 4. Publish one immutable terminal record without overwrite, apply gate selection, restore the recorded return phase/task, then remove the active entry under lock. Completion criterion: downstream work sees only valid, non-superseded, gate-approved evidence. Normal mode waits without a verdict or handoff timeout and keeps decisions with the user. Quick mode owns the one post-requirements request, can take over the oldest design blocker, uses reviewed receipts for eligible ephemeral cleanup, and always continues to design. Cancellation and interruption preserve source and publish reviewed terminal evidence before active-state removal. Prototype source, records, cleanup receipts, and quarantines are local evidence. A remote push, branch publication, PR inclusion, issue write, or deletion outside the single quick ephemeral cleanup path requires separate explicit authority. ## Task Execution Loop Ralph Specum v3.0.0+ has a self-contained execution loop via the stop-hook. No external dependencies required. Key signals: - `TASK_COMPLETE` - executor finished task - `ALL_TASKS_COMPLETE` - coordinator ends loop ## Error Handling When `taskIteration > maxTaskIterations`: block task, suggest manual intervention. If state file missing/invalid: output error, suggest re-running implement command. ## Branch Management All Ralph plugins follow consistent branch strategy: 1. Check current branch before starting 2. If on default branch (main/master): prompt for branch strategy 3. If on feature branch: offer to continue or create new 4. Exact `--quick`: create a feature branch without prompting only when currently on the default branch; otherwise keep the current non-default branch. Legacy `quickMode: true` does not select this path. Prototype isolation is separate from this feature-branch choice. Create or reuse a sibling worktree or eligible scratch path without checking out its branch in the current checkout. Retained and interrupted source remains available for recovery. ## Coordinator Behavior The main agent is a coordinator, not an implementer. Delegate all work to subagents. ### Coordinator Responsibilities 1. Parse user input and determine intent 2. Read state files for context 3. Delegate work to subagents via Task tool 4. Report results to user ### Do Not - Write code, create files, or modify source directly - Run implementation commands (npm, git commit, file edits) - Perform research, analysis, or design directly - Execute task steps from tasks.md ### Delegation Mapping | Work Type | Delegate To | |-----------|-------------| | Research | Research Team (parallel teammates) | | Requirements | product-manager subagent | | Design | architect-reviewer subagent | | Task planning | task-planner subagent | | Task execution | spec-executor subagent | | Prototype building | prototype-builder background subagent | Quick mode still requires delegation.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.