khive

分类: 工具与效率 | 上传者: ohdearquant | 下载: 0 | 版本: v1.0（最新）
将任务或承诺清晰地捕获到 GTD 收件箱中——标题、优先级、可选上下文——无需尝试对其进行计划。
更新日志: Source: GitHub https://github.com/ohdearquant/khive
目录结构

当前层级: tree/main/marketplace/gtd/skills/capture/
📄 SKILL.md 4.4 KB
SKILL.md

---
description: Capture a task or commitment into the GTD inbox cleanly — title, priority, optional context — without trying to plan it.
---

# Capture

You have a thought, commitment, request, or to-do that needs to leave your head. Drop it in the inbox now; plan later.

## Principle

Capture is a one-shot action. The goal is to **stop thinking about it** and trust the system to surface it later. Don't try to schedule, prioritize precisely, or break down — `inbox` is the right status for anything you haven't processed.

## Workflow

### 1. Decide the title

A task title is what you'd say out loud: short, verb-first, complete enough to remember in a week. "draft README" beats "documentation"; "ship release" beats "release stuff".

### 2. Assign with the smallest commitment

```
request(ops="assign(title=\"<title>\", priority=\"p2\")")
```

Default priority is `p2`. Use `p0`/`p1` only if you genuinely want it pushed up in `next` listings. `p3` for "nice to have, no pressure".

### 3. Add context if it's not in your head

If you might forget _why_ this matters, add a description:

```
request(ops="assign(title=\"<title>\", priority=\"p1\", description=\"<one-sentence why>\")")
```

If there's a deadline, set it — but only if it's a real deadline, not aspirational:

```
request(ops="assign(title=\"prep slides\", priority=\"p0\", due=\"2026-06-01T10:00:00Z\")")
```

### 4. Multiple captures? Batch them.

The DSL takes a parallel batch:

```
request(ops="[
  assign(title=\"call dentist\", priority=\"p2\"),
  assign(title=\"renew passport\", priority=\"p1\", due=\"2026-08-01\"),
  assign(title=\"finish bench script\", priority=\"p1\", tags=[\"work\",\"lattice\"])
]")
```

### 5. Don't pre-plan in capture

Resist:

- Setting `status=\"active\"` because "I'll do it now" — start the task with `transition`, not on creation.
- Adding `depends_on` for soft preferences — only encode hard prerequisites (the dep must actually be done first).
- Writing the full description up front — capture the _task_, save the _plan_ for later.

## When to use other verbs instead

| Situation                                               | Verb                                                                                                                                                               |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| "Can I act on this right now?" — actually start working | `transition(id=..., status="active")`                                                                                                                              |
| "I know I can't do this yet, blocked by X"              | `assign(..., status="waiting")` + describe blocker in `description`                                                                                                |
| "Maybe someday, not now"                                | `assign(..., status="someday")`                                                                                                                                    |
| Need to record several together and link dependencies   | capture the blocker first, then `assign(..., depends_on=[blocker_full_id])` for the dependent task — the property and the `depends_on` graph edge both get written |

## Examples

**Personal**:

```
request(ops="assign(title=\"book physical exam\", priority=\"p1\", due=\"2026-06-30\")")
```

**With dependency** (two-step — the second `assign` needs the first task's `full_id`):

```
# Step 1: capture the blocker
request(ops="assign(title=\"write spec\", priority=\"p1\")")
# → returns { id: "<short>", full_id: "<spec-uuid>", ... }

# Step 2: capture the dependent task referencing the blocker
request(ops="assign(title=\"implement feature\", priority=\"p2\", depends_on=[\"<spec-uuid>\"])")
```

`assign`'s `depends_on` writes both the property (`properties.depends_on`) and a `depends_on`
graph edge between the two tasks — so `neighbors(node_id=\"<impl-uuid>\", direction=\"out\", relations=[\"depends_on\"])`
will surface the blocker.

**Quick brain-dump** (4 things at once):

```
request(ops="[
  assign(title=\"reply to Mitchell\", priority=\"p1\"),
  assign(title=\"clean kitchen\", priority=\"p3\"),
  assign(title=\"file taxes\", priority=\"p0\", due=\"2026-04-15\"),
  assign(title=\"learn Polars\", priority=\"p3\", status=\"someday\")
]")
```
登录后下载/点赞/收藏 ❤ 19 | ★ 0
khive

目录结构

SKILL.md

举报内容

提示
