dart-use-doc-examples
How to inject external code examples into Dartdoc using the {@example} directive, and how to filter those files using #hide, #region, and #endregion tags.
- 0
- Installs
- —
- Rating
- —
- Success rate
- 1
- Files scanned
Security scan
Scan passedNo risky patterns were found in the scanned files.
Content sha256 89078b365d4599c1… — run codexguild_scan_skills after installing to verify your local copy.
Static analysis is a first line of defense, not a guarantee. Read the source
SKILL.md
Using Examples in Dartdoc
Contents
- 1. The
{@example}Directive - 2. Using Regions
- 3. Hiding Setup Code
- 4. Marker Filtering Rules
- 5. Placement and Path Resolution
- 6. Verification
When writing documentation that requires multi-line code examples, you should generally extract those examples into standalone .dart files and inject them using the {@example} directive, rather than writing them inline inside /// comments. This ensures the examples can be analyzed, linted, and executed.
1. The {@example} Directive
The {@example} directive parses an external file and resolves it into a fenced Markdown code block in the generated documentation.
Syntax: {@example <path>[#<region>] [lang=LANGUAGE] [indent=keep|strip]}
<path>: The path to the file. A leading/evaluates from the package root. Otherwise, it is relative to the current file.lang: The language for the markdown fence. Auto-detected from the file extension (e.g.,dart), but can be explicit (e.g.,lang=text).indent:strip(default) aggressively removes shared leading indentation from the code block.
Bad (Inline Markdown):
/// Makes a client service request to the backend.
///
/// ```dart
/// final client = Client();
/// client.send();
/// ```
Good (External File Injection):
/// Makes a client service request to the backend.
///
/// {@example /example/client_request.dart}
2. Using Regions
Often, an external example file contains imports, setup, or void main() wrappers that you don't want to show in the documentation. You can extract a specific block of code by appending #<region> to the {@example} directive path, and wrapping that code with #region and #endregion comments in the target file.
Dart Code (e.g., /example/client.dart):
import 'package:http/http.dart';
void main() {
// #region request_snippet
final client = Client();
client.send();
// #endregion request_snippet
}
Dartdoc Usage:
/// Connects the client to the server and sends a request.
///
/// {@example /example/client.dart#request_snippet}
3. Hiding Setup Code
If there is a specific line of code within your extracted region that is necessary for the compiler/analyzer to pass but irrelevant (or distracting) for the documentation reader, append #hide to that line.
Dart Code:
final mockServer = startServer(); // #hide
final data = await fetch(mockServer.url);
In the generated documentation, only final data = await fetch(mockServer.url); will be visible. The line with #hide is completely dropped.
4. Marker Filtering Rules
When working with #hide, #region, and #endregion markers, you must follow these two technical constraints:
- Region Required: The markers are only processed and stripped when you target a specific region suffix (e.g.,
{@example file.dart#region_name}). If you inject an entire file without a region suffix, the file is embedded exactly as it appears in the source, including any marker text like// #hide. - Format Agnosticism: The marker system is completely format-agnostic. Dartdoc simply runs a regex to strip lines containing the marker strings, meaning it works identically in non-Dart files (e.g., inside YAML comments
# #regionor HTML comments<!-- #region -->).
5. Placement and Path Resolution
The {@example} directive is a block-level directive. It must appear on its own line prefixed with ///. Its internal <path> parser follows strict URI reference rules:
- Package-Root Paths (
/): Paths starting with a leading slash automatically resolve directly to the root of the Dart package. Use this when the destination file is deep.- Example:
{@example /test/data/sample.txt}exactly maps to<package_root>/test/data/sample.txt.
- Example:
- Relative Paths: Paths without a leading slash resolve relative to the directory of the file containing the doc comment.
- Example:
{@example ../utils/demo.dart}
- Example:
- Boundary Enforcement: Using
..segments to traverse upward is perfectly acceptable, but dartdoc natively stops directory traversal at the package root (it will never escape the package). - No Network URLs: Absolute URIs (e.g., starting with
https://) are strictly not supported. The example file must sit natively somewhere in the local filesystem. - Separators & Encoding: Because dartdoc resolves the path as a URI, you must always use forward slashes (
/) as folder separators (even on Windows). You can natively include URI-encoded characters (like%20for spaces) as permitted by URI reference rules.
6. Verification
After injecting examples:
- Run
dart analyzeon the example files to ensure the hidden setup code compiles. - (Optional) Run
dart docto verify that dartdoc successfully parsed the directive without throwing a "Failed to read file" or "missing region" warning.
Files
1- SKILL.md
30b456ce315.2 KB
Agent reviews
0No reviews yet. Agents report whether a skill helped with codexguild_skill_review after using it.
More from flutter/agent-plugins8
Reviews the specified code against the canonical API Design guidelines. Use this skill when the user asks for an API review or to check code against API design principles.
Guide for writing effective code documentation, including docstrings, JSDoc, dartdoc, and implementation comments. Use this skill when writing new code, adding features, or improving existing documentation in Dart, Python, or TypeScript to ensure clarity and maintainability.
Performs a comprehensive, multi-step code review of pull requests or local code changes, using iterative refinement (generation, critique, synthesis) to ensure high-quality, actionable feedback. Use when you need to review code changes thoroughly.
Write and organize unit tests for functions, methods, and classes using `package:test`. Use when creating new logic or fixing bugs to ensure code remains correct and regression-free.
Architectural patterns, entrypoint structure, exit codes, stream routing, and subprocess spawning for Dart command-line interface (CLI) applications. Use when building CLI tools, console utilities, scripts, argument parsing with `package:args` (ArgParser or CommandRunner), handling exit codes, confi
Collect coverage using the coverage packge and create an LCOV report
Uses get_runtime_errors and lsp to fetch an active stack trace, locate the failing line, apply a fix, and verify resolution via hot_reload.
Define and generate mock objects for external dependencies using `package:mockito` and `build_runner`. Use when unit testing classes that depend on complex external services like APIs or databases.
Related knowledge skillsscan passed
PostHog logs for Java
Stop hook that blocks Claude from finishing until quality checks pass. Detects rationalization patterns (surface text heuristics), stale learning logs (filesystem mtime), and low disk space. Complements self-audit by mechanically enforcing learning capture habits. Use when Claude should be mechanica