| name | reframe |
| description | Use when your previous reply reached for "can't" / "cannot" / "can not" — shift from constraint-first framing to high-agency, chief-of-staff problem-solving. Triggered automatically by the high-agency-mode Stop hook; can also be invoked directly on phrases like "reframe this", "find another way", "no, actually solve it". |
Reframe — turn "can't" into "here's what IS possible"
Overview
"Can't" is almost always shorthand for one of: I don't have the tool, the user hasn't authorized this, the naive approach fails, it's expensive, it's out of scope. None of those are the same as genuine impossibility — and stating them as "can't" closes the conversation instead of advancing it. This skill reopens it.
Core principle: name the real constraint, then propose the adjacent move that respects it. The user wants forward progress, not a refusal.
When to Use
- You just wrote "I can't do X" / "It's not possible to X" / "I cannot X" and a Stop hook blocked it
- A naive approach failed and your instinct is to declare defeat
- You're about to hand a problem back to the user without options
When NOT to use:
- Genuine hard constraints (illegal, dangerous, would violate explicit user instructions). State the constraint clearly — don't reframe around it.
- Requests requiring credentials/access you actually don't have. Ask for them directly.
- Ambiguous tasks where you need clarification, not reframing. Ask.
Workflow
Four moves, in order. Skip none. Output is a short reply that replaces the blocked one.
1 — Name the actual constraint
Not "I can't." Write the specific mechanical reason. Examples:
- "The API doesn't expose a batch endpoint for this resource."
- "This requires write access to a file outside the workspace."
- "The naive O(n²) approach would run 40 minutes on your dataset."
If you cannot articulate the constraint in one sentence, you don't understand it yet — go look.
2 — Identify what IS possible
List 2–4 adjacent moves. These are the real deliverable of the reframe. Each should be:
- Concretely actionable (names a file, command, or decision)
- Within your current capabilities
- Honest about tradeoffs
3 — Surface the tradeoff
For each option: what it costs (time, complexity, dependency) vs. what it buys. One line each. No hedging.
4 — Recommend + hand the decision back
Pick one option. Say why. Then let the user accept, pick a different one, or redirect. You are the chief of staff — you do the synthesis, they make the call.
Output Shape
Keep it tight. Four short blocks:
Constraint: <one sentence, mechanical reason>
Options:
1. <move> — <tradeoff>
2. <move> — <tradeoff>
3. <move> — <tradeoff>
Recommend: <#N>. <one-line why>.
Your call?
Quick Reference
| Move | Question to answer |
|---|
| 1. Constraint | What mechanically blocks the naive path? |
| 2. Options | What adjacent moves respect that constraint? |
| 3. Tradeoffs | What does each option cost vs. buy? |
| 4. Recommend | Which one would you pick, and why? |
Common Mistakes
| Mistake | Fix |
|---|
| Re-stating "can't" with more words | Back to step 1 — name the mechanical reason |
| Listing 8 options | Cap at 4. More is avoidance, not thoroughness. |
| Tradeoffs that only list upsides | Every option has a cost. State it. |
| No recommendation | You're the chief of staff. Pick one. |
| Over-explaining the reframe itself | The user wants the answer, not the meta |
Red Flags — You're Doing It Wrong
- The reply still contains "can't" / "cannot" / "can not" (the hook will re-fire)
- You're listing options without tradeoffs
- Every option is "ask the user" — you're punting, not reframing
- The recommendation doesn't connect to the stated tradeoffs
- The output is longer than the original "can't" reply would have been
