Core concepts
Projectrr nests work in four levels:
Organization Greengage
└── Product ECOsmart
└── Project Web App
└── Issue WEB-142
Epics sit alongside that chain — they belong to a product and gather issues from any of its projects.
Organization
The billing and membership boundary. Everything you can see belongs to an organization you’re a member of, and nothing crosses between them.
Members have one of five roles: owner, admin, developer, member and
viewer. Everyone in an organization can read all of it — the role decides what
you can change:
| Resource | owner | admin | developer / member | viewer |
|---|---|---|---|---|
| Organization | Rename, delete | Rename | — | — |
| Members and invitations | Invite, change roles, remove | Invite, change roles, remove | — | — |
| Products and projects | Create, edit, delete | Create, edit, delete | — | — |
| Statuses and workflow rules | Create, edit, delete | Create, edit, delete | — | — |
| Issues and comments | Create, edit, delete | Create, edit, delete | Create, edit | — |
| Epics | Create, edit, delete, share | Create, edit, delete, share | Notes, issue links, members | — |
| Integrations and repositories | Connect, edit, disconnect, sync | Connect, edit, disconnect, sync | — | — |
developer and member are the same permission set under two names — nothing in
Projectrr treats them differently, so use whichever label describes your team.
In practice a developer or member runs the board: create issues, move them, comment, raise and resolve blockers and risks — on an issue or on an epic — and keep an epic’s journal by linking issues and people to it. They cannot reshape the setup around it. Creating or editing statuses and workflow rules, creating or editing an epic, connecting or disconnecting Trello and Claude, linking, editing or unlinking repositories, running a release sync, and triggering a Trello import or poll are all owner and admin only. So is deleting anything — issues, comments, epic notes — which is why a blocker is resolved rather than deleted. A viewer reads the whole organization and can watch issues, but changes nothing.
The web app doesn’t hide what your role can’t do. A control that’s beyond you is shown disabled, with a tooltip naming the roles that can use it — the app looks the same to everyone, and you know who to ask instead of guessing why a button vanished. The exception is a destructive action you could never hold, like deleting someone’s comment, which is left out entirely. A few corners still let you click and answer with a permission error; the server refuses either way.
Organization slugs are globally unique, so greengage appears in every URL and
in --org=greengage on the CLI.
Product
A thing you ship. Products own:
- Projects — the boards beneath them
- Repositories — linked GitHub repos, and the releases cut from them
- Integration credentials — Trello keys live here, not on the organization
- Epics — see Epics
A simple product is one that only needs a single board. Projectrr creates a default project for it and hides the extra level in the UI.
Project
One board, one issue-number sequence, one set of statuses. Each project has a
prefix (WEB) so its issues read as WEB-1, WEB-2, and so on. Numbers are
allocated atomically, so two people creating issues at the same moment never
collide.
Project slugs are unique within their product, which means two products can each
have a web-app project without conflict.
Issue
The unit of work. An issue carries:
- Title and a markdown spec — the spec is a full document, not a comment thread, and it’s the right place for acceptance criteria
- Status — a reference to one of the project’s statuses, not a fixed enum
- Priority —
urgent,high,medium,low - Estimate and watchers
- Creator, assignee and owner — three different people. The creator raised the issue and is recorded automatically when it’s created; the assignee is doing the work; the owner is the accountable lead. Only the creator is fixed — assignee and owner are optional and change hands. Issues raised by an incoming webhook or a workflow rule are credited to that source, not a person
- Comments — a thread on the issue page, below the spec, and the same thread the API, the CLI and MCP write to. A comment an agent leaves is read where a colleague’s is. Comments are typed, and two of the types stay open until someone closes them — see Comments are notes
- An optional epic
Creator and assignee are both filterable: a board can show only what you raised, and My Issues lists what’s assigned to you, what you raised, or either. The CLI and MCP take the same filters, one organization at a time.
In the web app, My Issues can also span organizations. If you belong to more than one, an All Organizations option merges them into a single list grouped by product and project, naming the organization on each group once more than one is in view. Membership is checked on every organization in the list, so it only ever merges what you can already read. Picking a single organization instead navigates to it, so the rest of the app follows.
Watchers get notified when an issue they care about changes, without having to own it. Commenting subscribes you to the issue. New comments sync both ways with a linked Trello card — one written here is posted to the card, and one written on the card comes back as an issue comment. Edits and deletes do not sync.
Comments are notes
An issue’s comments and an epic’s journal are the same
thing. Every comment has a kind — comment, update, decision,
blocker, context or risk — and on an issue the default is comment,
ordinary discussion. Comments thread one level deep, so a reply about a blocker
stays attached to the blocker rather than scattering down the page.
blocker and risk are the two kinds that stay open until someone closes
them, and that is what makes a stuck issue countable rather than a sentence
somebody has to notice. An issue with either shows a Needs attention panel
at the top of its page, and the organization dashboard rolls the same counts up
across every product, listing blocked issues next to blocked epics — each with
what it is blocked on. Resolving
one stamps who closed it and when, and records the explanation as a reply — the
original comment is never rewritten. Reopen it if the problem comes back.
A blocker or risk can also say what it is blocked on — other issues, epics, or an external URL — as clickable links carrying the target’s current status. See Epics.
The CLI and MCP can read the thread filtered — one kind, or just what is still open. The counts come back the same either way, taken across the whole issue, so a blocker can’t hide behind a filter.
That organization-wide rollup is not only a dashboard panel: prr attention and
the attention MCP tool return the same list, so “show me everything blocked”
is a question you can put to a terminal or an assistant as well as read off a
screen. It counts only unresolved, top-level blockers and risks, leaves out
finished work, and is capped at the worst few rather than being exhaustive.
Anyone who can comment can also edit a comment, and that means any comment: the permission is checked, authorship is not, so a developer can edit what an admin or an agent wrote. An edited comment is marked as edited, and the original isn’t kept, so treat the thread as a working conversation rather than a record of who said what. Deleting a comment is owner and admin only, and deleting one that has replies deletes them too — which is why a blocker is resolved rather than deleted.
Statuses
Statuses are defined per project. Each one has a name, a colour, an order on the board, and a category that tells Projectrr what the column means:
| Category | Meaning |
|---|---|
open |
Not started — counts as outstanding work |
active |
In flight, including finished-but-not-shipped work |
closed |
Cancelled or won’t-do — finished |
done |
Complete and shipped — finished |
done and closed are the two ways work finishes, and everything that hides
finished work hides both: boards, issue lists, the CLI’s --all flag and the
API’s includeClosed. They differ in meaning, not in how they are filtered.
closed is the abandoned pile, not the shipped one — all three templates use it
for Cancelled and nothing else, and the UI marks the category in red. Work
that is finished but not yet live — merged, on staging — stays active until it
reaches a done status.
Categories are what make cross-project reporting possible: a roadmap can show “in flight” across five products even though every board names its columns differently. They also drive workflow rule conditions.
Start from a template — Simple, Kanban or Release Flow — and edit from there.
Releases
When a product has linked GitHub repositories, Projectrr tracks the releases cut from them and ties issues to the release that shipped them, so “what went out last Tuesday” is a question you can answer.
Sharing
Roadmaps and epic status reports can be published as read-only links with a revocable token. Anyone with the link can read the report; nobody needs an account. Revoke the link and it stops working immediately.