@sk8metal/michi-cli 0.1.0 → 0.2.1

package/templates/claude/skills/e2e-first-planning/SKILL.md

@@ -0,0 +1,360 @@
+---
+name: e2e-first-planning
+description: |
+  E2Eファースト開発計画策定ガイド。
+  Walking Skeleton、MVP計画、縦割りタスク分割をサポート。
+allowed-tools: Read, Grep, Glob
+---
+
+# E2Eファースト計画策定スキル
+
+## 目的
+
+E2E（End-to-End）ファーストの開発計画を策定し、リスクを早期発見し、価値を段階的に提供する。
+
+## E2Eファーストとは
+
+### 定義
+
+**E2Eファースト**: ユーザーの視点から始めて終わりまで動作する最小限の機能を最優先で実装するアプローチ。
+
+### 重要な原則
+
+1. **価値の早期提供**: ユーザーが触れる機能を優先
+2. **リスクの早期発見**: インテグレーション問題を早期に検出
+3. **継続的なフィードバック**: 動くものを見せて方向性を確認
+4. **技術的実現可能性の検証**: 最初から本番環境を意識
+
+### なぜE2Eファーストが重要か
+
+| 利点 | 説明 |
+|------|------|
+| 🎯 **ユーザー価値重視** | 常に動作する機能を提供 |
+| 🚨 **早期リスク発見** | 統合の問題を早期に検出 |
+| 🔄 **継続的フィードバック** | ステークホルダーとの早期合意 |
+| 🏗️ **技術的実現可能性** | アーキテクチャの妥当性を検証 |
+| 📊 **進捗の可視化** | 動作する機能 = 進捗 |
+
+## アンチパターン: 横割り開発
+
+### ❌ 避けるべき開発順序
+
+```
+Phase 1: UI全体を作る
+Phase 2: API全体を作る
+Phase 3: DB全体を作る
+Phase 4: 統合（← ここで大量の問題発見）
+```
+
+**問題点:**
+- 統合まで動作する機能がゼロ
+- リスクが最後に集中
+- ユーザーフィードバックが遅い
+- 見積もりの精度が低い
+
+### ✅ 推奨: 縦割り開発（E2Eスライス）
+
+```
+Phase 1: ログイン機能（UI + API + DB）← 動作する
+Phase 2: ダッシュボード（UI + API + DB）← 動作する
+Phase 3: データ編集（UI + API + DB）← 動作する
+```
+
+**利点:**
+- 各フェーズで動作する機能を提供
+- リスクを段階的に管理
+- 継続的なフィードバック
+- 見積もりの精度向上
+
+## 計画策定フレームワーク
+
+### フェーズ1: Skeleton（骨組み）
+
+**目的**: プロジェクトの基本構造を定義
+
+**成果物:**
+- システムアーキテクチャ図
+- 主要コンポーネントの識別
+- 技術スタックの決定
+- 開発環境のセットアップ
+
+**期間**: 1-3日
+
+**チェックリスト:**
+- [ ] プロジェクト構造が明確か
+- [ ] 技術スタックが決定したか
+- [ ] 開発環境が構築できたか
+- [ ] チーム全員が構造を理解したか
+
+### フェーズ2: Walking Skeleton（歩く骨組み）
+
+**目的**: 最小限のE2E機能を実装
+
+**成果物:**
+- ユーザーから見て動作する最小機能
+- CI/CD パイプラインの構築
+- 本番環境へのデプロイ
+- 監視・ログの基本設定
+
+**期間**: 1-2週間
+
+**例: Webアプリケーション**
+```
+ユーザー → ログイン → 簡単なダッシュボード表示 → ログアウト
+（UI + API + DB + デプロイ）
+```
+
+**チェックリスト:**
+- [ ] E2Eで動作するか
+- [ ] 本番環境にデプロイできるか
+- [ ] CI/CDが機能するか
+- [ ] 監視が動作するか
+
+### フェーズ3: MVP（Minimum Viable Product）
+
+**目的**: 実際のユーザーに価値を提供できる最小限の機能セット
+
+**成果物:**
+- コア機能の実装
+- ユーザーが実際に利用できる状態
+- フィードバック収集の仕組み
+- ドキュメント
+
+**期間**: 4-8週間
+
+**チェックリスト:**
+- [ ] ユーザーが価値を感じるか
+- [ ] フィードバックを収集できるか
+- [ ] スケールするアーキテクチャか
+- [ ] 運用可能な状態か
+
+## タスク分割の原則
+
+### 縦割り（推奨）
+
+**定義**: 機能単位でUI→API→DBまで完結させる
+
+**例:**
+```
+タスク1: ユーザー登録機能
+  - UI: 登録フォーム
+  - API: POST /api/users
+  - DB: usersテーブル作成
+  - Test: E2Eテスト
+
+タスク2: ログイン機能
+  - UI: ログインフォーム
+  - API: POST /api/auth/login
+  - DB: sessionsテーブル
+  - Test: E2Eテスト
+```
+
+**利点:**
+- 各タスク完了時に動作する機能ができる
+- 統合の問題を早期発見
+- 進捗が可視化しやすい
+
+### 横割り（非推奨）
+
+**定義**: レイヤー単位で全機能を作る
+
+**例:**
+```
+タスク1: UI全画面作成
+タスク2: API全エンドポイント作成
+タスク3: DB全テーブル作成
+タスク4: 統合（← ここで問題発覚）
+```
+
+**問題点:**
+- 最後まで動作する機能がゼロ
+- 統合時に大量の問題
+- 進捗が見えにくい
+
+## E2Eスライスの特定方法
+
+### Step 1: ユーザーストーリーから始める
+
+```
+ユーザーストーリー:
+「ECサイトの管理者として、商品を登録したい」
+
+E2Eスライス:
+1. 商品登録フォームを表示（UI）
+2. 入力データを受け取る（API）
+3. データベースに保存（DB）
+4. 成功メッセージを表示（UI）
+```
+
+### Step 2: 最小限の実装を定義
+
+```
+Phase 1 (Walking Skeleton):
+- 商品名のみ登録可能
+- 画像・説明・価格は後回し
+- バリデーションは最小限
+
+Phase 2 (MVP):
+- 画像アップロード追加
+- 価格・在庫管理追加
+- 詳細なバリデーション
+```
+
+### Step 3: 依存関係を整理
+
+```
+優先度1: ログイン機能（他の機能の前提）
+優先度2: 商品一覧表示（データ確認のため）
+優先度3: 商品登録（メイン機能）
+優先度4: 商品編集（登録の拡張）
+```
+
+## マイルストーン設計
+
+### マイルストーン1: Walking Skeleton
+
+**目標**: 基本的なE2E動作を確認
+
+**成果物:**
+- ログイン → ダッシュボード表示 → ログアウト
+- CI/CDパイプライン
+- デプロイ自動化
+
+**期間**: 1-2週間
+
+**完了条件:**
+- [ ] 本番環境にデプロイ済み
+- [ ] E2Eテストが通る
+- [ ] CI/CDが動作する
+
+### マイルストーン2: MVP
+
+**目標**: ユーザーに価値を提供
+
+**成果物:**
+- コア機能3つ
+- ユーザードキュメント
+- フィードバック収集の仕組み
+
+**期間**: 4-6週間
+
+**完了条件:**
+- [ ] ユーザーが実際に利用できる
+- [ ] フィードバックを収集できる
+- [ ] パフォーマンステスト済み
+
+### マイルストーン3: 機能拡張
+
+**目標**: ユーザーフィードバックを基に機能追加
+
+**成果物:**
+- 追加機能
+- パフォーマンス最適化
+- セキュリティ強化
+
+**期間**: 継続的
+
+## 計画ドキュメントフォーマット
+
+### E2E計画テンプレート
+
+```markdown
+# プロジェクト名 - E2E計画
+
+## 概要
+- プロジェクトの目的
+- ターゲットユーザー
+- 提供価値
+
+## Walking Skeleton（1-2週間）
+
+### 目標
+最小限のE2E機能を動作させる
+
+### E2Eスライス
+1. ログイン機能（UI + API + DB）
+2. ダッシュボード表示（UI + API + DB）
+
+### 技術的準備
+- [ ] CI/CDパイプライン構築
+- [ ] デプロイ自動化
+- [ ] 監視設定
+
+## MVP（4-6週間）
+
+### 目標
+ユーザーに価値を提供できる最小機能セット
+
+### E2Eスライス（優先順）
+1. ユーザー登録（UI + API + DB）
+2. データ一覧表示（UI + API + DB）
+3. データ編集（UI + API + DB）
+
+### 完了条件
+- [ ] ユーザーが実際に利用できる
+- [ ] フィードバック収集可能
+- [ ] パフォーマンステスト済み
+
+## リスク管理
+
+| リスク | 対策 | 担当 |
+|--------|------|------|
+| 外部API統合の遅延 | モックAPIを先行実装 | チームA |
+| パフォーマンス問題 | 早期負荷テスト | チームB |
+
+## タイムライン
+
+```
+Week 1-2: Walking Skeleton
+Week 3-4: MVP Core機能
+Week 5-6: MVP追加機能
+Week 7+: フィードバック対応
+```
+```
+
+## チームへの共有方法
+
+### キックオフミーティング
+
+1. **E2Eファーストの説明**（15分）
+   - なぜ横割りではなく縦割りか
+   - 各フェーズの目標
+
+2. **Walking Skeletonのデモ**（10分）
+   - どこまで動くものを作るか
+   - 技術的な準備作業
+
+3. **タスク分割の確認**（15分）
+   - 各E2Eスライスの説明
+   - 依存関係の確認
+
+### 定期レビュー
+
+- **毎週**: E2Eスライス単位でデモ
+- **隔週**: マイルストーン進捗確認
+- **月次**: ユーザーフィードバック共有
+
+## よくある質問
+
+### Q1: すべてを最初から完璧に作る必要はないか？
+
+A: **不要です**。Walking Skeletonは最小限の実装で十分。重要なのは「E2Eで動作すること」。
+
+### Q2: 横割りの方が効率的では？
+
+A: **短期的には効率的に見えますが**、統合時の問題で結果的に遅延します。E2Eファーストは早期リスク発見により全体効率を向上します。
+
+### Q3: レガシーシステムでもE2Eファーストは可能か？
+
+A: **可能です**。まず新機能を小さなE2Eスライスで実装し、段階的に既存システムと統合します。
+
+### Q4: チームメンバーがフルスタック対応できない場合は？
+
+A: **ペアプログラミングや知識共有**で対応。または、E2Eスライス単位でフロント/バック担当を決めて密に連携。
+
+## 参考資料
+
+- [Walking Skeleton - Alistair Cockburn](https://alistair.cockburn.us/walking-skeleton/)
+- [Vertical Slice Architecture - Jimmy Bogard](https://jimmybogard.com/vertical-slice-architecture/)
+- [Shape Up - Basecamp](https://basecamp.com/shapeup)
+- [The Lean Startup - Eric Ries](http://theleanstartup.com/)

package/templates/claude/skills/oss-license/SKILL.md

@@ -0,0 +1,232 @@
+---
+name: oss-license
+description: |
+  OSSライセンス確認とコンプライアンスガイド。
+  許可/禁止ライセンス一覧、確認ツール使用法をガイド。
+allowed-tools: Bash, Read, Grep, Glob
+---
+
+# OSSライセンス確認スキル
+
+## 目的
+
+依存パッケージのライセンスを確認し、ライセンス違反リスクを早期発見する。
+
+## 重要な原則
+
+### ✅ 許可ライセンス（一般的に使用可能）
+
+- **MIT License** - 最も寛容なライセンス
+- **Apache License 2.0** - 特許条項付き
+- **BSD 2-Clause / 3-Clause** - シンプルな寛容ライセンス
+- **ISC License** - MITと同等
+- **CC0 / Public Domain** - 著作権放棄
+
+### ⚠️ 要注意ライセンス（条件付き使用）
+
+- **LGPL v2.1 / v3.0** - 動的リンクのみ許可（静的リンクは要注意）
+- **MPL 2.0 (Mozilla Public License)** - ファイル単位のコピーレフト
+- **CC BY-SA** - ドキュメント用（ShareAlike条項あり）
+- **EPL (Eclipse Public License)** - 弱いコピーレフト
+
+### ❌ 禁止ライセンス（商用利用時に要確認）
+
+- **GPL v2 / v3** - 強いコピーレフト（全体がGPLになる）
+- **AGPL v3** - ネットワーク経由でも適用される最も強いコピーレフト
+- **SSPL (Server Side Public License)** - MongoDBなどで使用
+- **CPAL (Common Public Attribution License)** - 帰属表示要求
+
+## ライセンス確認ツール
+
+### Node.js プロジェクト
+
+```bash
+# license-checker インストール
+npm install -g license-checker
+
+# 依存関係のライセンス一覧
+license-checker --summary
+
+# 問題のあるライセンスを検出
+license-checker --failOn "GPL;AGPL;SSPL"
+
+# JSON出力（詳細分析用）
+license-checker --json > licenses.json
+
+# 特定ライセンスのみ表示
+license-checker --onlyAllow "MIT;Apache-2.0;BSD"
+```
+
+### Python プロジェクト
+
+```bash
+# pip-licenses インストール
+pip install pip-licenses
+
+# 一覧表示
+pip-licenses
+
+# Markdown形式で出力
+pip-licenses --format=markdown
+
+# 許可リスト形式（違反を検出）
+pip-licenses --allow-only="MIT;Apache 2.0;BSD"
+
+# 禁止リスト形式
+pip-licenses --fail-on="GPL;AGPL"
+```
+
+### Java プロジェクト（Gradle）
+
+```gradle
+// build.gradleに追加
+plugins {
+    id 'com.github.hierynomus.license' version '0.16.1'
+}
+
+license {
+    header rootProject.file('LICENSE_HEADER')
+    strictCheck true
+}
+```
+
+または Maven:
+
+```xml
+<plugin>
+    <groupId>org.codehaus.mojo</groupId>
+    <artifactId>license-maven-plugin</artifactId>
+    <version>2.0.0</version>
+</plugin>
+```
+
+### PHP プロジェクト（Composer）
+
+```bash
+# composer-licenses インストール
+composer require dominikzogg/composer-licenses --dev
+
+# ライセンス一覧
+./vendor/bin/composer-licenses
+```
+
+### 汎用ツール
+
+```bash
+# FOSSA CLI（多言語対応）
+fossa analyze
+fossa test
+
+# Snyk（セキュリティ + ライセンス）
+snyk test --all-projects
+snyk monitor
+
+# Black Duck（エンタープライズ）
+# GitHub App: License Compliance Action
+```
+
+## ライセンス違反発見時の対応フロー
+
+### Step 1: 問題のある依存関係を特定
+
+```bash
+# Node.js の例
+license-checker --json | jq '.[] | select(.licenses | contains("GPL"))'
+
+# Python の例
+pip-licenses --fail-on="GPL"
+```
+
+### Step 2: 依存関係の調査
+
+1. **直接依存か間接依存か確認**
+   ```bash
+   # Node.js
+   npm ls <package-name>
+
+   # Python
+   pipdeptree -p <package-name>
+   ```
+
+2. **使用箇所を特定**
+   ```bash
+   grep -r "import <package-name>" .
+   ```
+
+### Step 3: 代替パッケージを調査
+
+- **同等機能のパッケージを検索**
+  - npmtrends.com（Node.js）
+  - pypi.org（Python）
+  - Maven Central（Java）
+
+- **ライセンス互換性を確認**
+  - 代替パッケージのライセンスをチェック
+  - 依存関係も確認
+
+### Step 4: 対応策の実施
+
+**A) 代替パッケージに置換**
+```bash
+npm uninstall <問題パッケージ>
+npm install <代替パッケージ>
+```
+
+**B) 除外（使用していない場合）**
+```bash
+npm uninstall <問題パッケージ>
+```
+
+**C) 法務/コンプライアンスチームに相談**
+- GPLライセンスの影響範囲を評価
+- デュアルライセンスの可能性を確認
+- 商用ライセンス購入の検討
+
+## ライセンス互換性マトリクス
+
+| 使用するライセンス | 依存先で許可されるライセンス |
+|------------------|--------------------------|
+| MIT/BSD/Apache   | ほぼすべて（GPL除く） |
+| GPL v2           | GPL v2のみ |
+| GPL v3           | GPL v3, AGPL v3 |
+| LGPL             | すべて（動的リンク時） |
+| 商用ライセンス     | MIT/BSD/Apache推奨 |
+
+## CI/CDへの組み込み
+
+### GitHub Actions 例
+
+```yaml
+name: License Check
+
+on: [push, pull_request]
+
+jobs:
+  license-check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: Install license-checker
+        run: npm install -g license-checker
+
+      - name: Check licenses
+        run: license-checker --failOn "GPL;AGPL;SSPL"
+```
+
+### Screwdriver 例
+
+```yaml
+jobs:
+  main:
+    steps:
+      - license-check: npm run license-check
+```
+
+## 参考資料
+
+- [SPDX License List](https://spdx.org/licenses/) - 標準ライセンス一覧
+- [choosealicense.com](https://choosealicense.com/) - ライセンス選択ガイド
+- [OSS Watch License Compliance](https://www.oss-watch.ac.uk/) - コンプライアンスガイド
+- [FOSSA Documentation](https://fossa.com/docs) - ライセンス管理ツール
+- [GNU License List](https://www.gnu.org/licenses/license-list.html) - GPLとの互換性情報