Draws architecture diagrams as editable draw.io files with a fixed house style, C4 levels, evidence-tagged shapes, and optional multi-view identity checks. Use when producing a system context, container, component, deployment, data flow, sequence, state, or ERD, or redrawing an ASCII or Mermaid one.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Never hand-write mxGraph XML. Write a spec; the scripts own every visual decision, so diagrams stay identical across authors, repositories, and sessions.
spec.json — schema in diagram-spec.md. For an ERD,
generate it: python3 scripts/schema_to_spec.py db/schema.sql --title "<System> — ERD" -o spec.jsonpython3 scripts/validate_spec.py spec.jsonpython3 scripts/render_drawio.py spec.json -o docs/architecture/<slug>.drawio --strict
(exit 2 = a layout finding; change the spec, per layout-rules.md)python3 scripts/validate_manifest.py view-manifest.jsonpython3 scripts/export_drawio.py docs/architecture/<slug>.drawio -f png -o docs/architecture/<slug>.png,
else ship the .drawio and say the image was not exported. See export paths.The JSON spec is the semantic source of truth; .drawio is the editable presentation and the
image is a copy for a deck. Generated XML records its own baseline; regeneration protects
manual edits by default. Use --acknowledge-manual-edits only after returning semantic changes to the spec.
assumed or unverified for honest design uncertainty.metric carries the load or SLO that sized the node,
constraint says why it exists; never invent either.style: async for events.gcp:* and aws:* are official icons; every other
vendor is a cloud:* kind with the service named in sublabel. No Azure logos exist in
the bundle, so Azure is always cloud:*.| Thought | Reality |
|---|---|
| "It is one box, I will write the XML" | The renderer owns style, legend, and title block. Use it. |
| "Close enough, I will guess this service" | Guesses ship as facts. Omit the evidence and let it render UNVERIFIED. |
| "Managers want the whole system on one page" | Past 12 nodes they stop reading. Split it. |
assets/fixtures/<type>.spec.json, one per diagram type, plus schema samples under assets/fixtures/schemas/.specialist-solution-diagrammer.まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Upgrade an Android project to Android Gradle Plugin (AGP) 9. Use when migrating to AGP 9, updating Gradle build files, migrating to built-in Kotlin, or adopting the new AGP DSL.
日本語の概要は準備中です。原文の説明を表示しています。
Apply Clean Architecture layering, modularization, and Unidirectional Data Flow in Android projects. Use when setting up project structure, placing code in layers, configuring feature/core modules, or implementing UDF patterns; defer Compose state and ViewModel/StateFlow implementation to their specific skills.
日本語の概要は準備中です。原文の説明を表示しています。
Implement WorkManager and background processing correctly on Android. Use when creating Worker classes, scheduling tasks, choosing between WorkManager and Foreground Services, or setting up Hilt in workers; defer FCM and notification delivery to android-notifications.
日本語の概要は準備中です。原文の説明を表示しています。
Build high-performance declarative UI with Jetpack Compose. Use when writing Composable functions, optimizing recomposition, hoisting state, or working with LazyColumn and side effects; defer deep-link and navigation routing to android-navigation.
日本語の概要は準備中です。原文の説明を表示しています。
Migrate an Android XML View to Jetpack Compose following a structured 10-step workflow. Use when converting XML layouts to Compose, setting up Compose in an existing View-based project, or incrementally adopting Compose.
日本語の概要は準備中です。原文の説明を表示しています。
Write correct coroutine scopes, lifecycle collection, and dispatcher injection in Android production code. Use for suspend functions, coroutine scopes, and dispatcher mechanics; defer ViewModel StateFlow/LiveData architecture, Fragment lifecycle recipes, persistence/notifications, and unit-test recipes to their specific skills.
日本語の概要は準備中です。原文の説明を表示しています。