// Ensure KDocs are high quality, concise, active, and explicitly linked to API components.
| name | ktdoc_quality |
| description | Ensure KDocs are high quality, concise, active, and explicitly linked to API components. |
This skill enforces strict standards for Kotlin documentation (KDoc) in AndroidX. It eliminates verbose technical language (jargon and over-explanation) in favor of direct, active, and linked documentation.
Never use plain text for APIs, classes, or parameters if a link is possible.
[ClassName], [methodName], or [parameterName] for in-scope symbols.[package.path.ClassName]. Do not add imports for links.Apply these rules ruthlessly. Any violation is a documentation bug.
Ban introductory and explanatory fluff. Start immediately with the action.
Use the shortest, most common word. If you use a long or jargon word when a short one works, it is a bug.
Start every summary sentence with an active verb. Never use passive voice.
Keep the summary sentence (the first line) under 15 words. If it is longer, it is too verbose. Cut it.
Write for both the Novice (needs simple language/examples) and the Pro (needs raw specs/links).
@sample, or show a 2-3 line inline code block.@param, @return (start with lowercase, no trailing period).Study these examples to understand the target style:
/**
* Provides manual, programmatic control over the system's software keyboard (IME).
*
* Developers can obtain an instance of this interface using the local composition local
* `LocalSoftwareKeyboardController.current`. It is commonly utilized in specialized forms to
* programmatically hide the soft keyboard (e.g. when a background network submit completes, or when
* clicking custom done/search keyboard actions).
*/
/**
* Controls the software keyboard.
*
* Obtain an instance using [LocalSoftwareKeyboardController]. Commonly used to hide the
* keyboard (e.g., after submitting data to a network, or when executing custom actions).
*/
/**
* Forces the standard keyboard to display English/Latin characters.
*
* **When to use it**: Ideal for usernames, system database IDs, or passcodes where you want
* to prevent typos from non-latin layouts. *Note: Does not automatically disable
* auto-correct; use KeyboardOptions' auto-correct setting to control suggestions.*
*/
/**
* Forces the keyboard to display Latin characters.
*
* **When to use it**: Ideal for usernames, database IDs, or passcodes where you want to
* restrict input to Latin characters.
*
* Note: Unlike [Uri] or [Email], this type does not automatically disable auto-correct. Use
* [androidx.compose.foundation.text.KeyboardOptions.autoCorrectEnabled] to disable it.
*/
* @param capitalization Informs the keyboard whether to automatically capitalize characters, words
* or sentences. Only applicable to only text based KeyboardTypes.
* @param capitalization capitalization style to apply to text-based [KeyboardType]s
While conciseness is key, KDocs are API specifications. Do not sacrifice technical accuracy or critical behavior contracts for brevity.
Do not remove descriptions of how parameters interact, how states map to behaviors, or what data callbacks receive.
onTextLayout: callback run when text layout changesonTextLayout: callback run when a new text layout is calculated. The [TextLayoutResult] parameter contains paragraph information, size, baselines, and other details.Explain what a class or component does first. Do not define it solely by what it does not do or how it differs from another component.
SpanStyle: Only allows character-level styling. For paragraph styling see ParagraphStyle.SpanStyle: Styling configuration that applies at the character level (e.g. text color, font size, background color). For paragraph styling see ParagraphStyle.Always specify:
letterSpacing, specify that it uses SP or EM.baselineShift, explain it is a vertical shift (up/down).fontSynthesis, explain it falls back to bold/italic if the font family lacks the requested style.fontFeatureSettings).For complex validation rules (like paragraph arrangement/nesting) or pipeline data flows (like text transformation pipelines), use clear ASCII diagrams, lists, or structured examples to explain the behavior. Do not remove existing diagrams for the sake of brevity; they are critical for visual APIs.
When documenting multiplatform (commonMain) code, avoid platform-specific terminology (e.g., referring to "Android resources" in a common ResourceFont class) unless the API is explicitly platform-bound. Use platform-agnostic terms (e.g., "application or device resources").
Define text-specific jargon (like "collapsed range" or "soft wrap") in plain English. For example, explain that a collapsed range represents a cursor position (start equals end), or describe soft wrap as automatic text wrapping to fit the container.
When warning about potential layout bugs (e.g., character or accent clipping in tight line heights), provide concrete language examples with tall scripts (e.g., Arabic "العَرَبِيَّةُ", Tibetan "དབུ་ཅན་", or Burmese "မြန်မာဘာသာ") to make testing instructions actionable.
Use this skill to find Compose feature flags introduced by a specific git user or email and map them to the library version in which they were added.
A skill for building instrumented tests in Remote Compose using GridScreenshotUI.
A skill for building instrumented screenshot tests in Remote Compose using RemoteScreenshotTestRule.
A skill for creating, amending, formatting, and uploading commits in the AndroidX frameworks/support project
Scaffold a new RemoteCompose wear material3 component with test, sample, and preview
Scaffold a new RemoteCompose remote creation component with test, sample, and preview