Merge pull request #4 from kc3hack/docs/copilot-docs

docs: Add GitHub Copilot guidelines and PR templates

Author: Inlet-back

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,11 @@
+## 実装の概要
+
+## 技術的な意思決定と「なぜ」
+
+## セキュリティに関する自己評価
+
+- [ ] 機密情報のハードコードはないか
+- [ ] 入力値の検証（バリデーション）は行っているか
+- [ ] 既知の脆弱性パターンへの対策は考慮したか
+
+## レビュワー（人間）への申し送り事項

.github/copilot-instructions.md

@@ -0,0 +1,30 @@
+# Role & Persona
+
+あなたは世界トップレベルのセキュリティエンジニア兼ソフトウェアアーキテクトの指導を受けている、**優秀な実装担当エンジニア**です。
+私はあなたのコードの「レビュワー」であり、設計の整合性とセキュリティ、可読性に責任を持ちます。
+
+## 基本的な振る舞い
+
+- **言語**: 日本語 (Japanese) で回答してください。
+- **スタンス**:
+  - 実装の意図と考慮したリスクを常に明確にしてください。
+  - アーキテクチャに関わる重大な方針決定は独断で行わず、必ず確認を求めてください。
+  - ディレクトリ構造やファイル名は、その時点で選定された言語やフレームワーク（Next.js / FastAPI）のコミュニティ標準（ベストプラクティス）に厳密に従ってください。
+
+## 絶対厳守事項 (Critical Rules)
+
+1. **Secrets Management**:
+   - AWSキー、APIトークン、パスワード等の機密情報をコードにハードコードすることは**厳禁**です。
+   - 必ず環境変数（`.env`）を使用してください。
+2. **Review Process**:
+   - 実装完了時は、私がレビューしやすいように「実装の意図」と「リスク」を要約して伝えてください。
+
+## 参照スキル (Agent Skills)
+
+特定のタスクを行う際は、以下のスキル定義を自動的に参照、または意識してください。
+
+- **コードスタイル・エラー処理**: `.github/skills/coding-standards/SKILL.md`
+- **セキュリティ実装**: `.github/skills/security/SKILL.md`
+- **コミット・PR作成**: `.github/skills/git-workflow/SKILL.md`
+- **コーディング・エラー処理**: `.github/skills/coding-standards/SKILL.md`
+- **アーキテクチャ設計**: `.github/skills/architecture/SKILL.md`

.github/skills/architecture/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: architecture
+description: Application Architecture (Frontend/Backend Separation), Directory Structure (FastAPI/Next.js)
+---
+
+# Architecture Guidelines
+
+## 1. System Overview
+
+本プロジェクトは、**Frontend (Next.js)** と **Backend (Python/FastAPI)** が分離された構成を採用しています。
+Frontendはユーザーインターフェースを提供し、Backendはビジネスロジック、データベース操作、およびLLMチェーンの実行を担当します。
+
+## 2. Backend Architecture (Python/FastAPI)
+
+Backendは、関心事の分離（Separation of Concerns）を重視し、以下のようなレイヤー構造を意識してください。
+
+### Directory Structure & Responsibilities
+
+- **`app/api/` (Presentation Layer)**:
+  - ルーティング定義とリクエスト/レスポンスのハンドリングのみを行う。
+  - ビジネスロジックをここに書かないこと。ServiceやChainを呼び出す役割に徹する。
+  - Pydanticモデル(`schemas/`)を使用してバリデーションを行う。
+
+- **`app/chains/` & `app/services/` (Business Logic Layer)**:
+  - コアとなるビジネスロジックや、LangChain等を用いたLLMのオーケストレーションを記述する。
+  - 特定のAPIエンドポイントに依存しない再利用可能なロジックを目指す。
+
+- **`app/models/` (Data Access Layer)**:
+  - データベースのモデル定義（SQLAlchemy等）。
+  - DB操作の具体的な実装（CRUD）は、必要に応じて `crud/` ディレクトリ（またはRepositoryパターン）に分離することを推奨するが、規模が小さいうちはService内で完結させても良い。
+
+- **`app/schemas/` (Data Transfer Object)**:
+  - APIの入出力定義（Pydanticモデル）。
+  - DBモデルとAPIレスポンスモデルは分離して定義すること。
+
+### Key Principles
+
+- **Dependency Injection (DI)**: DBセッションや設定、Serviceクラスの依存関係は、FastAPIの `Depends` を使用して注入する。
+- **Statelessness**: サーバーはステートレスに保ち、スケーラビリティを確保する。
+
+## 3. Frontend Architecture (Next.js)
+
+Feature-based な構成と、App Router の機能を活用したアーキテクチャを採用します。
+
+### Directory Structure (src/)
+
+- **`app/`**:
+  - ルーティング定義（page.tsx, layout.tsx）のみを配置する。
+  - ページコンポーネントは、`features/` 内のコンポーネントを組み立てる役割に徹する。
+
+- **`features/`**:
+  - 機能単位（ドメイン単位）で分割する（例: `auth`, `skills`, `generation`）。
+  - 各featureフォルダ内で `components`, `hooks`, `api`, `types` を持つことで、機能ごとの凝集度を高める。
+
+- **`components/ui/`**:
+  - ドメインに依存しない、汎用的なUIコンポーネント（Button, Input, Cardなど）。
+  - shadcn/ui 等のコンポーネントはここに配置される。
+
+### Server vs Client Components
+
+- **Server Components (Default)**:
+  - 原則としてServer Componentを使用する。
+  - データフェッチ、機密情報へのアクセス、重い計算処理はサーバー側で行う。
+  - DBへの直接アクセスや、バックエンドAPIへの直接コールはServer Componentで行うことが望ましい。
+
+- **Client Components**:
+  - `use client` ディレクティブが必要な場合のみ使用する（例: `useState`, `useEffect`, イベントハンドラを使用する場合）。
+  - Treeの末端（Leaf nodes）に配置することを心がける。

.github/skills/coding-standars/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: coding-standards
+description: Error Handling, Logging (JSON), Type Safety (TypeScript/Python), Naming Conventions
+---
+
+# Coding Standards
+
+## 1. General Principles
+
+- **No Silent Failures**: エラーを握りつぶさない。必ずハンドリングするか、上位へ伝播させる。
+- **Type Safety**:
+  - **TypeScript**: `any` 型の使用は原則禁止。必要なら `unknown` を使い型ガードを行う。
+  - **Python**: Type Hints (型ヒント) を必須とする。Pydanticモデルを積極的に利用する。
+
+## 2. Backend (Python/FastAPI) Guidelines
+
+### Error Handling & Logging
+
+ログは構造化されたJSON形式で出力すること。
+
+```python
+from app.core.logger import logger
+
+try:
+    # 処理
+    pass
+except Exception as e:
+    logger.error({
+        "event": "skill_generation_failed",
+        "error": str(e),
+        "user_id": current_user.id,
+        "stack_trace": traceback.format_exc()
+    })
+    raise HTTPException(status_code=500, detail="Internal Server Error")
+```
+
+### Dependency Injection
+
+- グローバル変数は避け、FastAPIの `Depends` を使用してServiceやDBセッションを注入すること。
+
+## 3. Frontend (Next.js/TypeScript) Guidelines
+
+### Component Design
+
+- **Container/Presentational Pattern**: データ取得ロジック（Server ComponentsまたはCustom Hooks）と、表示用コンポーネントを分離する。
+- **Server Components**: 可能な限りServer Components (`app/`配下) でデータフェッチを行い、Client ComponentsにPropsで渡す。
+
+### Error Boundary
+
+- 予期せぬクラッシュを防ぐため、主要な機能ブロックごとに React Error Boundary を設置すること。
+
+## 4. Naming Conventions
+
+- **Variables/Functions**:
+  - TS: `camelCase` (例: `fetchUserData`)
+  - Python: `snake_case` (例: `fetch_user_data`)
+- **Files**:
+  - TS Components: `PascalCase.tsx` (例: `SkillCard.tsx`)
+  - TS Utils: `camelCase.ts` or `kebab-case.ts`
+  - Python Modules: `snake_case.py`

.github/skills/domain-handson/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: git-workflow
+description: Git Commit Guidelines (Conventional Commits), Pull Request Templates, Atomic PRs
+---
+
+# Git & Commit Guidelines
+
+コードの変更理由を明確にするため、以下のルールに従ってコミットメッセージやPRを作成してください。
+
+## 1. Conventional Commits
+
+コミットメッセージのプレフィックスには以下を適切に使用してください。
+
+- `feat:`: 新機能
+- `fix:`: バグ修正
+- `docs:`: ドキュメントのみの変更
+- `refactor:`: リファクタリング（機能追加やバグ修正を含まない）
+- `test:`: テストの追加・修正
+- `chore:`: ビルドプロセスやツールの変更
+
+## 2. Commit Body (Explain "Why")
+
+変更理由はコード内のコメントではなく、**コミットメッセージの本文（Body）**に記述してください。
+「何をしたか」だけでなく**「なぜその変更が必要だったか」「なぜその実装を選択したか」**を記述してください。
+
+### 良い例
+
+```text
+fix: ユーザー登録時のバリデーションロジックを修正
+
+正規表現の不備により、特定のメールアドレス形式でReDoS脆弱性の懸念があったため、
+バリデーションライブラリ `validator.js` の標準関数に置き換えを実施。
+自作正規表現よりも保守性とセキュリティが担保されるため。
+```
+
+## 3. Pull Request (PR) Rules
+
+- **Template Compliance**: PR作成時は必ずリポジトリの `PULL_REQUEST_TEMPLATE.md` を使用し、全ての項目（特にセキュリティ自己評価）を埋めてください。
+- **Atomic PRs**: 1つのPRには1つの機能・修正のみを含めてください。巨大なPRはレビュー負荷が高まるため拒否します。
+- **Self-Review**: PRを作成する前に、あなた自身で生成されたコードを見直し、不要なデバッグ出力やコメントアウトされたコードが残っていないか確認してください。

.github/skills/domain-skill-memo/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: security
+description: Security Standard, Vulnerability Prevention (SQLi, XSS, CSRF), IPA Guidelines
+---
+
+# Security First Guidelines
+
+セキュリティに関わる実装（認証、DB操作、外部入力の処理など）を行う際は、以下の基準を遵守してください。
+
+## 1. Vulnerability Prevention
+
+- **基本方針**: SQLインジェクション、XSS、CSRF等の基本的な脆弱性が混入しないよう、常に検証済みのライブラリやフレームワーク標準の関数を使用してください。
+- **独自実装の禁止**: 暗号化ロジックやサニタイズ処理を独自に実装せず、信頼できるライブラリを使用してください。
+
+## 2. Security Standard (IPA)
+
+日本のIPA（情報処理推進機構）が発行する**『安全なウェブサイトの作り方』**のセキュリティ要件に準拠します。
+実装時は以下のチェックリスト観点を考慮してください（URLの内容を知識として参照すること）。
+
+- 参考：IPA「安全なウェブサイトの作り方」PDF（https://www.ipa.go.jp/security/vuln/websecurity/ug65p900000196e2-att/000017316.pdf ）。リンク切れの場合は、IPA公式サイト上で「安全なウェブサイトの作り方」を検索して参照してください。
+
+## 3. 具体的な実装チェック
+
+- **SQL操作**: ORMまたはプレースホルダを使用しているか？（文字列結合の禁止）
+- **HTML出力**: React/Next.jsの標準エスケープを利用しているか？（`dangerouslySetInnerHTML` の使用禁止、または正当な理由の説明）
+- **認証**: パスワードはハッシュ化されているか？ セッション管理はセキュアか？