القائمة
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.
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.
Upgrades Flutter's Android SDK dependency to a new Android API version (or preview/canary release) in packages.txt, verifies CIPD tag uniqueness, and packages/uploads the binaries using create_cipd_packages.sh across macOS, Linux, and Windows. Use whenever a user wants to pick up a new version of Android or upload Android SDK packages to CIPD.
Expertise in analyzing flake github issues in the flutter/flutter repository. Use when a user wants to analyze the flakiness of a specific link to a flutter github issue.
Rebuilds the Flutter tool and CLI. Use when a user asks to compile, update, regenerate, or rebuild the Flutter tool or CLI.
A skill to find the lowest Dart and Flutter release containing a given commit. Use this skill whenever users ask about when a commit landed in Flutter or Dart releases, inquire about release versions for specific SHAs, or want to know if a commit is included in stable, beta, or dev channels for Flutter/Dart projects.
Parse failures from Dart and Flutter test logs.
| 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: ...