# A feature end to end

> The full cycle of one task — from draft to pull request, under your control.

Use case

# A feature end to end

You need a feature — say, caching of API responses. You do not want to run the whole cycle by hand, but you cannot hand it off into the void either.

[Connect a repository](https://buff.systems/app) [All use cases](https://buff.systems/en/use-cases)

Situation

## The full cycle of one task — from draft to pull request, under your control.

What gets in the way

- The task is large — you do not want to run the whole cycle by hand.
- The wording is vague — it is easy to build the wrong thing.
- You need control over the plan before coding starts.
- A large feature takes long when built step by step.
- The changes need review, and nobody has the time.

Solution 01

## Draft, clarifications and specification

A task starts as a draft. If information is missing, Buff asks clarifying questions instead of guessing. You approve the finished specification and plan yourself — this rules out “we built the wrong thing”: development does not start without your consent.

[About tasks](https://buff.systems/en/docs/tasks)

**Draft, clarifications and specification**

← scroll the frame →

Description, clarifications and the approved specification.

Solution 02

## Subtasks run in parallel

An approved task is broken into subtasks and built in order of dependencies. Whatever can run in parallel does, each subtask in its own environment, so a large feature does not drag on step by step. The execution scheme shows what is done, what is in progress and what is ahead.

[About autonomous development](https://buff.systems/en/docs/pipeline)

**Subtasks run in parallel**

← scroll the frame →

Execution scheme: subtasks by stage and dependency.

Solution 03

## Review: remarks, rework and publishing

Changes do not reach you raw. First a separate reviewer goes through them — a model role that did not write the code: it raises remarks on questionable places, and fixes are brought to green tests. You approve or reject the remarks — the model’s and your own; sending the task back for rework restarts development on them. A task cannot be approved with open remarks. Once you approve, Buff opens a pull request right in your repository on GitHub, GitLab, Bitbucket or Gitea — you do the merge.

[About review and publishing](https://buff.systems/en/docs/review)

**Review: remarks, rework and publishing**

← scroll the frame →

Change review: a dialogue about the code, remarks and the decision.

Outcome

The finished change arrives as a pull request in your repository — already reviewed and approved by you, not somewhere out there.

The first step changes nothing in the code

## Start with a question about your project

Connect a repository and ask the system how your code is built: it reads the source code and answers in minutes, changing nothing. A starting balance is provided to try it out.

[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