コーディング支援スキル

概要

要件の明確化からアーキテクチャ提案、実装、コードレビューまでを支援するスキル。

既存コードベースのスタイルに合わせた一貫性のあるコードを出力する。

発動条件

ユーザーが「コード書いて」「実装して」「プログラム」「関数作って」「コンポーネント作って」等の開発依頼をしたとき。

作業フロー

Step 1: 要件の明確化

以下が不明確な場合のみ質問する（推測可能なら進める）:

**何を作るか** — 機能の目的と期待する動作

**技術スタック** — 言語、フレームワーク、ランタイム

**制約** — パフォーマンス要件、対応環境、依存制限

Step 2: アーキテクチャ / ファイル構成の提案

既存プロジェクトがある場合、その構成に従う

新規の場合、以下を提案:

- ディレクトリ構成

- 責務の分離方針

- データフローの概要

Step 3: 実装

以下のルールに従ってコードを書く。

コーディングルール

一般原則

関数は1つの責務に限定する（50行を超えたら分割を検討）

マジックナンバーは定数化する

ネストは3段階以内（早期リターンで浅くする）

コメントは「なぜ」を書く（「何を」はコード自体で表現）

TODO コメントには理由と期限を書く: `// TODO(2026-04): ◯◯のため暫定対応`

セキュリティ

ユーザー入力は必ずバリデーションする

SQL はパラメタライズドクエリを使う（文字列結合禁止）

機密情報はハードコードしない

`eval()` / `dangerouslySetInnerHTML` は原則使わない

CORS 設定は最小限に絞る

エラーハンドリング

try-catch は具体的なエラー型で捕捉する

エラーメッセージはユーザー向けと開発者向けを分離する

非同期処理は必ずエラーハンドリングを入れる

リトライが適切な場合は指数バックオフで実装する

TypeScript 固有

`any` は使わない（`unknown` + 型ガードを使う）

戻り値の型は明示する（推論に頼らない）

`interface` を優先（`type` は union / intersection 時のみ）

Optional chaining `?.` と Nullish coalescing `??` を活用する

React 固有

コンポーネントは関数コンポーネント + hooks

Props の型定義を必ず書く

`useEffect` の依存配列を正確に書く

状態管理: ローカルで済むなら `useState`、複雑なら `useReducer`

メモ化（`useMemo` / `useCallback`）は計測してから適用

Python 固有

型ヒントを付ける

docstring は Google スタイル

f-string を使う（format() / % は使わない）

with 文でリソース管理

既存コードへの適合

インデント、命名規則、import 順序は既存コードに合わせる

既存のユーティリティ関数やヘルパーを再利用する

新しいライブラリの追加は最小限にする

既存のテストパターンに合わせる

コードレビューチェックリスト

出力したコードに対して以下を自己チェックする:

[ ] 要件を満たしているか

[ ] エッジケースを処理しているか

[ ] セキュリティリスクがないか

[ ] パフォーマンスに問題がないか

[ ] 既存コードのスタイルに合っているか

[ ] エラーハンドリングが適切か

[ ] テストしやすい構造か

出力フォーマット

1. **方針説明**（2〜3行で何をどう実装するか）

2. **コード**（ファイル単位でコメント付き）

3. **使い方**（呼び出し例やコマンド）

4. **注意点**（既知の制限、将来の改善点）