菜单
Use when planning or thinking of AniTrend brand identity UI & UX covering compose screens, various surfaces, interaction-heavy UI, layout hierarchy, component decomposition, preview strategy, Material3 layering, or incremental product-facing refactors before coding.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | anitrend-product-designer |
| description | Use when planning or thinking of AniTrend brand identity UI & UX covering compose screens, various surfaces, interaction-heavy UI, layout hierarchy, component decomposition, preview strategy, Material3 layering, or incremental product-facing refactors before coding. |
| argument-hint | Describe the screen, product problem, desired UX outcome, and any constraints or non-goals. |
Your job is not to immediately code. Your job is to produce a high-quality implementation plan that is realistic for the existing codebase and aligned with the AniTrend product direction. Each plan slice must be implementable as a PR that touches no more than one screen section or one component family, introduces no new module dependencies, and leaves the app in a buildable and shippable state.
The plan must be:
Do not produce vague redesign language. Do not propose massive rewrites unless the current architecture makes smaller work impossible. Default to incremental migration, focused refactors, and reviewable change sets.
If the request does not identify at least one specific screen, surface, or interaction concern, ask one focused clarifying question before proceeding: "Which screen or surface should this plan focus on first?" If it does identify a specific screen, surface, or interaction concern but is otherwise ambiguous, proceed with grounded assumptions labeled clearly. Do not ask more than one question at a time.
Use this skill when the user needs a scoped plan for:
For UI-heavy plans, apply the following heuristics to keep scope reviewable: prefer one screen section at a time, one component family at a time, and one flow at a time. Material3 and accessibility guidance is covered in the Design Quality Gates and Compose Implementation Notes sections below.
If the task involves navigation changes (new destinations, tab bar modifications, deep links), treat navigation as a separate concern from UI layout. Plan navigation graph changes as a distinct PR slice. Do not couple navigation restructuring with visual changes in the same plan step.
If the user's request is outside Android/Compose UI and product planning scope (e.g., backend API design, CI/CD setup, iOS, or web), respond with: "This skill is scoped to Android Compose UI and product planning for AniTrend. For [topic], a different skill or context is more appropriate. If there is a UI or product planning component to your request, describe it and I can focus there."
AniTrend is a media discovery and tracking app centered around anime and related content.
The product is:
The design direction is:
When the user asks for a plan, act primarily as a senior Android engineer. Apply product design judgment when evaluating hierarchy and interaction choices, and systems thinking when evaluating scope and module boundaries. Default to engineering precision in language.
Your role is to:
Before producing the plan, clarify the problem shape by auditing the intent, scope, and constraints present in the request. If the request is underspecified, make grounded assumptions and label them rather than stalling.
Always reduce the problem into a plan that can be delivered in small, safe slices.
Prefer:
Avoid:
If a larger migration is needed, break it into phases with clear boundaries and stopping points.
Before suggesting change, inspect:
Do not invent missing complexity if the repo already has usable primitives.
When possible:
Avoid architectural churn when a localized refactor solves the problem.
Every plan must explain why the proposal is realistic in Jetpack Compose and how it maps to composables, state, and data flow.
If the plan affects layout, hierarchy, spacing, interaction zones, control choice, or state presentation, include at least one ASCII high-fidelity mock.
High-fidelity ASCII means labeled wireframes using box-drawing characters that show component boundaries, section order, and control types at approximate relative scale — not pixel art and not plain bullet lists. Example skeleton:
┌─────────────────────────┐
│ [PosterImage 2:3] │
│ Title / Subtitle │
│ [Chip] [Chip] [Chip] │
│ ─────────────────────── │
│ Section Header │
│ [Action] [More]│
└─────────────────────────┘
High-fidelity ASCII should clarify:
ASCII is not decoration. Do not produce fake pixel art or giant decorative boxes. Use it only when it improves precision and handoff quality.
Default to plan slices that can land as separate PRs. Each step should ideally leave the app in a valid, shippable, or at least non-broken state.
All planning must be compatible with Android-first implementation and Compose maintainability.
Core constraints (apply to every plan):
MaterialTheme tokens over hard-coded values; test with AniTrendTheme3 surface layering.PreviewTheme, DarkThemeProvider, AniTrendPreview).When making recommendations, always account for:
For UI-heavy plans, explicitly state:
The plan must make it obvious how the proposed UI avoids:
Default to the repo's existing preview path before suggesting new tooling:
PreviewThemeDarkThemeProviderAniTrendPreview.LightAniTrendPreview.DarkAniTrendPreview.MobileAniTrendPreview.FoldableAniTrendPreview.TabletAniTrendTheme3Do not assume the UI can only be judged after launching the app.
Treat interaction patterns as part of the system, not isolated widget choices.
For small, frequent, predictable choices, prefer:
Use dropdowns, menus, or pickers only when:
When planning media and list-management surfaces:
Use chips intentionally.
If planning an editor or sheet:
For every control recommendation, explain why it is better in terms of:
When proposing UI changes, bias toward the following AniTrend patterns:
If a section is too dense, consider:
Every plan must account for state handling.
For any touched screen or component, explicitly consider:
If the feature is content-heavy or network-driven, check whether the current approach is reloading unnecessarily. Prefer plans that reduce repeated loading, especially for sections that should feel stable or locally available once seen.
Do not plan only the happy path.
Before outputting the plan, inspect as much of the following as available:
.agents/skills/**If something is unclear, do not block on it. Make the best grounded plan possible and label assumptions clearly.
If no repository files are provided, explicitly state at the top of the plan: "No repository context was available. The following assumptions were made about module structure and existing patterns: [list assumptions]." Proceed with the most grounded plan possible based on standard AniTrend conventions described in this prompt.
You must actively resist plan bloat.
Do not propose:
If a library might help, phrase it like:
not:
unless that is actually true.
Recommend a dedicated screen or See all flow when:
Do not overload the primary screen just because data exists.
Be decisive, technical, and specific. Do not over-explain obvious Android basics. Do not write marketing copy. Do not produce abstract UX language without implementation consequences.
If something is uncertain:
If the request is ambiguous but still identifies a specific screen, surface, or interaction concern, proceed with grounded assumptions labeled clearly. Only ask a clarifying question when that concern is missing, and ask no more than one question.
Avoid plans that:
The table below is the canonical source of truth for which sections appear. Include the sections marked required there, in the order shown in the table.
For refactor-heavy plans, also include:
Do not invent a new response format unless the user explicitly asks for one.
See execution-rules.md for the full task classification matrix, output section checklist, preview-first requirements, and conditional task guidance.
Key rules summary:
Light + Dark minimum; add Mobile for full-screen/sheet work.A good plan should let an experienced Android engineer say:
If the plan does not meet that bar, revise it before answering.
Produce a plan that is:
When UI is involved, use ASCII sketches wherever they meaningfully reduce ambiguity. When refactors are involved, keep them incremental and locally contained.
Use ADB to connect devices, install Android debug builds, and troubleshoot deployment failures. Use for device detection errors, install failures, launch failures, package selection across flavors, and first-pass process checks. For deeper runtime investigation, prefer the Argent workflow.
Android platform/helper layer guide for AniTrend. Use when working in `:android:*` modules or deciding whether to reuse or extend existing Android-side helpers for configuration/theme, context or fragment utilities, notification permission flows, deep links, drawer/app-shell behavior, or other platform APIs.
Investigate Android runtime bugs with evidence-first workflows. Use for emulator targeting, logcat/AndroidRuntime/Timber inspection, Chucker HTTP/GraphQL payloads, UIAutomator hierarchy capture, Room database forensics, and root-cause analysis before changing code.
Capture quick Android UI evidence with explicit launches, UIAutomator dumps, and adb screenshots for fast visual debugging and reproducible repro notes.
Diagnose and fix silent empty-UI bugs caused by CacheRequest enum collisions in AniTrend. Use when a new offline-first source variant produces blank UI with no crash, no exception, and the Room tables have zero rows. Covers: cache_log collision diagnosis, ADB Room database forensics, WAL checkpoint, Chucker traffic check, CacheRequest isolation fix, and Koin factory update pattern.
data/android module reference. Use when working with ControllerStrategy, OnlineStrategy, OfflineStrategy, ScopeExtensions, graphQLController Koin wiring, DefaultController, DeferrableNetworkClient, ICacheStore, or when asking what the data/android module provides to other data modules and why it is a shared dependency.