The workspace
A second interface onto the work your engineers already do
Product managers, support staff and business owners see and triage GitHub Issues and Projects across every repository a product touches, without a GitHub seat and without learning Git.
Issues
Every repository, in one list
The scope is the whole workspace by default. One list over every connected repository, with the issue number and the repository name in a monospaced face because they are things you copy exactly, labels in the colors GitHub gave them, and the state as an icon and a word — Open, Completed, Not planned — never as a color alone.
- Three layouts: list, board and table.
- Board columns come from a project’s single-select field, a label group, assignee, milestone or state.
- Dragging a card sets the grouped field in GitHub. If GitHub refuses, the card moves back and GitHub’s refusal is shown.
- Table adds project fields as columns and edits them in place.
Views
A saved question, with a name
Filter, sort and group, then save the result as a view. A view is an object: it has a name, a URL, and colleagues who can open it. Layouts are saved with it, so opening a view puts a board on screen if a board is what it was.
- Filter by repository, state, label, assignee, milestone, project, project field, portal or text.
- Every active condition is a chip you can remove.
- Views are shared with the workspace or kept to yourself.
- A view is one of the few things Pealboard stores that GitHub cannot. Deleting one changes nothing about your issues.
Projects and fields
GitHub’s fields, used as they are
Pealboard has no project type of its own. A project is a GitHub Project; a field is a GitHub project field. Single select, number, date and iteration fields are read, set and used as dimensions to filter, sort and group by.
Statusis a project field, not a state. Pealboard uses both and never confuses them.- Pealboard does not create projects, fields or field options. Add them in GitHub and they appear on the next sync.
- A project’s own built-in automations keep running. Pealboard does not touch them, and GitHub exposes no way to author new ones.
Search
One search, no waiting on GitHub
Search matches titles, bodies, label names and issue numbers across every connected repository. It runs against Pealboard’s own copy, kept current by webhooks and repaired every hour, so results appear as you type and no one person’s typing can exhaust a request budget the whole workspace shares.
- Matching is by word:
deployfinds "deploying" and "deployment". - Comments are not matched. Filter and open the issue.
- A newly created issue is searchable within seconds of GitHub accepting it.
Notifications
An inbox, email, and one Slack webhook
The Inbox holds what concerns you: a new request in a portal you manage, a new public comment, a comment on an issue assigned to you, a status change on an issue you follow. It is a tray, not a bell.
- Email on status changes and new public comments, per member.
- One daily digest of portal activity you manage, if you want it.
- One outgoing Slack webhook per workspace, for status changes, new public comments and new requests. Messages are one line each and carry no buttons: this release ships a webhook, not a Slack app.
MCP
Twelve tools an agent can call
A stateless remote MCP server at mcp.pealboard.com, authenticated with the same API key as everything else. The tools are task-shaped and few, and each one’s input schema is the API’s own schema, so the two cannot disagree.
search_issues,get_issue— read across every connected repository.create_issue,comment_on_issue,update_issue— write to GitHub, under the same authorization as the API.move_issue— set a project field value.list_projects,list_views,run_view— run a saved view.list_portals,list_portal_requests,reply_to_portal_request— read and answer customers.
API
One API, published as OpenAPI 3.1
A versioned REST API for workspace callers and a second for portal callers, both published from the same schemas the server validates against. API keys begin `pb_`, are stored as digests, and are shown once.
- A request id on every response, success or failure.
- One error envelope, everywhere.
- Cursor pagination, ETags on reads,
Idempotency-Keyon creates. - A key can never do more than the role of the member who created it.
Mobile
A native app for iOS and Android
The inbox, the issue list with filters, the issue detail with comments and a quick status change, and the portal requests waiting for a reply. Push notifications for the same events the Inbox holds.
- The same account and the same workspaces as the web application.
- No separate purchase and no separate plan.
What the workspace does not do
Each of these is a decision, not a gap. Building any of them would make Pealboard a second system of record, which is the thing it exists to avoid.
No custom workflow engine
The board is a layout over a GitHub Project’s own Status field. GitHub exposes no way to author project workflows through its API, so nobody could build one on top of GitHub without keeping a second copy of the truth.
No estimation model or velocity charts
GitHub’s own Insights are its user interface only, with no API behind them. Pealboardâs copy of your issues keeps the current value and when it was read, not a history to chart.
No time tracking
It is not in GitHub’s data model and not something a product manager or a support lead asked for.
No help desk
No SLA timers, no queue independent of GitHub, no satisfaction surveys, no multi-channel inbox. A portal request is always exactly one GitHub issue.
Connect a repository and look at it
The Free plan connects three repositories and needs no card. Nothing is imported and nothing in GitHub changes.