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

# Team Usage

> Ideal workflow for using Tusk as a team

## Workflow for Engineers

1. Product Manager (PM) creates a ticket in their ticketing software with a detailed description and assigns it to an engineer.
   * The [Actual and Expected Results](https://medium.com/we-are-testers/chapter-2-how-to-write-useful-actual-and-expected-results-details-in-your-bug-report-10b83e5aaa75) or [Given-When-Then](https://www.agilealliance.org/glossary/given-when-then/) formats are good ways to prompt Tusk.
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 tests 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.
   * The [Actual and Expected Results](https://medium.com/we-are-testers/chapter-2-how-to-write-useful-actual-and-expected-results-details-in-your-bug-report-10b83e5aaa75) or [Given-When-Then](https://www.agilealliance.org/glossary/given-when-then/) formats are good ways to prompt Tusk.
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 tests the PR on a preview environment.
6. PM assigns the ticket to an engineer.
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. 🎉