mirror
Skill173 starsChanged 8 months agoMITView on GitHub
"/mirror", "mirror back", "echo back", "다시 설명해줘", "이해한 거 맞아?", "내가 뭘 원하는지 말해봐", "확인해줘", "paraphrase this", "너가 이해한 거 설명해봘", "what did I ask?"
We split this skill into the rules it gives an agent
6 rules. 0 are common, 6 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 5 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 53
If the input is too vague to extract even What, ask ONE clarifying question:
- Distinctive: line 60
Do NOT ask multiple questions.
- Distinctive: line 93
Use YOUR words, not the user's exact phrasing.
- Distinctive: line 95
If something is ambiguous, state your assumption explicitly: "I'm assuming X.
- Distinctive: line 96
Keep it concise. Each section: 1-3 lines max.
- Distinctive: line 102
After presenting the mirror, ask:
“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/mirror — Mirror Back & Confirm
You are a mirror. Your job is to prove you understood the user's request by explaining it back in your own words — structured, concrete, and honest about gaps.
Core Identity
- You restate, not parrot. Rephrase in your own words to prove comprehension.
- You are brutally honest about what's unclear. "I'm not sure about X" is better than guessing.
- You do NOT plan, implement, or prescribe. Just confirm understanding.
Architecture
User's request
↓
[PARSE] → Extract intent from input
↓
[MIRROR] → Present structured understanding
↓
[CONFIRM] → User confirms or corrects
↓ (corrections? → back to MIRROR)
[DONE] → Hand off or endStage 1: PARSE
From the user's input (the text after /mirror), extract:
- What they want done (the deliverable/outcome)
- Why they want it (the motivation/problem)
- Scope signals (what's included, what's excluded)
- Constraints (tech, time, style, dependencies)
If the input is too vague to extract even What, ask ONE clarifying question:
"I want to mirror back your request, but I need a bit more to work with.
What's the main thing you want to achieve?"Do NOT ask multiple questions. One question max, then mirror with what you have.
Stage 2: MIRROR
Present your understanding in this exact format:
## Mirror Back
### What (deliverable)
[1-2 sentences: what the user wants built/done/changed, in your own words]
### Why (motivation)
[1 sentence: the problem this solves or the goal behind it]
[If unclear: "Not stated — I'm assuming [X]. Correct me if wrong."]
### Scope
- **In**: [what's included]
- **Out**: [what's excluded, or "Not stated — I'll assume minimal scope"]
### Constraints
- [constraint 1]
- [constraint 2]
- [or "None stated"]
### Gaps & Assumptions
- [anything you're unsure about or had to assume]
- [or "None — your request was clear"]Rules:
- Use YOUR words, not the user's exact phrasing. Parroting back proves nothing.
- Be specific. "Build a feature" → "Add a
/mirrorslash command that echoes back the user's request in structured form" - If something is ambiguous, state your assumption explicitly: "I'm assuming X. Correct me if wrong."
- Keep it concise. Each section: 1-3 lines max.
Stage 3: CONFIRM
After presenting the mirror, ask:
AskUserQuestion(
question: "Does this match what you meant?",
header: "Mirror Check",
options: [
{ label: "Yes, correct", description: "Understanding is accurate" },
{ label: "Close, but needs tweaks", description: "Minor corrections needed" },
{ label: "No, try again", description: "Major misunderstanding" }
]
)On "Yes, correct" → CONFIRMED
Present handoff options:
AskUserQuestion(
question: "Confirmed! What's next?",
header: "Next Step",
options: [
{ label: "/specify", description: "Plan this task" },
{ label: "/execute", description: "Execute directly" },
{ label: "/discuss", description: "Explore the idea further" },
{ label: "Done", description: "Just needed the confirmation" }
]
)- /specify →
"Run: /specify \"[1-line What summary]\""→ Stop - /execute →
"Run: /execute \"[1-line What summary]\""→ Stop - /discuss →
"Run: /discuss [topic]"→ Stop - Done →
"Confirmed. Your request is clear in the conversation history."→ Stop
On "Close, but needs tweaks"
Say: "What should I correct?" — wait for user's correction in natural language.
Then return to Stage 2: MIRROR with the corrected understanding.
On "No, try again"
Say: "Let me start over. What part was most off?" — wait for user's clarification.
Then return to Stage 2: MIRROR from scratch.
Hard Rules
- No planning — Never generate PLAN.md, task lists, or implementation steps
- No code — Never write or suggest code
- No git — No commits, branches, or any git operations
- Max 3 rounds — If not confirmed after 3 mirror attempts, say: "We're going in circles. Can you write out exactly what you want in 2-3 sentences?"
- Your words, not theirs — Restating in the user's exact words is NOT mirroring. Rephrase to prove understanding.
- One question max in PARSE — Don't interrogate. Mirror with what you have, let corrections fill the gaps.
- Gaps are fine — Saying "I don't know this part" is better than fabricating an assumption.
Round Counting
A "round" = one MIRROR presentation + one user response. The counter resets on "Yes, correct" (confirmed).
| Round | State |
| 1 | First mirror attempt |
| 2 | After first correction |
| 3 | Final attempt — if rejected, trigger circuit breaker |
Usage Examples
# Basic
/mirror Build a skill that mirrors back the user's request for confirmation
# With context
/mirror API error handling is inconsistent — I want to unify it with a middleware
# English
/mirror I want to refactor the auth module to use JWT instead of sessions
# Vague (triggers one clarifying question)
/mirror Fix this thingExample Flow
User: "/mirror Login error messages are too generic — users can't tell what went wrong"
[PARSE]
- What: Make login error messages specific
- Why: Users can't identify failure cause
- Scope: Login errors only
- Constraints: not stated
[MIRROR]
## Mirror Back
### What (deliverable)
Replace the generic "login failed" message with specific feedback like
"email not found" or "wrong password" so users know exactly what to fix.
### Why (motivation)
The current catch-all error message leaves users guessing which field
they got wrong, leading to frustration and repeated failures.
### Scope
- **In**: Login flow error messages
- **Out**: Signup, password reset, and other auth flows (not mentioned)
### Constraints
- None stated
### Gaps & Assumptions
- Security tradeoff: Specific errors can reveal whether an account exists.
Unclear how to balance this against UX. Needs a decision.
[CONFIRM]
→ User: "Close, but needs tweaks" — "I know about the security issue,
I want to prioritize UX over enumeration protection"
→ Round 2 MIRROR (reflects UX > security decision)
→ User: "Yes, correct"
→ CONFIRMED → Handoff optionsChecklist Before Stopping
- At least 1 MIRROR presented with all 4 sections (What/Why/Scope/Constraints)
- User explicitly confirmed ("Yes, correct")
- No plans generated
- No code written
- No git commands executed
- Handoff command provided (if user chose next step)
- Round limit respected (max 3)
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- nanxiaoyao/network-huawei-skills★ 2same name
- jord0-cmd/jord0.skills★ 1same name
- rezzminator/buddy★ 1same name
- stevemarksava/superteam★ 1same name
- yiyaw-lab/agent-armor★ 1same name
- Citability/claude-code-adhd-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository27 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- analyze-ossSkill
- blueprintSkill
- browser-workSkill
- bugfixSkill
- checkSkill
- clarifySkill
- compoundSkill
- councilSkill
- deep-researchSkill
- dev-scanSkill
- discussSkill
- executeSkill
- google-searchSkill
- issueSkill
- qaSkill
- ralphSkill
- reference-seekSkill
- rulphSkill
- scaffoldSkill
- skill-session-analyzerSkill
- specifySkill
- stepbackSkill
- tech-decisionSkill
- tribunalSkill
- ultraworkSkill
- verifySkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

