---
name: using-ring
description: |
Mandatory orchestrator protocol - establishes ORCHESTRATOR principle (dispatch agents,
don't operate directly) and skill discovery workflow for every conversation.
trigger: |
- Every conversation start (automatic via SessionStart hook)
- Before ANY task (check for applicable skills)
- When tempted to operate tools directly instead of delegating
skip_when: |
- Never skip - this skill is always mandatory
---
If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST read the skill.
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. This is not optional. You cannot rationalize your way out of this.
## ⛔ 3-FILE RULE: HARD GATE (NON-NEGOTIABLE)
**DO NOT read more than 3 files directly. This is a PROHIBITION, not guidance.**
```
FILES YOU'RE ABOUT TO TOUCH: [count]
≤3 files → Direct operation permitted (if user explicitly requested)
>3 files → STOP. DO NOT PROCEED. Launch specialist agent.
VIOLATION = WASTING 15x CONTEXT. This is unacceptable.
```
**This gate applies to:**
- Reading files (Read tool)
- Searching files (Grep/Glob returning >3 matches to inspect)
- Editing files (Edit tool on >3 files)
- Any combination totaling >3 file operations
**If you've already read 3 files and need more:**
STOP. You are at the gate. Dispatch an agent NOW with what you've learned.
**Why this number?** 3 files ≈ 6-15k tokens. Beyond that, agent dispatch costs ~2k tokens and returns focused results. The math is clear: >3 files = agent is 5-15x more efficient.
## 🚨 AUTO-TRIGGER PHRASES: MANDATORY AGENT DISPATCH
**When user says ANY of these, DEFAULT to launching specialist agent:**
| User Phrase Pattern | Mandatory Action |
|---------------------|------------------|
| "fix issues", "fix remaining", "address findings" | Launch specialist agent (NOT manual edits) |
| "apply fixes", "fix the X issues" | Launch specialist agent |
| "fix errors", "fix warnings", "fix linting" | Launch specialist agent |
| "update across", "change all", "refactor" | Launch specialist agent |
| "find where", "search for", "locate" | Launch Explore agent |
| "understand how", "how does X work" | Launch Explore agent |
**Why?** These phrases imply multi-file operations. You WILL exceed 3 files. Pre-empt the violation.
## MANDATORY PRE-ACTION CHECKPOINT
**Before EVERY tool use, you MUST complete this checkpoint. No exceptions.**
```
┌─────────────────────────────────────────────────────────────┐
│ ⛔ STOP. COMPLETE BEFORE PROCEEDING. │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. FILES THIS TASK WILL TOUCH: ___ │
│ □ >3 files? → STOP. Launch agent. DO NOT proceed. │
│ │
│ 2. USER PHRASE CHECK: │
│ □ Did user say "fix issues/remaining/findings"? │
│ □ Did user say "apply fixes" or "fix the X issues"? │
│ □ Did user say "find/search/locate/understand"? │
│ → If ANY checked: Launch agent. DO NOT proceed manually.│
│ │
│ 3. OPERATION TYPE: │
│ □ Investigation/exploration → Explore agent │
│ □ Multi-file edit → Specialist agent │
│ □ Single explicit file (user named it) → Direct OK │
│ │
│ CHECKPOINT RESULT: [Agent dispatch / Direct operation] │
│ │
└─────────────────────────────────────────────────────────────┘
```
**If you skip this checkpoint, you are in automatic violation.**
# Getting Started with Skills
## MANDATORY FIRST RESPONSE PROTOCOL
Before responding to ANY user message, you MUST complete this checklist IN ORDER:
1. ☐ **Check for MANDATORY-USER-MESSAGE** - If additionalContext contains `` tags, display the message FIRST, verbatim, at the start of your response
2. ☐ **ORCHESTRATION DECISION** - Determine which agent handles this task
- Create TodoWrite: "Orchestration decision: [agent-name] with Opus"
- Default model: **Opus** (use unless user specifies otherwise)
- If considering direct tools, document why the exception applies (user explicitly requested specific file read)
- Mark todo complete only after documenting decision
3. ☐ **Skill Check** - List available skills in your mind, ask: "Does ANY skill match this request?"
4. ☐ **If yes** → Use the Skill tool to read and run the skill file
5. ☐ **Announce** - State which skill/agent you're using (when non-obvious)
6. ☐ **Execute** - Dispatch agent OR follow skill exactly
**Responding WITHOUT completing this checklist = automatic failure.**
### MANDATORY-USER-MESSAGE Contract
If additionalContext contains `` tags:
- Display verbatim at message start, no exceptions
- No paraphrasing, no "will mention later" rationalizations
## Critical Rules
1. **Follow mandatory workflows.** Brainstorming before coding. Check for relevant skills before ANY task.
2. Execute skills with the Skill tool
## Common Rationalizations That Mean You're About To Fail
If you catch yourself thinking ANY of these thoughts, STOP. You are rationalizing. Check for and use the skill. Also check: are you being an OPERATOR instead of ORCHESTRATOR?
**Skill Checks:**
- "This is just a simple question" → WRONG. Questions are tasks. Check for skills.
- "This doesn't need a formal skill" → WRONG. If a skill exists for it, use it.
- "I remember this skill" → WRONG. Skills evolve. Run the current version.
- "This doesn't count as a task" → WRONG. If you're taking action, it's a task. Check for skills.
- "The skill is overkill for this" → WRONG. Skills exist because simple things become complex. Use it.
- "I'll just do this one thing first" → WRONG. Check for skills BEFORE doing anything.
- "I need context before checking skills" → WRONG. Gathering context IS a task. Check for skills first.
**Orchestrator Breaks (Direct Tool Usage):**
- "I can check git/files quickly" → WRONG. Use agents, stay ORCHESTRATOR.
- "Let me gather information first" → WRONG. Dispatch agent to gather it.
- "Just a quick look at files" → WRONG. That "quick" becomes 20k tokens. Use agent.
- "I'll scan the codebase manually" → WRONG. That's operator behavior. Use Explore.
- "This exploration is too simple for an agent" → WRONG. Simplicity makes agents more efficient.
- "I already started reading files" → WRONG. Stop. Dispatch agent instead.
- "It's faster to do it myself" → WRONG. You're burning context. Agents are 15x faster contextually.
**3-File Rule Rationalizations (YOU WILL TRY THESE):**
- "This task is small" → WRONG. Count files. >3 = agent. Task size is irrelevant.
- "It's only 5 fixes across 5 files, I can handle it" → WRONG. 5 files > 3 files. Agent mandatory.
- "User said 'here' so they want me to do it in this conversation" → WRONG. "Here" means get it done, not manually.
- "TodoWrite took priority so I'll execute sequentially" → WRONG. TodoWrite plans WHAT. Orchestrator decides HOW.
- "The 3-file rule is guidance, not a gate" → WRONG. It's a PROHIBITION. You DO NOT proceed past 3 files.
- "User didn't explicitly call an agent so I shouldn't" → WRONG. Agent dispatch is YOUR decision.
- "I'm confident I know where the files are" → WRONG. Confidence doesn't reduce context cost.
- "Let me finish these medium/low fixes here" → WRONG. "Fix issues" phrase = auto-trigger for agent.
**Why:** Skills document proven techniques. Agents preserve context. Not using them means repeating mistakes and wasting tokens.
**Both matter:** Skills check is mandatory. ORCHESTRATOR approach is mandatory.
If a skill exists or if you're about to use tools directly, you must use the proper approach or you will fail.
## The Cost of Skipping Skills
Every time you skip checking for skills:
- You fail your task (skills contain critical patterns)
- You waste time (rediscovering solved problems)
- You make known errors (skills prevent common mistakes)
- You lose trust (not following mandatory workflows)
**This is not optional. Check for skills or fail.**
## Mandatory Skill Check Points
**Before EVERY tool use**, ask yourself:
- About to use Read? → Is there a skill for reading this type of file?
- About to use Bash? → Is there a skill for this command type?
- About to use Grep? → Is there a skill for searching?
- About to use Task? → Which subagent_type matches?
**No tool use without skill check first.**
## MANDATORY PRE-TOOL-USE PROTOCOL
**Before EVERY tool call** (Read, Grep, Glob, Bash), complete this check:
```
┌─────────────────────────────────────────────────────────────┐
│ Tool I'm about to use: [tool-name] │
│ Purpose: [what I'm trying to learn/do] │
│ Files this will touch: [count] ← CHECK 3-FILE RULE │
├─────────────────────────────────────────────────────────────┤
│ ⛔ 3-FILE GATE: │
│ □ Will touch >3 files? → STOP. Launch agent. DO NOT proceed│
│ □ Already touched 3 files? → STOP. At gate. Dispatch now. │
├─────────────────────────────────────────────────────────────┤
│ Orchestration Decision: │
│ □ User explicitly requested specific file → Direct tool OK │
│ □ Investigation/exploration/search → MUST use agent │
│ □ User said "fix issues/remaining/findings" → MUST use agent│
├─────────────────────────────────────────────────────────────┤
│ Agent I'm dispatching: [agent-name] │
│ Model: Opus (default, unless user specified otherwise) │
│ OR │
│ Exception: [why user explicitly requested this file] │
└─────────────────────────────────────────────────────────────┘
```
**CONSEQUENCES OF SKIPPING THIS CHECK:**
- You waste 15x context (agent returns ~2k, manual exploration ~30k)
- You deprive user of conversation headroom
- You violate ORCHESTRATOR principle
- **This is automatic failure**
**Examples:**
❌ **WRONG:**
```
User: "Where are errors handled?"
Me: [uses Grep to search for "error"]
```
**Why wrong:** No orchestration decision documented, direct tool usage for exploration.
✅ **CORRECT:**
```
User: "Where are errors handled?"
Me:
Tool I'm about to use: None (using agent)
Purpose: Find error handling code
Orchestration Decision: Investigation task → Explore agent
Agent I'm dispatching: Explore
Model: Opus
```
## ORCHESTRATOR Principle: Agent-First Always
**Your role is ORCHESTRATOR, not operator.**
You don't read files, run grep chains, or manually explore – you **dispatch agents** to do the work and return results. This is not optional. This is mandatory for context efficiency.
**The Problem with Direct Tool Usage:**
- Manual exploration chains: ~30-100k tokens in main context
- Each file read adds context bloat
- Grep/Glob chains multiply the problem
- User sees work happening but context explodes
**The Solution: Orchestration:**
- Dispatch agents to handle complexity
- Agents return only essential findings (~2-5k tokens)
- Main context stays lean for reasoning
- **15x more efficient** than direct file operations
### Your Role: ORCHESTRATOR (No Exceptions)
**You dispatch agents. You do not operate tools directly.**
**Default answer for ANY exploration/search/investigation:** Use one of the three built-in agents (Explore, Plan, or general-purpose) with Opus model.
**Which agent?**
- **Explore** - Fast codebase navigation, finding files/code, understanding architecture
- **Plan** - Implementation planning, breaking down features into tasks
- **general-purpose** - Multi-step research, complex investigations, anything not fitting Explore/Plan
**Model Selection:** Always use **Opus** for agent dispatching unless user explicitly specifies otherwise (e.g., "use Haiku", "use Sonnet").
**Only exception:** User explicitly provides a file path AND explicitly requests you read it (e.g., "read src/foo.ts").
**All these are STILL orchestration tasks:**
- ❌ "I need to understand the codebase structure first" → Explore agent
- ❌ "Let me check what files handle X" → Explore agent
- ❌ "I'll grep for the function definition" → Explore agent
- ❌ "User mentioned component Y, let me find it" → Explore agent
- ❌ "I'm confident it's in src/foo/" → Explore agent
- ❌ "Just checking one file to confirm" → Explore agent
- ❌ "This search premise seems invalid, won't find anything" → Explore agent (you're not the validator)
**You don't validate search premises.** Dispatch the agent, let the agent report back if search yields nothing.
**If you're about to use Read, Grep, Glob, or Bash for investigation:**
You are breaking ORCHESTRATOR. Use an agent instead.
### Available Agents
#### Built-in Agents (Claude Code)
| Agent | Purpose | When to Use | Model Default |
|-------|---------|-------------|---------------|
| **`Explore`** | Codebase navigation & discovery | Finding files/code, understanding architecture, searching patterns | **Opus** |
| **`Plan`** | Implementation planning | Breaking down features, creating task lists, architecting solutions | **Opus** |
| **`general-purpose`** | Multi-step research & investigation | Complex analysis, research requiring multiple steps, anything not fitting Explore/Plan | **Opus** |
| `claude-code-guide` | Claude Code documentation | Questions about Claude Code features, hooks, MCP, SDK | Opus |
#### Ring Agents (Specialized)
| Agent | Purpose |
|-------|---------|
| `ring-default:code-reviewer` | Architecture & patterns |
| `ring-default:business-logic-reviewer` | Correctness & requirements |
| `ring-default:security-reviewer` | Security & OWASP |
| `ring-default:write-plan` | Implementation planning |
### Decision: Which Agent?
**Don't ask "should I use an agent?" Ask "which agent?"**
```
START: I need to do something with the codebase
├─▶ Explore/find/understand code
│ └─▶ Use Explore agent with Opus
│ Examples: "Find where X is used", "Understand auth flow", "Locate config files"
│
├─▶ Search for something (grep, find function, locate file)
│ └─▶ Use Explore agent with Opus (YES, even "simple" searches)
│ Examples: "Search for handleError", "Find all API endpoints", "Locate middleware"
│
├─▶ Plan implementation or break down features
│ └─▶ Use Plan agent with Opus
│ Examples: "Plan how to add feature X", "Break down this task", "Design solution for Y"
│
├─▶ Multi-step research or complex investigation
│ └─▶ Use general-purpose agent with Opus
│ Examples: "Research and analyze X", "Investigate Y across multiple files", "Deep dive into Z"
│
├─▶ Review code quality
│ └─▶ Use ALL THREE in parallel:
│ • ring-default:code-reviewer (with Opus)
│ • ring-default:business-logic-reviewer (with Opus)
│ • ring-default:security-reviewer (with Opus)
│
├─▶ Create implementation plan document
│ └─▶ Use ring-default:write-plan agent with Opus
│
├─▶ Question about Claude Code
│ └─▶ Use claude-code-guide agent with Opus
│
└─▶ User explicitly said "read [specific-file]"
└─▶ Read directly (ONLY if user explicitly requested specific file read)
```
### Quick Reference: WRONG → RIGHT
| Your Thought | Action |
|--------------|--------|
| "Let me read files to understand X" | Explore agent: "Understand X" |
| "I'll grep for Y" | Explore agent: "Find Y" |
| "User mentioned file Z" | Explore agent (unless user said "read Z") |
| "Need context for good agent instructions" | Dispatch agent with broad topic |
| "Already read 3 files, just 2 more" | STOP at gate. Dispatch now. |
| "This search won't find anything" | Dispatch anyway. You're not the validator. |
**Any of these thoughts = you're about to violate ORCHESTRATOR.**
### Ring Reviewers: ALWAYS Parallel
When dispatching code reviewers, **single message with 3 Task calls:**
```
✅ CORRECT: One message with 3 Task calls (all in parallel)
❌ WRONG: Three separate messages (sequential, 3x slower)
```
### Context Efficiency: Orchestrator Wins
| Approach | Context Cost | Your Role |
|----------|--------------|-----------|
| Manual file reading (5 files) | ~25k tokens | Operator |
| Manual grep chains (10 searches) | ~50k tokens | Operator |
| Explore agent dispatch | ~2-3k tokens | Orchestrator |
| **Savings** | **15-25x more efficient** | **Orchestrator always wins** |
## TodoWrite Requirements
**First two todos for ANY task:**
1. "Orchestration decision: [agent-name] with Opus" (or exception justification)
2. "Check for relevant skills"
**If skill has checklist:** Create TodoWrite todo for EACH item. No mental checklists.
## Announcing Skill Usage
- **Always announce meta-skills:** brainstorming, writing-plans, systematic-debugging, codify-solution (methodology change)
- **Post-completion:** After non-trivial fixes, suggest `/ring-default:codify` to document the solution
- **Skip when obvious:** User says "write tests first" → no need to announce TDD
## Required Patterns
This skill uses these universal patterns:
- **State Tracking:** See `skills/shared-patterns/state-tracking.md`
- **Failure Recovery:** See `skills/shared-patterns/failure-recovery.md`
- **Exit Criteria:** See `skills/shared-patterns/exit-criteria.md`
- **TodoWrite:** See `skills/shared-patterns/todowrite-integration.md`
Apply ALL patterns when using this skill.
# About these skills
**Many skills contain rigid rules (TDD, debugging, verification).** Follow them exactly. Don't adapt away the discipline.
**Some skills are flexible patterns (architecture, naming).** Adapt core principles to your context.
The skill itself tells you which type it is.
## Instructions ≠ Permission to Skip Workflows
Your human partner's specific instructions describe WHAT to do, not HOW.
"Add X", "Fix Y" = the goal, NOT permission to skip brainstorming, TDD, or RED-GREEN-REFACTOR.
**Red flags:** "Instruction was specific" • "Seems simple" • "Workflow is overkill"
**Why:** Specific instructions mean clear requirements, which is when workflows matter MOST. Skipping process on "simple" tasks is how simple tasks become complex problems.
## Summary
**Starting any task:**
1. **Orchestration decision** → Which agent handles this? Use **Opus** model by default (TodoWrite required)
2. **Skill check** → If relevant skill exists, use it
3. **Announce** → State which skill/agent you're using
4. **Execute** → Dispatch agent with Opus OR follow skill exactly
**Before ANY tool use (Read/Grep/Glob/Bash):** Complete PRE-TOOL-USE PROTOCOL checklist.
**Skill has checklist?** TodoWrite for every item.
**Default answer: Use an agent with Opus. Exception is rare (user explicitly requests specific file read).**
**Model default: Opus** (unless user specifies Haiku/Sonnet explicitly).
**Finding a relevant skill = mandatory to read and use it. Not optional.**