From hoyeon
Mirrors user requests back in structured What/Why/Scope/Constraints format, highlighting gaps, to confirm understanding before action. Triggered by /mirror or phrases like 'mirror back'.
npx claudepluginhub team-attention/hoyeon --plugin hoyeonThis skill is limited to using the following tools:
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.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
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.
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 end
From the user's input (the text after /mirror), extract:
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.
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:
/mirror slash command that echoes back the user's request in structured form"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" }
]
)
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" }
]
)
"Run: /specify \"[1-line What summary]\"" → Stop"Run: /execute \"[1-line What summary]\"" → Stop"Run: /discuss [topic]" → Stop"Confirmed. Your request is clear in the conversation history." → StopSay: "What should I correct?" — wait for user's correction in natural language.
Then return to Stage 2: MIRROR with the corrected understanding.
Say: "Let me start over. What part was most off?" — wait for user's clarification.
Then return to Stage 2: MIRROR from scratch.
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 |
# 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 thing
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 options