Browse the documentation
Give every part a job
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
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.
| You need to | Look for | Bring to the task |
|---|---|---|
| Prepare a client proposal | Proposal and SOW | Agreed scope, discovery notes, constraints and a reviewer. |
| Turn a meeting into usable follow-up | Meeting Minutes | The authorized transcript, attendees and a way to verify decisions. |
| Review an account with the team | Account Plan | Account history, agreed goals, open issues and current evidence. |
| Explain an engineering decision | ADR Generation | The problem, alternatives, tests and relevant code. |
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
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 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
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.
- Agree on the assignment. Name the client, the deliverable, the inputs and the person who will approve commercial commitments.
- Read what is already known. Search Korium for agreed scope, rejected options and lessons from earlier work. Check the sources and any corrections.
- 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.
- Draft and review. Apply the proposal skills, then check the draft against the evidence. Return specific issues and proposed changes to the reviewer.
- 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.
- 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
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
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 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.
Use the setup checklist before changing an automated workflow. Check your installed client’s help if its interface differs.