Claude Code実験場

目次
claude code内commandで利用できるもので便利なもの。
claude commandで利用できるもので便利なもの。
GitHubスキルチェックCLI
Claude Code内で使うプロンプト用のshellを管理するようなツールを作る
プロンプトに含めると良さそうな考えてるもの

claude code内commandで利用できるもので便利なもの。
Allow / Deny Command
claudeが実行するコマンドの確認をスキップすることができる。
/allow-tools
追加例
Bash(npm init:*)

claude commandで利用できるもので便利なもの。
Claude DesktopからMCPサーバをimport
claude mcp add-from-claude-desktop

GitHubスキルチェックCLI
今回は、自身のGitHubアカウントからスキルの変遷や、現在のスキルセットなどをまとめて出力できるようなCLIを作ろうと思います。
プロジェクトの仕様決め
まずは、このプロジェクトの仕様を決めたいと思います。
その仕様を考えるためのメモや記録を行う場所を作りましょう。
/docs というディレクトリを作り、その中に仕様用と実装用とログ用のドキュメント管理をするディレクトリを掘り、その中にmdファイルを作成していくようにしていきたいです。
以後、その方針が当プロジェクトの進め方になるので、CLAUDE.mdに追記しておいてください。
これにより以下のようなフォルダ構成で作ってもらった。
何度かやりとりしてCLAUDE.mdとREADME.mdも作成してもらう。
.
├── CLAUDE.md
└── docs
├── implementation
├── logs
└── specifications
└── specifications.md
CLAUDE.md
GitHub Level Checking プロジェクト開発ガイドライン
ドキュメント管理方針
本プロジェクトでは、以下のディレクトリ構造でドキュメントを管理します:
/docs/
├── specifications/ # 仕様関連のドキュメント
├── implementation/ # 実装関連のドキュメント
└── logs/ # 開発ログ・作業記録
各ディレクトリの用途
- specifications/: プロジェクトの仕様、要件定義、設計書などを格納
- implementation/: 実装詳細、技術的な決定事項、コーディング規約などを格納
- logs/: 日々の開発ログ、進捗記録、問題と解決策などを格納
ドキュメント作成ルール
- すべてのドキュメントはMarkdown形式(.md)で作成する
- ファイル名は内容を表す分かりやすい名前にする
- 日付が重要なログファイルは
YYYY-MM-DD-内容.md
の形式で命名する
プロジェクト情報
- プロジェクト名: GitHub Level Checking
- 作成日: 2025年5月27日
specifications.md
GitHub Level Checking プロジェクト仕様書
プロジェクト概要
[ここにプロジェクトの概要を記載]
目的
[プロジェクトの目的を記載]
機能要件
必須機能
- 機能1
- 機能2
オプション機能
- 機能A
- 機能B
非機能要件
パフォーマンス
[パフォーマンスに関する要件]
セキュリティ
[セキュリティに関する要件]
使いやすさ
[ユーザビリティに関する要件]
技術スタック
フロントエンド
[使用する技術]
バックエンド
[使用する技術]
インフラ
[使用するインフラ]
アーキテクチャ
[システムアーキテクチャの説明]
データモデル
[データモデルの説明]
API仕様
[API仕様の概要]
開発スケジュール
フェーズ1
[内容と期間]
フェーズ2
[内容と期間]
メモ・アイデア
[プロジェクトに関するメモやアイデアを自由に記載]
初期段階はこんな感じ

Claudeに渡すためのプロンプト生成用のドキュメント保管所を作成
次に、自分が仕様などをClaudeに渡すための領域を確保します。
以下のプロンプトで作成。
では、次に私があなたに与えるためのプロンプトを書く領域を作りたいと思います。
promptsというディレクトリをルートに作り、CLAUDE. mdを中に作成してください。
その中で、仕様についてのプロンプトを作成していこうと思ってるので
最適化した状態で扱いやすいような構成で組んでください。
prompts/CLAUDE.md このファイルの内容を充実させていきたいと思います。
焦点として、まず、specificationsに記載されてる仕様のファイルを読み込んで、次にimplementationにあるメモを読み取り、最後にtemplateに当てはめて実行するようにするという手順を追加してください
docs/specifications/specifications.md これに対して必要な項目を埋めてください。
TypeScriptを使って、Commanderを使ったCLIを想定しています。
その上で、GitHubへのアクセスに関する技術構成も追記してください。

上記で作ってもらったspecificationを元にどんなインターフェースを想定しているかを確認してみる。
この時点で、僕自身はspecificationはほとんど読んでいない。
出てきた結果が良さそうだったので、それを実装のドキュメントに追加する。
それを実装後のアウトプットとして docs/implementation に追加してください

Claude Code内で使うプロンプト用のshellを管理するようなツールを作る
以下の仕様書を雛形は作ってもらってから自分で記載する。
docs.md
仕様書
1. 概要
1.1 プロジェクト名
Claude Code Prompt Directory Preset
1.2 目的
Claude Code でコーディングするときに、プロンプトやClaude Code が記録するメモリー的なテキストを入力しておく保管所を自動で作成するCLIツールです。
1.3 スコープ
- プロジェクトの種類に応じたディレクトリ構成の自動生成
- Claude Code用のプロンプトファイルの配置
- プロジェクトテンプレートの選択と適用
2. 要件定義
2.1 機能要件
2.1.1 必須機能
インタラクティブなCLIツールとして、以下の流れで動作します:
-
プロジェクトの目的選択
- Webアプリケーション開発
- API開発
- CLIツール開発
- ライブラリ開発
- その他
-
ディレクトリ構成の選択
- 標準構成
- クリーンアーキテクチャ
- MVCパターン
- カスタム構成
-
必要なディレクトリ・ファイルの自動生成
- 選択した構成に基づいて必要なディレクトリを作成
-
.claude/
ディレクトリにプロンプトファイルを配置 -
CLAUDE.md
メモリーファイルの生成
2.1.2 オプション機能
- プロジェクトテンプレートのカスタマイズ機能
- 既存プロジェクトへのClaude Code設定追加機能
- プロンプトテンプレートの管理機能
2.2 非機能要件
2.2.1 パフォーマンス
- ディレクトリ生成は1秒以内に完了すること
2.2.2 セキュリティ
- ファイルシステムへの書き込み権限の適切な確認
2.2.3 可用性
- クロスプラットフォーム対応(Windows, macOS, Linux)
2.2.4 保守性
- モジュール化された設計
- 十分なテストカバレッジ
3. システム構成
3.1 アーキテクチャ
標準的なGoプロジェクト構成を採用:
/
├── cmd/
│ └── claude-preset/
│ └── main.go
├── internal/
│ ├── cli/
│ ├── generator/
│ └── templates/
├── pkg/
├── go.mod
└── go.sum
3.2 技術スタック
- 言語: Go 1.21+
- CLIフレームワーク: Cobra
- 依存関係管理: Go Modules
3.3 インフラ構成
特になし(スタンドアロンCLIツール)
4. データ設計
4.1 データモデル
type ProjectConfig struct {
Purpose string
Architecture string
Directories []string
PromptTemplates map[string]string
}
type Template struct {
Name string
Description string
Structure map[string][]string
Prompts map[string]string
}
4.2 データベース設計
該当なし(設定はJSONファイルで管理)
4.3 API仕様
該当なし(CLIツール)
5. 画面設計
5.1 画面一覧
CLIインターフェース:
- 初期メニュー画面
- プロジェクト目的選択画面
- アーキテクチャ選択画面
- 確認画面
- 実行結果表示画面
5.2 画面遷移図
開始 → 目的選択 → アーキテクチャ選択 → 確認 → 生成 → 完了
5.3 UI/UXガイドライン
- 明確で簡潔なプロンプト表示
- 矢印キーでの選択操作
- 進捗状況の表示
6. 実装詳細
6.1 モジュール構成
- cmd/claude-preset: エントリーポイント
- internal/cli: CLIインターフェース処理
- internal/generator: ディレクトリ・ファイル生成ロジック
- internal/templates: プロジェクトテンプレート定義
6.2 主要な関数
// CLIの初期化と実行
func Execute() error
// プロジェクト生成
func GenerateProject(config ProjectConfig) error
// テンプレート適用
func ApplyTemplate(template Template, path string) error
7. テスト
7.1 テスト方針
すべての公開関数および主要な内部関数に対してユニットテストを実装します。
7.2 テストケース
- 各プロジェクトタイプの生成テスト
- ディレクトリ作成の成功・失敗ケース
- テンプレート適用のテスト
- エラーハンドリングのテスト
7.3 受け入れ基準
- テストカバレッジ80%以上
- 境界値テストの実施
- エラーケースの網羅的なテスト
8. 運用
8.1 デプロイ手順
-
go build
でバイナリをビルド - GitHubリリースにバイナリをアップロード
- Homebrewフォーミュラの更新(オプション)
8.2 監視項目
該当なし(スタンドアロンツール)
8.3 バックアップ方針
該当なし
9. 制約事項
- Go 1.21以上が必要
- ファイルシステムへの書き込み権限が必要
- 既存ファイルの上書きは行わない
10. 用語集
- Claude Code: Anthropic社のAIアシスタントツール
- プロンプト: Claude Codeに与える指示や文脈情報
- CLAUDE.md: Claude Codeがプロジェクトの文脈を記憶するためのファイル
11. 参考資料
12. 更新履歴
日付 | バージョン | 更新内容 | 更新者 |
---|---|---|---|
2025/01/27 | 1.0 | 初版作成 |
次にプリセットを配置するプロンプトを書く。
docs.md のファイルにどんなプリセットがあるといいか、ほしいプリセットを書く領域を作ってください。
しかし、これでは自分の想定してるプリセットが伝わっておらず、フレームワークなどを選択させると勘違いしていたので、より詳しくする。
プリセットの例としては、
ccpdp (calude code prompt dir preset) "docs > instructions" "docs > logs"
とかで実行するとdocsというディレクトリの中にinstructionsとlogsのディレクトリを作成するようなCLIを想定しています。
これでプリセットが想定通りになったが、webアプリケーションなども用意されていたので、削除用のプロンプトを流す。

プロンプトに含めると良さそうな考えてるもの
雑なプロンプトでもそれなりにやってくれるが、開発以外のものについてはさすがに指示を出さないといけないので、それらを中心にCLAUDE.mdに追加しておくと良さそう。
具体的には以下
- 作業のログを記録
- レビューの内容