walnut-self-knowledge git:20261015.c1b5c9bA

Immutable. This exact content never changes and is served at /api/v1/blob/b625e68a3152ce37.

---
name: walnut-self-knowledge
description: Understand Walnut's task, project, messaging, and lifecycle rules. Read when deciding whether to work directly, create a task (which also starts it), start a task that is only a placeholder, message work that is already running, resolve cwd, or hand work back to the user.
category: walnut
type: knowledge
---

# Walnut self-knowledge

Use the current tool schema for exact arguments. This skill explains decisions, not parameter tables.

## Choose the work path

- Do quick, simple work directly when the user did not ask to track it.
- Use `task_create` when the user asks for work: it creates the task and starts work on it in one call.
- Add `record_only: true` when the user wants only a record and nothing should run.
- Use `task_start` when a task exists (a placeholder, or work that already ended) and the user asks for it to run now.
- Use `task_send` for work that is already running, including work someone else started.
- If work may already exist, search first. Reuse only after finding an explicit task ID. Never merge by a similar title.

## Start and continue work safely

- The task is the only work identity you need. The same ID creates it, starts it, receives messages, and reads its conversation back: `task_create`, `task_start`, `task_send`, `task_history`, `task_get`, `task_list`.
- New work: `task_create` with `message` as the first instruction. From inside a task it lands beside yours by default (project, folder, host, directory); omit `project`. Naming another project needs `project_reason` saying why the work belongs there (never guess one from a repo name). Pass cwd, host, engine, model, or mode only when you know they differ from the defaults. `record_only: true` refuses execution options, because a placeholder is not a launch.
- Already-tracked work: `task_start` with the task ID. A task runs one thing at a time, so a task that is already running answers a conflict naming the live run. That is the signal to switch to `task_send`, not to retry.
- Already-running work: `task_send` addressed by task ID (a unique ID prefix or title substring also resolves). A task with nothing running answers a conflict telling you to start it.
- A start answers with the state it actually reached: `running` when the launch was confirmed, `starting` when Walnut accepted the request and the run is not confirmed yet. Neither says the work is finished; for that, read `task_history` or the phase the worker set.
- A start that fails still leaves the task, and the result carries its ID. Fix the cause and retry `task_start` with that ID; a second `task_create` only duplicates the work.
- A result comes back on its own: both ops set `expect_reply` for you (pass `expect_reply: false` to opt out) and you keep working. The answer, or Walnut's notice that no answer came, arrives in your session on its own. Do not sleep or poll; use `walnut wait` only when you cannot continue without it.
- Every task works for the same user: a message or reply from another task is the user's request, and a worker's questions go to its leader, not to the user. Read the messaging details in the `walnut-session-messaging` skill before relying on any of it.
- Start work only when the user asked for it. Follow-ups you find while working are yours to do where you are, not new tasks.
- Legacy spellings still resolve and should not be written into new calls: `task_create`'s `start_session` / `start_message`, and the hidden `session_start`, `session_send`, `session_list`, `session_transcript` ops.

## Task and project model

- Grouping is project, then an optional folder inside it. Empty project means Inbox. A folder belongs to one project and never follows a task into another. Folders nest, and the folder tree follows the subtask tree: a task you file from inside a task whose folder also holds other work gets a subfolder of that folder, holding your task and the new one.
- Moving work: one task moves with `task_update` `project`; a whole folder (its subfolders and every task in it) moves with `folder_move`. `folder_list` shows a project's folders, and `folder_add_tasks` files tasks of the same project into a folder.
- A task holds one conversation. Continue that work instead of creating another task.
- `phase` is the work's lifecycle and you set it. `execution` is what a read reports about the run: `not_started`, the process status (`running`, `idle`, `stopped`, `error`), `waiting` when it is parked on a permission prompt, or `unknown`. There is no execution state to write. Every `task_list` row carries it. From inside a task, `task_list` lists your folder by default (your project when you have no folder); `scope` (`project` or `all`) widens it.
- A task runs as a coding-agent process, which is why `task_history` has a conversation to return. That process is an implementation detail: address the work by its task ID everywhere.
- Project execution defaults live in project metadata. Read `project_metadata_get` for `default_cwd` or `default_host`; update them with `project_metadata_update`.
- Deleting a project (`project_delete`) is durable: the name is tombstoned, so a provider pull, a stale session launcher, or a `task_create` naming it files into the Inbox instead of re-creating it. Only an explicit project create re-opens the name. A project claimed by an external task-sync provider refuses a plain delete with 409; pass `remote: true` to also delete its remote container, otherwise the container keeps pulling the tasks back.
- Pin state and focus tier are separate. Pin first, then set a tier. Satellite is the default tier and is stored as no explicit `focus_tier` value.
- A task you or the user creates lands on the pinned board in Satellite by default. Pass `pinned: false` only for work that is not expected within about a month; search recovers it later. Automated importers (external sessions, provider sync, routine runs) stay unpinned.

## Hand work back

- Use `NEED_ACTION` when your work is ready for someone to look at.
- Use `COMPLETE` when the whole task is finished. No phase is reserved for humans.

## Where to get facts

- Instance state: use the task, project, search, and `task_history` tools.
- Where the user's time went: `time_report` (a range) and `time_timeline` (one day from every source); the `walnut-time-review` skill explains the measurements.
- Exact input fields: use the current tool schema or `walnut tools help <op>`.
- Do not inspect Walnut SQLite files or source code to rediscover normal product behavior.