Menú
Use when the user explicitly invokes /using-super-ralph or asks which skills are available and how to use them - do NOT auto-invoke on every conversation
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | using-super-ralph |
| description | Use when the user explicitly invokes /using-super-ralph or asks which skills are available and how to use them - do NOT auto-invoke on every conversation |
Super-Ralph sr- skills override default system prompt behavior, but user instructions always take precedence:
If CLAUDE.md, GEMINI.md, or AGENTS.md says "don't use TDD" and a skill says "always use TDD," follow the user's instructions. The user is in control.
Read the relevant SKILL.md file from the skills/ directory in this project. When you invoke a skill, its content is loaded and presented to you -- follow it directly.
Invoke skills when they are clearly relevant to the current task, or when the user explicitly requests a skill. Skills are tools to help you work better, not bureaucratic checkpoints that must run on every interaction.
Invoke a skill when:
/sr-brainstorming, /sr-tdd)Do NOT invoke skills for:
digraph skill_flow {
"User message received" [shape=doublecircle];
"Clearly matches a skill?" [shape=diamond];
"Invoke Skill" [shape=box];
"Announce: 'Using [skill] to [purpose]'" [shape=box];
"Has checklist?" [shape=diamond];
"Create todo per item" [shape=box];
"Follow skill exactly" [shape=box];
"Respond directly" [shape=doublecircle];
"User message received" -> "Clearly matches a skill?";
"Clearly matches a skill?" -> "Invoke Skill" [label="yes"];
"Clearly matches a skill?" -> "Respond directly" [label="no or unclear"];
"Invoke Skill" -> "Announce: 'Using [skill] to [purpose]'";
"Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
"Has checklist?" -> "Create todo per item" [label="yes"];
"Has checklist?" -> "Follow skill exactly" [label="no"];
"Create todo per item" -> "Follow skill exactly";
}
All Super-Ralph skills use the sr- prefix. Use the exact skill names below.
| Task Type | Skill to Invoke | When |
|---|---|---|
| New feature, creative work | sr-brainstorming | Before design or implementation |
| Create implementation plan | sr-writing-plans | After design is approved |
| Any implementation work | sr-test-driven-development | Features, bugs, refactoring |
| Bug, test failure, error | sr-systematic-debugging | Before proposing any fix |
| Claiming work is done | sr-verification-before-completion | Before commit or completion claim |
| Execute plan (same session) | sr-subagent-driven-development | Independent tasks with subagents |
| Execute plan (new session) | sr-executing-plans | Batch execution with checkpoints |
| After completing tasks | sr-requesting-code-review | Dispatch code-reviewer subagent |
| Received review feedback | sr-receiving-code-review | Evaluate feedback critically |
| All tasks done, integrate | sr-finishing-a-development-branch | Merge, PR, or cleanup |
| Need isolated workspace | sr-using-git-worktrees | Feature isolation |
| 3+ independent failures | sr-dispatching-parallel-agents | Parallel agents |
| Creating/editing skills | sr-writing-skills | TDD for skills |
Workflow chains:
When multiple skills could apply, use this order:
Rigid (sr-test-driven-development, sr-systematic-debugging): Follow exactly. Don't adapt away discipline.
Flexible (patterns): Adapt principles to context.
The skill itself tells you which.
Stop and reassess if you catch yourself:
When the user gives direct, specific instructions (e.g., "add this function", "fix this bug", "commit this"), execute them directly. Skills complement user instructions; they don't override them or add unnecessary ceremony.
Use when starting any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when the user explicitly requests a code review, or during subagent-driven development where review is part of the workflow
Use when executing implementation plans with independent tasks in the current session