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, so you do not need to name tools yourself.
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.
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 is about what to check.
Then 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 for what to check, and what the composer gets wrong
- Plan structure for the parts you are reading