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

mobile-checkpoint

モバイルアプリ開発における重要なタイミングで、プロジェクトの状態を保存・復元することで、開発作業を安全に進め、問題発生時の手戻りを最小限に抑えることを支援するSkill。

📜 元の英語説明(参考)

Checkpoint workflow for mobile development safety. Save/restore Android project state at critical points.

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

一言でいうと

モバイルアプリ開発における重要なタイミングで、プロジェクトの状態を保存・復元することで、開発作業を安全に進め、問題発生時の手戻りを最小限に抑えることを支援するSkill。

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

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

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

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o mobile-checkpoint.zip https://jpskill.com/download/16426.zip && unzip -o mobile-checkpoint.zip && rm mobile-checkpoint.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/16426.zip -OutFile "$d\mobile-checkpoint.zip"; Expand-Archive "$d\mobile-checkpoint.zip" -DestinationPath $d -Force; ri "$d\mobile-checkpoint.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して mobile-checkpoint.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → mobile-checkpoint フォルダができる
  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 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Mobile Checkpoint Skill

Android開発における安全性と状態復旧のための包括的なチェックポイントワークフローです。

どのような時に使うか

リスクの高い操作の前:

  • 大規模なリファクタリング (MVI移行、アーキテクチャ変更)
  • Gradleのアップデート (./gradlew wrapper、依存関係のアップグレード)
  • Manifestの変更 (パーミッション、コンポーネント)
  • ナビゲーションの再構築
  • 実験的な機能

マイルストーンの後:

  • 機能の完了
  • すべてのテストの合格
  • リリースビルドの成功
  • パフォーマンスの最適化

チェックポイントワークフロー

1. 操作前のチェック

# クリーンな状態を確認
git status
./gradlew check

# チェックポイントを作成
/mobile-checkpoint save before-<operation>

2. 操作の実行

# 変更を加える
# ... 編集、リファクタリング、アップデート ...

# ビルドを確認
./gradlew build

3. 操作後の検証

# 成功した場合 - 新しいチェックポイントを作成
/mobile-checkpoint save after-<operation>

# 失敗した場合 - リストア
/mobile-checkpoint restore before-<operation>

チェックポイントのコンテンツレベル

Level Content Use Case
Quick Gitのステータス、ブランチ、最近使用したファイル クイックな実験
Standard + ビルド設定、テスト ほとんどの操作のデフォルト
Full + 依存関係、manifest、instincts 大規模なリファクタリング、リリース

状態の復旧

Gitの状態の復旧

/mobile-checkpoint restore <name>
# Agentは以下を行います:
# 1. 現在の状態とのgit diffを表示
# 2. git reset --hard <commit> を提案
# 3. ステージング済み/未ステージングの変更を復元

依存関係の復旧

# チェックポイントには以下が含まれます:
# - build.gradle.kts ファイル
# - gradle/wrapper/gradle-wrapper.properties
# - バージョンカタログ (libs.versions.toml)

# Agentは手動復元のためのdiffを提供します

テスト状態の復旧

# チェックポイントは以下を表示します:
# - 以前のテスト結果
# - 失敗したテスト (もしあれば)
# - カバレッジメトリクス

# テストを実行して状態を確認:
./gradlew test

自動チェックポイント統合

チェックポイントシステムはフックと統合されています:

// hooks/checkpoint-hooks.json
{
    "trigger": "PreToolUse",
    "matcher": "tool == \"Bash\" && command contains \"gradle\"",
    "action": "Create quick checkpoint"
}

{
    "trigger": "PostToolUse",
    "matcher": "tool == \"Edit\" && file == \"AndroidManifest.xml\"",
    "action": "Create standard checkpoint"
}

チェックポイントの命名規則

操作とコンテキストを含む説明的な名前を使用してください:

Name Pattern Example
before-{operation} before-mvi-migration
after-{operation} after-koin-refactor
{feature}-complete auth-flow-complete
{version}-rc v1.2.0-rc1
working-{date} working-2026-02-03

checkpoint1savetemp は避けてください。

チェックポイントの管理

チェックポイントのリスト表示

/mobile-checkpoint list
# 出力:
# before-mvi-refactor    2 hours ago    Standard
# auth-feature-done     1 day ago      Full
# working-0203          2 days ago     Quick

古いチェックポイントの削除

# 最新の10個を保持
/mobile-checkpoint prune --keep 10

# 特定のものを削除
/mobile-checkpoint delete working-0203

バックアップのためにエクスポート

# ファイルにエクスポート
/mobile-checkpoint export release-ready > ~/backups/mobile-checkpoint.json

# ファイルからインポート
/mobile-checkpoint import ~/backups/mobile-checkpoint.json

Instinctsとの統合

チェックポイントはinstinctの学習を保持します:

{
    "instincts": {
        "version": "2.0",
        "count": 47,
        "highConfidence": 23,
        "lastUpdated": "2026-02-03T10:30:00Z"
    }
}

チェックポイントを復元すると、学習したパターンも復元されます。

トラブルシューティング

リストアが失敗する

  1. Gitの状態を確認: git status
  2. チェックポイントの整合性を検証: /mobile-checkpoint verify <name>
  3. 手動復旧: コミットを手動でチェックアウト

依存関係が見つからない

  1. チェックポイントは元のバージョンを表示します
  2. build.gradle.kts を手動で復元
  3. ./gradlew --refresh-dependencies を実行

リストア後にテストが異なる

  1. テストはチェックポイントと現在で変更されている可能性があります
  2. チェックポイントはテストのSTATEをキャプチャし、テストのCODEはキャプチャしません
  3. git diff を使用してテストファイルの変更を確認

ベストプラクティス

  1. チェックポイントを事前に: 主要な変更の前に必ず保存
  2. 明確な名前: 操作に基づいた名前を使用
  3. 事後に検証: チェックポイントを確定する前にテストを実行
  4. 定期的にクリーンアップ: 古いチェックポイントを毎月削除
  5. マイルストーンをエクスポート: リリースの前にエクスポート
  6. Gitを信頼: チェックポイントはバージョン管理を補完するものであり、置き換えるものではありません

覚えておいてください: チェックポイントは安全ネットであり、タイムマシンではありません。 変更された内容を示しますが、すべての変更を元に戻す方法を示すものではありません。

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Mobile Checkpoint Skill

Comprehensive checkpoint workflow for Android development safety and state recovery.

When to Use

Before risky operations:

  • Large refactors (MVI migration, architecture changes)
  • Gradle updates (./gradlew wrapper, dependency upgrades)
  • Manifest changes (permissions, components)
  • Navigation restructuring
  • Experimental features

After milestones:

  • Feature completion
  • Passing all tests
  • Successful release build
  • Performance optimization

Checkpoint Workflow

1. Pre-Operation Check

# Verify clean state
git status
./gradlew check

# Create checkpoint
/mobile-checkpoint save before-<operation>

2. Perform Operation

# Make your changes
# ... edits, refactors, updates ...

# Verify build
./gradlew build

3. Post-Operation Verification

# If successful - create new checkpoint
/mobile-checkpoint save after-<operation>

# If failed - restore
/mobile-checkpoint restore before-<operation>

Checkpoint Content Levels

Level Content Use Case
Quick Git status, branch, recent files Quick experiments
Standard + Build config, tests Default for most ops
Full + Dependencies, manifest, instincts Major refactors, releases

State Recovery

Git State Recovery

/mobile-checkpoint restore <name>
# Agent will:
# 1. Show git diff to current state
# 2. Offer git reset --hard <commit>
# 3. Restore staged/unstaged changes

Dependency Recovery

# Checkpoint includes:
# - build.gradle.kts files
# - gradle/wrapper/gradle-wrapper.properties
# - version catalog (libs.versions.toml)

# Agent provides diff for manual restoration

Test State Recovery

# Checkpoint shows:
# - Previous test results
# - Failing tests (if any)
# - Coverage metrics

# Run tests to verify state:
./gradlew test

Auto-Checkpoint Integration

The checkpoint system integrates with hooks:

// hooks/checkpoint-hooks.json
{
    "trigger": "PreToolUse",
    "matcher": "tool == \"Bash\" && command contains \"gradle\"",
    "action": "Create quick checkpoint"
}

{
    "trigger": "PostToolUse",
    "matcher": "tool == \"Edit\" && file == \"AndroidManifest.xml\"",
    "action": "Create standard checkpoint"
}

Checkpoint Naming Convention

Use descriptive names with operation and context:

Name Pattern Example
before-{operation} before-mvi-migration
after-{operation} after-koin-refactor
{feature}-complete auth-flow-complete
{version}-rc v1.2.0-rc1
working-{date} working-2026-02-03

Avoid: checkpoint1, save, temp

Checkpoint Management

List Checkpoints

/mobile-checkpoint list
# Output:
# before-mvi-refactor    2 hours ago    Standard
# auth-feature-done     1 day ago      Full
# working-0203          2 days ago     Quick

Delete Old Checkpoints

# Keep last 10
/mobile-checkpoint prune --keep 10

# Delete specific
/mobile-checkpoint delete working-0203

Export for Backup

# Export to file
/mobile-checkpoint export release-ready > ~/backups/mobile-checkpoint.json

# Import from file
/mobile-checkpoint import ~/backups/mobile-checkpoint.json

Integration with Instincts

Checkpoints preserve instinct learning:

{
    "instincts": {
        "version": "2.0",
        "count": 47,
        "highConfidence": 23,
        "lastUpdated": "2026-02-03T10:30:00Z"
    }
}

Restoring a checkpoint also restores your learned patterns.

Troubleshooting

Restore Fails

  1. Check git state: git status
  2. Verify checkpoint integrity: /mobile-checkpoint verify <name>
  3. Manual recovery: Checkout commit manually

Missing Dependencies

  1. Checkpoint shows original versions
  2. Restore build.gradle.kts manually
  3. Run ./gradlew --refresh-dependencies

Tests Differ After Restore

  1. Tests may have changed between checkpoint and now
  2. Checkpoint captures test STATE, not test CODE
  3. Use git diff to see test file changes

Best Practices

  1. Checkpoint Before: Always save before major changes
  2. Name Clearly: Use operation-based names
  3. Verify After: Run tests before confirming checkpoint
  4. Clean Regularly: Remove old checkpoints monthly
  5. Export Milestones: Export before releases
  6. Trust Git: Checkpoints complement, don't replace, version control

Remember: A checkpoint is a safety net, not a time machine. It shows you what changed, not how to undo every change.