Project briefs

What a brief is

When a repository is watched, diffy reads it and has the model write a brief: what the project is for, how it is built and which conventions it follows. Every review starts from the brief, so the model knows the project before it reads the change. A brief can be incomplete or wrong. The maintainers' instructions and the code in the diff win over it.

Status

• Building: diffy is reading the repository.
• Ready: the brief is written and used by reviews.
• Failed: it could not be built, and the reason is shown. A failed build is not started again by itself, because it may cost a model call. Choose Rebuild when you are ready.

A brief is built with the key and model in use for the organization. Until one is set up, briefs wait and start by themselves once it is.

Your notes

Open a repository on the Repositories page to read its brief and to add notes of your own. Notes are given to the model with the brief and are kept when the brief is built again. For rules that should live with the code, use .diffy.yaml instead.

Kept up to date

Once a day per repository, diffy asks GitHub what changed since the brief was written. It builds the brief again when the project's rules, documents or configuration changed, or when very many files did. You can also rebuild by hand at any time.