Contributing and support

Where to ask for help, how to report a bug or a misbehaving skill, how to report a vulnerability, and how a change gets in.

.md

Getting help

The manual you are reading, starting with Troubleshooting.
GitHub Issues for bugs, skill problems and feature requests. Run scoutjobs doctor first and paste its output; the templates ask for it.
GitHub Discussions for questions and how-you-use-it threads.

Never paste profile.md, scoutjobs.db, application folders or a real employer’s posting. Redact names and salaries.

Reporting a vulnerability

Do not open a public issue. Use private vulnerability reporting on GitHub. What counts as a security issue, the scope and the response times are in SECURITY.md in the repository; the short list is in Security and privacy.

Contributing

Code, docs and skills are welcome. The rules every change keeps, the pull request checklist and the release process are in CONTRIBUTING.md; the project roles and how decisions are made are in GOVERNANCE.md; the code of conduct is in CODE_OF_CONDUCT.md. All three are at the root of the repository.

The short version:

Open an issue before anything bigger than a bug fix.
Git flow, always: branch from develop (feat/, fix/, docs/), one topic per pull request, Conventional Commits, rebase on develop, pull request against develop. main only receives release and hotfix merges; nothing is pushed to it directly. The branch table and the step-by-step are in CONTRIBUTING.md.
Pull requests into develop run a short CI job; the full matrix runs for releases. Run make test and make lint locally first.
make test, make lint and claude plugin validate . pass. New CLI commands and API endpoints come with a test and a row in CLI or JSON API and webhook.
A new skill follows Writing a new skill and gets an eval case when it makes claims, sends something or reads a posting.

Edit this page Last updated October 11, 2026