Shipfox

Task to pull request

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

Another workflow sends a task, or you assign the agent to a Linear issue

How it works

  1. The agent gets a tasktriggerAnother workflow, such as a Slack dispatcher, sends the task with its acceptance criteria. Optional: assign the agent to a Linear issue, mention it, or add a label.
  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 draft pull requestwriteThe starting workflow reads the PR link or the questions of the agent. With Linear, the workflow also comments on the issue.
  5. You review and merge the pull requesthumanOptional: the agent replies to inline review comments and fixes failed CI.

What it writes

  • GitHub
    • Pushes a branch and opens a draft pull request
    • Replies to review threads and resolves them (feedback loop only)
  • Linear
    • Comments on the issue and can change its status (optional)

Before you start

  • Connect GitHub.
  • Run CI on GitHub Actions to use the feedback loop.
  • To start from Linear issues, connect Linear.

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.
  • Should the agent respond to inline review comments and failed GitHub Actions runs on its pull request?Default: Stop after opening the PR1 other choice
    • Stop after opening the PRDefaultA person handles later feedback.
    • Respond to feedbackEach 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.
  • When the agent responds to review comments, should it resolve the threads it handled?Default: Resolve handled threads1 other choice
    • Resolve handled threadsDefaultResolves a thread once its fix is pushed or it was already handled. Reviewers can reopen it.
    • 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.
  • What should the workflow write to the ticket?Default: Comment with the pull request2 other choices
    • Comment with the pull requestDefaultPosts one comment with the PR link, or the agent's questions when the ticket is unclear.
    • Comment and change statusAlso moves the ticket to a chosen status after the PR opens.
    • Do not write to the ticketThe ticket gets no PR link, questions, or status change.

Models

  • fixtested with gpt-6-luna · high thinkingImplements the task and handles review comments and CI failures in one conversation.
  • replytested with gpt-6-sol · 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