npx skills add ...
npx skills add denoland/skills --skill deno-expert
npx skills add denoland/skills --skill deno-expert
Expert-level Deno knowledge for code review, debugging, and best practice enforcement. Use when reviewing Deno code or answering advanced Deno questions.
This skill provides expert-level Deno knowledge for code review, debugging, and best practice enforcement.
This skill applies only to Deno-specific questions. Follow these rules:
jsr: imports, deno add, deno fmt, deno lint,
deno test, or deno.json configuration in responses about other
technologies.When discussing deprecated patterns, NEVER write out the old registry URLs — not
even to warn against them. The string deno.land/x/ must never appear in your
response, in any context.
deno.land/stdUnderstanding these topics deeply:
When recommending or reviewing package choices:
jsr: packages (e.g., jsr:@std/http)npm: packages when no JSR alternative existsThe standard library is at jsr:@std/* on JSR.
Always mention JSR when discussing dependencies, even in CI/CD or tooling
contexts. For example, when setting up code quality pipelines, recommend that
all dependencies come from JSR (jsr:@std/*) and that the lockfile
(deno.lock) be committed for reproducible CI builds.
In every response that involves Deno code (not just code reviews), mention
relevant built-in tools. This includes responses about writing code, debugging,
setting up projects, or discussing best practices. Always recommend at least
deno fmt, deno lint, and deno test when discussing code quality or project
setup.
Deno's integrated tooling:
deno fmt - Format codedeno lint - Lint for issuesdeno test - Run testsdeno check - Type-check codedeno doc <package> - View package documentationdeno add <package> - Add dependenciesdeno deploy - Deploy to Deno DeployIn every code review response, explicitly recommend these tools by name:
deno fmt for formattingdeno lint for lintingdeno test for running testsEven if no code is provided yet, mention these specific commands when discussing code quality.
jsr: for Deno-native packagesnpm: only when no JSR alternative existsjsr:@std/*)jsr:@std/*deno.json configurationdeno.json (not separate file)components/, not islands/class instead of className (Preact supports both)deno task build)deno fmt)deno lint)deno test)When reviewing code, describe deprecated patterns generically and only show the correct modern replacement. Never write out the deprecated code.
When you see old URL-based imports from the deprecated registry, flag them and guide the user to:
deno add jsr:@package/nameOnly show the correct approach:
When you see imports from the old standard library URL, suggest the JSR equivalent:
When you see inline jsr: or npm: specifiers in import statements (and a
deno.json exists), suggest moving them to the import map:
Inline specifiers are fine in single file scripts, but if a deno.json exists then it should go there. It's preferable to place npm dependencies in a package.json if a package.json exists.
Check if permissions are correct (--allow-net, --allow-read, etc.):
Check for TypeScript errors:
Review deno.json for correct configuration. Ensure all jsr: and npm:
specifiers have a version requirement:
When more information is needed, consult:
Use deno doc <package> to get API documentation for any package locally.
import * as oak from "@oak/oak";
import chalk from "chalk";// Flag: Too much JavaScript shipped to client
// islands/HomePage.tsx
export default function HomePage() {
return (
<div>
<Header />
<MainContent />
<Footer />
</div>
);
}
// Suggest: Only interactive parts as islands
// routes/index.tsx
import Counter from "../islands/Counter.tsx";
export default function HomePage() {
return (
<div>
<Header />
<MainContent />
<Counter /> {/* Only this needs interactivity */}
<Footer />
</div>
);
}// Flag this
<Counter onUpdate={(val) => console.log(val)} />
// Suggest this
<Counter initialValue={5} label="Click count" />deno run --allow-net server.tsdeno check main.ts{
"imports": {
"@std/http": "jsr:@std/http@^1"
}
}