# Korium:Workflow

A proposal is not finished because an assistant wrote a document. Someone has to check the scope, challenge the assumptions and approve the commitments. A workflow makes those steps explicit and keeps the work moving toward a result you can use.

## Give every part a job {#parts}

Memory provides the client history and earlier decisions. Skills provide methods such as reviewing scope or synthesizing research. A workflow puts those methods in order, defines the outputs and says where someone needs to review or decide.

Korium:Code joins in when the work requires finding an implementation. It is useful in an engineering review, but a meeting summary does not need a code index. Choose the parts the job actually uses.

## Choose a playbook for the outcome {#choose}

Ask the assistant to inspect the workflow catalog with `bottega_config`:

```
{
  "schema_version": "1"
}
```

The response includes `platform_playbooks`, with names, versions and hashes, alongside your workspace’s team and flow configuration. This is a catalog read, not a command to start work. Select a playbook by the result you need, then read its actual instructions.

<div class="table-scroll"><table><thead><tr><th>You need to</th><th>Look for</th><th>Bring to the task</th></tr></thead><tbody><tr><td>Prepare a client proposal</td><td>Proposal and SOW</td><td>Agreed scope, discovery notes, constraints and a reviewer.</td></tr><tr><td>Turn a meeting into usable follow-up</td><td>Meeting Minutes</td><td>The authorized transcript, attendees and a way to verify decisions.</td></tr><tr><td>Review an account with the team</td><td>Account Plan</td><td>Account history, agreed goals, open issues and current evidence.</td></tr><tr><td>Explain an engineering decision</td><td>ADR Generation</td><td>The problem, alternatives, tests and relevant code.</td></tr></tbody></table></div>

These names come from the Korium catalog. Read the selected playbook’s inputs and review points before beginning; the table is a starting checklist, not a substitute for its instructions.

## Load the instructions, not just the name {#load}

The catalog response does not contain the playbook files. The Tinker installer and `tinker_get_skill` load the versioned bundle. Follow the [registry loading steps](skills.html#catalog) to resolve the release, fetch its manifest and files, and check its receipt.

Use the exact namespace and version returned by the registry. A catalog slug is not permission to guess the bundle’s namespace. If the loader cannot retrieve the release, stop and resolve that failure rather than improvising a workflow from its title.

The assistant runs the loaded instructions using the tools and permissions available in that session. Fetching a bundle does not send a proposal, create a meeting or approve a release. Those actions still need the authority and checks defined for the task.

## Follow one proposal through the work {#example}

This is an illustration of how you could adapt a proposal workflow. It is not a customer result or a promise that every catalog playbook uses these exact steps.

1. **Agree on the assignment.** Name the client, the deliverable, the inputs and the person who will approve commercial commitments.
2. **Read what is already known.** Search Korium for agreed scope, rejected options and lessons from earlier work. Check the sources and any corrections.
3. **Resolve the gaps.** Ask about missing scope or an unconfirmed deadline. Don’t turn an assumption into a commitment to make the document look finished.
4. **Draft and review.** Apply the proposal skills, then check the draft against the evidence. Return specific issues and proposed changes to the reviewer.
5. **Approve and hand off.** Record what was approved and what remains open. Sending the proposal is a separate action, not something implied by finishing a draft.
6. **Keep what changed.** Save new approved decisions and useful lessons, including their sources. Check the capture receipts so the next task can find them.

The result is the proposal plus a clear handoff. Memory keeps why the scope changed, not simply a note that a file was created.

## Give the assistant a bounded first run {#start}

```
Find the Proposal and SOW playbook available to this workspace.
Show the release you selected and load its instructions.
Use the discovery notes I supplied and search Korium for the
client's agreed scope and previous decisions.
Tell me what is missing before drafting. Do not invent prices,
deadlines or approvals. Stop at a reviewable draft; do not send it.
After my review, propose the decisions and lessons worth saving.
```

Replace the example with your real assignment and authorized sources. If a person has not approved something, leave it pending. The workflow should make missing decisions visible, not hide them behind a confident answer.

## Keep the improvements for the next run {#reuse}

When a review finds a missing check, improve the workflow and record why. Keep the changed version with its test example, rather than silently changing the instructions halfway through another run. Separate a proposed improvement from the version the team agreed to use.

Use the [instructions and hooks guide](make-it-automatic.html) for repeatable read/write habits. A hook can remind or invoke a specific step, but it is not proof that a whole workflow finished. Verify the output, the approvals and the saved learning separately.