Gibon.yml

The gibon.yml file contains the various commands needed for Gibon to setup your repository and validate its own work.

Here is a sample gibon.yml for GoLang

dependencies: go mod download
generate: go generate ./...
lint: golangci-lint run --fix ./...
unit: go test ./...
build: go build ./...

File Structure

1. dependencies: Installs your apps dependencies. Remember this will be run in CI so it needs to be fully headless (e.g. `npm ci`, not `npm i`). Most repos should have this command.
2. generate: This command is used for creating any generated code. This is common for testing mocks or fixtures. Not all repos will have this.
3. lint: Runs your repositories static code analyzer. If supported, include flags for linter autofixes.
4. unit: Run your unit tests, important for Gibon to validate its work and ensure it didn't break anything existing. Unit tests should have little to no external dependencies to ensure deterministic results across environments (e.g. mock your database client rather than connect to a real database)
5. build: Builds the application, if you're using an interpreted language like NodeJS or Python, you probably won't have this command.

How it's used

Gibon starts every coding session in a fresh container.

• Your repository is cloned and the gibon.yml commands are run in the order depicted above.
• If any command fails Gibon will cancel the task, Gibon won't proceed if its starting point can't be verified, otherwise it would have no way to know if its changes broke the application.
• Once the codebase is validated, Gibon implements the task
• After implementation is complete, Gibon runs the commands again in order, if any fail Gibon will attempt to fix them. Gibon will try several times before giving up on fixing validation failures.

Assigning Tasks

Learn how to effectively assign work to Gibon through your existing issue tracking system.

Assignment Methods

GitHub Issues

Simply mention @gibon in an issue description. Gibon will comment back on the issue to indicate it's been received.

Writing Effective Task Descriptions

Generally you should follow your company's best practice for filing issues. Barring those best practices, here's some hints to get the most out of Gibon:

• Be specific: Clear requirements lead to better implementations.
• Include context: If you're asking Gibon to integrate with another API, provide an example call to the API in the issue description. Gibon currently can't reach your private company documents, so only links to public documentation will work.
• Define acceptance criteria: What does "done" look like? For a bug, a clear "actual" and "expected" descriptions work well to guide Gibon's investigation and the required solution. For features, make the scope clear, if there's something obvious that should be deferred until later, make that clear.

Example Task

Providing Feedback

Review Process

When Gibon creates a pull request, review it just like any teammate's work:

• Check the implementation against requirements
• Review code quality and patterns
• Verify tests are comprehensive
• Ensure documentation is updated
• Comments should be specific and actionable. Instead of "this looks wrong", try "this function should return a boolean instead of a string"

Use GitHub's Request Changes

On your first comment on a PR, be sure to press "Start a Review" when writing the comment.

Then, use the "Submit review" button in the top right and select Request Changes

Task Credits

Understand how Gibon's credit system works and track your usage effectively.

What Counts as a Task

• Initial implementation: Gibon's first attempt at implementing a feature or fixing a bug
• Feedback rounds: Each time you provide PR feedback and Gibon makes updates.

What's Free

• Errors: If Gibon fails to implement, the credit is refunded
• System downtime: Credits aren't consumed during service interruptions

Volume Discounts

Supported Languages

Gibon's implementation runtime supports the following languages. If your language isn't supported contact us and we'll look into adding it.

Additional Tools

The following tools are also available in the Gibon runtime and are available to your scripts

• curl
• bash
• make
• gcc
• g++
• patch
• ed
• sed

Supported Integrations

Common Errors

Troubleshoot common issues and learn how to resolve them quickly.

Task Assignment Issues

Task Not Picked Up

Problem: Gibon doesn't start working on an assigned issue

Solutions:

• Check the issue is properly assigned, Gibon should comment on the issue to acknowledge it was received. You should also see the issue in your queue in the WebApp
• Ensure your account has available task credits
• Gibon will only work on so many tasks concurrently within your organization and across all organizations. If tasks appear in the WebApp and are stuck in a queued state, most likely Gibon is working on something else at the moment. Simply wait, if the task isn't picked up after a few hours then contact support

Max Steps / Iterations

Problem: Task failed with a max iterations or max steps error

Solution: Gibon has a limit on the number of LLM iterations it will do for a task. This prevents infinite loops. Retrying the task usually works. However, if the task is extremely complex it may not be achievable within limits. Contact Support if you see this error frequently.

Code Quality Issues

CI Failing

Problem: Gibon's implementations don't pass CI builds

Solution:

• There's a difference between the commands in your gibon.yml and what you run in CI. Make sure they are aligned
• You may be running more robust tests in CI that are not in your gibon.yml file (e.g. Unit Tests vs. Integration Tests). Provide Gibon the feedback about the failing tests in the PR and it will fix them.

Code Style Violations

Problem: Implementation doesn't match your coding standards

Solution: Configure linting rules in your repository and provide examples of preferred patterns in your feedback.