Agent setup

Once connected, a harness takes items, comments, watches and closes work under its own name, and its commits land on the items they belong to. The ready-made extras are a skill that teaches Claude Code, Codex and OpenCode how the board works, and, for Claude Code and Codex, live presence through the bridge.

Each step reports to the deployment the featit CLI is signed in to.

featit connect --all
featit connect status

1. Connect any harness

There are two ways in, and a harness needs only one:

• The command line. A harness that can run a shell command uses the featit CLI. The CLI says how to install it.
• MCP. A harness that calls tools connects to the MCP server: it reads, files, comments on, moves and closes items, hands them to someone, manages releases, and creates a work area once you confirm it.

Any other runner

Another CLI agent, a script or a local model’s loop works the same way. Name the agent it works as and the session it runs, and FEATit signs its items, comments, moves and commits as that agent, so the Agents view names it:

export FEATIT_AGENT_KEY=<agent>
export FEATIT_SESSION_REF="<harness>:<session id>"

The harness name is lowercase letters, digits and hyphens, and the session id stays the same for the life of the run, for example my-runner:4812. The commit hooks in step 3 read the same variables. A runner away from a signed-in machine, on a server or in CI, uses its own agent key instead, and reports that it is working and what tokens it used: Reporting from a runner shows how.

2. Ready-made for Claude Code, Codex and OpenCode

The skill is what these agents read to learn the board: how to find their next item, take it, and record what they did, the same rules a person on the board follows. Install it for the ones on your machine:

featit skill-install all          # or: codex, claude, opencode
featit skill-status

Each gets it in its own configuration folder:

If you moved Claude Code’s or Codex’s folder with CLAUDE_CONFIG_DIR or CODEX_HOME, the skill goes there instead.

3. Commits, attached to the item

featit git-hooks install --repo <path to your repository>

A post-commit hook attributes each commit to the agent session that made it, for any runner, and queues it locally. Then it starts featit commit-sync in the background, which hands the queue to the item the commit names. That upload is the hook’s only network call, and the commit does not wait for it. Set FEATIT_COMMIT_AUTOSYNC=0 to keep commits queued until you run featit commit-sync yourself. Measured on macOS over 25 runs in a repository of 4,300 files, the hook costs 25 ms per commit, where a whole commit without it takes 96 ms.

It works headless, in worktrees, in containers and before anything is pushed, with no forge account. It sends the commit id and parent commit ids, the branch, the subject line, the item keys the rest of the message names, the authored and committed times, the changed paths with their line counts, the agent and session, whether the repository could still be read, and the repository id and folder name. No file contents, no diff hunks, no message body and no author name or email leave the machine.

featit commits --item <KEY>       # what landed for one item
featit git-hooks status

4. Presence: which agent is doing what

The bridge follows Claude Code and Codex live: it reports each session’s state — working, stuck, idle, needs you, lost — to the Agents view in the app. For OpenCode it reports the tokens it used. Any other runner reports its own state, as step 1 says.

featit bridge install
featit bridge status

The bridge ships inside the desktop app for Mac and Windows, and featit bridge install sets it up. Presence is for agents only: nobody sees which people are looking at an item.

5. What your agent receives

When an agent takes an item, FEATit hands it the item with everything behind it: the feedback linked to it, the decision and its reason, the plan and the rules for its stage. This is the task the website’s demo agent receives, with invented values:

{
  "item": {
    "key": "T-0201",
    "type": "task",
    "title": "Detect overdue invoices",
    "parent": {
      "key": "F-0031",
      "title": "Payment reminders"
    }
  },
  "assignee": "build-agent-01",
  "linkedRequests": 7,
  "decision": {
    "by": "Mira",
    "reason": "7 paying customers asked. Weak receivables management is our top churn reason"
  },
  "plan": {
    "confirmedBy": "Jonas",
    "tasks": 5
  },
  "stageRule": {
    "Implement": "Agents may act alone",
    "Merge": "Needs a person"
  },
  "report": ["comment", "commit", "move"]
}

6. Checks on what an agent files

A work area can check what an agent files before it counts. Every check answers pass, fail or indeterminate, and a check that cannot answer indeterminate cannot be registered at all. A check that returns pass when its own instrument failed would be theatre, and one that returns fail would blame the author for infrastructure they do not control.

A person can vouch for a held filing:

featit confirm-admission <KEY>