Claude を使用して GitHub 用のカスタム アプリ ストアを構築しました (プロンプトが含​​まれています)

GitHub は、膨大な量の本当に優れた無料のオープンソース ソフトウェアをホストしています。しかし、アプリを見つけてインストールするためのインターフェイスとしては、これは最悪のエクスペリエンスの 1 つです。カテゴリごとの参照やインストール ボタンはなく、README の半分の時間はビルド ツールチェーンが何であるかをすでに知っていることを前提としています。私はそれにうんざりしたので、Claude を使って自分で回避策を構築しました。これは、GitHub の上にあるアプリストアのようなレイヤーです。

GitHub はユーザー エクスペリエンスを改善する必要がある

優れたソフトウェアを見つけるのにコンピュータ サイエンスの学位は必要ありません

クレジット: Lucas Gouveia/ハウツー ギーク

あなたが私と同じように、フリーのオープンソース ソフトウェア (FOSS) を愛し、それを支持し、毎日それを使用している人であれば、おそらく GitHub に対して多少の愛憎の感情を抱いているでしょう。

GitHub が優れている理由は、通常、発見したばかりのオープンソース アプリの背後にある実際のソース コードがここにあるからです。 FOSS アプリにその機能を説明する独自の Web サイトがある場合でも、GitHub を使用すると、コードを検査したり、他のユーザーが報告した現在の問題を確認したり、プロジェクト開発者が実際にどの程度対応しているかを確認したりできます。

しかし同時に、GitHub は、一般のユーザーがこれらの素晴らしいプロジェクトを発見できるようにするという点で、非常にひどい仕事をしています。

たとえば、GitHub にアクセスして「Notion 代替」を検索しても、アプリ ストアのエクスペリエンスに似たものを期待することはできません。確かに、GitHub にはリポジトリ トピックがあり、プロジェクトには「メモ取り」や「パスワード管理」などのタグを付けることができます。ただし、その分類は、メンテナがリポジトリの説明とタグ付けをどのように選択するかによって完全に決まります。 GitHub 検索では、リポジトリ名、説明、コード、その他のメタデータも調べることができますが、基本的にはアプリケーションを探している一般ユーザーではなく、ソフトウェア プロジェクトを探している開発者向けに構築されています。

公平を期すために言うと、GitHub はアプリ ストアであるべきではありません。ここには、アプリから、アプリの構築に必要なライブラリ、データセット、さらには書籍や詩に至るまで、あらゆるものが格納されています。これは、Git リポジトリをホストし、バージョン管理、コラボレーション、問題追跡のためのツールを提供するためのプラットフォームです。アプリの発見は決して重要ではありませんでした。

とはいえ、非常に多くの素晴らしいソフトウェアが組み込まれているため、よりアクセスしやすくするためのもっと便利な方法があるはずです。実際、アプリの発見は問題の半分にすぎません。良いアプリを見つけたとしても、簡単にインストールするオプションはありません。プロジェクトによっては、優れたインストール ドキュメントが用意されている場合もありますが、専門用語だらけのプロジェクトもあります。技術的なユーザーにとっては、それは些細な煩わしさですが、技術的でないユーザーにとっては、完全に行き止まりになる可能性があります。

私は友人や家族に FOSS アプリケーションを勧めたときに、このことに直接遭遇しました。 GitHub で本当に便利なオープンソース ツールを見つけてリンクを送りますが、彼らは次に何をすればいいのか全く分かりません。

そこで、その問題を解決したいと思いました。私は、Claude を使用して、GitHub 上に位置し、その膨大な FOSS プロジェクトのコレクションをアプリケーション ストアのように扱うインターフェイスを構築することにしました。これにより、ソフトウェアの発見、プロジェクトの実際の動作の理解、それが自分にとって適切かどうかの判断が容易になり、可能であれば Git の仕組みを勉強することなくインストールできるようになります。

クロードを使って問題を解決する方法

専門用語はクロードに任せましょう

アイデアは非常にシンプルです。Claude を開いて、探しているアプリケーションの種類を伝えます。それは、特定のアプリの代替となる可能性があります。たとえば、Notion の代替や Todoist の代替など、あるいは、優れたオープンソースのメモ作成アプリなど、私が興味のあるソフトウェアのカテゴリに限られることもあります。

欲しいものをもとに、クロードはインターネットを探しに出かける。

まず、Claude は、私の要件に最も適したアプリについて自身の知識を確認し、GitHub 上でそれらを相互参照して、それらが維持され、最新で、動作していることを確認します。これにより、最初のアプリのセットが生成されます。次に、AlternativeTo (ソフトウェアおよびソフトウェア代替品の巨大なクラウドソーシング データベース) を検索して、2 番目のセットを構築します。そして 3 番目に、一般的な Web 検索を実行して、最初の 2 つの方法では見逃したアプリやプロジェクトを発見する可能性のある記事、推奨事項、その他のソースを見つけます。

その後、クロードは 3 つのソースすべてを使用して、およそ 10 ～ 15 個のアプリケーションを厳選し、基本的なレイアウトで私に提示します。各アプリについて、その名前、簡単な説明、スクリーンショット (利用可能な場合)、および GitHub のスター数やフォーク数などの有用なシグナルを確認できます。それだけで、GitHub で抱えていたインターフェースの問題は解決します。

そこからは、クロードに「このアプリケーションをインストールしたい」と伝えるだけです。

次にクロードは、私が作業を進める前に、ソース コードとプロジェクトの現在の問題ページを読んで、疑わしいものがないかチェックします。確かに、これはウイルス対策スキャンや適切なセキュリティ監査ではなく、誤検知が発生する可能性は絶対にあります。しかし、完全に盲目的にアプリをインストールするよりも、追加レイヤーがあると便利だと思います。

ソース コードに問題がない場合、クロードはシステムが実際にアプリを実行できるかどうかを確認します。特定のアプリには特定の依存関係が必要であり、依存関係がないとインストールされません。一部の GitHub プロジェクトはこれについてあまり明示的ではありませんが、Claude は通常、プロジェクトの種類に基づいてどの依存関係が必要かを推測できます。

Claude Code を使用している場合、このプロセス全体を自動化できます。システムにアクセスしてターミナル コマンドを実行できるように設計されています。つまり、必要な依存関係があるかどうかを確認し、不足している依存関係があればインストールできます。代わりに Claude Web アプリを使用している場合は、ターミナル コマンドが生成されますが、それを自分で実行する必要があります。依存関係のチェックが完了したら、クロードはアプリ自体のインストールに進みます。

Claude GitHub インストーラー スキルは次のとおりです。

自分で設定するために必要なものすべて

私は個人的にこのワークフローに Claude Code を使用しています。 GitHub-Installer という名前のカスタム スキルを作成しました。以下のプロンプトを使用して自分で作成できます。セットアップが完了したら、スキルを呼び出して、アプリのカテゴリまたは代替アプリを要求するだけです。クロードは、アプリの検索、クリーンなグラフィカル ビューでの表示、ソース コードのチェック、必要な依存関係がすべてインストールされていることの確認、そして最終的にアプリのインストールを支援します。

スキルと、このワークフローに必要な他のすべての関連ファイルとスクリプトを設定するためのプロンプトは次のとおりです。

Create a skill called "github-installer" that turns GitHub into a browsable, 
installable app store.

## When it triggers

Any request for software by category or as an alternative to a known app —
"find me a Notion alternative," "open-source screenshot tool," "something like
Todoist but self-hosted." Also triggers on "install (app name) from GitHub."

## Step 1 — Pin down the request

Before searching, establish three things (ask only if not already obvious):
- Operating system and distro/version
- GUI app, CLI tool, or self-hosted service
- Any dealbreakers: must be actively maintained, must be offline-only,
  must not require Docker, etc.

Do not ask more than one round of questions. Infer what you can.

## Step 2 — Discovery from three independent sources

Run all three, then merge. Do not stop after one.

1. **Prior knowledge, verified.** List candidates you already know, then
   confirm each one still exists and is maintained via the GitHub API. Drop
   anything you cannot verify — do not present an app you have not confirmed.
2. **AlternativeTo.** Search alternativeto.net for the app or category,
   filtered to open source. Note the community vote counts.
3. **Open web search.** Look for recent roundups, Reddit and Hacker News
   threads, and awesome-lists. Prioritise sources from the last 18 months.

Merge into a deduplicated shortlist of 10–15. If fewer than 6 survive
verification, say so plainly rather than padding the list.

## Step 3 — Pull real data for every candidate

For each repo, hit the GitHub API and collect:
- stars, forks, open issue count
- date of last commit to the default branch
- license, and whether the repo is archived
- topics
- the README

Use `gh api` if the GitHub CLI is installed and authenticated — the
unauthenticated limit is 60 requests per hour, which 15 repos plus READMEs
will exhaust. If `gh` is unavailable, use curl and warn about the limit.

Flag as **unmaintained** anything archived or with no commit in 12+ months.
Include these in the gallery but mark them clearly; do not silently drop them.

**Screenshots.** Parse each README for image URLs and grab the first two or
three that look like app screenshots — skip badges (shields.io, img.shields,
badgen), logos, and icons. Convert relative paths to absolute
`raw.githubusercontent.com/関連情報は以下のリンクからご確認いただけます/公式情報はこちら/このテーマについてさらに詳しく知りたい方は以下をご覧ください/完全ガイドはこちら` URLs so
they load outside GitHub. If a repo has no usable screenshot, render a
placeholder card rather than a broken image.

## Step 4 — Build the gallery

Generate a single self-contained HTML file — all CSS inline, no external
dependencies, no build step.

- Responsive card grid, one card per app
- Screenshot leads each card, with the remaining screenshots in a simple
  click-through if more than one exists
- Below the image: app name, one-sentence description in plain language
  (rewrite the README's jargon; do not paste it), and a metadata row showing
  stars, forks, last commit, and license
- A coloured badge for maintenance status: active / slow / unmaintained
- Buttons linking to the repo and the project homepage
- Sortable by stars and by last-commit date
- Dark theme, generous whitespace, no framework

In Claude Code: write the file to the working directory and open it in the
default browser. In the Claude web app: return it as an HTML artifact.

## Step 5 — Pre-install smell test

When the user picks an app, do a fast sanity check before touching the
system. This is **not** a security audit — say so to the user explicitly,
every time.

Look for:
- obfuscated or minified code in a repo that should be readable source
- install scripts that curl-pipe to shell, or request sudo without cause
- network calls to domains unrelated to the project
- open issues mentioning malware, supply-chain problems, or a hijacked
  maintainer account
- a very new repo with a suspiciously high star count
- a license that is missing or contradicts the README

Report what you checked and what you did not. If anything looks off, stop and
explain rather than proceeding.

## Step 6 — Dependency check

Read the README and the project's build files (package.json, Cargo.toml,
requirements.txt, PKGBUILD, etc.) to determine runtime dependencies. Check
which are already present on the system.

In Claude Code: run the checks directly. In the web app: give the user a
single block of commands to run and ask them to paste back the output.

Prefer a distro package, Flatpak, or official binary release over building
from source. Only build from source if no packaged option exists — and tell
the user which route you have chosen and why.

## Step 7 — Install

In Claude Code: install missing dependencies and the app itself, showing each
command before running it. Never run a destructive command without
confirmation.

In the web app: hand over exact copy-pasteable commands for the user's
specific distro, plus a GUI alternative where one exists.

Afterwards, tell the user how to launch the app and how to uninstall it
cleanly.

## Rules

- Never invent a repository URL, a star count, or a screenshot. Every number
  in the gallery comes from a live API response.
- Never claim an app has been security-audited.
- Prefer projects with a real license over unlicensed code dumps.
- If the best tool for the job is not open source, say so rather than
  recommending a weak FOSS option to satisfy the brief.

スキルを作成すると、かなりの量のトークンが消費されます。私は 20 ドルの Pro プランを利用していますが、セッション使用量の 80% を消費しました。ただし、これは 1 回限りのことであり、今後のすべてのアプリ検索が最良の結果とトークン使用量の削減のために最適化されるようになります。

技術的なことをもっと親しみやすくする

以前は、技術的な知識がない場合、つまりコーディング、ターミナル、または広範な開発者エコシステムに精通していない場合、膨大な数の強力で、多くの場合無料のツールが事実上隠されていました。たとえ見つけたとしても、インストール方法や実行方法がわからないでしょう。

幸いなことに、Claude のような LLM はこの問題を効果的に解決しました。プロジェクトとは何かを説明し、ニーズに合うかどうかを説明し、実際にシステム上でプロジェクトを実行する手順を説明することで、技術的に親しみやすくしています。