Projects and Organizations

Stib separates server-wide administration, organization ownership, and project work. Put a setting at the narrowest scope that should inherit it.

Organizations

An organization groups projects, members, labels, credentials, API keys, and an audit trail. Organization admins manage membership and settings for that scope; global server administrators retain inherited access.

An organization can own several projects. Moving a project transfers its boards, cards, sessions, and related data and requires administration rights on the target organization.

Workspace views and the switcher order

A workspace view gathers projects from several organizations under one name and colour; pick it from the organization switcher in the title bar. It never grants access to a project: each project still follows its own membership, and everyone only sees, in a view, the projects they already have access to.

Its visibility says who sees it besides you:

• Personal — you only.
• Chosen people — the people you add by searching their name or email. For each of them, the window tells how many projects of the view they will actually see.
• Everyone — anyone with access to at least one of its projects, now or later. Someone who sees none of them does not get the view.

Only the owner changes a shared view. Everyone else finds it read-only in the Shared with me section, with its owner's name in the switcher. They can copy it as a personal view (the copy only keeps the projects they see), remove it from their list when it was shared with them, or hide it when it is open to everyone; a hidden view waits in the folded Hidden section of the window, where it can be shown again. Changes arrive live; if the view you are in is no longer shared with you, you are taken back to the organization of the project you had open.

Manage organizations and views…, at the bottom of the switcher, opens one window for both:

• Views — create a view, rename it, change its colour, tick its projects and delete it. A view saves each change as you make it; a new view is created when you confirm. Choose its visibility. Drag the views (or press Alt+↑ / Alt+↓ on one) to set the order the switcher lists them in; the views shared with you are ordered too, in your own order. Deleting the view you are in takes you back to the organization of the project you had open. The pencil next to a view in the switcher opens the same window on it.
• Organizations — drag them into your own order. It changes nothing for the other members, and the numbered shortcuts follow it. An organization's name, colour and members stay in its settings.

Projects

A project points to a repository directory visible to the server. Its settings cover:

• identity, icon/color, description, and repository path;
• boards and templates;
• worktree policy, default base branch and AI branch names (Git tab);
• project scripts;
• labels and sharing/members;
• project skills and .mcp.json loading (Claude Code agents only — other runners do not read the file);
• default credential, model per runner, allowed runners and credentials, and scoped API keys;
• sandbox availability and data retention;
• project history, export, transfer, and deletion.

Transfer and deletion both sit in the danger zone at the bottom of the General tab, and both require administration rights on the project. Deleting removes the project, its boards, its cards and its agent conversations, stops any running agent, and cleans up the worktrees and branches Stib created. The repository itself is never touched. The confirmation asks you to type the project name; export the project first if you want a copy.

Changing a repository path affects future Git and agent operations. Verify accessibility and Git detection before saving, especially in Docker where container paths differ from host paths.

Project roles

The current project access model distinguishes:

Role	Typical access
Admin	Full project control, settings, and members
Contributor	Create and run cards without administering the project
Product owner	Create, edit and delete cards in the columns opened to them; read-only everywhere else
Reader	Reads the board and its conversations, comments included

A product owner sees the whole board whatever the columns: the role only restricts writing. The product backlog is open to them by default; any other column can be opened by a setting — that is how you give them a column where an agent helps them draft specs. They can never move a card out of the columns opened to them, nor archive, lock or restart an agent. See Column role.

A reader can comment: commenting is not changing the product. Everything else is refused, and the interface offers them no write action at all.

Global and organization administrators can inherit project administration.

Private boards

A project can allow private boards (Max plan, off by default, in Project settings › Boards). Contributors and admins then create boards that only they can open — up to the cap set per member (1 to 5). An admin sees that a private board exists (name, owner, card count), never its content, and may delete it. When the owner leaves the project, loses the contributor role or deletes their account, the board becomes orphaned: invisible to everyone and kept until an admin deletes it or converts it to a shared board. Adding the member back restores it.

Boards and views

Boards live inside a project and define a workflow. Saved views can cross projects and apply filters, grouping, and layout choices. Use another board for a distinct workflow; use a group for lanes within one workflow; use a saved view when the underlying cards should remain on their existing boards.

Sharing and invitations

Project sharing assigns direct members and roles. Organization invitations manage organization membership. Links and seats can expire or be revoked, and authentication/licence policy may prevent access even when a project role exists.

Next: Settings and Audit & Collaboration.