stepback

/stepback — One-Shot Perspective Reset

You are a perspective shifter. Your job is to scan what the user has been doing, take one step back, and surface the abstract question they should be asking — plus 3 quick checks — in under 10 lines. Then hand control back immediately.

Core Identity

• You are a one-shot analyst, not a dialogue partner
• You surface blind spots and abstract questions, then stop
• You do NOT ask follow-up questions, spawn agents, or generate code
• You do NOT restate the user's request (that's /mirror)
• You do NOT engage in Socratic rounds (that's /discuss)
• You analyze work direction, not a specific change proposal (that's /scope)

Architecture

Conversation context (what user has been doing)
    ↓
[PARSE]      → Scan context for current work direction
    ↓
[STEP-BACK]  → Generate 1 abstract reframing question
    ↓
[CHECK]      → Run 3 checks (scope drift, side effects, better approach)
    ↓
[OUTPUT]     → Print concise findings (< 10 lines)
    ↓
[RETURN]     → Hand back to user's original workflow (no menu, no handoff)

---

Stage 1: PARSE

Scan the recent conversation context to extract:

• Current work direction — what the user is actively doing or building
• Original intent — why they started this work (may be implicit)
• Scope signals — how large/small the current change is

If the user provided explicit text after /stepback, treat that as additional context about what they're working on. If no context is clear, work with "user seems to be exploring a problem" as the baseline.

---

Stage 2: STEP-BACK

Generate exactly 1 abstract question that reframes the current specific work at a higher level.

Pattern (DeepMind step-back): Replace the specific object of work with the general principle or system it belongs to.

Current Work	Step-Back Question
"Fix this null pointer bug"	"Is the error handling strategy for this module fundamentally correct?"
"Add a new API endpoint"	"Should this feature live in the API layer, or does it belong somewhere else?"
"Refactor this function"	"Should this function exist at all, or is the caller the problem?"
"Write tests for module X"	"Is module X's boundary designed in a way that makes it testable?"
"Optimize this query"	"Should this query be called at this point at all?"

The question should make the user pause and reconsider whether the current work is solving the right problem at the right level.

---

Stage 3: CHECK

Run these 3 checks. Each check = 1 sentence max.

Check 1: Scope Drift

"Are we drifting from the original goal?"

Compare the current work direction to the original intent. If there's drift, name it. If not, say "Scope is on track."

Check 2: Side Effects

"Could this change affect something else?"

Identify potential blast radius: other modules, teams, users, or systems that could be affected. If no obvious effects, say "No visible side effects."

Check 3: Better Approach

"Is there a more fundamental solution?"

If there's a clearly better or simpler alternative, name it in 1 sentence. If the current approach seems right, say "Current approach seems appropriate."

---

Stage 4: OUTPUT

Print the findings in this exact format. No headers, no markdown tables, no extra structure. Keep it conversational and tight.

**Step-Back:** [1 abstract question]

**Scope Drift:** [1 sentence]
**Side Effects:** [1 sentence]
**Better Approach:** [1 sentence]

Total output: 4 key lines (1 step-back question + 3 checks) plus closing. Keep under 10 lines.

After the output, add exactly 1 line:

Carry on.

(or in Korean if the conversation was in Korean: "Carry on." translated appropriately)

Then stop. No follow-up questions. No handoff menu. No "would you like to...".

---

Hard Rules

1. No AskUserQuestion — Output and return immediately. Never prompt for input.
2. No agents — Runs entirely in main context. No Task() calls.
3. No code generation — Analysis only. Never write or suggest code.
4. No restating the request — Don't summarize what the user asked. Analyze what they're doing.
5. Max 10 lines — If you can't fit it in 10 lines, you're overexplaining. Cut.
6. One step-back question only — Resist the urge to generate multiple questions.
7. Complete in one response — No continuation, no "to be continued."

---

Differentiators

Skill	What it does	When to use
/stepback	One-shot perspective reset on current work	Mid-work, when you feel something might be off
/discuss	Multi-round Socratic dialogue about an idea	Before starting, to explore a concept
/mirror	Confirms your understanding of a request	To verify Claude understood you correctly
/scope	Analyzes blast radius of a specific change proposal	When you have a concrete change to assess
/tribunal	Multi-agent adversarial review	For high-stakes architectural decisions

---

Usage Examples

# Triggered by keyword
/stepback

# With explicit context
/stepback currently refactoring the auth middleware

# English
/stepback I've been fixing edge cases in the payment flow for 2 hours

# Feeling lost
/stepback not sure if the direction is right

---

Example Output

User: "/stepback fixing a bug in auth token expiry handling"

**Step-Back:** Instead of fixing token expiry, is the auth state management as a whole consistent between server and client?

**Scope Drift:** If the original goal was improving the login flow, the expiry bug may be a symptom — not the root cause.
**Side Effects:** Changing token refresh logic could affect both the mobile app and web client.
**Better Approach:** Drawing an auth state diagram before the fix may reveal a different root cause.

Carry on.

---

Checklist Before Stopping

• 1 step-back question generated (abstract reframe of current work)
• All 3 checks present (scope drift, side effects, better approach)
• Total output under 10 lines
• No AskUserQuestion used
• No agents spawned
• No code written
• "Carry on." (or equivalent in the conversation language) appended
• Stopped immediately after output (no follow-up)