> ## Documentation Index
> Fetch the complete documentation index at: https://docs.montra.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent workflow

> The recommended loop for implementing Montra tickets and reporting progress back.

Montra documents are built from screen recordings: a person narrates what they want while pointing at real UI, and Montra turns that into tickets whose bodies are markdown implementation specs. The connector gives an agent everything the person captured — and a way to report progress back. This is the loop that works well.

<Steps>
  <Step title="Find the work">
    Start from [`list_documents`](/tools/list-documents) (optionally narrowed by a folder from [`list_folders`](/tools/list-folders)), or from a pasted share link via [`get_document_by_share_url`](/tools/get-document-by-share-url). Then open the document with [`get_document`](/tools/get-document) — it returns the document, its folder, its latest generation status, and the visible tickets in order.
  </Step>

  <Step title="Read the full spec before implementing">
    List views omit ticket bodies. Call [`get_ticket`](/tools/get-ticket) for each ticket you are about to work on — the `body` field is the markdown implementation spec.

    Then fetch [`get_ticket_images`](/tools/get-ticket-images) and actually look at the images. They are real UI captures the person marked up while recording — arrows, boxes, and notes are instructions, not decoration. For surrounding intent, [`get_transcript`](/tools/get-transcript) returns the narration; treat it as supporting context, the tickets remain the spec.
  </Step>

  <Step title="Clarify before guessing">
    If a ticket is ambiguous or underspecified, ask the person clarifying questions first instead of implementing a guess. Once resolved, record the clarified scope on the ticket itself with [`update_ticket`](/tools/update-ticket) so the spec stays true.
  </Step>

  <Step title="Implement, then report back">
    As soon as a ticket is finished, call [`set_ticket_status`](/tools/set-ticket-status) with `done` — that is how progress reaches the person who recorded it. If you exported the ticket to Linear or Notion, record it with [`link_ticket_issue`](/tools/link-ticket-issue) so the Montra ticket links back to the downstream issue.
  </Step>
</Steps>

## Rules of the road

* **Overwrites are total.** [`update_ticket`](/tools/update-ticket) and [`update_document`](/tools/update-document) replace each field you pass outright — send the complete new text, never a fragment or a diff. Fields you omit are untouched.
* **Edits are protected.** Ticket writes made through the connector are flagged as manual edits, so a later background generation will not silently overwrite them.
* **Signed URLs are short-lived.** Image and media URLs from [`get_ticket_images`](/tools/get-ticket-images) (and member-resolved share links) expire — fetch them while working the ticket rather than storing them.
* **Scope is the bound workspace.** Anything outside the workspace chosen at [consent](/authentication#workspace-binding) reads as not found. Share links are the one deliberate exception.
* **Deletes are soft.** [`delete_ticket`](/tools/delete-ticket) removes the ticket from the document but it stays recoverable from the Montra app.