Buff Development
Buff Code

Project repositories

The model in Buff Code searches and reads the project’s code in Buff without a clone on the machine: file search, content search and reading on any branch.

A development project in Buff is a pool of repositories. The model in Buff Code sees all of them, even if the developer’s machine holds only one of them or entirely different code: the tools of the repos server search and read the project’s copy in Buff.

Why it matters: a neighbouring microservice, a shared library, configuration in an adjacent repository — the model looks there itself instead of guessing about the “neighbouring” code.

Tools

ToolWhat it does
repos_globfind files by a pattern in the project’s code: directory, hidden files, number of results
repos_grepfind lines by a regular expression or exact text, with a file pattern
repos_readread a file or a directory: lines are numbered, a large file comes in parts

Each has a branch parameter: empty — the repository’s main branch, otherwise any existing one. This way the model can check its edit against what already sits in a colleague’s branch.

Word, Excel, PowerPoint and PDF documents from the repository are read as text — as in “Ask”.

A developer asked what the project’s repositories contain. The model read them in Buff — this code is not on the developer’s machine — and answered with a table.

Your files and the project’s files

The model tells two places apart:

  • your working folder — Buff Code’s usual tools: read, edit, run;
  • the project in Buff — the repos_* tools: read-only, paths from the repository root.

Edits go only to the working folder. Nothing in Buff’s repositories changes from Buff Code — for changes in the project there are tasks and your usual git.

What you need

  • A chosen project in the working context. Without a project the model gets “First choose a project in the Buff Code working context (/project)”.
  • A connector v0.15.0 or newer.
  • The developer’s access to this project in Buff.

How it is counted

repos_* calls are reads: they cost no tokens and do not go into the audit log, just like reading code in the workspace. Call results are recorded in development sessions together with the model’s answer.

The first call in a project may answer “Buff is still preparing the answer: the project repository is loading for the first time or the search is very broad” — the model repeats the same call half a minute later and gets the whole answer. A long answer comes in parts, with a hint where to continue.

On this page