Shipfox

Task to pull request

Turn a ticket or a request into a tested GitHub pull request.

An agent sends a task, or a ticket is ready in Linear, Jira, ClickUp, or GitHub

How it works

  1. The agent gets a tasktriggerYour coding agent or another workflow, such as a Slack dispatcher, sends the task with its acceptance criteria. With a tracker, a ready ticket starts it too, from a label, a tag, a status, an assignment, or a mention of the Shipfox agent.
  2. The agent changes the codeagentIt reads the task and the repository. Then it makes the smallest change, or asks questions when the task is unclear.
  3. The workflow runs your testscheckIf a test fails, the workflow sends the log to the agent.If this step fails, the workflow goes back to “The agent changes the code”
  4. The workflow opens a task pull requestwriteThe task pull request holds the code change, as a draft by default. The starting workflow reads its link or the questions of the agent. With a tracker, the workflow also comments on the ticket.
  5. You review and merge the task pull requesthumanMerging it ships the change. With the feedback loop, the agent also replies to inline review comments and fixes failed GitHub Actions runs.

What it writes

  • GitHub
    • Pushes a branch and opens a task pull request, as a draft by default.
    • With the feedback loop, pushes fixes, replies to inline review comments, and can resolve addressed threads.
    • With a tracker, comments on the ticket and can set its in-progress status, or an in-progress label on GitHub, unless ticket updates are off.

Before you start

  • With ClickUp, connect a dedicated service account that can see every Space, Folder, and List the workflow watches.

Choices you make

When you set up this workflow, your coding agent asks you these questions. The workflow file on this page uses the default answers.

  • What should start the workflow?Default: Assign or mention the Shipfox agent1 other choice
    • Assign or mention the Shipfox agentDefaultStarts when the Shipfox agent is assigned to or mentioned on an issue in the chosen Linear team.
    • Add a Linear labelStarts when an issue in the chosen Linear team is created with the label or gets it later. Requires the label's exact name.
  • What should start the workflow?Default: Add a Jira label1 other choice
    • Add a Jira labelDefaultStarts when an issue in the chosen Jira project is created with the label or gets it later. Requires the label's exact name.
    • Move the issue to a statusStarts when an issue in the chosen Jira project moves to the status. Requires the status's exact name. Issues created directly in that status do not start it.
  • What should start the workflow?Default: Add a ClickUp tag1 other choice
    • Add a ClickUp tagDefaultStarts when a task in the chosen List gets the tag. Requires the tag's exact name.
    • Move to a ClickUp statusStarts when a task in the chosen List moves to the status, including a task created in it. Requires the status's exact name.
  • What should start the workflow?Default: Add a GitHub label1 other choice
    • Add a GitHub labelDefaultStarts when an open issue in the project's repository gets the label. Anyone who can label issues can start a run.
    • Assign a GitHub userStarts when someone assigns an open issue in the project's repository to the chosen user, such as a machine user. GitHub cannot assign an issue to a GitHub App.
  • Should the workflow handle inline review comments and failed GitHub Actions runs after opening a PR?Default: Handle PR review comments and CI failures1 other choice
    • Stop after opening the PRA person handles later feedback.
    • Handle PR review comments and CI failuresDefaultEach batch of inline review comments or failed GitHub Actions runs starts another execution until the PR closes. Review summaries, PR conversation comments, and other CI providers are not handled.
  • Should the workflow resolve addressed inline review threads?Default: Resolve addressed threads1 other choice
    • Resolve addressed threadsDefaultResolves threads after fixes are pushed or comments are confirmed as already handled. Reviewers can reopen them.
    • Leave threads openReviewers resolve every thread themselves.
  • How should the pull request open?Default: Draft1 other choice
    • DraftDefaultSomeone marks the PR ready before review.
    • Ready for reviewOpens the PR for review right away, which can notify reviewers.
  • How should the workflow update the ticket?Default: Comment and set in-progress status2 other choices
    • Comment onlyPosts the PR link, or clarification questions when needed.
    • Comment and set in-progress statusDefaultMoves the issue to its in-progress status when work starts; posts the PR link or clarification questions. On GitHub, adds an in-progress label.
    • No updatesMakes no ticket updates.

Models

  • fixtested with gpt-6-luna · max thinkingImplements the task and handles review comments and CI failures in one conversation.
  • replytested with glm-5.3-flash · low thinkingPosts prepared review replies and resolves threads.

When you set up this workflow, your coding agent suggests models that your workspace can use. You choose the model for each step.

Related examples

Was this page helpful?
Edit this page on GitHub