mobile-memory
モバイルアプリ開発において、プロジェクト構成や依存関係、テストの状態などを記憶し、セッションを跨いでも開発をスムーズに継続できるように支援するSkill。
📜 元の英語説明(参考)
Memory persistence for mobile development context across sessions. Maintains project structure, dependencies, architecture, and test state.
🇯🇵 日本人クリエイター向け解説
モバイルアプリ開発において、プロジェクト構成や依存関係、テストの状態などを記憶し、セッションを跨いでも開発をスムーズに継続できるように支援するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o mobile-memory.zip https://jpskill.com/download/16430.zip && unzip -o mobile-memory.zip && rm mobile-memory.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/16430.zip -OutFile "$d\mobile-memory.zip"; Expand-Archive "$d\mobile-memory.zip" -DestinationPath $d -Force; ri "$d\mobile-memory.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
mobile-memory.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
mobile-memoryフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
モバイルメモリ Skill
セッションを跨いでモバイル開発のコンテキストを維持する永続的なメモリシステムです。
目的
(パターンを捉える)直感とは異なり、メモリは事実に基づいたプロジェクトの状態を保持します。
- どのようなモジュールが存在するか
- どのような依存関係がインストールされているか
- アーキテクチャがどのように見えるか
- どのようなテストがどのコードをカバーしているか
これはセッションの中断やコンパクション後も維持されます。
メモリの種類
プロジェクト構造メモリ
Android プロジェクトのレイアウトを記憶します。
{
"modules": ["app", "core:network", "feature:auth"],
"buildVariants": ["debug", "release", "staging"],
"featureModules": ["auth", "home", "profile"]
}
使用時: 新しい機能の開発を開始する際、プロジェクトのレイアウトを知る必要がある場合
依存関係メモリ
すべての Gradle の依存関係を追跡します。
{
"libraries": [
{"name": "compose-runtime", "group": "androidx.compose", "version": "1.5.0"}
],
"kgpVersion": "1.9.20",
"gradleVersion": "8.2"
}
使用時: 新しい依存関係を追加する際、互換性を確認する場合
アーキテクチャメモリ
アーキテクチャパターンをドキュメント化します。
{
"pattern": "mvi",
"uiLayer": {"screens": ["Home", "Profile"]},
"dataLayer": {"repositories": ["UserRepository"]},
"di": {"framework": "koin", "modules": ["appModule"]}
}
使用時: 新しい開発者のオンボーディング時、コードベースを説明する場合
テストカバレッジメモリ
テストメトリクスを追跡します。
{
"totalCoverage": 78,
"trend": "improving",
"failingTests": [
{"class": "AuthViewModelTest", "method": "testLogin"}
]
}
使用時: テスト作業を計画する際、品質目標を追跡する場合
Compose スクリーンメモリ
すべての Composable スクリーンをインデックス化します。
{
"screens": [
{"name": "HomeScreen", "route": "home", "file": "HomeScreen.kt"}
]
}
使用時: スクリーンを探す際、ナビゲーションを理解する場合
使い方
メモリのロード
# セッション開始時 - すべてのメモリをロード
/memory-load all
# 特定のタイプをロード
/memory-load project-structure
/memory-load dependencies
メモリの保存
# 現在の状態を保存
/memory-save project-structure
/memory-save test-coverage
# すべてを保存 (通常は自動)
/memory-save all
メモリのクエリ
# プロジェクトに関する質問をする
/memory-query "What modules use Ktor?"
/memory-query "Which screens are not tested?"
/memory-query "What's the test coverage for auth module?"
メモリの消去
# 古いメモリを削除
/memory-forget recent-changes
/memory-forget --older-than 90days
サマリー
# すべてのメモリの概要を取得
/memory-summary
メモリのリフレッシュトリガー
メモリは以下の場合に自動的にリフレッシュされます。
- Gradle sync: 依存関係、ビルドバリアント
- ファイルの変更: 最近の変更、アーキテクチャ
- テストの実行: テストカバレッジ、失敗したテスト
- セッションの開始: すべてのメモリをロード
- セッションの終了: すべてのメモリを保存
メモリ vs 直感
| 側面 | メモリ | 直感 |
|---|---|---|
| 内容 | 事実の状態 | パターン |
| 例 | モジュールリスト、依存関係 | "Use collectAsStateWithLifecycle" |
| 更新 | 変更時 | 観察時 |
| 信頼度 | 二値 (存在する/存在しない) | 0.0-1.0 のスコア |
| 保持期間 | 30-90 日 | 永続的 |
統合
チェックポイントとの連携
チェックポイントにはメモリの状態が含まれます。
{
"checkpoint": {
"memory": {
"project-structure": {...},
"dependencies": {...}
}
}
}
チェックポイントを復元すると、メモリも復元されます。
コンパクションとの連携
メモリはコンパクション後も維持されます。
- 最近のメモリ: そのまま保持
- 古いメモリ: 要約
/memory-queryで常に利用可能
直感との連携
メモリは直感の抽出に役立ちます。
- プロジェクト構造 → パターンを探す場所
- 依存関係 → どのようなフレームワークが使用されているか
- アーキテクチャ → どのようなパターンが期待されるか
ベストプラクティス
- 自動リフレッシュに任せる: メモリはフックで自動的に更新されます
- クエリを実行し、記憶しない: ユーザーに尋ねる代わりに
/memory-queryを使用します - ロード時に検証する: メモリが実際のプロジェクトと一致することを確認します
- 変更後に更新する: 大きな変更の後に
/memory-saveを実行します - クリーンアップする:
/memory-forgetを使用して古いデータを削除します
セッション例
User: I need to add a new feature for user profiles
Agent: /memory-query project-structure
Response: Found modules: app, core:network, feature:auth
No profile module exists.
Agent: /memory-query dependencies
Response: Using Compose 1.5.0, Ktor 2.3.0, Koin 3.4.0
Agent: Based on memory, I'll create feature:profile module
following your existing architecture pattern.
覚えておいてください: メモリは存在するものに関するものであり、あるべきものに関するものではありません。それは直感の役割です。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Mobile Memory Skill
Persistent memory system that maintains mobile development context across sessions.
Purpose
Unlike instincts (which capture patterns), memory retains factual project state:
- What modules exist
- What dependencies are installed
- What the architecture looks like
- What tests cover what code
This survives session breaks and compaction.
Memory Types
Project Structure Memory
Remembers your Android project layout:
{
"modules": ["app", "core:network", "feature:auth"],
"buildVariants": ["debug", "release", "staging"],
"featureModules": ["auth", "home", "profile"]
}
Use when: Starting work on a new feature, need to know project layout
Dependencies Memory
Tracks all Gradle dependencies:
{
"libraries": [
{"name": "compose-runtime", "group": "androidx.compose", "version": "1.5.0"}
],
"kgpVersion": "1.9.20",
"gradleVersion": "8.2"
}
Use when: Adding new dependencies, checking compatibility
Architecture Memory
Documents your architecture patterns:
{
"pattern": "mvi",
"uiLayer": {"screens": ["Home", "Profile"]},
"dataLayer": {"repositories": ["UserRepository"]},
"di": {"framework": "koin", "modules": ["appModule"]}
}
Use when: Onboarding new developers, explaining codebase
Test Coverage Memory
Tracks test metrics:
{
"totalCoverage": 78,
"trend": "improving",
"failingTests": [
{"class": "AuthViewModelTest", "method": "testLogin"}
]
}
Use when: Planning testing work, tracking quality goals
Compose Screens Memory
Indexes all Composable screens:
{
"screens": [
{"name": "HomeScreen", "route": "home", "file": "HomeScreen.kt"}
]
}
Use when: Finding screens, understanding navigation
Usage
Load Memory
# At session start - load all memory
/memory-load all
# Load specific type
/memory-load project-structure
/memory-load dependencies
Save Memory
# Save current state
/memory-save project-structure
/memory-save test-coverage
# Save all (usually automatic)
/memory-save all
Query Memory
# Ask questions about project
/memory-query "What modules use Ktor?"
/memory-query "Which screens are not tested?"
/memory-query "What's the test coverage for auth module?"
Forget Memory
# Remove stale memory
/memory-forget recent-changes
/memory-forget --older-than 90days
Summary
# Get overview of all memory
/memory-summary
Memory Refresh Triggers
Memory auto-refreshes on:
- Gradle sync: Dependencies, build variants
- File changes: Recent changes, architecture
- Test runs: Test coverage, failing tests
- Session start: Load all memory
- Session end: Save all memory
Memory vs Instincts
| Aspect | Memory | Instincts |
|---|---|---|
| Content | Factual state | Patterns |
| Examples | Module list, deps | "Use collectAsStateWithLifecycle" |
| Updates | On changes | On observations |
| Confidence | Binary (exists/doesn't) | 0.0-1.0 score |
| Retention | 30-90 days | Persistent |
Integration
With Checkpoints
Checkpoints include memory state:
{
"checkpoint": {
"memory": {
"project-structure": {...},
"dependencies": {...}
}
}
}
Restoring a checkpoint restores memory too.
With Compaction
Memory survives compaction:
- Recent memory: Kept as-is
- Old memory: Summarized
- Always available via
/memory-query
With Instincts
Memory informs instinct extraction:
- Project structure → Where to look for patterns
- Dependencies → What frameworks are used
- Architecture → What patterns to expect
Best Practices
- Let it auto-refresh: Memory updates automatically on hooks
- Query, don't remember: Use
/memory-queryinstead of asking user - Validate on load: Check memory matches actual project
- Update after changes: Run
/memory-saveafter major changes - Clean up: Use
/memory-forgetto remove stale data
Example Session
User: I need to add a new feature for user profiles
Agent: /memory-query project-structure
Response: Found modules: app, core:network, feature:auth
No profile module exists.
Agent: /memory-query dependencies
Response: Using Compose 1.5.0, Ktor 2.3.0, Koin 3.4.0
Agent: Based on memory, I'll create feature:profile module
following your existing architecture pattern.
Remember: Memory is about what exists, not what should be. That's what instincts are for.