Skip to the content
Menu

The board decides who works

Each column on your board holds the agents that work its cards, so a card moves from builder to tester to you by itself.

Clients, projects and cards

  • Clients with contacts, and projects with docs and files.
  • Cards with labels, priorities and acceptance criteria, on a board or in a list (Ctrl+B switches). What needs you collects in the Inbox.
  • Labels are tags for people, such as Must have and Could have: create, rename, recolour and remove them on the Team page.
  • Archive a card in Done: it leaves the board and every list, and keeps its ID, comments, runs and branch. The bin on the Tasks page lists archived cards, and Restore puts one back in Done.

The columns

A card moves through Backlog → To do → In progress → Testing → Review → Deploy → Done. You set this flow up on the Team page (Team → Workflow). Each column:

  • holds the agents that work its cards;
  • is Auto, where its agents pick up its cards by priority as they have room, or Manual, where only Run starts one;
  • links to the column its cards go to next.

In a new team, To do, In progress and Testing are Auto. Add your own columns, like a Design column with a design agent, linked to Review. Drag columns into any order, or remove one.

The column decides, labels don’t

  • Starting a card in To do moves it to To do’s next column.
  • An agent’s done answer moves the card on: In progress → Testing → your Review.
  • A card assigned to an agent is started only by that agent.

Testing has rules of its own: a failed test sends a card back, and a card can skip Testing. See Tested before you see it.

The team

  • Agents for each role (frontend, backend, design, QA, DevOps), each with its own model, effort and allowed commands.
  • A new install starts with five: the Team Lead, and the Backend, Frontend, QA and DevOps Agents. The Backend and Frontend Agents work the cards in To do, and the QA Agent tests them.
  • An org chart of your team: the Team Lead on top, then branches (Design, Development, Quality, Operations and your own), each with one empty spot that adds an agent there.
  • Drag an agent onto a column in Team → Workflow to put it to work there.

Several teams

Team → New team adds a team with the seven usual columns and no agents. Each team has its own board: its columns, the agents on them, and the cards of its projects. An agent works only the columns it is on, so only its own team’s cards. Labels are shared by all teams.

  • A project’s team. A project’s cards are on its team’s board. With more than one team, the project form has a Team select, and the project page shows the team. A new project starts in the team the board shows; without a pick, in the first team.
  • Moving a project to another team (its form → Team) asks first: “Move Hersir to Research team? Its 31 cards go to the columns of the same kind, and My team’s agents are taken off them.” Then all its cards move, archived ones too: each to the new team’s first column of the same kind, in board order, else to its first Backlog column. Agents that aren’t on the new team come off a card as its assignee, pin or implementer; people stay. The new team’s agents pick up the cards in its Auto columns.
  • Refused while a run is under way: while one of the project’s cards has a run live or starting, the move is refused and nothing changes: “Wait for GA-12’s run to end, or stop it, before you move Hersir to another team.”
  • The board’s Team select. With more than one team, the Tasks page’s toolbar has a Team select. The board and the list show that team’s columns and the cards of its projects; cards without a project go with the first team. The Team page and the sidebar’s agents follow the same pick. The Inbox still shows every team’s cards that need you.

With one team there is no Team select anywhere, and everything works as before. The Team Lead’s tools name the team when there is more than one: Teams.

When agents start

Agents start when you press Run, or when a card lands in an Auto column they are on (or is assigned to them there). An agent works on several cards at once when its Cards at once allows it.

A start that can’t work (Claude Code missing or not logged in, a wrong model, no repository) holds the card “blocked” without counting as a failed run. That agent takes no new cards until you start or edit it, or Hersir restarts.

Settings → Runs sets how many runs go at once, for all agents together. Pause all agents stops the starts from Auto columns; Run still works by hand.

Memory for agent runs, also in Settings → Runs, is how much memory all agent runs may use together: half of the computer’s memory until you set it. On Linux the system holds the runs to it, and Hersir stays outside the limit, so a big build can’t take Hersir down (PLATFORMS.md). On every system no run starts while the runs use over 80% of it or the computer has under 2 GB free: the card waits with the reason, like Runs at once, and starts by itself once memory frees up.

A project can also keep how many of its cards are tested at the same time, so a heavy test suite doesn’t run several times at once: Test runs at once.

A card that builds on another card waits until that card is merged: Cards that build on others.

Cards that build on others

A card that needs another card’s code builds on it, like screens on their backend, or a follow-up on its base. It waits until that card is merged, then starts by itself, so a plan of cards runs through in order.

  • Merged means in a Deploy or Done column. An archived card came from Done, so it counts. A cancelled card never counts.
  • Set it in the card’s Properties → Builds on: Add a card finds a card by ID or title, as @ does, and × takes one off. Any card may be named, another project’s too, up to 20. The Team Lead sets it with builds_on (A Team Lead you talk to).
  • Refused: a card building on itself, more than 20 cards, and a loop, like “GA-227 can’t build on GA-225: GA-225 already builds on GA-227.” A loop through other cards names them: “…, through GA-226.”
  • Needed by, under Builds on, lists the cards that build on this one.

While it waits:

  • No agent takes it; they take their next cards meanwhile. It keeps its place, without a move or a hold, in To do, In progress, Testing or a column of your own.
  • The board shows “Waits for GA-226”, or “Waits for 2 cards”, with the cards in its tooltip. The badge goes once they are merged.
  • Run and Continue don’t start it, and say why: “GA-227 builds on GA-226, which isn’t merged yet. It starts by itself once GA-226 is merged; to start it now, take GA-226 off its Builds on.”
  • You can still move it to any column. In an Auto column it waits there with its badge.
  • When a card it waits for is on hold or cancelled, the Team Lead’s board check reports it (builds_on_blocked). Waiting for a card that is still in work isn’t reported.

Once the last of them is merged (its pull request merged, the DevOps Agent’s release, or you moving it to Deploy or Done), the agents take it at the next pull, without anyone moving it. Its run’s prompt lists the cards it builds on, like “Builds on GA-226: Team templates (backend), merged.”, so the agent knows their code is on main.

A card without Builds on works as before.

A worktree for every card

Every card gets its own git worktree and branch, started from main on GitHub or Bitbucket when the project is linked. Main is fetched through your checkout’s own remote for that repository (origin first), so your own git settings apply as they do for your own git fetch, like an insteadOf rule that sends it to an SSH host alias. Worktrees start warm. Per project, a new worktree gets:

  • paths copied from your checkout (cp --reflink=auto);
  • missing dependencies installed (composer install, npm ci);
  • a setup command.

A new card takes over a finished card’s worktree. A build folder over 20 GB is emptied first, and the card says so.

Settings → Data lists old worktrees with their uncommitted files, and removes them. Remove anyway puts uncommitted changes in git’s stash first.

Runs

  • Live output while an agent works.
  • Run history, with the reason each run ended, what started it and the commits it made.
  • Limits: time and tool-call limits per run, a spending limit per run, and a monthly budget per agent.

Continue with a note

Continue picks an agent’s run up again, in the same session. The box above Continue takes a note for the agent, like “use the existing CSV writer”. The continued run hears it next to why its last run stopped, and it is saved on the card as your comment.

The Team Lead’s continue_agent_run takes a note the same way. On a run that asked for a decision, the Team Lead’s note counts as an answer.

One nudge

A run that ends normally without its GIZAI_RESULT line is continued once by itself, in the same session, like Continue. Hersir tells the agent that nothing wakes it up later, to check in the foreground now if it was waiting, and to end with its result line. The Runs list shows it as Nudge (trigger result_nudge), apart from a Continue.

  • It never happens after Stop, a time or tool-call limit, a failed run or Hersir quitting.
  • It happens only when a start is allowed now: agents not paused, the agent active, within its budget and cards at once, and room in Runs at once. Otherwise nothing changes.
  • If the nudged run also ends without a result, the card goes on hold “stalled” and shows in the Inbox.

How an agent waits, during its run, for something outside it, like a CI run: Waiting in a run.

Deploy

Deploy is Manual by default, so no agent starts there by itself.

  • Press Run for the agent on the column: the DevOps Agent releases what you merged, and its deployed answer moves the card to Deploy’s next column, Done.
  • Or deploy it yourself and drag the card to Done.

Read more

Edit on GitHub (opens GitHub)