القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Guidelines and format for writing pull request descriptions in this repository. Use this skill whenever the user asks you to draft a pull request description, submit a PR, or update a PR description.
Validates an in-progress PR or feature branch of dart_skills_lint against known downstream ecosystem consumers. Use when assessing breaking changes across external repositories during PR evaluation, testing migrations against the changelog, or determining necessary backwards compatibility shims.
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.
Use this skill when you need to validate AI agent skills with dart_skills_lint — running the linter, interpreting failures, fixing violations, and authoring custom rules.
A deliberately broken fixture used by example/README.md to show what each rule's error output looks like.
Reference fixture for dart_skills_lint. Demonstrates a SKILL.md that passes every default rule: hyphen-lowercase name matching the parent directory, a properly sized description, and no other frontmatter fields that would trigger the disallowed-field check.
| 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: ...