agentsclimarketplace

Design test gate

Skill GDvega/super-android-kotlin-firebase-skill/skills/design-test-gate

A modular Agent Skills repository for Android, Kotlin, Jetpack Compose and Firebase development.

Install
npx -y skills add GDvega/super-android-kotlin-firebase-skill --skill design-test-gate

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use before Android UI, UX, Material 3, Compose design or visual refactor work to verify build and tests first, stop on failures, and define safe validation before design changes.

SKILL.md

4.3 KB, as published. Nobody here has run it

Purpose

Protect Android design work with an engineering gate: build and tests first, design second.

When to use

  • Before changing Compose UI, Material 3 theme, screen layout, design system components or UX copy.
  • When the user asks for a redesign, visual improvement, UI polish, app makeover or design refactor.
  • When an AI-generated app needs design review but may have broken build, tests or Gradle setup.
  • When design changes could affect navigation, ViewModels, Firebase data, local persistence or accessibility.

Inputs to inspect

  • Current branch status and changed files.
  • Gradle files, module structure and available test tasks.
  • Existing unit, UI, screenshot, preview or instrumentation tests.
  • Recent build/test failures, CI logs and flaky test notes.
  • Target screen, flow or component requested for design work.

Required workflow

  1. Inspect the project structure and identify the smallest relevant validation commands.
  2. Run or request the baseline build/test commands before making visual changes.
  3. If build or tests fail, stop design work and report the failure with the smallest next debugging step.
  4. If validation passes, define the design scope, affected screens and regression risks.
  5. Select related design skills only after the gate passes.
  6. End with commands that should be rerun after design changes.

Rules

  • Always treat build/tests as the first step for UI or UX work.
  • Do not redesign around a broken build unless the user explicitly asks to triage the failure first.
  • Do not hide test failures behind visual recommendations.
  • Preserve existing behavior, ViewModels, repositories, Firebase logic, navigation and persistence.
  • Prefer the cheapest meaningful command first, then broaden validation for risky UI changes.
  • If commands cannot run locally, explain the blocker and provide the exact command the user should run.

Related existing skills

Local skills to invoke

  • testing
  • debugging
  • gradle-build
  • code-review-refactor

External companion skills to use when installed

Do not assume these companion skills are installed. Prefer the local skills above first, then consult Companion Skills for install and verification commands.

  • aldefy/compose-skill — use for deeper Jetpack Compose, Material 3, design-to-code, theming or Compose architecture guidance.
  • skydoves/android-testing-skills — use for deeper Android or Compose UI testing, semantics, assertions or test workflow guidance.

Files commonly touched

  • build.gradle.kts
  • settings.gradle.kts
  • gradle/libs.versions.toml
  • src/test
  • src/androidTest
  • CI workflow files
  • Design target files only after validation passes

Commands to validate

./gradlew assembleDebug
./gradlew test
./gradlew lint
./gradlew connectedDebugAndroidTest
npm run check

Common mistakes to avoid

  • Starting a redesign before confirming the app builds.
  • Running only UI tests when a unit test would catch the broken state faster.
  • Treating flaky tests as irrelevant to design work.
  • Changing Gradle versions just to make design changes.
  • Ignoring broken accessibility or UI tests because the screen "looks better."

Checklist

  • Baseline command identified.
  • Build result known.
  • Test result known or blocker reported.
  • Design scope limited to requested surfaces.
  • Related skills selected after the gate.
  • Post-change validation commands listed.

Example prompts

  • Use $super-android-kotlin-firebase to run the design-test-gate before improving this Compose screen.
  • Use $super-android-kotlin-firebase to verify this AI-generated Android app is safe to redesign.
  • Use $super-android-kotlin-firebase to stop if build/tests fail, then tell me what to fix before UI polish.

Expected response style

Start with gate status: passed, failed or blocked. If failed, lead with the failing command and stop design recommendations. If passed, summarize the safe design scope, related skills to use next, and validation commands to rerun.

References

  • ../../docs/audits/FUENTES_LOCALES.md
  • references/design-test-gate-notes.md
  • templates/design-test-gate-report-template.md

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.