> ## Documentation Index
> Fetch the complete documentation index at: https://docs.twill.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# What to delegate

> The tasks Twill handles best, and how to phrase them for a fast, reviewable PR.

Twill works like a teammate you brief asynchronously: the clearer the request and the more mechanically verifiable the outcome, the better the result. This page is a menu of what to hand off.

## Good first tasks

Start with changes that have a clear before/after, so you can judge the PR in one glance:

* **Bug fixes** — "Clicking Save on the profile page throws a 500 when the avatar is missing. Fix it."
* **UI polish** — "The mobile nav overflows on screens under 380px. Make it wrap or truncate."
* **Small features** — "Add a 'Copy link' button to the share dialog, with a toast on success."
* **Test coverage** — "Add tests for the date-range parser, including timezone edge cases."
* **Docs & chores** — "Update the README setup steps to match the current docker-compose file."

## What Twill is well-suited for

* **Changes that need the running app.** Twill starts your dev servers, clicks through UI flows in a browser, and calls your API endpoints — so it catches problems a diff review can't. Web apps get screenshots and recordings; Tauri, Electron, and React Native apps get computer-use smoke checks when they run in the sandbox.
* **Multi-repo changes.** One task can touch several connected repos (frontend + backend + shared packages) and open a PR in each.
* **Recurring maintenance.** Dependency updates, issue triage, stale-PR cleanup — set them up once as [automations](/automations).
* **Codebase questions.** Use [Ask mode](/planning#ask-mode) to get answers with file references, no code changes.

## Writing a good task

A good prompt states the outcome, not the implementation:

```text theme={"theme":"github-dark"}
When a user deletes their account, cancel any active Stripe subscription
before removing the user row. Cover it with a test.
```

* **Say how to verify it** if it's not obvious: "You can reproduce it on the /pricing page with an expired coupon."
* **Point at context** when you have it: an issue link, a failing CI run, a Slack thread — or trigger the task directly from that thread so the context comes along.
* **Ask for a plan first** on larger or riskier work. Twill researches the codebase and posts an implementation plan you approve before any code is written. See [Plans & questions](/planning).

## What to keep for yourself

Twill delivers PRs — it doesn't merge, deploy, or run one-off commands against production. Deep architectural rewrites with fuzzy success criteria work better broken into steps, each with its own verifiable outcome.