WCAG 2.2 audits, on request

Minitap integrations: GitHub, CI, Slack, tickets and MCP

mini works where your team works.

Findings land in your pull requests and Slack, and your tracker on request.

Book a demoEvery integration

Every integration, and how far it goes.

Code review and CI

  • GitHub

    Native

    A comment on pull requests to main, a check on every run.

    How far it goes

    Install the MiniTest GitHub App once. mini comments on every pull request to your main or release branches, with a box to tick to run the tests, and posts a check, Minitest (your app), on every run. Comment @mini test to start one, and mini asks on the pull request when it needs context. The check informs by default; turn on Block merge on failing tests and branch protection can require it.

    GitHub docs

  • GitHub Action

    Runs mini from any workflow, signed in with GitHub OIDC.

    How far it goes

    Starts a run from any workflow, signed in with GitHub OIDC. It uploads your build or asks mini to build the commit, and can wait for the verdict to hold a release. On a release tag it runs only the tests affected since the previous tag.

    GitHub Action docs

  • CLI, for any CI

    The CLI runs mini from GitLab CI, CircleCI, Jenkins or any CI.

    How far it goes

    The open-source minitest CLI starts runs, waits for them and reads every verdict as JSON, with a workspace API key. GitLab CI, CircleCI, Jenkins, Azure Pipelines and Bitbucket Pipelines run mini through the CLI.

    CLI, for any CI docs

  • GitLab and Bitbucket

    Connect and build

    mini builds and tests your repositories. Gate pipelines through the CLI.

    How far it goes

    Connect a GitLab group, self-hosted included, or a Bitbucket workspace. mini builds from your repositories and keeps the tests in step with your code. Comments and checks on pull requests are GitHub only; gate a pipeline through the CLI.

Where your team talks

  • Slack

    One message per run, and a thread per finding with its clip.

    How far it goes

    mini posts one message per run and edits it as the run goes. Each finding gets a thread with a clip of the failure and three buttons: Acknowledge, Not a bug, Resolved. Start runs with @mini run, and mini asks your team in the channel when it needs context or a test account.

    Slack docs

Tickets and specs

  • Notion

    mini reads your specs and PRDs, and writes tests from them.

    How far it goes

    Connect Notion and mini reads the specs and PRDs your team already wrote, and writes tests from them.

  • Jira

    On request

    Tickets with the steps to reproduce and the recording.

    How far it goes

    On request, mini files a Jira ticket from a failing test or a suggestion, with the report, the steps to reproduce and the recording, and reads your tickets and epics for context.

  • Linear

    On request

    Issues with the steps to reproduce and the recording.

    How far it goes

    On request, mini files a Linear issue from a failing test or a suggestion, with the steps to reproduce and the recording attached.

Coding agents

  • MCP server

    Your coding agent reads tests and results, and starts runs.

    How far it goes

    Your coding agent, in Cursor, Claude Code or Windsurf, signs in to mini’s MCP server. It can read and edit tests, test accounts and builds, start runs and read their results.

  • Fix prompts

    Copy a fix prompt from any failed criterion into your agent.

    How far it goes

    Every failed criterion has a Copy fix prompt button: the root cause, the steps to reproduce and a proposed fix, ready for your coding agent. The CLI ships a skill so the agent can run mini itself.

    Fix prompts docs

Hold a release on the verdict.

The Action signs in with GitHub OIDC, waits for the verdict and fails the step on a failing test.

GitHub Action reference
.github/workflows/release.yml
permissions:
  id-token: write

steps:
  - uses: minitap-ai/minitest-trigger@v1
    with:
      app-slug: shop
      wait-for-result: true
      fail-on-failure: true

Good questions.

The platformSecurity and data
Does mini block merges?

Not unless you ask it to. mini’s check informs by default. Turn on Block merge on failing tests for an app and the check fails when a test fails, so branch protection can require it. In a release workflow, the GitHub Action can wait for the verdict and fail the step.

Does mini run on every pull request?

No. mini comments on the pull request and waits: a run starts when someone ticks its box, comments @mini test, or your CI calls the Action or the CLI.

Which CI does mini work with?

GitHub Actions natively, through the minitap-ai/minitest-trigger Action. Any other CI, from GitLab CI and CircleCI to Jenkins, Azure Pipelines and Bitbucket Pipelines, runs mini through the open-source CLI with a workspace API key, and reads the verdict as JSON.

Can mini run on a schedule?

Not on its own yet. Run it nightly from your CI instead: a scheduled GitHub Actions workflow that calls the Action, or a cron job that calls the CLI.

Do GitLab and Bitbucket get comments and checks?

No. Connect them and mini builds from your repositories and keeps the tests in step with your code. Comments and checks on pull requests are GitHub only, so gate a GitLab or Bitbucket pipeline through the CLI.

How do we get tickets from mini?

On request. Ask us and we switch ticketing on for your workspace: mini then files Jira or Linear tickets from a failing test or a suggestion, with the report, the steps to reproduce and the recording.

What does mini get access to?

On GitHub, the repositories you pick when you install the MiniTest GitHub App. In Slack, mini joins your public channels, posts each run to the channel you pick, and anything done from Slack runs as the person’s own Minitap account and role. The CLI and the MCP server use a workspace API key or your sign-in.

See it in your own tools.

Bring a build. We run mini on it, and the finding lands in your tools.

Book a demoSee a real report