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: Static and Runtime Rules

check runs two kinds of rule, and they behave differently (see The Two Kinds of Rule):

• Static rules (.taskless/rules/) are inert ast-grep patterns. They always run in every mode, offline, with no account.
• Runtime rules (.taskless/runtime-rules/) 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. Your static rules still run normally.

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	Run only static rules; skip runtime rules entirely
--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? }. 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-parity", "reason": "not verified (logged out)" }]
}

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

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.