Mobile application-focused system design and architectural decision framework. Domain discovery with EventStorming, ADR (Architecture Decision Record) templates, trade-off analysis, mobile-backend integration architecture, and Mermaid-based C4 diagrams for documentation.
SkillScore91Maintained
Automatic
◆Coding pack
Last verified 8/6/2026
What it changes
Passed 20 of 22 test cases with the skill, and 9 of 22 without it.
Without skill41%
With skill91%
Checks it passed that the model alone missed
sets the Policy classDef fill color to #e91e63
sets the Command classDef fill color to #2196f3
sets the Hotspot classDef fill color to #f44336
and 14 more in the full report
11 fixed9 passed either way2 still failing0 broke
Pass-rate lift
+50 pp
Tokens
+89%
Agent turns
0%
Response time
-13%
Model gemini-3.6-flashMeasured 8/6/2026v1 · latest is v220 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
See it in action
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 11
Prompt
Our team needs to document the internal structure of our authentication module down to the controller and repository layer. Which C4 diagram level and markdown file naming convention should we use within our architecture docs folder?
What was checked, without and with the skill
Checked
Without skill
With skill
specifies using Level 3 Component level documentation for complex individual modules
Passed
Passed
uses the c4-components- prefix for the level 3 component file naming in the docs directory
Missed
Passed
case-17 · gemini-3.6-flash · 8/6/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md359 linessingle file
Mobile System Design
Architecture + EventStorming + ADR + Mermaid Diagrams — structuring and
documenting architectural decisions for mobile applications and their backend services.
When to Use This Skill
Invoke this skill in the following situations:
Before designing a new feature or service
At an architectural decision point (which approach and why)
When defining an offline-first, push notification, or sync strategy
When establishing an API contract between the backend and the mobile client
When formalising a technical debt or refactoring decision in writing
When producing architecture documentation for the team or stakeholders
Core principle: Complexity is not introduced until it is proven necessary. The simplest working solution is always the first candidate.
The Iron Laws of System Design Documentation
Law 1: ASK QUESTIONS — No Assumptions
Never make "industry-standard assumptions" without asking first.
Question
Affected Decision Area
Platform: iOS / Android / both?
Offline strategy, push architecture
Backend: existing API or greenfield?
Contract design, versioning
Estimated user count (first six months)?
Scaling decisions
Is real-time data required?
WebSocket vs polling vs SSE
Is offline use a requirement?
Sync, conflict resolution
Team size?
Mono-repo vs multi-repo, ownership boundaries
Law 2: MERMAID ONLY — No ASCII Diagrams
All diagrams MUST use Mermaid format. No exceptions.