# Drafting a plan

Describe what you want in plain language and the composer drafts a plan of real steps and real tools. It stays a draft until you keep it.

Source: https://opafra.com/docs/plans/composer

---

The composer turns a request written in plain language into a plan of real steps calling
real tools. It is a drafting surface, not a chat window: what it produces is a plan you
can read, edit, dry run and approve like any other.

## Write the request

Say what outcome you want and which hosts it applies to. The composer knows your
inventory, your environments and the [tool catalogue](/docs/reference/tools), so you do
not need to name tools yourself.

```text title="a request that works"
Roll out the new nginx config to the web tier in staging.
Back up the existing config first, validate before reloading,
and stop if validation fails.
```

That request carries the four things worth including:

- **The outcome**, not the commands
- **Which hosts**, by environment or by name
- **Ordering that matters**, such as backing up before changing
- **What should happen on failure**

A vaguer request still produces a plan; it just produces one you have to correct more.

## What comes back

A draft plan: named, described, with ordered steps, each targeting hosts and calling
tools with arguments. It can also create a script or a config template if the work needs
one, and reference it from the step that uses it.

Nothing has run. The draft is a plan sitting in front of you.

## The draft is not yet a plan

A draft is hidden until you keep it. It does not appear in your plan list, and any script
or config template created alongside it stays hidden too. Abandoning a draft leaves no
trace, so there is no cost to trying a request and discarding the result.

**Keep** promotes the draft and everything created with it into real, listed objects.

> **Important**
>
> The composer never executes anything. Drafting and running are separate actions, and the
> gap between them is where you read the plan, dry run it, and let an approver see it. A
> plan that arrives already running has skipped every one of those.

## Refining it

Ask for changes in the same place. The composer edits the draft surgically, adding a step,
changing targets, fixing an argument, rather than regenerating the whole plan from your
new sentence.

That matters more than it sounds. A plan you have already corrected twice does not lose
those corrections because the third request was phrased differently.

You can also edit the draft directly. The two are the same object, so a hand edit and a
subsequent request compose rather than fight.

## Starting from a template

Opafra ships starter plans for common jobs. Using one clones it into your workspace as a
normal plan, which you then edit like any other. The original is read-only and stays
available.

A template is often a better start than a blank request when the job is a common one,
because you are correcting something concrete rather than describing something abstract.

## What to do next with a draft

Read it before you run it. The composer is good at structure and ordinary at judgement,
and the [next page](/docs/plans/reviewing-a-draft) is about what to check.

Then [dry run](/docs/running/dry-run) it against the real hosts. That is the step that
turns "this looks right" into "this is what it would do to web-02".

## Next steps

- [Reviewing a draft](/docs/plans/reviewing-a-draft) for what to check, and what the composer gets wrong
- [Plan structure](/docs/plans/structure) for the parts you are reading