Overdesk Docs

Appearance

Creating issues from a conversation ​

When a customer reports a bug your engineers need to see, you can turn the conversation into an issue on GitHub, Linear or Jira without retyping it. Overdesk suggests a title and description from what the customer wrote. You edit them, check where the issue is going, and confirm.

Before you start ​

Open an issue ​

  1. Open Agent drafts and open the draft for the conversation.
  2. In the Engineering card, click Open an issue. Overdesk reads the conversation and fills in a suggested title and description.
  3. If more than one tracker is available, choose one under Tracker. If that tracker has more than one repository, team or project connected, choose where the issue goes.
  4. Edit the Title and the Description. The title can be up to 250 characters.
  5. Read the line under the description, which says who will be able to read the issue.
  6. Click Open the issue. A link to the new issue appears in the card.

Where the suggestion comes from ​

Overdesk writes the suggestion from the customer's own messages, not from your team's replies or internal notes, so it describes the problem rather than an answer someone proposed. It runs on your Anthropic API key and is told to leave out anyone's name, email address, phone number or license key, and to call the person "a customer". If no key is saved, or the model does not answer, the form starts from the conversation's subject and the customer's words instead.

For conversations from Help Scout, Zendesk and FreeScout, a link back to the conversation in your help desk is added at the end of the description, so an engineer can find it. That link opens only for people with access to your help desk.

The form's own hint says it plainly: "Written by Overdesk from the conversation, so edit it before you post. Email addresses, phone numbers and card numbers are removed on the way out; names and links are not." That removal runs on the text you actually submit, including anything you typed yourself.

Public repositories ​

When the chosen GitHub repository is public, the form warns you before you post. For a repository named your-org/your-repo, it reads:

your-org/your-repo is public. Everything above will be readable by anyone, and searchable, from the moment you post it. Check it says nothing about the customer you would not publish.

For a private repository, and for any Linear team or Jira project, the line says instead that anyone with access to it will be able to read the issue.

One issue per conversation on each tracker ​

Each conversation can produce one issue on each tracker. Once it has, the card shows a link to that issue, and opening another on the same tracker has to be done in the tracker itself. Clicking twice, or two people clicking at once, does not open a second issue: the later click either gets the first issue's link or is told the issue is already being created.

When something goes wrong ​

If the tracker refuses, Overdesk says what to change, such as a permission on the token or a field a Jira project requires. If Overdesk cannot tell whether the tracker created the issue, it says that too. Check the tracker before you try again, so you do not end up with two.