# Take one piece home

Choose one annoyance in a project you already have. Try one habit that makes the work easier to resume and one guardrail that contains a mistake. These are suggested patterns you can adapt to a single agent, a small crew, or your own work.

## Match a practice to the friction

| If this keeps happening… | Try this small version | Check whether it helped |
|---|---|---|
| Every session begins with archaeology | One current-task page or status command | Can a fresh actor find the next action without asking you to reconstruct it? |
| Useful material disappears into chat or Downloads | One inbox, with an owner and a review point in startup | Does the next orientation surface the new input? |
| Agents keep interrupting with routine updates | One queue of questions, one reporter, explicit urgent exceptions | Are consequential choices visible without repeating every worker's status? |
| Parallel tests touch yesterday's data | Separate workspace and disposable test state | Can two runs proceed without sharing mutable test data? |
| The same mistake returns | Put the repair in the actual form, tool, or check | Does the next use encounter and exercise the repair? |
| Stopping means losing your place | A short exit breadcrumb linked to evidence | Can tomorrow-you continue from it? |

## Start here: one small task card

Keep this in the project's existing task record. A prompt describes authority; actual tools and permissions must enforce consequential boundaries.

```text
Outcome: what useful result should exist?
Inputs: revision, relevant facts, dependencies, existing checks
Territory: files, environment, and shared resources this task may change
Authority: allowed actions and limits
Stop / budget: conditions that require stopping or a decision
Done when: observable result, evidence location, and who accepts it
```

For an ordinary read-only investigation, this can be a short paragraph. For a deployment, use the more complete records in templates.md.

## Ask for a useful re-entry view

```text
Read the current task and its linked evidence. Before changing anything,
show me:
- the task, working directory, revision, and last observation time;
- what changed since the last handoff;
- jobs still running and how to observe them;
- decisions or missing access that block the next action;
- the next useful action and the boundary it must stay inside.
Link the sources. Distinguish observed state from stale or unknown state.
```

A maintained Markdown page may be enough. If you repeat the same lookups, a small status helper can assemble them. Keep it read-only and make failures or missing observations visible.

## Leave a note to tomorrow-you

```text
Task / revision / checked at:
Changed + evidence:
Open uncertainty or failed check:
Next action + its authority boundary:
Still running: job identity, owner, observe/stop route (or none)
```

Illustrative example:

```text
Task / revision: service upgrade, candidate abc123
Changed: staging checks passed; evidence at evidence/upgrade-17/
Open: restore test has not run
Next: test recovery in the isolated staging environment
Authority: staging tests only; production change needs its execution grant
Still running: none
```

Update the current-work indicator when you stop. Keep older evidence and history; a fresh summary should link to them. If an action may have succeeded but its result was lost, write **outcome unknown** and inspect the target before retrying.

## Capture without turning everything into permanent instructions

```text
Inbox item: new source, question, or idea
Relevant task / evidence link:
Owner + next review point:
Disposition: use now / defer with reason / archive with a pointer
```

For a temporary reminder, add an expiry or review date: “Staging port differs during this migration; review Friday.” An expiry can remove temporary context from the active view; it does not itself schedule an alert or complete a review. It must not silently erase an unresolved obligation or grant continuing authority.

For ordinary questions, one reporter can collect: **decision needed, evidence, options/tradeoff, needed by, and what can proceed meanwhile**. Define separately what interrupts immediately: a changed target, an uncertain external effect, a failed recovery check, or another task-specific stop condition.

## Make the environment convenient to use correctly

Give a worker a named task, a known working directory, and an expected artifact. A setup helper can create separate working files and test state. A named long-running job should have matching logs and a reconnect route.

Check where each database, port, credential, and deployment target actually points. Separate branches and directories do not isolate all of them. Recovering a terminal does not by itself authorize restarting its previous job.

## Grow only when the next problem appears

- **One task:** versioned inputs, a clear assignment, an isolated environment, evidence, and a next-action note.
- **Several concurrent workers:** explicit shared-resource ownership, one current task view, a question queue, and enough review capacity to finish what comes back.
- **Long-running services:** scoped credentials, repeatable deployment checks, durable attempt identity, backups and tested restore, observation, and an independent operator route. Add transactional coordination or workflow machinery when claims, waits, and retries need it.

Ask each component: what problem does it solve, who maintains it, and how do we recover without it?

## Your experiment this week

```text
Project / task:
One repeated annoyance:
Habit I will try:
Boundary or check I will add:
Evidence that the next use improved:
When I will keep, change, or retire it:
```

Success is a useful task that someone can resume, review, and finish. Agent count is not the acceptance criterion.