mobile-reference-research
Skill3 starsChanged 3 months agoMITView on GitHub
Find, inspect, compare, and shortlist native mobile product references for a new app or feature. Use when Codex needs evidence-backed reference research, a source matrix, competitor or pattern comparison, style-family inputs, or a clear borrow/transform/reject boundary before UX or UI design.
In this repository11 other files it gives its agents.
- analyze-mobile-uiSkill
- mobile-design-osSkill
- mobile-design-reviewSkill
- mobile-design-systemSkill
- mobile-design-to-codeSkill
- mobile-platform-guidelinesSkill
- mobile-product-briefSkill
- mobile-prototypeSkill
- mobile-ui-designSkill
- mobile-ux-architectSkill
- mobile-wireframeSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 16
Use analyze-mobile-ui after this Skill when screenshots or source products need detailed Design DNA extraction.
- Distinctive: line 24
Prefer official App Store/Google Play pages, first-party product pages, platform surfaces, and supplied screenshots.
- Distinctive: line 26
Keep native-mobile and platform-surface references at or above 60% of the set, including at least one real native-mobile product.
- Very specific: line 49
Run python3 scripts/validate_reference_research.py <path-to-reference-research.json> and fix every error.
- Distinctive: line 60
Do not finish with a gallery of names only.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Mobile Reference Research
Build a small, traceable reference field that informs product and interface decisions without turning the target into a clone.
Choose the research mode
- Discover: find a focused set of current, first-party mobile references from a product brief and search terms.
- Compare: compare supplied references across mechanics, task flow, platform behavior, visual grammar, and risks.
- Shortlist: reduce a larger board or source set to the references that should influence the next design stage.
Use analyze-mobile-ui after this Skill when screenshots or source products need detailed Design DNA extraction. Use mobile-ui-design when the user wants visual directions or rendered screens.
Establish the research question
Record the target product, primary user/job, platform, core task, usage frequency, and what decision the references must inform. Do not search for “beautiful apps” without a decision to make.
Build the evidence set
- Prefer official App Store/Google Play pages, first-party product pages, platform surfaces, and supplied screenshots.
- Record a stable
RFID, source URL or local path, platform, product state, access date, and evidence limitations for every source. - Keep native-mobile and platform-surface references at or above 60% of the set, including at least one real native-mobile product.
- Inspect screenshots and boards directly; treat store marketing frames as presentation evidence, not proof of runtime behavior.
- Mark current, versioned, or time-sensitive claims with their date. Use
unknownwhen a source does not establish behavior.
Compare reusable qualities
For each selected reference, record:
- One concrete product or interaction quality to borrow.
- One visual or behavioral boundary not to copy.
- The target-product decision it may inform.
- Whether the transfer is
transfer,transform, orreject. - Confidence and the evidence IDs supporting the conclusion.
Compare the same task across references whenever possible: entry, action, feedback, durable result, and recovery. Separate product mechanics from visual decoration.
Produce the research package
Create:
reference-research.mdusing assets/reference-research-template.md.reference-research.jsonusing assets/reference-research-template.json and references/reference-research-schema.md.
Run python3 scripts/validate_reference_research.py <path-to-reference-research.json> and fix every error. Treat warnings or evidence gaps as inputs to the next Skill, not as permission to invent behavior.
Enforce the output order
- Research question and target context.
- Evidence inventory and coverage gaps.
- Reference comparison matrix.
- Transfer, transform, and reject decisions.
- Shortlist for UX, platform, and visual work.
- Open questions, freshness, and confidence.
Do not finish with a gallery of names only. Every shortlisted reference must change a concrete design decision or be removed.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

