Mobile theme

Skill ahtishamshahzad/agent_dev_flow/.ai/skills/mobile/mobile-theme

Tool-neutral AI Engineering System: 174 reusable skills (installable as Claude Code plugins) for planning and building software with AI agents. Classify → plan → approve → build under quality gates. Works with Claude Code, Codex, Cursor, Windsurf, Copilot & Antigravity. Canonical in .ai/.

Install

npx -y skills add ahtishamshahzad/agent_dev_flow --skill mobile-theme

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

2 things to look at

21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 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 to plan theming — light/dark modes, theme tokens, and runtime switching — built on the design system's tokens. Ensures consistent, switchable appearance without hard-coded values.

SKILL.md

3.0 KB, 596 tokens by cl100k_base, as published. Nobody here has run it

Mobile Theme

Purpose

Plan a theming layer over the design tokens: light/dark (and any brand) themes, a theme provider, and runtime switching — so appearance is consistent and switchable.

When to Use

When the app needs light/dark or multiple themes.
When colors are hard-coded and can't switch.
Not before a design system exists (mobile-design-system first).

Inputs

Design tokens (mobile-design-system).
Light/dark/brand requirements; system-appearance behavior.

Discovery Questions

Which themes are required (light/dark/brand)?
Follow system appearance, user override, or both?
Should theme choice persist across restarts?

Responsibilities

Define theme token sets (light/dark/brand) mapped from design tokens.
Provide a theme provider and hook for components.
Support runtime switching and (if needed) persistence (mobile-secure-storage/async storage).
Respect system appearance where required.

Required Workflow

Map design tokens into theme sets.
Add a theme provider + access hook.
Wire runtime switching + optional persistence.
Respect system appearance.
Record the theming plan.

Decision Rules

Themes are token sets; components read theme via a hook, never hard-coded colors.
Follow system appearance by default; allow user override where specified.
Persist theme choice only if the requirement calls for it.

Rules

No hard-coded colors — resolve via theme.
Build on design tokens; don't invent a parallel palette.
Coordinate persistence with storage skills.

Anti-Patterns

Hard-coded colors that ignore theme.
A theme system detached from design tokens.
Forcing a theme against system appearance without reason.

Validation Checklist

Theme sets defined from tokens.
Theme provider + hook in place.
Runtime switching supported.
Persistence handled if required.
System appearance respected.

Definition of Done

A recorded theming plan: token-derived theme sets, a provider/hook, runtime switching, optional persistence, and system-appearance handling — with no hard-coded colors.

Related Skills

mobile-design-system, mobile-fonts, mobile-accessibility, mobile-secure-storage

Related Knowledge

../../../knowledge/ (brand/appearance decisions).

Related References

../../../references/mobile/screens/ when populated.

Context Loading Guidance

Requires: design tokens, theme requirements, appearance behavior.
Does not require: the whole app source, unrelated references, every mobile skill.
May load: mobile-secure-storage for persistence.
Stop when: the theming plan is recorded.

Token Efficiency Guidance

Reuse design tokens; don't restate the palette. Keep theme mapping concise.