> ## Documentation Index
> Fetch the complete documentation index at: https://docs.harborframework.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Contributing

> Contributing documentation for Harbor.

Harbor welcomes community contributions. This guide describes how Harbor manages issues and PRs and how to contribute in a way that is likely to be accepted.

# Golden Rule

We've adopted [Ghostty's golden rule](https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md): **you must understand the code you contribute**. Feel free to use coding agents liberally, but you are in charge of demonstrating an understanding of your code.

How to demonstrate an understanding:

* Write your own PR descriptions
* Document your design process including approaches and tradeoffs
* Propose clean code with good abstractions (coding agents don't do this without a heavy hand)
* Disclose which agents were used and to what extent

As models improve, we may loosen this constraint. In an ideal world, we could trust the agents without needing to understand code ourselves. In our experience, this is not currently the case.

# Communication

Code can be written by agents. Docs, PR descriptions, issues, and comments should be written by a human with AI assistance.

A general guideline for written communication: **you are in charge of the *first* draft and the *last* draft but can use agents in between**.

# Issues

The issues section is to report bugs and request features.

In line with our communication standards, please write the first and last draft of your issue description and feel free to use agents in between.

You must understand the *problem* but do not need to propose a solution. Because implementation is easier than ever, issues are often better than a PR.

# PRs

## Agents, Sandboxes, and Plugins

We are fairly liberal with integrations. All that we require is that at least one *user* has asked for the integration so please provide evidence of that (e.g. by having them leave a comment).

We are slightly less liberal with plugins and only plan to maintain plugins with high demand.

## Interfaces and Core Logic

We are unlikely to change interfaces or core logic without first discussing a design. This is especially true for Harbor format.

To open a design discussion, create a PR with an RFC. The RFC should be **concise** and written by a human with AI assistance. If an RFC is slop, we will close it.

RFCs should be placed in the `rfcs/` directory and follow the existing naming convention.

# CHANGELOG.md

For a **major feature** or **breaking change**, add a concise bullet under
**Unreleased** in `CHANGELOG.md`. Otherwise, do not edit it.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.