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

Memory

Gibon has its own internal memory for remembering what its done and learning over time. Memory is scoped to 3 tiers:

• Organization: These are things Gibon has learned about your entire organization, such as how repositories work together or coding standards that cross multiple repositories in your organization.
• Repository: Codebase specific insights such as the purpose of the repository, how code is organized, etc. This portion of memory is similar to markdown files you may find from other coding agents such as the claude.md, agents.md, or codex.md files.
• Task: Task memory is scoped to individual tasks, this is used for Gibon to remember important information and decisions it made during coding sessions so it can reference those when addressing feedback on tasks.

When a task is running, Gibon has access to the task level memory for that task, that task's repository, and your organization.

You an view all of Gibon's internal memory via the Gibon WebApp.

Subscription & Billing

Understand how Gibon's subscription works and manage your account.

Monthly Subscription

Gibon offers a simple flat-rate subscription:

• Price: $200 per month
• Includes: All Gibon features with 1 concurrent task execution
• Tasks: Unlimited tasks per month (processed sequentially)

Concurrent Execution

• 1 Task at a Time: Gibon works on one task at a time, completing it before moving to the next
• Unlimited Queue: Queue as many tasks as you need - they'll be processed sequentially
• No Task Limits: Complete as many tasks as you need each month

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

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 subscription is active
• With 1 concurrent task execution, Gibon works on one task at a time. If tasks appear in the WebApp and are stuck in a queued state, Gibon is working on another task. 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.