Skip to main content
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. Reading is the default; writing back happens only when the person asks for it. This is the loop that works well.
1

Find the work

Start from list_documents (optionally narrowed by a folder from list_folders), or from a pasted share link via get_document_by_share_url. Then open the document with get_document — it returns the document, its folder, its latest generation status, and the visible tickets in order.
2

Read the full spec before implementing

List views omit ticket bodies. Call get_ticket for each ticket you are about to work on — the body field is the markdown implementation spec.Then fetch 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 returns the narration; treat it as supporting context, the tickets remain the spec.
3

Clarify before guessing

If a ticket is ambiguous or underspecified, ask the person clarifying questions first instead of implementing a guess. If they want the clarified scope written back onto the ticket, they will say so — then, and only then, record it with update_ticket.
4

Implement, then report in conversation

Tell the person what you built in the conversation. Do not write progress into Montra: there is no ticket status to set, and rewriting a title or body to say “implemented” or ”✅” overwrites the person’s spec. The one write you should make without being asked separately is link_ticket_issue: whenever the person asks you to create a Linear or Notion issue from a ticket, record the link as part of that export so the Montra ticket points at the downstream issue.

​
Rules of the road

  • Writes are opt-in. Call create_ticket, update_ticket, delete_ticket, create_document, or update_document only when the person explicitly asks for that change in the conversation — never on your own initiative, and never to mark work done. link_ticket_issue is the exception: it is part of any export the person asked for.
  • Overwrites are total. update_ticket and 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 (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 reads as not found. Share links are the one deliberate exception.
  • Deletes are soft. delete_ticket removes the ticket from the document but it stays recoverable from the Montra app.