android-benchmark-comp…
Use when comparing physical Android benchmark configurations, investigating inconsistent rankings, or selecting an Android default from measured results. Do…
Use when drafting or revising text for the user to publish or send, including short review comments, replies, and evidence-led technical prose.
$ npx -y skills add chrisbanes/skills --skill grounded-writing --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/grounded-writingContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when drafting or revising text for the user to publish or send, including short review comments, replies, and evidence-led technical prose.
name: grounded-writing description: Use when drafting or revising text for the user to publish or send, including short review comments, replies, and evidence-led technical prose.
Make the reasoning visible at the scale the artifact supports. Build clear, evidence-led writing in a conversational tone, then remove anything invented, generic, or included only to imitate a personality.
1. Confirm that the text is for the user to publish or send. Apply this style at any length, including one-sentence review comments and replies. Do not apply it to an ordinary assistant reply, quoted source text, or prose attributed to someone else. 2. Read [the style profile](references/style-profile.md) before drafting or revising. 3. Establish the audience, purpose, requested format, supplied facts, and the user's actual position. Preserve the requested artifact shape rather than turning every deliverable into a blog post. 4. In public developer documentation, explain observable behaviour, setting choices, trade-offs, and relevant limitations. Keep implementation and test or diagnostic detail in internal references unless needed to use the API correctly or explicitly requested. Retain public contracts and the context needed to interpret claims. This does not apply to internal design documents or technical reports. 5. Resolve missing material before writing:
text, ask the user and stop drafting that part.
honestly. Never invent a first-person claim, result, preference, or memory. 6. Choose the register from the style profile. Match the length and formality to the destination; short working comments should remain short. 7. Shape the reasoning before polishing sentences. Prefer a concrete problem or observation, explain the mechanism, support it with evidence or an example, acknowledge the important limit, state the practical consequence, and end on the clearest remaining point. Omit any stage the artifact does not need. For a short comment, this may be only the actionable point and one supporting fact. 8. Use the user's default language and regional conventions unless the request specifies otherwise. Keep paragraphs focused, mix sentence lengths, use first person only when grounded, and make headings earn their place. 9. Edit once for style and once for truth. Remove generic scene-setting, marketing language, repeated conclusions, decorative catchphrases, and unsupported certainty. Treat the headline and opening claim as substantive: remove or qualify promotional framing that the supplied evidence does not directly support. 10. For a no-change review, name the material facts, mechanism, and qualification that make the existing text publishable. A bare “no edit needed” does not show that the truth and clarity checks were completed.
Finish only when all of these are true:
or clearly marked as missing.
a disclaimer.
conventions.
phrases, rhetorical questions, asides, or emoji.
If a check fails, revise the draft. If the failure depends on an unknown personal position, ask the user rather than smoothing over the gap.
A set of skills for Kotlin, Jetpack Compose, Android development, and grounded writing. The repository is also a portable Agent Plugins and the immediate skill directories under skills/.
Repo: chrisbanes/skills
Use when comparing physical Android benchmark configurations, investigating inconsistent rankings, or selecting an Android default from measured results. Do…
Use when writing or reviewing Jetpack Compose motion: visibility enter/exit, animating one property toward a target, color or size transitions, multiple…
Use when designing or reviewing reusable Jetpack Compose component APIs with modifier parameters, root layout placement, caller-provided variable content,…
Use when writing or reviewing Jetpack Compose UI for TV, keyboard, desktop, accessibility focus, D-pad navigation, FocusRequester, focusProperties, key events,…
Use when investigating Jetpack Compose recomposition cost, compiler stability reports, skippability, unstable parameters, frame-rate State reads, cross-phase…
Use when writing or reviewing Jetpack Compose state ownership, remember state, state hoisting, screen state holders, LaunchedEffect, DisposableEffect,…