First converge the multi-platform MVP into a single set of observable behaviors and a page matrix, then generate page-by-page corresponding, reproducible, reviewable Phone/Tablet UI assets. Platform consistency refers to equivalence of features and states, and does not require flattening the native interaction differences between Android and Apple.
Quick Start
- "Compare the MVP specifications of Kotlin and Swift, list the differences in features, states, and pages, then unify the four-platform matrix."
- "Using the confirmed visual master, generate same-source complete artwork sets for Android/Apple Phone/Tablet."
- "Audit whether P01-P19 are complete across all four platforms, distinguishing candidate artwork, reviewed masters, and native acceptance screenshots."
At the start, read the user-specified specifications, README, manifest, existing assets, and confirmed masters. If the repository has its own specification system, follow its source of truth and do not create conflicting specifications. When information is insufficient, first output an audit result with assumptions and gap markers; only ask the user about gaps that would change page scope, the main flow, or visual direction.
Target Audience and Capability Boundaries
Good At
- Product/design leads: compare MVP scope across multiple platforms and adjudicate divergences.
- Mobile teams: establish a shared page and state matrix for Android/Apple × Phone/Tablet.
- Design engineers: generate complete sets of candidate assets based on same-source scenarios, tokens, and rendering rules.
- Reviewers: verify coverage, cross-platform semantic equivalence, file archiving, and asset maturity.
Required Materials
- At least one specification, feature list, or existing product flow to determine the MVP boundary.
- At least one confirmed master or explicit style constraint to perform visual alignment.
- Target platforms, canvas sizes, and delivery directories to generate assets that can be written to disk.
- When old assets need to be replaced, review status or explicit authorization must be provided.
Out of Scope
- Do not claim based on artwork that native implementation, accessibility, dark mode, or runtime behavior has passed.
- Do not delete old READMEs, artwork, manifests, or historical versions without authorization.
- Do not copy Android and Apple controls pixel by pixel; instead use shared semantics plus platform-native mapping.
- Do not process screenshots containing real tokens, accounts, private sessions, or production data; first redact or switch to synthetic data.
Workflow
For complete steps, see references/workflow.md。
- Establish a factual baseline: locate the specification source of truth, asset tree, manifest, confirmed masters, and historical drafts; distinguish source facts, user decisions, inferences, and items pending verification.
- Compare product semantics: compare item by item across features, entry points, states, events, permissions, error recovery, and background recovery, without comparing pixels first.
- Adjudicate a unified contract: form one shared MVP contract; platform differences go into the native mapping table and must not form a second set of product logic.
- Establish a page matrix: use stable IDs for each page/key state; record trigger conditions, visible results, next steps, and four-platform coverage.
- Lock the design language: Extract tokens, hierarchy, color areas, materials, typography, icons, and feedback from the confirmed master; preserve the confirmed depth and color quality.
- Generate same-source assets: The four ends share scenario data, copy, illustration packages, states, and rendering inputs. Phone and Tablet compose separately; Android and Apple are natively implemented separately.
- Validate and tier: Check the matrix, dimensions, naming, manifest, visual consistency, and provenance. Distinguish candidate assets, review masters, and native screenshots.
- Promote after review: Only after the user confirms a new baseline can the candidate tree be promoted; deleting or archiving old assets requires separate authorization and the mapping must be retained.
Core Decision Rules
- Function before visuals: The same page count does not mean functional alignment; states, events, and recovery paths must be checked.
- Shared contract, platform implementation: Share functions, states, copy intent, and page IDs; platforms use native navigation, controls, and feedback.
- Tablet is not an enlarged Phone: It should use two columns, master-detail areas, or persistent context, but maintain the same closed task loop.
- Same source does not equal copying: Business scenarios, test data, and illustration sources are the same; the layout may be rearranged by device and platform.
- Tiered asset evidence: Spec consistency, successful rendering, file existence, visual review, and native runtime are different gates.
- Preserve confirmed decisions: When correcting deviations, preserve confirmed layouts, interactions, and visual strengths, and only fix the issues pointed out.
Output Contract
By default, deliver the source-of-truth checklist, cross-platform differences and adjudication table, shared MVP contract, page coverage matrix, design language card, Phone/Tablet asset list, and validation report. For field templates, see references/artifact-contract.md. Explain the basis for each conclusion; mark anything that cannot be confirmed as an assumption, and do not fabricate nonexistent features, review conclusions, or runtime evidence.
Quality and Security Gates
- Use synthetic or desensitized names, sessions, locations, tokens, and accounts; do not copy sensitive content from observation records.
- Record the source and license of external images, fonts, and icons; when the source is unreliable, use your own assets or explicit placeholders.
- Before destructive operations, resolve the exact target, list the files, and obtain user confirmation.
- When a tool fails, report “missing tool/material + supplementary method”; you may deliver a downgraded matrix, prompt, or rendering specification, but do not fake artwork.
- When the output directory already contains uncommitted content, stop overwriting, switch to a candidate directory, or request adjudication.
Common Questions
Q1: Which of the two specifications takes priority? Look at the source of truth specified by the project and the user's latest adjudication; if it cannot be determined, retain the conflict and request a choice.
Q2: Must the four ends be pixel-identical? Not necessarily. Functions, states, copy intent, and visual brand should be consistent, and controls should follow platform conventions.
Q3: What if there is no master? First provide a neutral design language candidate and mark it as unapproved; do not generate the full matrix in bulk.
Q4: Should Phone or Tablet be done first? Usually first lock one Phone and one Tablet main-scenario master; if a master already exists, continue using it.
Q5: When can old images be deleted? After the new specifications, matrix, and artwork pass review and the user explicitly authorizes it.
Q6: Does successful rendering count as completion? No. File/manifest and visual checks are also required; native implementations additionally require device verification.
For more edge cases, see references/faq-deep.md, and for failure modes, see references/anti-patterns.md。