← All use cases

Engineering

github · pull_request.opened

A reviewer on every pull request.

A workflow reads each diff against your conventions and leaves a real review. A second workflow on a schedule posts the week's merged work, review backlog, and CI health.

Get started free
See the templates

5,000 free credits to start.

How it works

Three steps to a workflow

  1. Step 01

    Teach it your conventions

    Point the agent at your contributing guide and let it read recent reviews. It learns what your team comments on.

  2. Step 02

    Add a GitHub trigger

    Run the reviewer on pull_request.opened and pull_request.synchronize. Filter by base branch. Add a label filter to opt pull requests in one at a time.

  3. Step 03

    Read the review, then the weekly digest

    The agent posts inline comments where they belong. A second workflow on a Friday schedule posts the digest to your engineering channel.

The run

What one run looks like

Each line is a tool call. The agent finds the API it needs, reads the result, and acts. The full transcript stays on the run.

github · pull_request.opened

Review new pull requests against our conventions and leave inline comments.

  1. github·fetch the diff for PR #2841
  2. github·read CONTRIBUTING.md and recent reviews
  3. code·run the linter over the changed files
  4. github·post a review with 3 inline comments
  5. slack·notify the author in #eng

Review posted on PR #2841

  • Flagged an unhandled error path in `sync.ts:142`
  • Suggested reusing `parseCursor` instead of a second parser
  • Confirmed the migration is backward compatible
  • Author notified with a link to the review

Integrations

The tools this workflow uses

Connect each one once. The agent gets its full API, and the credential stays at the network layer.

FAQ

Questions, answered

Put a workflow on pull request review.

Write the prompt, pick the trigger, and read the first run.

Get started free
Read the docs