Runtime Rules

Most rules are decided by one file: its structure, or its words. Some can’t be. They need to look across multiple files, compare code against configuration, or apply logic that matching a single file can’t express. Runtime rules cover those cases.

What a runtime rule is

A runtime rule is a directory under .taskless/rules/runtime/, named for the rule, that pairs ast-grep capture rules with a check.ts. The captures do the cheap work: if nothing matches, check.ts is never invoked. The check.ts then does the part no single-file engine can: hold two files at once, read git, resolve an alias, look outside the repository.

So a runtime rule can verify that every environment variable read in code is declared in .env, or that every i18n key used in source exists in each locale file.

Anatomy of a Rule has the directory layout and everything in it: the metadata.taskless block on a capture, the (root, matches) contract a check.ts exports, why a fixture case is a directory, and the three demands the engine makes of a rule (fixtures that fire a capture, a 10 second timeout, and verification before anything runs). This page is about why the engine is gated.

Runtime rules run as part of the same command as every other engine:

npx @taskless/cli check

Runtime rules and the other engines

	sg / vale rules	Runtime rule
Lives in	.taskless/rules/{sg,vale}/<id>/	.taskless/rules/runtime/<name>/
What it is	Inert data	ast-grep captures plus a check.ts
Executes code?	No	Yes, check.ts runs
When it runs	Always, offline, no account	Only when the check.ts is verified
Needs Cloud	no	yes
Decided by	One file	Evidence spanning or outside files

Why they’re gated

Because they execute code, not because of what they can express.

An sg or vale rule is inert data. Whatever is in it, the worst a malicious one achieves is a wrong finding, so taskless check runs them with no login, no network, and nothing to verify, because there is nothing to verify.

A runtime rule’s check.ts is a program that runs on your machine with your permissions. A rule file arriving in a pull request is code arriving in a pull request. So check signs each check.ts, reconciles that signature with the Taskless service, and runs only what comes back verified. Anything else is reported as skipped, with the reason.

On an ordinary local check while logged out, anonymous, or with no GitHub remote, runtime rules are reported but not run, while your other rules run normally.

This is a property of executing code. It says nothing about whether a runtime rule is more capable: sg and vale rules are not less trusted, they are unexecuted.

The Security page covers the model in full: how verification works when you’re logged in, what happens when you’re not, the CI enforcement backstop, and the deliberate escape hatch for running them unverified.

Authoring and checking

Runtime rules are authored through the same routing as every other engine:

npx @taskless/cli agent create-runtime-rule

See Authoring rules for how a rule’s destination is chosen, Engines for the full engine model, and Checking rules locally for how check reports runtime rules that were skipped because they weren’t verified.