Contribute to Critiq OSS

#Where to contribute

Critiq OSS is split across two public repositories. Put CLI runtime, configuration, formatting, and command-surface changes in critiq-core. Put shared catalog rule additions, fixes, and rule specs in critiq-rules.

Choose the smallest repository boundary that matches the change. That keeps reviews focused and avoids mixing runtime behavior with catalog policy updates in one pull request.

#Contribution workflow

1. Open an issue or start from a documented bug or missing rule.
2. Fork the relevant OSS repository and create a focused branch.
3. Implement the smallest change that proves the behavior.
4. Run the local checks for the area you changed.
5. Open a pull request with before-and-after examples.

Keep pull requests narrow. A single rule fix, one new CLI behavior, or one documentation improvement is easier to review and safer to release than a mixed batch of unrelated changes.

#Local setup

The docs site in this workspace is built with Nx and Vite. Install dependencies once, then use the project targets directly while editing docs or validating contribution guidance.

npm install
npx nx dev docs
npx nx test docs
npx nx build docs

#Validate changes

Match the checks to the area you touched. Docs changes should still pass the docs app test and build. Rule catalog changes should also keep the generated rules snapshot current.

npx nx test docs
npx nx build docs
npm run docs:generate-rules

For rule authoring work, also validate the rule files and specs in the target repository before opening the pull request.

#What belongs in OSS

• Deterministic CLI behavior and stable JSON output.
• Public catalog rules with clear evidence and remediation text.
• Rule specs that prove both detection and non-detection.
• Docs that describe the published OSS surface area accurately.

Avoid putting hosted-product concerns into the OSS repos. The open source boundary should stay explainable: installable packages, public rules, deterministic checks, and docs that match what contributors can run locally.

#Docs updates

When you change a command, add a new rule workflow, or clarify a contributor path, update the docs in the same change set. The docs site is part of the public contract and should move with the behavior it describes.

Prefer concrete examples over abstract guidance. If a contributor needs to run a command, show the command exactly. If a route or page changes, add or update the route test with it.

#Next links