​
Workflow for Engineers

  1. Product Manager (PM) creates a ticket in their ticketing software with a detailed description (Given-When-Then formula works well) and assigns it to an engineer.
  2. Engineer sees Tusk’s comment on the ticket which says that Tusk may be able to complete it.
    • If more context is required, the engineer adds details to the ticket description as prompted by Tusk’s clarifying questions
  3. Engineer adds the Tusk label to the ticket.
  4. After Tusk creates a PR, the engineer receives a GitHub / Jira / Linear / Notion notification.
    • If Tusk self-determines that its changes aren’t satisfactory, it will instead create a branch and leave engineering advice on the ticket as a jumping-off point
  5. Engineer reviews the PR on a preview environment.
  6. If the changes look right, the engineer approves the PR.
    • If the PR is not entirely correct, they 1) request changes from Tusk via a PR review, or 2) checkout the branch to make changes manually
    • If the PR is directionally wrong, they close the PR with a comment and un-assign themselves from the ticket. Tusk will learn from this for future tasks.
  7. Engineer merges PR after it is approved. If you have Jira, Linear, or Notion’s GitHub integration set up, this will change the ticket status to “Done” automatically. 🎉

​
Workflow for PMs

  1. PM creates a ticket in their ticketing software with a detailed description (Given-When-Then formula works well).
  2. Tusk leaves a comment on the ticket saying that it may be able to complete it.
    • If more context is required, PM adds details to the ticket description as prompted by Tusk’s clarifying questions
  3. PM adds the Tusk label to the ticket.
  4. After Tusk creates a PR, the PM receives a GitHub / Jira / Linear / Notion notification.
    • If Tusk self-determines that its changes aren’t satisfactory, it will instead create a branch and leave engineering advice on the ticket as a jumping-off point
  5. PM assigns the ticket to an engineer.
  6. Engineer reviews the PR on a preview environment.
  7. If the changes look right, the engineer approves the PR.
    • If the PR is not entirely correct, they 1) request changes from Tusk via a PR review, or 2) checkout the branch to make changes manually
    • If the PR is directionally wrong, they close the PR with a comment and un-assign themselves from the ticket. Tusk will learn from this for future tasks.
  8. Engineer merges PR after it is approved. If you have Jira, Linear, or Notion’s GitHub integration set up, this will change the ticket status to “Done” automatically. 🎉
Browser TestingLimitations