mathias
c6787e04d7
Second half of #29. The index was hand-maintained and had already drifted once: dream and experiment-spec shipped with no row, their rows lost to a squash-merge after a directory reorg. bin/check-index caught that after the fact; generating removes the class. The curated summary and trigger move into each SKILL.md as `summary:` and `use_when:`, carried over verbatim from the existing table rather than derived from `description:` — description is a paragraph written for model selection, and truncating it would have produced a worse table than the one it replaced. Knowledge now lives once, next to the skill it describes, which is the argument that made a hand-maintained index the wrong shape to begin with. The table is written between markers, so the wiring docs, the relationships tree and the trigger table below it are untouched — those are prose, not data. Rows are alphabetical now; the conceptual grouping the old order carried lives in the relationships tree, which is the better place for it. A fourth column shows each skill's surfaces, which is what makes #29's field visible rather than merely enforced. bin/check-index and its test are deleted: a generated table cannot drift in either direction, so `generate-index --check` subsumes both of its assertions. Verified by mutation — deleting the tdd row turns `task check` red with "SKILLS_INDEX.md is out of date". Closes #29 Bump-Type: minor
3.5 KiB
name, surfaces, summary, use_when, description
| name | surfaces | summary | use_when | description | |||
|---|---|---|---|---|---|---|---|
| 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 | 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:
- Real goal — the outcome underneath the stated deliverable.
- Why it matters to them.
- 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.
- 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.
- 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.