Compare commits
1
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
85e125703e |
@@ -23,6 +23,7 @@ This index lists all available engineering skills. Load the full SKILL.md on dem
|
||||
| `session-retrospective` | Surface non-obvious learnings from a session log | After a coding session ends, before context is lost |
|
||||
| `trainer` | Two-phase brain curation (score candidates, write past quality gate) | Periodic brain pruning and curation |
|
||||
| `grill-me` | Structured plan interrogation — Quick Poke, Full Grill, Pre-mortem | Stress-testing a plan before committing; end of Diamond 1; before promoting to pre-prod |
|
||||
| `own-the-task` | Delegation ownership — Intake → Brief → Plan → Execute | A task is handed over open-ended; "take this off my plate"; before a plan exists |
|
||||
| `telos-load` | Load TELOS intention substrate at session start | Starting any koala session; before architectural decisions; CAD pipeline entry |
|
||||
| `regulatory-risk-assessment` | Structured risk register for regulated-industry features | Filing a CAD issue (needs Risk: level); features touching payments, auth, external APIs, user data |
|
||||
| `discovery-framing` | Problem-before-solution discovery/framing method | Framing/validating a problem before any solution; opportunity sizing |
|
||||
@@ -90,6 +91,7 @@ code-review ──→ refactoring ──→ clean-code
|
||||
session-retrospective ──→ trainer ──→ brain (via brain_write)
|
||||
|
||||
(planning & convergence)
|
||||
own-the-task ──→ grill-me (intent first, then stress-test the plan)
|
||||
grill-me ──→ planning (after plan is sharpened)
|
||||
──→ spec-driven-dev (after hypothesis is validated)
|
||||
```
|
||||
@@ -113,5 +115,6 @@ grill-me ──→ planning (after plan is sharpened)
|
||||
| "Grill me / stress-test this / is this ready?" | `grill-me` |
|
||||
| "End of Diamond 1 — should we build this?" | `grill-me` (Full Grill) |
|
||||
| "About to promote to pre-prod" | `grill-me` (Pre-mortem) |
|
||||
| "Take this off my plate / own this / act as my AI employee" | `own-the-task` |
|
||||
| "What are the risks?" / "compliance gate" / "risk register" | `regulatory-risk-assessment` |
|
||||
| "Start of session" / "load TELOS" / "what are we optimizing toward?" | `telos-load` |
|
||||
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user