New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Debugging Recompositions

by rosuH in rosuH/EasyWatermark

A skill your agent uses to find which Jetpack Compose composables are recomposing and why, using Android Studio Layout Inspector recomposition counts and skip counts, the per-parameter Argument…

Apache-2.0Auto-check passedMobile

Install Debugging Recompositions

skills CLI
$ npx skills add rosuH/EasyWatermark --skill debugging-recompositions -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install rosuH/EasyWatermark debugging-recompositions --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/rosuH/EasyWatermark.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/debugging-recompositions .claude/skills/debugging-recompositions && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
debugging-recompositions
GitHub stars
1.9k
Used in
1 other repo
Token cost
~4.3k tokens
SKILL.md length
1,623 words
Files
1
Skills in repo
28
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses to find which Jetpack Compose composables are recomposing and why, using Android Studio Layout Inspector recomposition counts and skip counts, the per-parameter Argument…

  • Works in 5 steps: Enable recomposition counts in Layout… → Reproduce the symptom while watching… → Inspect Argument Change Reasons → …
  • Find which Jetpack Compose composables are recomposing and why
  • SKILL.md covers When to use this skill, When NOT to use this skill, Prerequisites and Workflow, plus 4 more sections
  • Calls adb

What it does

Debugging Recompositions is an agent skill from rosuH/EasyWatermark. Use this skill to find which Jetpack Compose composables are recomposing and why, using Android Studio Layout Inspector recomposition counts and skip counts, the per-parameter Argument Change Reasons (Changed / Unchanged / Uncertain / Static / Unknown) introduced in Android Studio Hedgehog and later, and runtime @TraceRecomposition from compose-stability-analyzer for production-like measurement. Walks through enabling counts, mapping each Argument Change Reason to a fix, and confirming the result in a release…

Its SKILL.md is about 4.3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Mobile, covering Android development, App store release and Debugging. It works with Jetpack Compose. The repository describes itself as: 🔒 🖼 Securely, easily add a watermark to your sensitive photos. 安全、简单地为你的敏感照片添加水印，防止被人泄露、利用. The licence is Apache-2.0.

When your agent uses it

  • Find which Jetpack Compose composables are recomposing and why
  • Using Android Studio Layout Inspector recomposition counts and skip counts
  • Runtime @TraceRecomposition from compose-stability-analyzer for production-like measurement
  • The developer says this should be skipping but isnt

Example prompts

  • “this should be skipping but isn”
  • “I want to see recomposition counts”
  • “Uncertain”
  • “/debugging-recompositions”

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Enable recomposition counts in Layout Inspector
  2. Reproduce the symptom while watching counts
  3. Inspect Argument Change Reasons
  4. Map status to action
  5. Confirm in release with @TraceRecomposition

What it can do on your machine

Read from SKILL.md and the folder at commit 61223db. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • adb

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • medium.com
    • developer.android.com
    • chrisbanes.me
    • github.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Debugging Recompositions loads about 4.3k tokens when it runs. Until then it costs about 199 tokens; SKILL.md has 1,623 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~199
When it runs · the whole SKILL.md, loaded when a task matches
~4.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from rosuH/EasyWatermark at commit 61223db, republished under its Apache-2.0 licence (© rosuH). 1,623 words, ~4,259 tokens.

Download SKILL.mdSave it as .claude/skills/debugging-recompositions/SKILL.md (or your agent's skills folder).
name
debugging-recompositions
description
Use this skill to find which Jetpack Compose composables are recomposing and why, using Android Studio Layout Inspector recomposition counts and skip counts, the per-parameter Argument Change Reasons (Changed / Unchanged / Uncertain / Static / Unknown) introduced in Android Studio Hedgehog and later, and runtime `@TraceRecomposition` from `compose-stability-analyzer` for production-like measurement. Walks through enabling counts, mapping each Argument Change Reason to a fix, and confirming the result in a release build. Use when the developer says "this should be skipping but isn't", "I want to see recomposition counts", asks what "Uncertain" or "Unknown" means in the inspector, or needs to confirm a stability or strong-skipping fix actually worked end-to-end.
license
Apache-2.0. See LICENSE for complete terms.
metadata.author
Jaewoong Eum (skydoves)
metadata.keywords
jetpack-compose, performance, recomposition, layout-inspector, argument-change-reasons, trace-recomposition, android-studio-hedgehog, debugging…

Debugging Recompositions — make the invisible visible, then map status to action

Recomposition is invisible by default. A composable that re-runs sixty times a second to redraw an animation looks identical in source to one that should re-run zero times when its parent ticks. Three layers of instrumentation make it visible: Layout Inspector recomposition counts and skip counts (Android Studio, debug build), Layout Inspector Argument Change Reasons (Hedgehog and later, per-parameter Changed / Unchanged / Uncertain / Static / Unknown classifications), and runtime @TraceRecomposition from compose-stability-analyzer for release / R8 / real-device measurement.

This skill is the diagnostic layer. It does not fix recompositions; it tells the developer which composable is recomposing and which parameter is responsible. Once the param is named, the fix lives in a sibling skill — stability for unstable types, strong skipping for lambda capture, or phase deferral for state reads in the wrong phase.

When to use this skill

  • The developer says "this should be skipping but it's not" or "this re-runs every time the parent ticks".
  • The developer wants to count recompositions of a specific composable to confirm a fix worked.
  • The developer asks what "Uncertain", "Unknown", "Static", or "Unchanged" means in the Layout Inspector recomposition reasons panel.
  • A PR claims a stability or strong-skipping fix; the reviewer needs to confirm the recomposition actually went away in release.
  • The user mentions "recomposition count", "Layout Inspector", "Argument Change Reasons", "Hedgehog", "@TraceRecomposition", or "why is this recomposing".

When NOT to use this skill

  • The composable is recomposing because of an unstable type — once this skill names the offender, the actual fix is in ../../stability/diagnosing-compose-stability/SKILL.md and ../../stability/stabilizing-compose-types/SKILL.md.
  • The composable is recomposing because of a lambda capture or non-skippable scope — fix work lives in ../using-strong-skipping-correctly/SKILL.md.
  • The composable is recomposing because a state read happened in the wrong phase (Composition vs Layout vs Draw) — fix work lives in ../deferring-state-reads/SKILL.md.
  • The team needs a CI gate against future regressions — use ../../stability/enforcing-stability-in-ci/SKILL.md.

Prerequisites

  • Android Studio Hedgehog (2023.1.1) or later for Argument Change Reasons. Earlier Studio versions have recomposition counts but not the per-parameter reason panel.
  • A debug build for Layout Inspector (Layout Inspector requires debug). Read counts as directional signal only; debug builds run interpreted with Live Literals which inflate recomposition counts.
  • androidx.lifecycle:lifecycle-runtime-compose available so collectAsStateWithLifecycle can replace plain collectAsState when a flow turns out to be the offender.
  • For release-mode confirmation: the runtime tracing setup from ../../measurement/tracing-recompositions-at-runtime/SKILL.md (the compose-stability-analyzer runtime + ComposeStabilityAnalyzer.setEnabled(true) in Application.onCreate).
  • Familiarity with the Compose Compiler reports format (see ../../stability/diagnosing-compose-stability/SKILL.md) — Layout Inspector classifications mirror the same stability vocabulary.

Workflow

1. Enable recomposition counts in Layout Inspector

Run the app on a connected device or emulator in debug. Open Android Studio → Tools → Layout Inspector. In the Layout Inspector toolbar, toggle:

  • Show recomposition counts — adds a "Recompositions" column to the component tree and overlays a count badge on the rendered tree.
  • Show recomposition skip counts — adds a sibling column showing how many times the composable's skip guard fired (i.e. it was invoked but its body was skipped).

Both are off by default. With both on, the tree displays <recompositions>/<skips> per node, which is the primary signal.

The healthy ratio is "skips ≫ recompositions". A composable with 100/0 (one hundred recompositions, zero skips) is the smoking gun — every parent tick re-ran its body without any skip guard firing. A composable with 100/95 is doing fine — only five recompositions triggered actual work.

2. Reproduce the symptom while watching counts

Counts are cumulative. Reset them via the Layout Inspector "Reset" button before reproducing. Then perform the user action that the developer suspects is causing the jank — scroll, tap, animation tick — and watch which composables' counts climb.

The composable with the disproportionate count growth is the suspect. Note its name and parameter list before moving on.

3. Inspect Argument Change Reasons

Click the suspect composable in the Layout Inspector tree. The right-hand panel now shows a "Recomposition reasons" section listing each parameter with one of five classifications:

StatusMeaningLikely action
StaticCompile-time constant; never invalidates.None. This param is not the cause.
UnchangedValue compared equal to the previous composition (same identity or equals).None. This param did not trigger the recomposition.
ChangedValue compared not-equal to the previous composition.Investigate whether the change was meaningful or accidental (e.g. a copy() with identical content failing equals because a field is MutableList).
UncertainCompose cannot determine whether the parameter changed since the last composition; typically the param type is unstable to the compiler so the runtime fell back to identity equality (===) and the comparison was inconclusive.Stabilize the type (annotate with @Stable / @Immutable, or replace List<T> with ImmutableList<T> / PersistentList<T> so structural equals applies) — or accept the recomposition.
UnknownThe compiler could not statically classify the type's stability. The runtime fell back to ===.Run ../../stability/diagnosing-compose-stability/SKILL.md to find why the type is unclassified — usually a separately-compiled module without @StabilityInferred, an interface, or an unannotated POJO from a Java library.

The status names what to do next; do not jump to a fix without naming the status.

4. Map status to action

Decision tree once a status is identified:

  • Status = Changed. The value really did change. Ask whether the change was meaningful: did the user input change, or did copy() produce a structurally-different object the developer thought was identical? Common offender: a Flow collected without distinctUntilChanged() emitting equal values that fail reference equality.
  • Status = Uncertain. Identity changed, content might match. Annotate the type or use a stable collection. See ../../stability/stabilizing-compose-types/SKILL.md. Frequently the smoking gun for an instance-equality miss after a data class copy().
  • Status = Unknown. The compiler did not classify. Run the stability diagnosis. See ../../stability/diagnosing-compose-stability/SKILL.md. Most common causes: interface-typed parameter, separately-compiled Java POJO, generic parameter with no instance to substitute.
  • Status = Static. No action; the param is a compile-time constant.
  • Status = Unchanged. No action; the param was equal across the recomposition. The cause must be elsewhere (another param, or the parent's restart scope re-invoking unconditionally).
Show full SKILL.md (653 more words)Show less
5. Confirm in release with @TraceRecomposition

Layout Inspector counts come from a debug build. Debug builds have Live Literals (constant values become getters), interpreted Compose runtime, and no R8. Counts are useful as a directional signal but not as a final number. For release-mode confirmation, instrument the suspect composable with @TraceRecomposition from compose-stability-analyzer and re-run the scenario on a release + R8 build. Cross-link ../../measurement/tracing-recompositions-at-runtime/SKILL.md for the full setup; the two-line summary:

kotlin
@TraceRecomposition(traceStates = true)
@Composable
fun SnackRow(snack: Snack, onClick: (Long) -> Unit) { /* ... */ }

Logcat under Recomposition tag will print one line per recomposition, with each parameter and whether it changed. The release-mode count is the ground truth; quote it (not the debug count) when reporting that a fix worked.

Patterns

Pattern: do not draw conclusions from debug counts alone
text
# WRONG
"Layout Inspector shows SnackRow at 100/0 in debug — fix shipped."

# WRONG because: debug builds run interpreted with Live Literals turning constants into
# getters that defeat compile-time folding and inflate recomposition. The same composable
# in release + R8 may run 5/95. Always confirm the final number in release with @TraceRecomposition.
text
# RIGHT
"Layout Inspector showed SnackRow at 100/0 in debug. After the fix, debug shows 5/95
and release-mode @TraceRecomposition confirms 0 recompositions across a 30-frame scroll."

See ../../measurement/testing-compose-in-release-mode/SKILL.md for why debug counts lie.

Pattern: name the status, then act
text
# WRONG
"FilterBar is recomposing too much. I'll mark Filter @Stable and see if it helps."

# WRONG because: the developer skipped naming the Argument Change Reason. If the status was
# Unknown, the type needs classification (probably from an external module); if it was
# Uncertain, the type needs @Immutable + ImmutableList; if it was Changed, the upstream
# producer is mutating where it shouldn't. Each requires a different fix; guessing wastes a cycle.
text
# RIGHT
"FilterBar is recomposing per-frame. Layout Inspector reports the `filter` param as Uncertain.
The Filter type holds List<String>; replacing with ImmutableList<String> + @Immutable should
let equals() catch structural equality. Confirm with @TraceRecomposition in release."
Pattern: ignoring "Uncertain" is the most common mistake

"Uncertain" is the single most diagnostically-rich status. It says: "the compiler thought this type was stable, the runtime ran the comparison, and identity differed." That is almost always a copy() or a builder producing structurally-equal-but-identity-different instances, plus an equals that does not apply because a sub-field is unstable.

kotlin
// WRONG — declared @Immutable but the field is mutable
@Immutable
data class Filter(val tags: List<String>, val sort: SortOrder)
// WRONG because: List<String> is unstable; @Immutable is a contract the developer broke.
// Layout Inspector reports `filter` as Uncertain on every recompose; structural equals
// does not run because a sub-field is unstable.
kotlin
// RIGHT
@Immutable
data class Filter(val tags: ImmutableList<String>, val sort: SortOrder)
Pattern: chain into runtime tracing for end-to-end confirmation
kotlin
// RIGHT — annotate the suspect, run release with R8, capture logcat
@TraceRecomposition(traceStates = true)
@Composable
fun FilterBar(filter: Filter) { /* ... */ }
bash
adb logcat -s Recomposition:D
# Expected after the fix: a single "[Recomposition #1]" on initial composition,
# then no further entries during the scroll scenario.

See ../../measurement/tracing-recompositions-at-runtime/SKILL.md for the full instrumentation skill.

Pattern: use the skip count, not the recompose count, as the health metric

A composable at 0/0 is dead code or never reached. A composable at 100/0 is broken. A composable at 100/95 is healthy — only five real recompositions out of one hundred parent ticks. The skip-to-recomposition ratio is the metric to track over time, not the absolute count.

Mandatory rules

  • MUST name the Layout Inspector Argument Change Reason status (Changed / Unchanged / Uncertain / Static / Unknown) when reporting a recomposition finding. "It recomposes a lot" is not a finding; "param filter is Uncertain on every parent tick" is.
  • MUST NOT treat debug Layout Inspector recomposition counts as the ground-truth number. Debug uses interpreted Compose + Live Literals; the count is directional only. Confirm in release with @TraceRecomposition.
  • MUST reset Layout Inspector counts before reproducing the scenario. Cumulative counts from earlier app states pollute the diagnosis.
  • MUST map each status to the correct sibling skill: Uncertain / Unknown → ../../stability/diagnosing-compose-stability/SKILL.md, Changed (lambda capture) → ../using-strong-skipping-correctly/SKILL.md, Changed (state read in wrong phase) → ../deferring-state-reads/SKILL.md.
  • MUST NOT ignore "Uncertain". It is the most common smoking gun for an @Immutable contract violated by a mutable sub-field.
  • PREFERRED: chain a Layout Inspector finding into ../../measurement/tracing-recompositions-at-runtime/SKILL.md for end-to-end release confirmation.
  • PREFERRED: when reporting "the fix works", quote the skip-to-recomposition ratio (e.g. "100/95" or "0 recompositions across a 30-frame scroll") rather than a raw recomposition count. The ratio survives across debug/release, the raw count does not.

Recomposition is invisible by default; the Layout Inspector + Argument Change Reasons + @TraceRecomposition triple is the diagnostic stack. Skippability remains a diagnostic, not a KPI — the goal is "no surprising recompositions on the user-perceived hot path", not "zero recompositions everywhere".

Verification

  • Layout Inspector "Show recomposition counts" and "Show recomposition skip counts" both toggled on.
  • Counts reset before reproducing the scenario.
  • Suspect composable identified by disproportionate growth in the Recompositions column relative to skip count.
  • Argument Change Reasons panel inspected for the suspect; per-parameter status (Changed / Unchanged / Uncertain / Static / Unknown) named in the report.
  • Status mapped to the correct sibling fix skill; fix applied; baseline (../../stability/enforcing-stability-in-ci/SKILL.md) updated if applicable.
  • @TraceRecomposition in a release + R8 build confirms the post-fix recomposition count matches the developer's expectation. Debug numbers were directional; this is the final number.

References

For the upstream stability fix when the status is Uncertain or Unknown, see ../../stability/diagnosing-compose-stability/SKILL.md and ../../stability/stabilizing-compose-types/SKILL.md. For lambda-capture causes of Changed, see ../using-strong-skipping-correctly/SKILL.md. For confirming a fix in a release + R8 build, see ../../measurement/tracing-recompositions-at-runtime/SKILL.md and ../../measurement/testing-compose-in-release-mode/SKILL.md. For preventing future regressions, see ../../stability/enforcing-stability-in-ci/SKILL.md.

© rosuH, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/debugging-recompositions of rosuH/EasyWatermark.

Open the folder on GitHubat commit 61223db

Used in 1 other repository

We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in rosuH/EasyWatermark, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Debugging Recompositions next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Debugging Recompositions compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Debugging Recompositions this skillrosuH/EasyWatermark1.9k1 repos~4.3kAutomated safety check: PassApache-2.0
Coding Stylesk2andy/candy-browser485—~548Automated safety check: PassMPL-2.0
Desktop And Build Footgunsmaxrave-dev/kotlin-footguns1k—~3.8kAutomated safety check: PassGPL-3.0
Android App FactoryJasonColapietro/suede-creator-skills127—~2.6kAutomated safety check: PassMIT
ComposeMeet-Miyani/compose-skill301—~1.4kAutomated safety check: PassMIT
Senior Mobileborghei/Claude-Skills874—~1.9kAutomated safety check: PassMIT

Similar skills

  • Coding Style

    sk2andy/candy-browser

    Apply Candy Browser's project-specific Kotlin, Jetpack Compose, Android/WebView, testing, and generator conventions.

    485 GitHub stars~548 tokensUpdated yesterday
    MobileAuto-check passed

  • Desktop And Build Footguns

    maxrave-dev/kotlin-footguns

    Desktop JVM and build traps: JNA natives, bundling, memory, packaging, code signing, R8, deep links, Gradle and CI releases.

    1k GitHub stars~3.8k tokensUpdated 12 days ago
    MobileAuto-check passed

  • Android App Factory

    JasonColapietro/suede-creator-skills

    Takes a native Android app from product idea to Google Play release, covering Compose architecture, policy checks, privacy, billing, testing, signing and rollout.

    127 GitHub stars~2.6k tokensUpdated 3 days ago
    MobileAuto-check passed

  • Compose

    Meet-Miyani/compose-skill

    Use this skill first for any Jetpack Compose or Compose Multiplatform task: a new feature or screen, a change to existing code, a bug fix, a review, making code follow the kit, project or build…

    301 GitHub stars~1.4k tokensUpdated yesterday
    MobileAuto-check passed

  • Senior Mobile

    borghei/Claude-Skills

    A skill your agent uses when the user asks to "build a mobile app", "scaffold React Native project", "create SwiftUI views", "set up Jetpack Compose", "optimize mobile performance", "configure Expo…

    874 GitHub stars~1.9k tokensUpdated today
    MobileAuto-check passed

  • Android Design

    hashgraph-online/awesome-codex-plugins

    A skill your agent uses when the user asks for an Android app, Compose UI, Material 3, Material You, Material 3 Expressive, Pixel-style app, foldable/adaptive layout, Play Store deliverable, React…

    1.2k GitHub stars~2.5k tokensUpdated yesterday
    MobileAuto-check passed

More from rosuH/EasyWatermark

All 28 skills in this repo

  • Deferring State Reads

    rosuH/EasyWatermark

    A skill your agent uses to push frequently-changing Jetpack Compose state reads (scroll position, animation values, drag offsets) out of the Composition phase and down into Layout or Draw using…

    1.9k GitHub starsUsed in 1 repo~3.8k tokens
    Auto-check passed

  • Diagnosing Compose Stability

    rosuH/EasyWatermark

    A skill your agent uses to diagnose Jetpack Compose stability problems by enabling and reading the Compose Compiler Reports (classes.txt, composables.txt, composables.csv, module.json).

    1.9k GitHub starsUsed in 1 repo~3.3k tokens
    Auto-check passed

  • Generating Baseline Profiles

    rosuH/EasyWatermark

    A skill your agent uses to generate and measure Jetpack Compose Baseline Profiles end-to-end with the AGP 8.2+ Baseline Profile Generator module and the Macrobenchmark harness.

    1.9k GitHub starsUsed in 1 repo~5k tokens
    Auto-check passed

  • Migrating To Modifier Node

    rosuH/EasyWatermark

    A skill your agent uses to author new custom Jetpack Compose modifiers and migrate legacy ones from Modifier.composed { } to Modifier.Node + ModifierNodeElement<T.

    1.9k GitHub starsUsed in 1 repo~5k tokens
    Auto-check passed

  • ML Kit Genai Prompt API

    rosuH/EasyWatermark

    Analyzes Android codebases to implement ML Kit GenAI Prompt API.

    1.9k GitHub starsUsed in 1 repo~1k tokens
    Auto-check passed

  • Stabilizing Compose Types

    rosuH/EasyWatermark

    A skill your agent uses to fix unstable Jetpack Compose types once a stability diagnosis has identified them.

    1.9k GitHub starsUsed in 1 repo~4.4k tokens
    Auto-check passed

Works with

Categories

Questions about Debugging Recompositions

What does Debugging Recompositions do?

A skill your agent uses to find which Jetpack Compose composables are recomposing and why, using Android Studio Layout Inspector recomposition counts and skip counts, the per-parameter Argument…. Debugging Recompositions is an agent skill from rosuH/EasyWatermark. Use this skill to find which Jetpack Compose composables are recomposing and why, using Android Studio Layout Inspector recomposition counts and skip counts, the per-parameter Argument Change Reasons (Changed / Unchanged / Uncertain / Static / Unknown) introduced in Android Studio Hedgehog and later, and runtime @TraceRecomposition from compose-stability-analyzer for production-like measurement.

When should I use Debugging Recompositions?

Debugging Recompositions fits situations like: find which Jetpack Compose composables are recomposing and why; using Android Studio Layout Inspector recomposition counts and skip counts; runtime @TraceRecomposition from compose-stability-analyzer for production-like measurement; the developer says this should be skipping but isnt.

How do I install Debugging Recompositions in Claude Code?

Run `npx skills add rosuH/EasyWatermark --skill debugging-recompositions -a claude-code`. Or copy the skill folder (.agents/skills/debugging-recompositions in rosuH/EasyWatermark) into .claude/skills/debugging-recompositions in your project. Claude Code loads it when a task matches its description.

How do I install Debugging Recompositions in Codex?

Run `npx skills add rosuH/EasyWatermark --skill debugging-recompositions -a codex`. Or copy the skill folder (.agents/skills/debugging-recompositions in rosuH/EasyWatermark) into .agents/skills/debugging-recompositions in your project. Codex loads it when a task matches its description.

Can I use Debugging Recompositions in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add rosuH/EasyWatermark --skill debugging-recompositions -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/debugging-recompositions, .gemini/skills/debugging-recompositions, .github/skills/debugging-recompositions and .opencode/skills/debugging-recompositions in your project.

What does Debugging Recompositions need to run?

Going by SKILL.md and its folder, Debugging Recompositions needs the command-line tools its instructions call (adb).

Does Debugging Recompositions access the network?

SKILL.md names 4 domains. As links in the text: medium.com, developer.android.com, chrisbanes.me and github.com. This is read from the text; nothing was executed.

Is Debugging Recompositions safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Debugging Recompositions use?

Debugging Recompositions is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Debugging Recompositions use?

About 4.3k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Debugging Recompositions?

Skills that share tags, products or a category with Debugging Recompositions: Coding Style (sk2andy/candy-browser, 485 stars), Desktop And Build Footguns (maxrave-dev/kotlin-footguns, 1k stars), Android App Factory (JasonColapietro/suede-creator-skills, 127 stars) and Compose (Meet-Miyani/compose-skill, 301 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Debugging Recompositions?

rosuH (a GitHub user) maintains it in rosuH/EasyWatermark, which has 1,894 GitHub stars. The repository holds 28 skills in this directory. The repository was last updated on October 6, 2026.

Source: rosuH/EasyWatermark on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.