Deno Agent Rules

A JavaScript and TypeScript runtime with integrated development tools.

Overview

Deno's CLAUDE.md explains the CLI, runtime assembly, native extensions, development commands, and test recipes. It shows how spec tests encode commands and expected output, requires incremental review history, and changes lint scope when Rust is touched.

Hard prohibitions Good and bad pairs House vocabulary Verification by change type Contribution etiquette

Documents

├── 
└── .github
    └──

Techniques in this file

01 / Hard prohibitions

Choose the harness by setup requirements

The guide explicitly warns against running JavaScript and TypeScript unit tests directly with the Deno binary. Cargo owns the setup those tests need.

175Do NOT run these directly with `./target/debug/deno test` — they depend on the176cargo test harness for correct setup.

02 / Good and bad pairs

Show the spec-test format

A directory contains the command description, input files, and expected output. The example covers both a single command and a sequence of steps, making the custom test format concrete.

1981. Create a directory in `tests/specs/` with a descriptive name1992. Add a `__test__.jsonc` file describing your test steps2003. Add any input files needed for the test2014. Add `.out` files for expected output (or inline in `__test__.jsonc`)

03 / House vocabulary

Explain the output-matching vocabulary

The guide distinguishes wildcards that span lines from those confined to one line, plus unordered blocks and literal character counts. These definitions help keep expectations specific around nondeterministic output.

247- `[WILDCARD]` : matches 0 or more of any character, like `.*` in regex. this248  can cross newlines249- `[WILDLINE]` : matches 0 or more of any character, ending at the end of a line250- `[WILDCHAR]` - match the next character251- `[WILDCHARS(5)]` - match any of the next 5 characters252- `[UNORDERED_START]` followed by many lines then `[UNORDERED_END]` will match253  the lines in any order (useful for non-deterministic output)254- `[# example]` - line comments start with `[#` and end with `]`

04 / Verification by change type

Select lint scope from the changed language

Non-Rust changes use the JavaScript lint path. Rust changes require the full lint command, so verification follows the affected surface.

29- Before committing, if only non-Rust was changed, make sure to run30  `tools/lint.js --js` and fix any lint errors before committing

05 / Contribution etiquette

Preserve incremental review history

The no-force-push rule explains that changes will be squashed at merge and reviewers need to see follow-up commits. It gives a concrete reason to keep the branch history intact.

35- When pushing updates to the PR, make sure to never force push. Create as many36  commits as you need, all of them get squashed when the PR is merged, so there37  is no need to rewrite history. This also allows reviewers to see the38  incremental changes you made in response to feedback.

Ideas for your repo

Name the harness responsible for test setup, even when tests use another language.
Include a minimal example of a custom test format.
Explain wildcard semantics before encouraging their use in expected output.
Map changed languages to the appropriate verification commands.
Explain how branch-history rules support the review process.