Skills: プロンプトエンジニアリングの基礎

あなたは Python バックエンド開発の専門家です。

あなたは10年の経験を持つ Python バックエンド専門家で、FastAPI と Django を専門としています。
特に以下が得意です：
- データベース最適化と ORM チューニング
- RESTful API 設計
- 非同期プログラミングと並行処理
あなたのコードスタイル：シンプル、型安全、十分なコメント

# マルチロール Skill

タスクタイプが「アーキテクチャ設計」の場合、あなたはシステムアーキテクトで、スケーラビリティとパフォーマンスに注目します。
タスクタイプが「コード実装」の場合、あなたはシニアエンジニアで、コード品質と保守性に注目します。
タスクタイプが「デバッグ」の場合、あなたはトラブルシューティング専門家で、根本原因分析と迅速な修正に注目します。

指定された Python ファイルを読み込み、type hints が含まれているかチェックする。
なければ、すべての関数に型アノテーションを追加する。

以下の手順でデータベースマイグレーションレビューを実行：

## ステップ 1：マイグレーションファイルを理解
- マイグレーションファイルの内容を読み込む
- 操作タイプを特定（CREATE/ALTER/DROP）

## ステップ 2：リスク評価
- データ損失リスクがあるかチェック（DROP COLUMN、DROP TABLE）
- テーブルロックリスクがあるかチェック（ADD COLUMN without default）
- パフォーマンスリスクがあるかチェック（大規模テーブル ADD INDEX）

## ステップ 3：提案の生成
- 高リスク操作には段階的実行案を提案
- 低リスク操作は直接実行可能と確認

## 条件ロジック

- Python プロジェクトの場合 → `ruff check` を実行
- TypeScript プロジェクトの場合 → `eslint` を実行
- Go プロジェクトの場合 → `go vet` を実行
- 技術スタックが不明な場合 → 先に package.json / pyproject.toml / go.mod を読み込む

## 出力フォーマット

厳密に以下の JSON フォーマットを使用：

```json
{
  "summary": "一言でまとめる",
  "issues": [
    {
      "severity": "high|medium|low",
      "location": "file:line",
      "description": "問題の説明",
      "suggestion": "修正提案"
    }
  ],
  "score": 85
}

### (2) 長さの制約

```markdown
## 出力制約

- 要約は3文以内
- 各問題は100字以内
- 修正提案にはコードサンプルを含める
- 総出力は1000字以内

## 品質要件

- 修正提案は直接使用可能なコードでなければならず、擬似コードではない
- 深刻度には明確な基準が必要：high=セキュリティ脆弱性/crash、medium=パフォーマンス低下/保守性不良、low=スタイル/提案
- 不確実な問題は「要人工確認」と注記し、推測しない

## サンプル

### 入力
```python
def get_user(id):
    db = connect()
    result = db.execute(f"SELECT * FROM users WHERE id = {id}")
    return result

def get_user(user_id: int) -> dict:
    db = connect()
    result = db.execute(
        "SELECT * FROM users WHERE id = ?",
        (user_id,)
    )
    return result.fetchone()

Alice はプロンプトに3つのサンプルを追加した後、AI 出力の一貫性が60%から95%に向上しました。Bob は言います：「サンプルは最良の先生——AI に何が欲しいか伝えることは、何が欲しいかを説明するより10倍効果的です。」

---

## ❓ よくある質問

> **Q：プロンプトはどのくらいの長さが適切ですか？** **A：必要十分であれば OK です。通常 50〜200 行です。重要なのは具体的で操作可能であることで、長ければ良いわけではありません。長すぎるプロンプトは AI の焦点をぼやけさせます。**
> **Q：ネガティブ制約（「〜するな」）は書くべきですか？** **A：必要ですが、少なく抑えましょう。ポジティブな事前制約（「X だけをする」）はネガティブ制約（「Y をするな」）より効果的です。AI は「するな」という指示を見落としやすいです。**
> **Q：サンプルはいくつ書くべきですか？** **A：1〜3個で十分です。1個のサンプルでフォーマットを示し、2〜3個でエッジケースをカバーします。5個を超えると品質が低下します。**

---

## 📖 まとめ

- SPECIFIC 法則：具体的、目的、サンプル、制約、対話的、フォーマット、反復的
- ロール設定は具体的に：専門分野、スタイル、経験レベル
- タスク分解の3段階：単一ステップ記述、マルチステップフロー、条件分岐
- 出力制約：フォーマット、長さ、品質の3本柱
- Few-shot サンプルは最も効果的な品質管理手法

---

## 📝 練習問題

1. **基礎問題（難易度⭐）**：SPECIFIC 法則を使って以前書いたシンプルなプロンプトを書き直し、効果の違いを比較してください。
2. **応用問題（難易度⭐⭐）**：「API インターフェースドキュメント生成」Skill の完全なプロンプトを作成し、ロール、フロー、制約、サンプルを含めてください。
3. **チャレンジ問題（難易度⭐⭐⭐）**：変数注入で異なるロールとルールをサポートしながら、出力フォーマットの一貫性を保つ汎用プロンプトテンプレートフレームワークを設計してください。