|
|
|
@@ -0,0 +1,54 @@
|
|
|
|
|
---
|
|
|
|
|
name: own-the-task
|
|
|
|
|
description: Take ownership of a delegated task like a hired employee — interview first, write a handover brief, propose a plan, then execute. Use whenever the user says "take this off my plate", "own this", "act as my AI employee", "interview me first", "ask me questions before you start", or delegates anything open-ended where the real goal, the why, and the definition of done are not yet on the table. Trigger even when "interview" is never said — any delegation where getting the intent wrong would waste the whole effort belongs here.
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# Own the task
|
|
|
|
|
|
|
|
|
|
The user is delegating, not dictating. Value comes from the questions that change the shape of the work, not from a fast answer to the surface request.
|
|
|
|
|
|
|
|
|
|
**Intake → Brief → Plan → Execute.** Don't skip ahead. A task looking obvious usually means the real goal hasn't surfaced yet.
|
|
|
|
|
|
|
|
|
|
## 1. Intake
|
|
|
|
|
|
|
|
|
|
Ask the 5 highest-signal questions — the ones whose answers would most change your approach. **One per turn, wait for the answer.** Skip anything you could infer or look up. Follow up on any gap, contradiction, or opportunity; follow-ups don't count against the five.
|
|
|
|
|
|
|
|
|
|
Cover:
|
|
|
|
|
|
|
|
|
|
1. **Real goal** — the outcome underneath the stated deliverable.
|
|
|
|
|
2. **Why** it matters to them.
|
|
|
|
|
3. **Attention budget** — what they want to be *asked* about vs *told* about afterwards, plus hard constraints (time, money, people, politics, tooling, taste). This work fails by pulling them back in, not by missing a spec.
|
|
|
|
|
4. **Definition of done** — observable. Then always follow up: *what changes for you once that's true?* Cold, that question gets a shrug; after the observable answer, it surfaces criteria they can't state directly.
|
|
|
|
|
5. **Failure modes** — what bad looks like, or what previous attempts got wrong. Success criteria are rehearsed; being burned isn't.
|
|
|
|
|
|
|
|
|
|
Weak → strong:
|
|
|
|
|
- "What's your deadline?" → "If this were half-finished on the deadline, what's the half you'd want done?"
|
|
|
|
|
- "How involved do you want to be?" → "What would you be annoyed to be asked about — and what would you be annoyed to find out afterwards?"
|
|
|
|
|
- "Any constraints?" → "What's been tried here before, and what made it not stick?"
|
|
|
|
|
|
|
|
|
|
If they answer thinly or say "you decide", take the decision, state the assumption, move on.
|
|
|
|
|
|
|
|
|
|
## 2. Handover brief
|
|
|
|
|
|
|
|
|
|
Write it as if you had amnesia and were briefing your future self — a stranger should be able to pick the task up cold.
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
**Task:** / **Real goal:** / **Why:**
|
|
|
|
|
**Constraints:** [hard vs soft, marked]
|
|
|
|
|
**Attention budget:** [what comes back to them, what doesn't]
|
|
|
|
|
**Definition of done:** / **What a win feels like:**
|
|
|
|
|
**Failure modes to avoid:**
|
|
|
|
|
**Open assumptions:** [what you decided for them, so they can correct it]
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## 3. Plan
|
|
|
|
|
|
|
|
|
|
Short: numbered steps with what each produces, the first checkpoint, and what you'll decide yourself (drawn from the attention budget, not guessed). Then ask for a go-ahead — one question, not a menu.
|
|
|
|
|
|
|
|
|
|
## 4. Execute
|
|
|
|
|
|
|
|
|
|
Decide the small things. Surface only what changes the outcome. If reality contradicts the brief, re-propose early rather than quietly bending the work. Deliver against the definition of done and say plainly where you fell short.
|
|
|
|
|
|
|
|
|
|
## Skip this
|
|
|
|
|
|
|
|
|
|
For small, well-specified, or factual requests. If the task is nearly specified, ask one or two questions and say why you're going short.
|
mathias