# How fenbs works

The simple AI project management tool for features, enhancements and bugs, where people and AI assistants are both members of the board. This page is the same for both: humans read it here, AI assistants fetch it from /llms.txt.

## The whole model, in four words

Board, task, lane, member. There is nothing else to learn.

- **Board** — One per profile, made for you the first time you open it. It has no name to set and there is never a second one — a business that wants another board makes another business.
- **Task** — One thing to do. Every task is a Feature, an Enhancement or a Bug — which is where the name comes from.
- **Lane** — Where the work is: To Do, Next Up, In Progress, Completed.
- **Member** — A person or an AI assistant, holding a role on the board. Personal boards have exactly one member: you.

## Refs: FE-014, EN-015, BU-016

The letters say what kind of thing it is and the number identifies it. Change a task from a bug to a feature and BU-014 becomes FE-014 immediately — the letters are worked out when the ref is shown, not stored.

Because of that, only the digits matter when looking something up. A link, a search or a tool call for FE-009 still finds the task that now calls itself BU-009. Numbers are unique per board and are never reused, so a ref quoted in a message last year still means the same task.

Your reference is a separate box on every task, for whatever your own work already calls it — a ticket number, a job number, a client PO. Nothing parses it and search covers it.

## Lanes and priority

Four lanes, in order: To Do, Next Up, In Progress, Completed. Drag a card between them, or use the arrows on the card.

Priority runs 1 to 10, where 1 is the most urgent, and groups into bands so you can filter by "high" without arguing about 2 versus 3.

Moving between lanes is its own permission. A role can be allowed to drag work to Completed without being able to rewrite what it says.

## Projects and categories

Both are optional labels, and both are made at the moment you need one: type a new name in the task editor and it exists. There is no list to set up first.

They are rows, not repeated words, so renaming one changes every task filed under it in a single step. Rename, add and delete them under Settings. Deleting one never deletes its tasks — they lose the label and nothing else, or you can move them to another in the same step.

"No project" and "Uncategorised" are real answers the board groups and filters by, not gaps.

## Ordering a lane

Each column has its own sort, because the columns are read for different reasons: To Do is triaged, Completed is a record. Choose from Custom, Urgent, Newest, Oldest, Changed, A–Z or Number.

Custom is the hand-made order: drop a card onto another card and it goes directly above it. Dragging within a lane switches that lane to Custom, because that is what the drag asked for. The order is shared — everybody on the board sees it.

## Adding a lot at once

Add many, next to + New task on the board. Nobody adopts a project management tool by hand-typing a backlog they already have.

Paste one task per line. Start a line with bug:, feature: or enhancement: to set that line's type; without a marker it takes the type you chose for the batch.

```
Fix the login redirect
bug: Payment webhook drops the currency
feature: Export the board as CSV
```

Or paste a markdown list, which is what a backlog usually already looks like. Indented lines under an entry become that task's note. A heading above a list is treated as a section label rather than a thing to build — with no bullets anywhere, the headings are the list.

```
## Checkout
- [ ] bug: Search ignores the category filter
      Only at 390px. The chip renders but the query never carries it.
- [ ] Add keyboard shortcuts
      j and k to move between cards.
```

Project, category, lane and priority are set once for the whole batch — the reason to paste thirty lines is that they have something in common. A type marker on an individual line still wins for that line.

Everything is previewed before anything is created, so a misparse is something you correct rather than something you clean up. Rows are created one at a time so refs stay sequential, and a partial failure names which rows landed instead of throwing the good ones away.

## Roles, and being told no

A business board takes its roles from the company: who may read, write, move, comment, see the roster and change roles. A personal board has one person and no roles to manage.

Every refusal names the permission that was missing and the role you hold — so "I cannot move FE-014, I am a Viewer here" is a sentence the product gives you rather than one you have to work out. AI Assistants should relay that sentence as-is rather than reinterpreting it.

## History

Every change is recorded with who made it, and each task shows its own trail on its page. This is the part a shared document cannot give you.

## AI context

Take your AI context with you: written down once, read by every AI assistant you connect.

AI context is everything an AI assistant should know before it touches your work — what you are making, how you like tasks written, what must never be done — kept on the board instead of inside whichever assistant you happened to be using. Change assistant tomorrow and the new one reads all of it the moment it arrives.

There are two levels. Notes that apply to everything are read on every project. Notes for one project are only given to an assistant working on that project — never the other projects' notes, so the picture stays small enough to keep up to date.

Assistants can add to it. A note an AI assistant writes is signed with its name and outlined in indigo on the AI context page, so what one assistant worked out is waiting for the next.

- Anyone who can see the board can read the context. Changing it needs the permission to change tasks.
- Over MCP: fenbs_get_context (pass project for one project's notes) and fenbs_add_context_note.
- As plain text: /me/context.txt, or /me/context.txt?project=Name, with your fenbs token as a Bearer header.

## For AI assistants: connecting over MCP

fenbs speaks MCP. Prefer it over reverse-engineering the REST API — the tools are stable and the refusals are readable.

The endpoint is /api/mcp on this host. In Claude Code:

```
claude mcp add --transport http fenbs https://fenbs.ai/api/mcp
```

Issue a token under Settings, "Connect an AI assistant". It is shown once and cannot be read back, so keep it when you see it.

A token acts AS the person who issued it and inherits their board role — narrow their role and every token they issued narrows with it, immediately. On top of that it carries scopes: read, write, comment. Both gates apply and the narrower one wins, so a token can never do something its owner could not.

Revoking one stops it at once and does not touch its owner's own sign-in. Everything it did stays in History, recorded by name — "Claude via Fenbs Tester" — so an AI assistant's changes can be told apart from a person's.

In the tool names and the API a task is called an item: fenbs_create_item adds a task, fenbs_list_items lists them. The two words mean the same thing.

Start with fenbs_whoami. It answers who you are acting as and what you may do, which is the question to settle before writing anything.

- **fenbs_whoami** — The actor, and its role on every board.
- **fenbs_list_boards** — The boards this actor can see.
- **fenbs_list_items** — Filter by lane, kind, assignee or free text.
- **fenbs_get_item** — One task by ref, with its comments.
- **fenbs_create_item** — Add a task.
- **fenbs_update_item** — Change lane, title, note, kind or priority.
- **fenbs_comment** — Comment on a task.
- **fenbs_search** — Across everything this actor can see.

Two things worth knowing before you write: refs are matched on their digits, so a stale ref still resolves; and a refusal is a whole sentence naming the missing permission, which is more useful to repeat than to summarise.

## Where things are

- Board: https://fenbs.ai/board
- This guide: https://fenbs.ai/guide
- MCP endpoint: https://fenbs.ai/api/mcp