Checking Rules Locally

Once you have rules in your .taskless/ directory, you can run them locally to catch issues before they reach code review.

Running a Check

Use the Taskless CLI to run all applicable rules against your codebase:

npx @taskless/cli check

This scans your codebase and reports any matches. The command exits with code 1 if any error-severity matches are found, making it suitable for CI pipelines. You can scope the scan to specific paths:

npx @taskless/cli check src/foo.ts src/bar.ts

Paths that don’t exist on disk are silently filtered, so you can pipe a raw git diff straight in:

npx @taskless/cli check $(git diff --name-only main...HEAD)

What Runs

check runs the rules Taskless owns, and they behave differently by engine (see Engines):

• sg rules (.taskless/rules/sg/) are inert ast-grep patterns. They always run, in every mode, offline, with no account.
• vale rules (.taskless/rules/vale/) are equally inert, and also always run. Checking prose needs no account.
• Runtime rules (.taskless/rules/runtime/) execute a check.ts, so they run only when that code is verified. When you’re logged out, pass --anonymous, have no GitHub remote, or the service is unavailable, runtime rules are reported but not run. Everything else still runs normally.

check does not run your linters. A rule authored into ESLint, Ruff, RuboCop, or Stylelint is enforced by that tool in your own lint step. Taskless writes it, your toolchain runs it.

check itself never requires authentication. For the full verification model, and why runtime rules are gated this way, see Security.

Flags

Flag	Effect
--json	Machine-readable output (see below)
--anonymous	Skip runtime rules entirely; sg and vale rules still run
--dangerously-run-scripts	Run runtime rules without server verification, trusting local signatures
--timeout <seconds>	Per-runtime-check wall-clock bound (default 10)

--dangerously-run-scripts is a deliberate escape hatch that runs unverified code. See Security before using it.

JSON Output

For machine-readable results, add --json:

npx @taskless/cli check --json

The output is { success, results, skipped?, notices? }. When runtime rules were present but not run (for example, because you’re logged out), the additive skipped array lists them:

{
  "success": true,
  "results": [],
  "skipped": [{ "rule": "env-read", "reason": "not verified (logged out)" }]
}

Surface skipped so a pipeline can tell that runtime rules did not execute. It never affects the exit code.

notices is the other advisory array, present only when there is something to say. Today it names a file over 128KB that a Vale rule’s own scope would have reached and that check skipped rather than let one oversized document consume the whole Vale run’s time budget. A prose file that Vale cannot parse (broken front matter, for instance) is different: it is reported as a per-file finding with ruleId: "vale-parse-error" and every other file’s findings are still returned, where an earlier CLI lost the whole run to it.

Exit Codes

• 0: all checks passed, no rules configured, or all supplied paths were missing.
• 1: at least one error-severity match, or the scan itself failed.

Skipped or withheld runtime rules are reported. They never change the exit code; only actual error-severity findings do.

Running in CI

Add a taskless check step to your pipeline so rules run on every push and pull request. See Continuous Integration for the patterns (full scan vs diff scan), a GitHub Actions reference, and how to enable server-enforced runtime rules in CI.

Using Rules with Agents

When you have agent skills installed (see Using Agent Skills), rules from .taskless/ are automatically available to your coding agents. The agents reference these rules during code generation to avoid patterns your team has already flagged.