ref-sp-js-denolisted

# Deno ## Purpose Provide portable defaults for modern Deno projects, especially when the codebase mixes Deno with Node-oriented tooling, needs a clean migration path from older Deno patterns, or is adopting Deno into an existing TypeScript or Node repository. ## When to use this skill - Writing Deno scripts, servers, or edge code. - Configuring `deno.json`, tasks, and dependency sources. - Adapting existing `tsconfig.json` or `eslint.config.*` files to coexist with Deno. - Mixing Deno code with Node or TypeScript code in one repository. - Reviewing Deno permissions, testing, or runtime patterns. ## Scope boundaries This skill owns the **Deno runtime**: `deno.json`, tasks, permissions, Node interop, and adopting Deno into a repo that already runs Node. - `ref-sp-js-typescript` — the type system itself. Deno runs TypeScript natively, but strict typing and runtime boundaries are a separate subject from the runtime that executes them. - `ref-sp-js-javascript` — plain JavaScript and JSDoc typing. - `ref-sp-js-react` and `ref-sp-js-next` — framework concerns, whichever runtime is underneath. - `ref-sp-dev-package-management` — dependency and version policy across manifests. ## Defaults - Use `deno.json` as the Deno source of truth. - Prefer `deno check`, `deno task`, `deno fmt`, `deno lint`, and `deno test` over ad hoc wrappers when Deno owns the workflow. - Deno's native tooling is sufficient for Deno-owned code; use Yarn only when the repository also has Node-managed