jpskill.com
🛠️ 開発・MCP コミュニティ

mobile-memory

モバイルアプリ開発において、プロジェクト構成や依存関係、テストの状態などを記憶し、セッションを跨いでも開発をスムーズに継続できるように支援するSkill。

📜 元の英語説明(参考)

Memory persistence for mobile development context across sessions. Maintains project structure, dependencies, architecture, and test state.

🇯🇵 日本人クリエイター向け解説

一言でいうと

モバイルアプリ開発において、プロジェクト構成や依存関係、テストの状態などを記憶し、セッションを跨いでも開発をスムーズに継続できるように支援するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
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
🪟 Windows (PowerShell)
$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. 1. 下の青いボタンを押して mobile-memory.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → mobile-memory フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

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 で常に利用可能

直感との連携

メモリは直感の抽出に役立ちます。

  • プロジェクト構造 → パターンを探す場所
  • 依存関係 → どのようなフレームワークが使用されているか
  • アーキテクチャ → どのようなパターンが期待されるか

ベストプラクティス

  1. 自動リフレッシュに任せる: メモリはフックで自動的に更新されます
  2. クエリを実行し、記憶しない: ユーザーに尋ねる代わりに /memory-query を使用します
  3. ロード時に検証する: メモリが実際のプロジェクトと一致することを確認します
  4. 変更後に更新する: 大きな変更の後に /memory-save を実行します
  5. クリーンアップする: /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

  1. Let it auto-refresh: Memory updates automatically on hooks
  2. Query, don't remember: Use /memory-query instead of asking user
  3. Validate on load: Check memory matches actual project
  4. Update after changes: Run /memory-save after major changes
  5. Clean up: Use /memory-forget to 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.