메뉴
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 직업 분류 기준
| 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: ...Mandatory checks to run before completing any task that touches md files or dart code in this repository.
Instructions for adding a new validation rule and CLI flag to dart_skills_lint. Use this skill when asked to create a new rule that validates aspects of skills (like frontmatter metadata).
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.
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.
Use this skill when you need to set up validation for AI agent skills in a Dart project for the first time. Adds the linter as a dev_dependency, creates a configuration file, and generates a baseline for legacy repos.