Get started

Your first job

Start with one bounded result. Four steps, and one successful run teaches the operating pattern for everything after it.

  1. 01Name the resultState what should exist or change when the run is complete. An artifact, a system state, or both.
  2. 02Connect the workAttach the source files and authorize only the systems the job requires. Fewer connections make the first run easier to review.
  3. 03Define proof and authoritySay what Opulent may change, how completion is checked, and which decisions require a person.
  4. 04Inspect the outcomeOpen the artifact, review the evidence and the exceptions, then accept or revise.

One successful run teaches the operating pattern. When the same result and completion test stay valid, package the method and decide whether it should run from a schedule or an event.

Choosing the first job

The right first job has a clear owner, a repeatable finish, and a proof object your team already knows how to review. Narrow enough that another person can tell whether it finished, and real enough that finishing it is worth something.

  • Turn a research question into a cited brief with an unresolved-claims section.
  • Reconcile two exports and return a checked workbook.
  • Fix a bounded bug and open a tested pull request.
  • Produce a weekly metrics pack from known systems.
  • Update a document and return both the final file and a redline.
  • Walk a product flow and return a short recording with failures marked.

Before the run starts, write down what you expect to inspect at the end. That one habit makes the prompt, the plan, the verification, and the review all more concrete.

A worked example

A finance team wants July invoice exceptions cleared. The vague version is "clean up our invoice backlog". The version a run can finish and a person can check:

Match every July invoice to its purchase order and receipt.

Hold anything outside a 2% tolerance and route it to me with
the match attached. Treat the ERP as the system of record.
Do not change a payment status without asking.

Return a workbook of matched invoices, a list of held
exceptions with the variance on each, and a note of anything
you could not resolve.

That request names the outcome, the boundary, the tolerance, the system of record, the approval gate, and the three things the reviewer will open. It can be checked by someone who did not write it.

What to expect from the first run

The first run of a new workflow usually surfaces missing context rather than missing capability. A source nobody named, a rule that lived in someone's head, an exception category the request did not anticipate. That is the run working correctly: it found the gap before the gap became a wrong write.

Resist the urge to fix the first run by making the prompt longer. Decide which layer the correction belongs in, then put it there. Stable facts belong in Knowledge, procedures belong in a Skill, and one-time exceptions belong in the run and nowhere else.