Triage

Every request is judged before it is planned — whether it joins, follows or starts a cycle, how the work is handled, and how urgency becomes a priority.

Triage decides how a new request enters the project. It checks whether the work is already covered, how well the change is understood, how costly a mistake would be, and how urgent it is. A cycle opened from an already-pushed branch is different: it carries existing work into the delivery process and does not ask triage to classify a new request.

Where triage sits

request ──▶ triage ──┬──▶ draft ──▶ planning ──▶ executing ──▶ …
                     │
                     └──▶ canceled

Requests from chat, the client portal, the board, Canvas context, the API, Linear or GitHub issues go through triage before new work is planned. A request may join an existing cycle or become a new one. The project manager’s own requests use the same process.

A request from a branch that already exists in the project’s repository carries a commit rather than a description, so it skips request classification. It must still confirm the pushed branch and pass the delivery checks.

What triage decides

Join, follow, or start new

Triage first compares the request with the project’s open cycles:

The request…	What happens
Repeats work a cycle already does	It joins that cycle instead of creating a second one. A stopped cycle is reopened.
Builds on or reworks a cycle’s work	It becomes a new cycle that starts once that one finishes.
Is separate work	It becomes its own cycle and runs in parallel with the others, up to your Parallel cycles setting.

This comparison helps the project reuse existing work instead of opening duplicate cycles.

How the work is classified

Triage then judges three things about the request and writes a short rationale.

It judges	Meaning	Values
Complexity	How well understood the change is before work starts	`simple` · `ambiguous` · `systemic`
Risk	How costly a wrong answer would be	`low` · `medium` · `high`
Urgency	How far this should move ahead of work already waiting	`urgent` · `high` · `normal` · `low`

Urgency is judged from what the work is — something user-facing is broken, or other work is blocked on it — not from how urgently the request is worded.

Forward or decline

A request you or your team make directly — chat, the board, the API, or the project’s own brief — is always forwarded. Only requests from an external tracker (Linear and GitHub issues) can be declined, and only when triage is confident the request is out of scope for the project, unsafe, or too vague to act on.

Handling comes from rules

A cycle’s handling describes how the work is treated. Hlix assigns it from the assessed complexity and risk. For example:

fast-review uses a lighter review with a single round.
experiment delivers work on the cycle’s own branch for inspection instead of merging it into preview.

Other handling values classify the work for filtering and reporting. Cycles run autonomously after any required initial proposal approval; you control the final merge into the repository’s default branch.

Urgency becomes a priority

Ready cycles start in urgency order: urgent, high, normal, then low. Dependencies and the number of build agents that can run at once still determine which cycles can start. Equal priorities keep their roadmap order.

Choose Priority in the dashboard’s Cycles view to inspect the queue. API clients can request GET /v1/api/cycles?orderBy=priority; see the Cycles API for the numeric values and sorting options.

What gets recorded

A forwarded cycle moves to draft; a declined cycle moves to canceled. The cycle’s stage history records the decision and its reason. Its API response includes the lane field and priority.

Workspace owners and administrators can also inspect the classification and rationale in the audit log, under cycle.triaged or cycle.canceled.

Reading a decision back

Ask the project manager in chat — “why was this cycle canceled?” — and it returns the decision, its rationale and the handling. Owners and admins also see the complexity and risk behind the handling. The same information is in the audit log, filtered to that cycle.

Choosing the model that triages

Triage uses the Project manager model, shared with the project manager and chat. Workspace owners and administrators can set it under Settings → Models & accounts → Defaults → Project manager. Projects can override that selection. See Models & provider keys.

If a cycle is not where you expect

A cycle reads canceled and you did not cancel it. Triage declined an external request. The rationale is the reason on its last stage-history entry and on the cycle.canceled audit entry.
You sent a request and no new cycle appeared. It joined a cycle that already does that work. See Cycles.
Two cycles dispatched in an order you did not expect. Compare their priority values, not their creation times. A normal cycle created first still goes after an urgent one.
A cycle has no lane value. Triage has not finished, or the cycle did not go through triage (work pushed to a branch of the project’s repository skips it). A null lane means no classification was recorded.