# Features

> What Buff does: from setting a task to a finished pull request — and answers from documents for teams without code.

Features

# Autonomous development — *from task to pull request*

Project analysis, answers about code and documents, deep research, development with review and a pull request to your repository. All in the cloud, with no access to your infrastructure: you set the task and accept the result.

[Connect a repository](https://buff.systems/app) [See it in the demo](https://buff.systems/demo-app/auth/demo?to=shopizer) [How the cycle works](https://buff.systems/en/product#cycle) Development is the first of the platform’s three ways in; the second is a knowledge space for departments without code

What the system does

## Eleven tools around your code and documents

[Task writing Describe the task in words — the system clarifies the details and shows you a brief to approve. Learn more](https://buff.systems/en/product/tasks) [Autonomous pipeline A task is broken into subtasks that run in parallel, each in its own environment; progress is shown on a diagram. Learn more](https://buff.systems/en/product/pipeline) [Review Changes are reviewed with comments; you approve them or send them back for rework. Learn more](https://buff.systems/en/product/review) [Publishing Once approved, a pull request to your repository on GitHub, GitLab, Bitbucket or Gitea. Learn more](https://buff.systems/en/product/publish) [Ask A question about the code, connected trackers and documents — an answer in minutes with links to the source, without changing anything. Learn more](https://buff.systems/en/product/ask) [Deep research A solution is worked out before the code: a checked document, exportable to PDF and Markdown. Learn more](https://buff.systems/en/product/research) [Knowledge space — no code For departments without code: questions and research on policies, contracts and reports — answers with a link to the document. Learn more](https://buff.systems/en/business) [Audits Project analysis in ten areas — the rules come from your code. Learn more](https://buff.systems/en/product/audits) [Project onboarding Connecting a repository, with build and tests as the project’s baseline. Learn more](https://buff.systems/en/product/onboarding) [Members and roles Organisations, member roles and repository access. Learn more](https://buff.systems/en/product/teams) [Buff Code — for developers For those who write the code themselves: a terminal and an app on the organisation’s models, knowledge and connections. Learn more](https://buff.systems/en/buff-code)

Tool 01

## First, it gets to know your code

Ten areas: architecture, testability, build, dependencies, data and security, development process, behaviour, interface, environment constraints, contracts.

### The rules come from your code, not from our idea of what is right

Each section has a status and a date. When the code moves on, the system warns that a section is out of date; you can refresh a single section and the rules change at once. Analysis takes 2–8 hours whatever the size of the codebase.

**Project analysis** 10 areas

**A section report** with a table of contents; at the top, a mark showing whether it is current for the code as it is now.

[More about this tool](https://buff.systems/en/product/audits)

Tool 02

## An answer about the code in minutes, without changing anything

Works as soon as a repository is connected — before the project analysis and the first task.

### Ask about any part — the answer links to the files

The system reads the source — and the connected trackers and documents — and answers to the point: where a response is built, how a query is escaped, where to make a change. You can follow its reasoning, and attach files to a question.

**An answer about the code** in minutes

[More about this tool](https://buff.systems/en/product/ask)

Tool 03

## The solution is worked out before the code

For questions where options need comparing first and code comes later.

### An analyst and a reviewer prepare a checked document

The document takes shape as the work goes, and you steer the research in a conversation. The result exports to PDF and Markdown — attach it to a decision or pass it to a task as a requirement.

**Deep research** PDF · Markdown

[More about this tool](https://buff.systems/en/product/research)

Tool 04

## From a description in words to a finished change

The engineer takes part twice — when setting the task and at acceptance. In between, the task runs on its own.

### The brief is agreed before the start, and progress is visible by subtask

The system asks clarifying questions and shows the brief: what is in scope, what is out, the acceptance criteria. Once you approve it, the task is broken into subtasks that run in parallel, each in its own environment with build and tests.

**Brief** before the start

**Progress** in parallel

[More about this tool](https://buff.systems/en/product/pipeline)

Tool 05

## A change is reviewed — before it reaches your code

You only read what was agreed: a change arrives already put through the build and tests.

### Comments with their status, the decision is yours

A separate reviewer — a model role that did not write the code — comments on the debatable places; you accept, reject or edit each comment. **Approve or send back for rework** — once approved, the system opens a pull request in your repository on GitHub, GitLab, Bitbucket or Gitea. You do the merge.

**Change review** before your code

[More about this tool](https://buff.systems/en/product/review)

A task’s path

## One continuous flow — from words to a pull request

The forks are where the system checks details with you, merges parallel edits itself or waits for your decision.

[*01* Task description In plain words, without a three-page specification.](https://buff.systems/en/docs/tasks) [*02* Clarifying questions If something is missing, the system asks you rather than guessing.](https://buff.systems/en/docs/tasks/clarifications) [*03* Brief and plan The scope of edits and the acceptance criteria — you approve them before the start.](https://buff.systems/en/docs/pipeline/decomposition) [*04* Development Subtasks run in parallel, each in its own environment with build and tests.](https://buff.systems/en/docs/pipeline/execution-scheme) [*05* Merging edits Parallel changes are combined, and a main branch that has moved on is merged into the task.](https://buff.systems/en/docs/pipeline/lifecycle) [*06* Change review A separate reviewer goes through the change and comments on the debatable places.](https://buff.systems/en/docs/review/changes) [*07* Your decision Approve, or send back for rework with a comment.](https://buff.systems/en/docs/review/decision) [*08* Pull request A finished change in your repository; you do the merge.](https://buff.systems/en/docs/review/publish)

### Forks along the way

#### Clarifying questions

If something is missing, the system asks you rather than guessing.

#### Overlapping edits

When changes run in parallel, the system merges them itself before review.

#### Comments → rework

Review and rework run in a loop until the change is clean.

#### You have the final say

Nothing goes into your repository without your explicit “yes”.

Connecting takes minutes

## Connect a repository

Questions about the code work straight away, and project analysis takes hours. By the time you hand over the first task, you will know how the system reads your project. A starter balance is included so you can try it.

[Connect a repository](https://buff.systems/app) [Write to us](mailto:info@buff.systems)

Companies and sole traders can pay by bank transfer and receive closing documents