Projectrr

Integrations

Projectrr connects to the places your work already happens. GitHub and Sentry connect once per organization and can be shared between organizations; what each product tracks — which repositories, which Sentry projects — is set per product. Trello credentials live on the product itself.

GitHub

Link repositories to a product and Projectrr ties code back to issues.

What you get

  • Commits and pull requests that mention an issue key (WEB-14) are linked to that issue. The prefix is the project’s key and must be uppercase
  • WEB #14 works too, as long as WEB is a real project prefix in the same product. Both spellings mean the same issue, so a title reading test: pin the WEB #14 N+1s links like WEB-14 does. The prefix and the # must be on the same line — a prefix ending the title does not bind to a #14 opening the body
  • A bare #14 is read as a GitHub number rather than an issue key. On commits and releases it still links whatever issues that pull request references, so a squashed (#266) in a release note reaches the right issues. On a pull request it does not
  • A #14 is read as an issue key only when the prefix in front of it is one of the product’s own, and it is then never also read as GitHub number 14
  • PR #266 always stays a GitHub number. PR is reserved from this spelling, so release notes keep resolving their pull requests even in a product that happens to have a project prefixed PR — write PR-266 to reach that project’s issue instead
  • A pull request’s links track its current title and body. Edit a key out and the issue is unlinked; change it to a different key and the link moves. A commit or release keeps what it referenced, because its text does not change
  • Releases cut from linked repos are tracked, with the issues that shipped in them
  • Workflow rules can fire on push, PR opened, PR merged, PR closed and release published
  • Rules can create GitHub issues from Projectrr issues, and push status changes outward

Setting it up

  1. Open your organization’s settings, go to GitHub and choose Install GitHub App (a product’s GitHub Integration tab has the same button, if you are already there).
  2. Pick the account or organization to install on, and grant either all repositories or a selection of them.
  3. GitHub sends you back to Projectrr, which lists everything the installation grants.
  4. Open the settings of the product that should track a repository and hit Link next to it under Available to link on the GitHub tab. Repositories belong to a product, so this step is per-product even though the installation is not.
  5. A repository no installation grants can still be added with Link manually — it links, but nothing syncs until an installation covers it.

An installation belongs to the organization, not to one repository, so you can install once at the org level and link repositories whenever you like — before or after. Repositories linked later pick up the installation automatically. Disconnect on an installation releases Projectrr’s claim on it and unbinds its repositories; uninstalling the app on GitHub does the same thing, from the other end.

One installation can serve several Projectrr organizations. If your GitHub account hosts the work of more than one of them, open the second organization’s GitHub settings and use Connect under “Available from your other organizations” — do not use Install, because GitHub allows one installation per account and it is already installed, so it has nothing to do and will not send you back. Anyone who can manage integrations in an organization that already holds it can connect it to another. Disconnecting affects only the organization you do it from.

Connecting an installation nobody has yet is different, because holding one is what lets Projectrr act on those repositories: for the first half hour after it is created anyone who can manage integrations can connect it, and after that only the GitHub account that ran the install can. So if you installed from GitHub directly rather than from the button here, come back and connect it while it is fresh — or sign in with that GitHub account.

From the CLI:

prr repo link starkey-digital/projectrr --product=<productId>
prr repo list --product=<productId>
prr release sync --product=<productSlug>

Trello

Two-way sync between a Trello board and a Projectrr project.

What you get

  • Cards become issues, and issues become cards
  • Trello lists map to your project’s statuses, so moving a card moves the issue and vice versa
  • New comments travel both ways between an issue and its card (edits and deletes do not sync)
  • Existing boards can be imported in one go
  • Changes arrive by webhook, with a scheduled poll as a safety net for anything a webhook missed. The poll only acts on a card whose list or name differs from what Trello last showed — so a move made in Projectrr stays put even if the card never followed it

Setting it up

  1. Get a Trello API key and token, and save them against the product.
  2. Link a board to a project.
  3. Map each Trello list to one of the project’s statuses. A status with no list leaves its cards wherever they were — create-list adds the missing list to the board, maps it, and moves that status’s cards onto it.
  4. Import the cards already on the board.

A project syncs with one board. Linking a second one is refused — unlink the current board first, which also removes its webhook.

From the CLI:

prr trello connect --product=<productId> --key=<key> --token=<token>
prr trello boards --product=<productId>
prr trello link --project=<projectId> --board=<boardId>
prr trello lists --id=<boardLinkId>
prr trello create-list "In Progress" --id=<boardLinkId> --status=<statusId>
prr trello map-lists --id=<boardLinkId> <listId>:<statusId> ...   # replaces every mapping
prr trello import --id=<boardLinkId>
prr trello unlink --id=<boardLinkId>

Loop prevention. An update that arrived from Trello is never pushed back to Trello, and a chain of rules triggering rules stops after three hops. See Workflow rules.

Sentry

Errors from Sentry, on your terms: nothing lands on a board unless a workflow rule says so, and shipped fixes can be resolved back in Sentry automatically. Works with sentry.io and any self-hosted install.

What you get

  • Sentry issue events arrive by webhook and fire the Error Created, Error Resolved and Error Regressed triggers
  • A rule decides whether an error becomes an issue and which column it lands in — link a noisy project without flooding the board
  • Rules can resolve, ignore or unresolve the Sentry issue behind a Projectrr issue, so the error closes when the fix goes live
  • A scheduled poll picks up anything a webhook delivery missed

Setting it up

  1. In Sentry, open Settings → Developer Settings → Custom Integrations and create an internal integration.
  2. Give it org:read, project:read and event:write permissions, and tick the issue webhook.
  3. Copy its auth token and client secret. In Projectrr, open your organization’s settings, go to Sentry and paste them in along with your Sentry URL and organization slug. The credentials are checked against Sentry before anything is saved.
  4. Copy the webhook URL Projectrr shows you and paste it into the integration’s Webhook URL field in Sentry. It carries the connection’s id, which is how a delivery finds its way to the right tenant, so it only exists once the connection is saved.
  5. On the product that should track a Sentry project, open its Sentry tab and link the Sentry project to one of the product’s projects.
  6. Add a rule on the Error Created trigger with a Create issue from event action naming the column you want.

Without that last step, errors are recorded but nothing appears on the board. That is deliberate: a busy Sentry project would otherwise open an issue for every new error group the moment it was linked. Narrow it further with an Event field is condition — level is error, say.

Deliveries are rejected without the client secret. Sentry signs every webhook with it; a connection saved without one is treated as unverifiable, and its deliveries are refused rather than trusted.

Your Sentry has to be on a public address. Projectrr will not call a host on a loopback, link-local, private or otherwise special-use address — on a shared install, that would let anyone who can sign up aim the server at the network it runs in and read what comes back. An IPv6 address is callable only if it is global unicast, or one of the translation prefixes described below, so the reserved and documentation ranges are refused too.

Reaching an IPv4 Sentry over NAT64 or 6to4 works. Those addresses carry an IPv4 address inside them, and Projectrr judges the address they carry: from an IPv6-only network, 64:ff9b:: your Sentry’s public IPv4 is fine, while the same prefix pointed at a private address is not.

If you run Projectrr yourself, on the same private network as your Sentry, set ALLOW_PRIVATE_INTEGRATION_HOSTS=true to lift the restriction. Never set it where strangers can sign up.

One Sentry organization can serve several Projectrr organizations. Connect it once, then in the second organization’s Sentry settings use Connect under “Available from your other organizations”.

Pasting the credentials again instead only works if your organization already holds that connection, or you manage integrations in one that does. Otherwise it is refused: the credentials are stored once and shared, so saving them would replace the token every other organization’s rules authenticate with, and being able to reach that Sentry organization does not mean you are entitled to the ones already using it. When you do hold it, re-saving rotates the token for everyone — which is the point, since it is one set of credentials.

Disconnecting affects only the organization you do it from, and removes only that organization’s project links.

Deleting an organization gives up its hold the same way. If it was the last organization holding the connection, the stored token and client secret are deleted with it — so if you run two Projectrr organizations off one Sentry integration, disconnect the one you are removing before you delete it, or the other one keeps working only because it is still a holder. The same applies to a GitHub App installation: deleting the last organization holding it releases the installation, and connecting again means installing it again.

From the CLI:

prr sentry connect --url=https://sentry.example.com --sentry-org=<slug> --token=<token> --secret=<clientSecret>
prr sentry projects --id=<connectionId>
prr sentry link --id=<connectionId> --product=<productSlug> --project=<projectSlug> --sentry-project=<slug>
prr sentry links --product=<productSlug>
prr sentry poll --id=<linkId>

Loop prevention. A rule that fired on a Sentry event never pushes back to Sentry. See Workflow rules.

Claude routines

A workflow rule can hand an issue to a Claude Code routine — the agent picks up the issue’s full context, does the work, and comments back on the issue with a link to the session. Configure the routine against a product, then use the Trigger Claude routine action in a rule.

For interactive work, connect your assistant directly over the MCP server instead.

AI assistants and scripts

  • MCP server — Claude, Cursor and anything else that speaks MCP
  • CLI — prr, for terminals, scripts and CI

On the roadmap

Linear triggers are selectable in the rule dialog, but nothing sends those events yet and there is no connection to configure — a rule built on one will never fire.