The loop: Signal to Closed
nima's five-stage pipeline, where each stage is worked today (Slack, MCP, API), what nima does on its own and the one human gate.
nima runs one pipeline: Signal → Beacon → Spec → PR → Closed. Raw feedback goes in, a pull request comes out, and the people who cared are told when it ships.
On for every workspace. Extraction and automatic grouping into beacons run without setup; PR linking, drift checks and shipping notices run once a spec has a ticket on a board linked to its repository. Automatic promotion of beacons to specs is off, so a person starts every spec. The web app does not work the pipeline: you work it in Slack, over MCP and over the REST API.
The five pipeline stages
The pipeline has five stages, and each one ends in a defined state. This section gives one line per stage and links to the page that owns it.
- Signal. One piece of raw evidence from Slack, GitHub, Linear, ClickUp, Sentry, PostHog, Granola, a webhook or a manual note (HubSpot is rolling out; ask the nima team). nima classifies it, extracts its stakeholders and product area, embeds it and tags its origin as
internal,externalorcustomer. A signal ends in a beacon or is dismissed. Manual signals (fromcreate_signalorPOST /v1/signals) are not de-duplicated, so a retried call creates a second signal. Details: How nima decides. - Beacon. A ranked collection of related signals, and the unit a person decides on. Each beacon has a workspace-unique key such as
BCN-12that is never reused. Rank is a 0 to 100 score from severity, reach, source weight and recency. Details: How nima decides. - Spec. A document of type
spec, written from a beacon's signals and grounded in your indexed code and the knowledge graph. Details: Anatomy of a spec. - PR. The pull request that delivers the spec, linked through the spec's ticket. Details: From spec to shipped.
- Closed. The linked pull request merged, the spec is marked
shipped, and nima tells the people involved. Details: From spec to shipped.
The human gate: promoting a beacon
Promoting a beacon is the one human gate in the loop. Because automatic promotion is off, nothing becomes a spec until a person promotes a beacon.
Today a beacon is promoted with POST /v1/beacons/:id/promote from a signed-in web session. There is no MCP tool and no Slack action for it, and API keys and OAuth tokens get 403. The route is declared under the copilot_chat plan feature. A workspace whose plan lacks it can get 403 INSUFFICIENT_PERMISSIONS with details.feature set to copilot_chat; handle that response. The workspace also needs at least one indexed repository, otherwise the call fails with 400. If you cannot make a session call, ask the nima team.
Promoting creates the spec document immediately and starts the research and writing run. The beacon's pmNotes and up to 20 of its top-ranked signals go into the run. See Promote a beacon for the request and error list.
Decision questions during spec generation
A spec run pauses at most once, when it has more than one approach to choose between or up to three open questions it cannot answer from your code. Only the person who promoted the beacon can answer, through a session-only route. Runs with one obvious approach and no questions never pause.
If nobody answers within 24 hours, nima picks the options it judges best and writes the spec. Every pick made this way appears under Decisions in the finished spec, marked (assumed by nima — not yet confirmed). The Slack and drift links nima sends to the web app land on Integrations, not on a decision card.
What nima does automatically at each stage
This section lists every step nima performs without a person acting, in pipeline order.
| Stage | What nima does on its own |
|---|---|
| Signal | Classifies the signal (nima assigns bug, feature_request or spec_drift), sets impact to low, medium or high, extracts stakeholders and product area, embeds it. Noise is dismissed, except topics such as pricing, compliance, contracts or legal terms, which are kept. Extraction stops after 3 runs or USD 0.25 per signal and the signal becomes failed. |
| Beacon | Places each ready signal 60 seconds after new signals arrive: an AI judge either joins the signal to one of up to 6 similar open beacons or forms a new one; held, promoted and dismissed beacons are never offered to the judge. A signal from an error alert with a known fingerprint skips the judge: it joins the repair beacon for the same error, even one already promoted, or forms a new repair beacon. Regenerates the one-line ask of a beacon 15 seconds after its evidence changes. |
| Beacon readiness | A beacon nima opens is ready as soon as it exists. A beacon a person groups by hand becomes ready once it has at least 3 pieces of evidence and a rank of at least 70, or as soon as one of its signals is an open urgent incident. |
| Spec | Researches your code and knowledge graph, may post up to 5 questions to the workspace's Slack updates channel, writes the spec, and attaches late evidence to the draft with a notification to the promoter. |
| PR | Links a pull request to the spec's ticket by branch name, title, body, or an AI match with at least 0.7 confidence. Moves the ticket across columns as the PR opens, is reviewed and merges. Requests a drift check on open, push, reopen and merge, and posts the result as a PR comment. |
| Closed | Marks the spec shipped once no open PR remains on the ticket. Posts one threaded Slack reply per originating Slack thread (Shipped: <spec title> — <PR url>, at most 20 threads), sends the spec owner an in-app notification, and moves the signals behind the spec to resolved. |
Two things nima never does automatically today: it does not merge duplicate signals, and it does not merge beacons. Automatic dismissal, the daily duplicate sweep and automatic promotion are off; the nima team controls them.
PR linking needs a ticket. The spec must be promoted to a ticket on a board, the GitHub repository must be linked to that board, and the branch (after a slash, for example feature/ACME-12-slug), title or body should carry the ticket key. Without a board linked to the repository, nima does not link that repository's PRs or move cards. Details: From spec to shipped.
Where you work each stage today
Each stage is reachable through a different mix of Slack, MCP and REST. Session-only means the route needs a signed-in web session and rejects API keys and OAuth tokens.
| Stage | Slack | MCP | API with a key | Session-only |
|---|---|---|---|---|
| Signal | Ask nima in a mention or DM | search_signals, get_signal, create_signal | GET /v1/signals, GET /v1/signals/:id, POST /v1/signals | Dismiss, merge, restore, edit, delete |
| Beacon | Ask nima in a mention or DM | list_beacons, get_beacon | GET /v1/beacons, GET /v1/beacons/:id | Create, hold, dismiss, merge, add or remove members, promote |
| Spec | Ask nima in a mention or DM | list_specs, get_document_markdown | GET /documents, GET /documents/:id/markdown; writes need documents:write | Answer decision questions |
| PR | Drift and link notices via watches (off until an owner or admin turns watches on) | get_spec_delivery, get_history | GET /documents/:id/delivery | Kanban boards, columns, cards, repository-to-board link |
| Closed | Threaded ship reply | get_spec_delivery, get_history | GET /documents/:id/delivery | None |
Notes on this table:
- MCP reads:
search_signals,list_beacons,get_beacon,list_specs,get_document_markdown,get_spec_deliveryandget_history. The only MCP write in the pipeline iscreate_signal. Tool reference: Pipeline tools. - Spec writes such as
PUT /documents/:id/markdownandPOST /documents/:id/promote(spec to ticket) need thedocuments:writescope. Only an owner or admin can hold it, and MCP clients cannot be granted it. See Scopes. - The
/documentsroutes are declared under thedocumentsplan feature; a workspace whose plan lacks it can get403 INSUFFICIENT_PERMISSIONSwithdetails.featureset todocuments. Promoting a spec to a ticket needs acolumnId, which only the session-only kanban routes return. - Nima's Slack assistant answers questions about beacons and specs but cannot promote or edit them.
Correcting nima at each stage
nima can be wrong at every stage, and most corrections are session-only routes today. This table says what each correction is and where it lives.
| Stage | Correction | Where |
|---|---|---|
| Signal | Change classification, impact, origin, stakeholders or notes; dismiss; merge into another signal | PATCH /v1/signals/:id and the dismiss and merge routes, session-only. See Signals API. |
| Beacon | Hold with a reason, dismiss, merge beacons, add or remove signals, edit title and notes | Session-only routes. See Beacons API. |
| Spec | Rewrite the body; set priority or owner | PUT /documents/:id/markdown and PATCH /documents/:id/spec-metadata with documents:write. See Specs API. |
| PR | Add a missing link by putting the ticket key in the branch (after a slash), title or body; nima picks it up on the PR's next event (a push, review or reopen). A wrong link cannot be removed through the API today; ask the nima team. | GitHub |
A beacon's rank is computed from its signals' impact and stakeholders, but editing a signal does not recompute it right away: the new rank shows the next time the beacon itself changes (a signal added or removed, an edit to the beacon, or a merge). How nima decides has the formula and every threshold.
Being told when something moves
nima tells people about pipeline movement through watches and shipped notices. Shipped notices (the threaded Slack reply and the signal resolution) run without setup.
Watches on events such as beacon.ready, spec.generation_completed, pr.linked_to_spec, pr.merged, pr.drift_checked and spec.shipped are off until a workspace owner or admin sets triggersEnabled with PATCH /organizations/settings from a signed-in session, or you ask the nima team. See Watches and reminders and Availability.
Related pipeline concepts
Install the nima plugin for Claude Code
Install the nima Claude Code plugin to connect nima's MCP server, make the agent query nima before claiming demand, and file guarded product-gap signals.
How nima decides
Every rule nima uses to classify signals, place them into beacons, rank beacons and decide when a beacon is ready.