Appearance
Customizing how Tenbi works on your code
Tenbi's agents follow a fixed, quality-gated pipeline — but how they write your PRDs, design your files, and shape your tests is yours to steer. There are three channels, from lightest to most structured. All of them inform the agents; none of them can override Tenbi's operating rules, quality gates, frozen intent, or test immutability — where guidance conflicts with a rule, the agent follows the rule and notes the conflict in its artifact, so you always see the decision.
The four channels
| Channel | What it's for | Where |
|---|---|---|
Your repo's CLAUDE.md / AGENTS.md | Conventions that live with the code — agents read them natively | In your repository |
| Optimize (project guide) | Tenbi-maintained map + guide of your repo: stack, commands, conventions | Lane → Optimize |
| Skills | Guidance documents — file layouts, testing style, PR templates, standing instructions | Workspace → Skills → attach per lane (runs) or per project (Composer) |
Skills
A skill is a markdown document in your workspace's skill library (Workspace → Skills). Create one in-app or upload a .md file — it's auto-named from the filename and renameable. Attach skills to Lanes (Lane → Skills); every run on that Lane stages them for the agents, whichever AI provider the run uses.
By default a skill is visible to all agents (auto): each agent sees an index entry for it and reads the full text when doing related work — a PRD-layout doc gets used by the PM, a Vue-structure doc by the Architect and Developer, with no mapping on your part. Pin a skill to specific agents when you want precision.
Where docs naturally land (for pinning, or just to know):
- PRD layout, requirements conventions → PM
- File/function layout, architecture conventions → Architect (+ Developer)
- Testing best practices, test file examples → Test Author — tests are authored there; the QA phase reviews blind on purpose, so guidance goes to the author, not the reviewer
- Code style beyond your linters → Developer
- PR description template → DevOps
Required reading. On each Lane, an attached skill can be marked Required reading (on its card in the Lane's settings) — changing its instruction from "consult when relevant" to "read before producing your artifact" for that Lane only. The same skill can be required on your flagship Lane and advisory on a prototype Lane. It needs the skill pinned to specific agents, and it spends context on every run — keep it for must-follow conventions ("build Vue files exactly like this").
Multiple repos, one Lane. Skills apply wherever they're appropriate: on a Lane spanning a Vue frontend and a C# backend, a Vue structure skill governs Vue files and nothing else — the agent routes it by reading it. For extra clarity, start each skill with a line like "Applies to: frontend repo, Vue single-file components."
Skills vs. your linters. A skill shapes what agents generate; your repo's own lint and build gates make conventions provable — the Developer runs them on every change. For rules important enough that violations should fail the run, encode them in your lint config too. They compose: the skill gets it right the first time, the linter proves it.
Limits. Up to 15 skills per module, 5 per agent, 64KB each.
Where each channel wins
Use the repo file for things every tool should know, Optimize for letting Tenbi maintain the map itself, and a skill for anything else — templates, examples, layouts, or standing instructions (pin those to one agent and mark them Required). When in doubt, start with a skill: it's named, versioned with your module, and visible per-agent.