Contributing

Signalint and this documentation site are maintained in separate repositories. Open a focused contribution in the repository that owns the change:

• Signalint — MCP server, CLI, engines, tests.
• signalint-site — website, docs, search, and design.

Develop the MCP project

Use Node.js ≥ 22.12.0 and pnpm 11.9.0. The current runtime depends on built-in SQLite; older Node 20 setup advice does not apply to v1.

git clone https://github.com/TranQui004/signalint.git
cd signalint
pnpm install --frozen-lockfile

Run the available verification commands:

pnpm lint
pnpm typecheck
pnpm test
pnpm build

Read AGENTS.md for coding and test expectations. The project’s CI checks the supported Windows, Ubuntu, and macOS environments; inspect the current workflow for authoritative requirements.

Improve this website

git clone https://github.com/TranQui004/signalint-site.git
cd signalint-site
pnpm install --frozen-lockfile
pnpm dev

Before opening a website PR:

pnpm check
pnpm test:content
pnpm llms
pnpm build

The build validates authored documentation links and generates the Pagefind search index. Preview the built site to test search; search is not available in Astro development mode.

For interactive and accessibility checks, install the Playwright Chromium browser and run pnpm test:e2e after building. See the website README for details.

Keep technical docs accurate

When runtime behavior and a narrative document disagree, inspect the current implementation and tests before changing a public claim. In particular:

• Distinguish MCP tool payloads from CLI output.
• Treat clustering as a rule-based heuristic, not proven semantic causality.
• Label fixture metrics and their baselines explicitly.
• Document the limits of cache invalidation and local trust boundaries.
• Regenerate llms.txt and llms-full.txt after content changes.

Pull requests

Keep a PR scoped to one coherent change and explain how it was verified. Use conventional subjects such as fix(cache): ..., docs(clients): ..., or feat(site): ....

Do not bypass protected-branch checks. Release and deployment actions require maintainer approval; a local preview is not a release.

For MCP publication, follow the upstream release checklist rather than publishing from a developer machine.

Patch-release verification

The 1.2.1 source pins upstream CI/action dependencies to immutable SHAs and verifies package/server/action metadata and the packed artifact before publication. The reviewed development lockfile also updates Vitest to address advisory findings. Follow the living upstream release checklist; these website docs do not authorize publishing a package from this checkout or bypassing the gates.