使い方ガイドの画面図は、1枚もスクショを撮っていない ── ui-sketch で作れるもの
Y.NetLabo の使い方ガイドに載っている画面図は、すべて Claude にコードを読ませて描かせたラフ画です。実際にサイトで公開している図をそのまま並べて、何ができて何ができないか、なぜスクリーンショットをやめたのかを書きました。
続きを読む →はじめに
Claude Code を使っていると、毎回まったく同じ説明をしていることに気づく。
「spec は差分を追記せず本文を書き換えて」「Flutter はコード生成を使わない構成で」「ストア申請のチェックリストを作って、プライバシー申告と広告 SDK の矛盾も見て」。
プロジェクトが変われば CLAUDE.md も変わるので、そのたびに書き直す。書き直すたびに少しずつ内容が痩せていく。
そこで Agent Skills として切り出して、GitHub に公開した。
- リポジトリ：github.com/yuuint/claude-skills
- サイト内の一覧：Claude スキル集
現時点で10スキル、MIT ライセンス。実際にアプリ開発と旅行の計画で使っているものを、機密情報を抜いてそのまま出している。
Agent Skills とは
SKILL.md という手順書を置いておくと、関連する作業が来たときだけ Claude が自分で読み込む仕組みだ。
CLAUDE.md との違いはここにある。CLAUDE.md はセッション中ずっとコンテキストに乗っているが、スキルは必要になるまで読まれない。だから、旅行の計画書を作るときの細かい規約が、Flutter のリファクタ中にコンテキストを圧迫することがない。
置き場所は2つ。
~/.claude/skills/<skill-name>/ # 全プロジェクトで使う
<your-project>/.claude/skills/<name>/ # そのプロジェクトだけ呼び出すためのコマンドは要らない。ディレクトリを置くだけで、あとは Claude が判断する。
公開したスキル
| カテゴリ | スキル | 何をするか |
|---|---|---|
| アプリ開発 | app-store-submission | App Store Connect / Google Play の全入力項目を、値付きチェックリストに落とす |
| アプリ開発 | aso-store-copy | ストア掲載コピー（アプリ名・サブタイトル・キーワード・説明文）を欄ごとに設計する |
| アプリ開発 | flutter-lean-architecture | コード生成を使わない Flutter 構成。feature-first + 軽量レイヤード |
| アプリ開発 | ui-sketch | Flutter / SwiftUI のコードから、画面のラフ画を SVG で生成する |
| 設計・UX | app-design-philosophy | UI/UX 判断の基準を1枚のドキュメントにまとめる |
| 開発プロセス | spec-driven-dev | 実装前に spec を書き、設計判断は ADR に1枚ずつ残す |
| 旅行 | trip-planner | 複数人の国内旅行の計画書を Markdown 一式で作る |
| 旅行 | trip-planner-pdf | その一式を A4 の提案書スタイル PDF に組む |
| 旅行 | trip-map | 旅程に載せる地図を SVG で生成する |
| 学習 | exam-prep | 要点まとめ → 模擬試験 → 誤答の「型」分析 → 追加問題、のループ |
exam-prep は前回の記事で書いた、試験前日にやった学習ループをそのままスキルにしたものだ。
スキルにしたもの / しなかったもの
切り出すかどうかの判断は、最終的にこの1点に落ち着いた。
同じ判断を、別のプロジェクトでもう一度させることになるか。
spec-driven-dev の「spec は差分を追記せず本文を書き換える」は、プロジェクトが変わっても同じ判断だ。だからスキルにする価値がある。
逆に、このアプリのこのモデルはこう扱うという類はスキルにしなかった。それは CLAUDE.md か spec の仕事で、スキルに書くと他のプロジェクトで邪魔になる。
もうひとつ切り出さなかったのが、一度きりの作業手順だ。「今回のリリースはこの順で」のような手順は、書いた翌週には古くなる。スキルは置きっぱなしになるので、腐るものを入れると害の方が大きい。
書くときに効いた3つのルール
1. description が本体だと思って書く
SKILL.md の frontmatter にある description は、読み込むかどうかの判断にしか使われない。ここが弱いと、どれだけ本文を作り込んでも呼ばれない。
なので「何をするか」だけでなく、どういう状況で使うかまで書く。
実際の spec-driven-dev の description はこうなっている（1行で書く）。
description: 実装の前に仕様書（spec）を書き、設計判断は ADR に 1 枚ずつ残す進め方を運用する。spec は常に「現在の仕様」だけを書き、変更時は差分を追記せず本文を書き換える。ユーザーが新機能の実装を始めるとき、仕様書やドキュメントの書き方・更新について話しているとき、技術選定の理由を残したいときに使う。Use when the user mentions spec, specification, design doc, ADR, architecture decision record, feature planning, or asks to document a decision.日本語で書いたあとに英語のトリガー文を足しているのは、依頼が英語混じりになったときの取りこぼしを減らすため。
2. SKILL.md は薄く、詳細は references/ に逃がす
SKILL.md は読み込まれた瞬間に全文がコンテキストに乗る。ここに App Store のリジェクト条項を全部書くと、毎回それを読ませることになる。
だから SKILL.md には手順と判断基準だけを置いて、事例集やテンプレートは別ファイルにし、本文からリンクする。必要になったときだけ Claude が開く。
skills/app-store-submission/
├── SKILL.md # 手順と判断基準（薄く保つ）
├── references/rejections.md # 実際に落ちたリジェクト条項の事例集
├── references/ios-app-store.md
└── assets/submission-checklist.md # 出力のテンプレート3. 「やらないこと」を明記する
効いた記述の多くは、やることではなくやらせないことだった。
ui-sketch の「コードに無い要素を足さない」は、これを書く前は「あった方が自然」で存在しない項目を描き足してきた。図が嘘になると仕様レビューが成立しない。
trip-planner の「確定・未手配・提案を混ぜない」「憶測を確定として書かない」も同じで、書かないと全部が予約済みであるかのような計画書が出てくる。
公開にあたって
リポジトリは公開なので、API キー・トークン・個人情報・絶対パス・実データは一切入れていない。すべてプレースホルダで、コミット前に機密情報スキャンを通している（GitHub Actions でも自動で回している）。
自分のために書いた手順書をそのまま公開しようとすると、/Users/<名前>/ のような絶対パスや、実在のプロジェクト名がぽろぽろ出てくる。ここは Claude 自身に CLAUDE.md で禁止事項を持たせて、書くたびにプレースホルダ化させるのが結局いちばん確実だった。
使ってみる
git clone https://github.com/yuuint/claude-skills.git
cp -r claude-skills/skills/<skill-name> ~/.claude/skills/インストール後、Claude Code でスキルに関連する依頼をすれば自動的に読み込まれる。最新版に追従したいならシンボリックリンクでもいい。
各スキルの SKILL.md は全文をスキル一覧ページに載せてあるので、入れる前に中身を読んでから判断できる。
スキルは今後も増やしていく予定です。要望や「ここが動かない」があれば、お問い合わせか GitHub の Issue からお願いします。
