// Contains well-defined rules for creating natural, accurate, and readable writing. Use whenever authoring longer text, like analysis documents, PR or CL descriptions, or documentation.
How to integrate, update, and configure the dart_skills_lint validation tool within a repository. Make sure to use this skill whenever the user asks to update dart_skills_lint, configure skills validation tests, fix skills linter dependency drifts, verify repository state before editing, optimize lint rules execution, or draft pull request submission commands.
Mandatory checks to run before completing any task that touches md files or dart code in this repository.
Use this skill when you need to set up validation for AI agent skills in a Dart project for the first time. This includes adding dependencies, configuring the linter, setting up tests, and creating a CI workflow.
Use this skill when you need to validate that AI agent skills meet the specification. This includes running the linter via CLI, authoring custom rules, and following the validation workflow.
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.
Use the `http` package to execute GET, POST, PUT, or DELETE requests. Use when you need to fetch from or send data to a REST API.
| name | natural-writing |
| description | Contains well-defined rules for creating natural, accurate, and readable writing. Use whenever authoring longer text, like analysis documents, PR or CL descriptions, or documentation. |
This document outlines strict rules to avoid common "AI-isms"—stylistic and structural patterns that language models typically fall into. Follow these rules to produce content that is more understandable, and reads as natural, human-authored text.
Avoid these words, which are statistically overrepresented in AI text. Use simpler, more direct alternatives.
Do not replace simple "is/are" verbs with flowery equivalents.
Do not use synonyms just to avoid repeating a subject's name (e.g., "the eponymous character," "the titular protagonist," "the celebrated author"). It is acceptable to repeat the name or use pronouns naturally.
Do not use relative temporal terms in code, variable names, function names, or comments. These words lose their meaning as the codebase evolves over time.
// This function now uses the config parser instead of hardcoding.// Resolves paths via [ConfigParser.loadConfig] to support custom config locations.Do not inflate the importance of a topic with vague praise. If a subject is important, the facts should demonstrate it without help.
Avoid attaching "dangling" present-participle phrases that offer vague commentary.
Maintain a neutral tone. Avoid "advertisement" words.
LLMs often end articles with a generic "Despite challenges... remains important" conclusion.
Do not treat a descriptive article title (like a list or broad topic) as a proper noun in the first sentence.
Do not populate "See Also" sections with broad, generic terms.
Do not use vague "weasel words."
Avoid sentences that structure a contrast unnecessarily.
Avoid listing exactly three adjectives or three noun phrases to sound "comprehensive."
Do not use "from X to Y" unless X and Y are endpoints of a logical scale (like time or size).
* **Header:** Description.... Use prose or simple lists.#, -) in lists. Use standard bullets (*).##) in formats that do not support it (like Wikitext), unless explicitly converted.", ') and straight apostrophes ('). Do not use curly/smart quotes (“, ’).Subject: ...