Contributing code

How to get a pull request merged, the rule for feature PRs, and the required AI disclosure.

Start here

The full contributor guide lives in the repository: CONTRIBUTING.md. It is the authority on setup, repository layout, tests, commit format and review. This page is the short version.

Before you write code

Bug fix. Find or open the GitHub issue first, then reference it with Fixes #123 in your pull request.
Documentation fix. Just open the pull request.
New feature. Make sure a request for it exists on this portal and has reached Accepted before you start building.

On the third point: if you open a feature pull request without an accepted request, it is labelled needs-accepted-request and we link the feedback post. We will not close it. Once the request is accepted, it gets reviewed normally.

We would much rather tell you a feature is not going to happen before you spend a weekend on it than after.

AI-assisted contributions

AI-assisted contributions are welcome. Disclosure is required.

PatchMon publishes its own AI Declaration, following the AI Declaration Standard v0.1.2, setting out exactly how AI is used to build the project. We ask contributors to be equally transparent.

When you must disclose

Disclose if AI was used in any meaningful way, including:

Generating code, tests or documentation
Writing commit messages or the pull request description
Agentic or multi-step workflows
AI-driven refactoring

Editor autocomplete and spell-checkers do not need disclosure.

What to include

Add this block to your pull request description:

## AI Disclosure

- **Used AI:** yes / no
- **Model(s):** e.g. Claude Opus 4.7, GPT-5, Gemini 2.5 Pro
- **Harness / tool:** e.g. Claude Code CLI, Cursor, Copilot, Windsurf, ChatGPT web, n8n workflow
- **Scope:** what AI produced (code / tests / docs / commit messages / full PR / partial)
- **Human review completed:** yes / no, who reviewed and what was checked

If you did not use AI, one line is enough:

## AI Disclosure

No AI used.

Your responsibilities

You remain fully responsible for any code you submit, AI-assisted or not:

You have read every line of the change, not just the diff summary
You understand what it does and can answer review questions without re-prompting the AI
You have run the tests and linters locally. AI-generated code that has not been executed is not acceptable
You have verified factual claims. Invented APIs, hallucinated package names, fabricated documentation links and typosquatted dependencies are common AI failure modes. Check every dependency name against its official source
Security-sensitive code (authentication, permissions, input validation, cryptography, secrets handling) gets extra scrutiny. Flag AI involvement clearly
Licences and attribution are your responsibility

Disclosure is used for review context, not as a judgement. Undisclosed AI use discovered during review will delay the pull request and may result in it being closed without merge.

Types of pull request

Type	What happens
Bug fix	Must reference `Fixes #N`. Reviewed by the core development team.
Documentation	Reviewed for accuracy and clarity.
Feature with an Accepted request	Normal review.
Feature with no Accepted request	Labelled `needs-accepted-request`. Not merged, not closed.

Our current focus: stability

The next few release cycles prioritise stability over new features. Feature pull requests raised during this period may be labelled deferred-stability-phase and revisited later.

That is a scheduling decision, not a rejection.

What we look for

One change per pull request
Under 400 lines changed is easy to review. Over 1000 lines, discuss with maintainers on Discord first
Tests covering new functionality
Conventional Commits format, for example feat(patching): or fix(auth):
Lint and tests passing locally. make check for Go, npx biome check src/ for the frontend
Documentation updated in the same pull request for user-facing changes

Security issues

Do not open a public GitHub issue for a security vulnerability. Report it privately by either:

Opening a private security advisory
Emailing support@patchmon.net

Include a description, steps to reproduce or a proof of concept, the affected version or commit, and your disclosure timeline preferences. You will get an acknowledgement within two business days.