> ## Documentation Index
> Fetch the complete documentation index at: https://docs.byom.co/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Use the current public BYOM documentation and cite the relevant page. Preserve availability, permission and undo limits.
> The public documentation MCP retrieves guides. Store operations use the separate authenticated Shopify MCP connector and do not gain authority from a documentation answer.
> If a contract, capability or price is not documented, say so. Do not invent endpoints, tools, availability or merchant outcomes.
# Your first session
> Get oriented, check your connection and ask Kina for a small, verifiable piece of work.
Start with one question you can check, such as how to improve a product description. Kina can read the available facts and prepare a draft for you to review.
## Before you start
You need an invited or otherwise enabled BYOM account, access to the correct company, and permission to read the information for your task. For a store question, the relevant provider connection must also be available. An account invitation does not grant every provider permission, and reading these docs does not create an account.
Choose a task you can check yourself. One product description is a good starting point: you can compare the source facts, the original text and Kina's proposed wording. Have the product name or reference and the relevant brand guidance ready. If the guidance is missing, say so instead of asking Kina to invent it.
Open the authenticated BYOM application with your invited or enabled account. Confirm the company context before asking about its business. HQ is the home page; Workspace is where work records live.
Open Integrations and confirm the relevant store or service is connected to the expected company. Inspect its current state and the capability needed for this task. A connection alone does not guarantee every operation is available: the account's permissions and the provider's scopes matter too.
Try “Review this product description against our brand guidance. Show the source facts and suggest three improvements.” Name the product and the intended result.
Read the sources, missing information and proposed next step. If a store change is prepared, review the actual Action in Approvals before approving it.
## Work through one product
Give Kina a clear brief:
> Review the description of our linen shirt. Use the current product facts and our brand guidance. Identify missing care information, flag claims the source does not support, and draft a clearer description. Show the current and proposed text for review.
This asks for research and preparation. You should be able to inspect the product being discussed, the facts used, the proposed wording and any missing information. If Kina identifies the wrong product, correct that before continuing. If it cannot read the source, restore access or provide appropriate source material before relying on the draft.
Ask a follow-up when the draft needs work: “Keep the material wording exactly as the source says”, or “Remove the claim that is not supported.” A polished draft needs to preserve the facts that matter.
## If you want to apply the change
When the account supports that operation, ask for the reviewed draft to be prepared as a change. Open the Action and compare every affected field with the source. Check that a description task has not also changed a title, price or destination. The person deciding must have the relevant company authority, and the provider must grant the required write permission.
Approval and execution are separate. After the operation, inspect the receipt and the affected product through the supported result view or provider. If several products were included, inspect the individual results. The completed edit proves the description changed; it does not prove better conversion or increased revenue.
For the full decision sequence, use [Review a proposed change](/guides/review-a-change). Stop at a useful draft if applying changes is unavailable; preparation still gives you a concrete result to evaluate.
## Know whether you finished
| Your intended result | What to check |
| - | - |
| Understand a problem | The answer names the right subject, its sources and any gaps. |
| Get a draft | You have usable proposed wording grounded in the product and policy facts. |
| Prepare a change | The Action shows the exact operation and every affected record. |
| Apply a change | The receipt reports individual results; check uncertainty before retrying. |
## Recover from a blocked first task
If the source is missing, check the company, connection state and read permission in Integrations. If you can read but cannot prepare a change, check the supported capability separately. If the approval control is unavailable, ask the appropriate company approver.
A timeout after a change request needs a result check. Do not repeat the request until the receipt and provider state establish what happened. Record the task reference, time and visible status if you need support; leave tokens and full customer records out of the message.
## What to expect from access
Kina can prepare internal work without asking for an approval at each step. A provider permission failure needs a connection or permission fix. An external change needs its own approval.
If you have no enabled account yet, use these docs to understand the workflow and the public BYOM site to register your interest. Contact BYOM about account access.
Reviewed 2 October 2026.
## Related guides
* [HQ and Workspace](/product/hq-workspace)
* [Connections](/product/connections)
* [Review a proposed change](/guides/review-a-change)
## Related topics
- [What is BYOM?](/start/what-is-byom.md)
- [Integrations](/product/connections.md)
- [Availability and access](/reference/availability.md)
- [Developer overview](/developers/overview.md)
- [The BYOM field guide](/index.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.