Parallax Cli

Parallax

Trigger your [Hermes](https://hermes-agent.nousresearch.com) agents from your tickets and pull requests.

You already run a fleet of Hermes profiles — a product reviewer, a code reviewer, an implementer, each with its own memory, model, and GitHub account. Parallax is the layer that decides **which one should start, when, and with what context**, then records what happened and tells your team about it.

// "When a Linear ticket gets the feasibility label,
//  have the product agent assess it and comment back."
{
  "name": "Product review on feasibility label",
  "trigger": { "type": "ticket", "provider": "linear", "projectId": "taplands" },
  "match":   { "labels": { "any": ["feasibility"] } },
  "target":  { "agentRef": { "profile": "product" } },
  "execution": { "prompt": "Assess {{ticket.ref}}: {{ticket.title}}\n\n{{ticket.body}}",
                 "timeoutSeconds": 1800 },
  "outcome": {
    "postComment": { "target": "ticket" },
    "labels": { "add": ["reviewed"], "remove": ["feasibility"] }
  }
}

That is the whole idea. Routes are data, so a new workflow is a row, not a code change — and the prompt lives on the route, so rewording what an agent is asked to do never needs a release.

Ready-made routes for every supported case, including multi-round pull request review, are in **[docs/routes.md](./docs/routes.md)** and served from `GET /v1/route-templates`.

How it fits together

Mac Mini                                    Railway
┌──────────────────────────────┐      ┌──────────────────────┐
│ Hermes gateway               │      │ api                  │
│   :8642  /p//v1/…   │      │   config · registry  │
│   owns git, PRs, identity    │      │   run history        │
│            ▲                 │      │   Slack              │
│            │ POST /v1/runs   │      │          ▲           │
│ parallax runner              │─────►│          │           │
│   triggers → routes →        │ long │  ┌───────┴────────┐  │
│