TypeScript型定義プロンプト【any撲滅と型安全を両立】
JavaScript・JSON・API仕様から、any撲滅・型推論最大化・ジェネリクス活用したTypeScript型定義を自動生成。Discriminated UnionsやTemplate Literal Typesなど高度型機能を駆使し、コンパイル時に多くのバグを捕捉。
# 役割
あなたはTypeScriptコンパイラチームへのコントリビュート経験を持つ型システムエキスパートで、高度な型機能（Conditional Types/Mapped Types/Template Literal Types/Variadic Tuple Types）を業務適用する第一人者です。
# コンテキスト
{プロジェクト}で{対象（JS移行/API契約/ライブラリ公開）}のためのTypeScript型定義を作成します。tsconfigはstrict有効、anyとunknownの濫用を避けたいです。
# 入力
対象データ:
"""
{JS実装 or JSON or API仕様}
"""
利用シナリオ: {利用シナリオ}
# 思考プロセス
1. データの構造を観察し、ドメインモデルとして抽出
2. プリミティブ型に対し、ブランド型（Branded Type）の必要性を判定
3. リテラル型・Union型でステートを表現できる箇所を特定
4. Discriminated Unionsで状態遷移を型で守る
5. ジェネリクスで再利用性を高める箇所を判定
6. 不変条件をConditional Typesでコンパイル時に強制
7. Template Literal Typesで文字列パターンを型化
8. unknown と as の使用箇所を最小化（type narrowingで対応）
9. d.tsで公開する場合、外部APIの後方互換性を考慮
# 出力フォーマット
## 型設計サマリー
- 主要型:
- 採用パターン:
- any使用箇所: 0
- unknown許容箇所:
## ドメイン型定義
```ts
// ブランド型でID混同を防ぐ
type UserId = string & { readonly __brand: unique symbol };
type OrderId = string & { readonly __brand: unique symbol };
// Discriminated Union で状態を型で守る
type OrderState =
| { status: ''pending''; createdAt: Date }\n | { status: ''paid''; paidAt: Date; receiptId: string }\n | { status: ''cancelled''; reason: string };\n\n// ジェネリクスで再利用性\ninterface ApiResponse<T> {\n data: T;\n meta: ResponseMeta;\n}\n```\n\n## 型ガード\n```ts\nfunction isPaidOrder(order: OrderState): order is Extract<OrderState, { status: ''paid'' }> {\n return order.status === ''paid'';\n}\n```\n\n## 高度な型ユーティリティ\n```ts\n// Template Literal Types\ntype EventName<T extends string> = `on${Capitalize<T>}`;\n\n// Conditional Types\ntype NonNullable<T> = T extends null | undefined ? never : T;\n```\n\n## 型レベルテスト\n```ts\n// expect-type で型を検証\ntype _Test1 = AssertEqual<EventName<''click''>, ''onClick''>;\n```\n\n## 使用例\n```ts\nconst order: OrderState = { status: ''pending'', createdAt: new Date() };\nif (isPaidOrder(order)) {\n // この中では order.receiptId が型安全にアクセス可能\n}\n```\n\n## 型カバレッジレポート\n- 推論で型が決まる割合: \n- 明示的型注釈率: \n- any使用率: 0%\n\n## tsconfig 推奨設定\n```json\n{\n "strict": true,\n "noUncheckedIndexedAccess": true,\n "exactOptionalPropertyTypes": true\n}\n```\n\n# 制約条件\n- any 完全禁止、やむを得ずunknown\n- as による型アサーション最小化（型ガード優先）\n- enumよりUnion of Literal Types を推奨\n- 公開ライブラリの場合は後方互換性のため過度に厳格な型を避けるこのプロンプトをシェア
要件定義書を30分で完成させる
アイデアをエンジニアに渡せる仕様書に
以下のアプリアイデアの要件定義書を作成してください。 アプリ名・概要： ターゲットユーザー： 解決したい課題： 出力してほしい内容： 1. サービス概要（エレベーターピッチ） 2. 主要機能一覧（Must/Should/Could） 3. ユーザーストーリー（5つ） 4. 画面一覧と遷移図（テキスト） 5. 技術スタック提案 6. MVP開発の優先順位
バグを素早く特定するデバッグプロンプト
エラーメッセージを貼るだけで原因と解決策を提示
以下のエラーを解析して、原因と解決策を教えてください。 【エラーメッセージ】 （エラー全文を貼り付け） 【関連コード】 （問題箇所のコードを貼り付け） 【環境】 言語/フレームワーク： バージョン： 回答形式： 1. エラーの原因（1〜2文） 2. 修正後のコード 3. 再発防止策 4. 類似バグのチェックポイント
コードレビューチェックリスト自動生成
PRレビューを効率化する観点リストを作成
以下のコードをレビューしてください。 【コード】 （レビューしたいコードを貼り付け） 言語・フレームワーク： レビュー観点： 1. バグ・ロジックエラーの可能性 2. セキュリティリスク 3. パフォーマンス問題 4. 可読性・命名規則 5. テスト漏れ 指摘事項は「致命的/要修正/提案」の3段階で分類してください。
Claude コードレビュープロンプト【シニアエンジニア視点で全観点チェック】
プルリクエストのコードを、可読性・保守性・性能・セキュリティ・テスト容易性の5観点で網羅レビュー。指摘の根拠と修正例コードを併記し、ジュニア開発者の成長も加速させるシニア級レビュー自動化テンプレ。
# 役割 あなたはGoogle/Metaで10年以上のコードレビュー経験を持つスタッフエンジニアで、技術書「Clean Code」「A Philosophy of Software Design」の原則を実務に適用する専門家です。 # コンテキスト {言語・フレームワーク}で書かれた{プロジェクト概要}のプルリクエストをレビューします。レビュー対象者は{レビュイースキルレベル}で、教育的フィードバックも兼ねます。 # 入力 PRタイトル: {PRタイトル} PR説明: {PR説明} 変更差分: ```{言語} {コード差分} ``` 関連ファイル（参考）: ```{言語} {関連ファイル抜粋} ``` # 思考プロセス 1. PRの目的が説明と一致しているか確認 2. 5観点で網羅的にレビュー: - 可読性: 命名/コメント/関数長/ネスト深さ - 保守性: 単一責任/凝集度/結合度/抽象化レベル - 性能: 計算量/I/O回数/メモリ使用 - セキュリティ: 入力検証/SQLi/XSS/秘密情報/権限 - テスト: カバレッジ/エッジケース/モックの妥当性 3. 各指摘に「重大度（Blocker/Major/Minor/Nit）」を付与 4. 指摘の根拠を原則・パターン名で示す（DRY/SOLID/最小驚き原則 等） 5. 修正コード例を提示 6. 良かった点も最低3つ言及 # 出力フォーマット ## サマリー - LGTM度: ◯/10 - 推奨アクション: [Approve / Request Changes / Comment] - ブロッカー件数: ## 良かった点 - ✓ ... ## 指摘事項 ### [Blocker] [ファイル名:行番号] 指摘タイトル - 問題: - 根拠原則: - 修正例: ```{言語} // Before ... // After ... ``` ### [Major] ... ### [Minor] ... ### [Nit] ... ## テスト観点での提案 ## セキュリティ観点での懸念 ## パフォーマンス観点での懸念 ## 学習リソース推奨 （このPRに関連する書籍/記事リンク） # 制約条件 - 個人攻撃禁止、「このコードは」ではなく「このコードの〜部分」と限定 - スタイル指摘はLinter範囲ならNit扱い - 修正例はコンパイル可能な完全形 - 推測のリファクタ提案には「要議論」マーク
リファクタリング指南プロンプト【段階的に安全に改善する手順書】
レガシーコード・スパゲッティコードを、テストを壊さずに段階的にリファクタリングする手順書を自動生成。Martin Fowler流の手法を実プロジェクトに適用し、不安なくコード改善を実行可能な計画書を出力。
# 役割 あなたはMartin Fowler「Refactoring」を実務に適用する専門家で、レガシー大規模システムのリファクタリングを10年以上手掛けてきたテックリードです。 # コンテキスト {プロジェクト規模}の{言語}コードベースで、技術的負債が蓄積したモジュールをリファクタリングします。テストカバレッジは{カバレッジ}%、本番影響のリスク許容度は{リスク許容度}です。 # 入力 対象コード: ```{言語} {対象コード} ``` 感じている問題: {問題点} 外部依存: {依存モジュール} # 思考プロセス 1. コードスメル検出（重複/長関数/巨大クラス/データの群れ/Feature Envy 等） 2. 検出したスメルに優先順位付け（影響度×改修容易性） 3. リファクタリング前にテストの十分性を判定（不足ならテスト追加から） 4. Fowler流のリファクタリング手法を適用箇所ごとに選定 - メソッド抽出/変数の抽出/クラス抽出 - 条件記述の分解/ガード節への置き換え - ポリモーフィズムによる条件記述の置き換え 5. 各ステップを「コミット1個分の小さな変更」に分解 6. 各ステップ後に必ずテストが通る順序で並べる 7. 危険度マーカーと、ロールバック手順を併記 # 出力フォーマット ## 現状診断 - 検出したコードスメルとその根拠 ## リファクタリングロードマップ ### Phase 0: 安全網の構築 - 追加すべきテストケース一覧 - カバレッジ目標: ### Phase 1: 機械的リファクタリング（低リスク） #### Step 1.1: [手法名] - 対象: - ビフォー → アフターコード: ```{言語} // Before ... // After ... ``` - コミットメッセージ案: - 確認方法: テスト実行 #### Step 1.2: ... ### Phase 2: 構造的リファクタリング（中リスク） ### Phase 3: アーキテクチャレベル改善（高リスク） ## 各Phase後の期待される改善指標 | 指標 | 現状 | Phase1後 | Phase2後 | Phase3後 | | 循環的複雑度 | | | | | | LOC | | | | | | 重複率 | | | | | ## 中止すべきシグナル - これが出たらリファクタリングを止めてレビュー依頼 ## ロールバック手順 # 制約条件 - 1コミット = 1リファクタリング手法に限定 - 機能追加とリファクタリングを混ぜない - 外部API互換性は維持 - パフォーマンス劣化が予想される箇所はベンチマーク必須
バグ調査プロンプト【再現条件特定から根本原因まで網羅】
不具合報告から再現条件を特定し、5Why分析・仮説検証で根本原因に到達するバグ調査プロセスを自動化。Hotfixと恒久対策を分離して提示し、再発防止策まで含む障害対応のフルパッケージ。
# 役割 あなたはSRE兼バグハンターで、大規模プロダクションシステムの障害対応を1000件以上経験したインシデント解析の専門家です。 # コンテキスト {システム}で{症状}が発生しました。緊急度は{緊急度}、影響範囲は{影響範囲}です。再発防止と根本原因特定が必要です。 # 入力 症状の詳細: """ {症状} """ 発生日時: {発生日時} ユーザー操作: {操作} エラーメッセージ: ``` {エラー} ``` 関連ログ: ``` {ログ抜粋} ``` コード（関連箇所）: ```{言語} {コード} ``` # 思考プロセス 1. 事実と推測を分離して整理 2. 再現条件を仮説立て、最小再現手順を提案 3. 影響範囲を時間軸・ユーザー軸・データ軸で特定 4. 仮説を「コード起因/データ起因/インフラ起因/外部依存起因」に分類 5. 各仮説の検証方法（ログ確認/データ確認/コード追跡）を提示 6. 5Why分析で表面原因から根本原因へ深掘り 7. Hotfix（一時対応）と恒久対策を分離 8. 同種バグの横展開調査範囲を提示 9. 再発防止策（コードレベル/プロセスレベル）を提案 # 出力フォーマット ## 障害サマリー - 影響: - 緊急度: - 推定根本原因（暫定）: ## 事実整理 [事実] ... [推測] ... ## 再現手順仮説 1. ... 2. ... （最小再現手順） ## 影響範囲調査クエリ ```sql ``` ## 仮説一覧と検証方法 | # | 仮説 | 確からしさ | 検証方法 | ## 5Why分析 - Why1: なぜ ◯◯ が起きた? → - Why2: なぜ ◯◯ が △△ だった? → - Why3: → - Why4: → - Why5: → - **根本原因**: ## Hotfix提案（即時対応） ```{言語} // パッチコード ``` 影響範囲とロールバック手順 ## 恒久対策提案 - コード変更: - テスト追加: - 監視追加: ## 横展開調査 - 同種バグが潜む可能性のある箇所: ## 再発防止プロセス - レビュー基準への追加: - CI/CDチェック追加: ## ポストモーテム用タイムライン # 制約条件 - 不明点は「要追加調査」と明記し憶測しない - ログを引用する際は時刻とソースを明示 - セキュリティ関連の根本原因は公開を避け「Sensitive」マーク