Skill.md検索

テストを先に書いてからコードを実装することで、仕様漏れやバグを事前に防ぐことができます。 Red-Green-Refactorサイクル（失敗→成功→改善）を繰り返し、常にテストで保護されたコードを維持できます。 言語別のテストフレームワーク（Jest、Vitest、pytest等）の使い方がわかり、プロジェクトに合わせて選択できます。 リファクタリング（コードの整理・改善）時にテストがあることで、既存機能を壊さない安心感を得られます。 小さなテストケースに分解することで、複雑な機能も段階的に実装できます。 品質の高いコードを書きたいエンジニア バグの少ないシステムを構築したいチームリーダー テストの書き方が曖昧で、何から始めたらいいかわからない開発者 既存コードの改善時に壊す心配なくリファクタリングしたい人 TDD（テスト駆動開発）は Red-Green-Refactor というサイクルを繰り返します。RED（赤）フェーズではテストファイルを作成し、期待する振る舞いをテストとして記述してから実行し失敗を確認します。GREEN（緑）フェーズでは、テストを通すことだけに集中した最小限のプロダクションコードを書きます。REFACTOR（青）フェーズでは、テストが通る状態を維持しながら、重複を除去し、可読性を向上させ、既存パターンとの一貫性を保ちながら改善します。TDDには3つの法則があります：(1)失敗するテストを書くまで、プロダクションコードを書いてはならない、(2)失敗するテストを必要以上に書いてはならない（コンパイルエラーも失敗とみなす）、(3)現在失敗しているテストを通すために必要なプロダクションコード以上を書いてはならない。テストの書き方は AAA パターン（Arrange-Act-Assert）を使い、準備→実行→検証の構造で記述します。言語別のテストフレームワークとしては TypeScript/JavaScript では Vitest（高速・Vite統合）、Jest（エコシステムが豊富）、Playwright（E2Eテスト）があります。

特定スキルのフィードバックファイルと使用ログを自動分析し、SKILL.md改善案を提示できます。 複数件のフィードバックから繰り返し報告される問題パターンを特定し、優先度付きで改善提案できます。 ユーザー承認後、提案された変更を自動的にSKILL.mdに適用できます。 適用済みフィードバックを自動でfeedback/applied/ディレクトリに整理できます。 スキル開発者：ユーザーフィードバックに基づいてスキルを継続改善したい方 プロジェクト管理者：スキルの品質と使いやすさを向上させたい方 チームリード：スキル開発の定量的な改善プロセスを確立したい方 ナレッジマネジメント責任者：スキルのドキュメント精度を高めたい方 skill-improveスキルは、対象スキル名を$ARGUMENTSから取得（未指定時はユーザーに確認）し、{cwd}/.claude/skills/{target}/SKILL.mdまたはグローバルスキルを読み込みます。フィードバックファイルは{cwd}/.claude/skills/{target}/feedback/配下の全.mdファイルを分析対象とし、auto_generated:trueで空欄ファイルは除外します。使用ログ（usage.jsonl）とInsightログ（insights.jsonl）からsession_idで照合し、使用コンテキストと補足説明必要箇所を特定します。分析結果から「変更セクション名→現在内容→提案内容→変更理由」フォーマットで改善案を提示し、ユーザーが「all・番号指定・cancel」で選択承認後、frontmatterを保持してSKILL.mdに適用します。適用済みフィードバックをfeedback/applied/に移動し、完了サマリーを表示します。

作業中に得た「これは将来役立つ知見だ」という気づきを、その場でスキル化・保存できます。 既存スキル一覧を参照し、その知見が現在のどのスキルに関連するかを判断し、既存スキルに統合するか、新規スキルとして作成するかを自動的に判定・実行します。 知見を「状況→内容→理由→適用場面」という体系的な形式で整理することで、将来の自分やほかのエージェントが簡単に活用できる形で保存します。 セッション終了時に過去の学びを自動キャプチャし、スキル資産を継続的に増やしていきます。 繰り返し同じ問題解決をしたり、同じ質問を受けたりする人で、「これをスキル化すれば効率化できるな」と感じている人 プロジェクトやセッションを重ねるたびに得た知見を、形式化して資産化したい開発チーム 個人的な「暗黙知」「ノウハウ」を、体系的に蓄積し、チーム全体で活用できる形にしたい人 学習を継続的に行い、スキルセットを自動的に成長させたいエージェント利用者 このスキルは、作業中または セッション終了時に「この知見はスキル化すべき」という気づきをトリガーに動作します。 Step 1（知見の言語化）: ユーザーに「どのような知見を得ましたか？（例：○○という状況で△△すると□□になる）」と質問。知見を「状況（Context）：どんな条件で得た知見か」「知見の内容：何を学んだか」「理由・根拠：なぜそうなるか」「適用場面：今後どんな場面で使えるか」として整理。 Step 2（既存スキルとの照合）: ~/.claude/skills/INDEX.mdを読込み、既存スキル一覧をユーザーに提示。「この知見はどのスキルに関連するか」と確認。 Step 3a（既存スキル統合）: 関連スキルが特定された場合、対象スキルのSKILL.mdを読込み、知見を適切なセクションに追加。形式は「### [知見のタイトル] 状況: [適用条件] [内容] > 根拠: [理由]」。 Step 3b（新規スキル作成）: 新規スキルの場合、ユーザーと対話的にスキル名（kebab-case）・一行説明・用途を決定。テンプレート（概要、いつ使うか、メインセクション、注意事項）に従って~/.claude/skills/[スキル名]/SKILL.mdを作成。INDEX.mdにエントリ追加。 Step 4（保存確認）: 作成・更新内容をユーザーに確認。修正が必要な場合は対応。知見の質を高めるヒント：「○○した方がいい」より「○○という状況で○○すると○○になる、なぜなら〜」の形が再利用しやすい。汎用的すぎるより具体的な状況と結びついた知見が価値が高い。

Black、flake8、isort、mypy等の推奨設定を一元管理でき、プロジェクト固有の設定ファイルがない場合に即座に適用できます ワンコマンドで全Pythonファイルのコードフォーマット（Black）、リント（flake8）、インポート整理（isort）、型チェック（mypy）を実行できます VSCodeのSave時自動フォーマット機能を有効化し、開発中に自動的にコードを整形・整理できます Lefthookを使用したpre-commitフックで、コミット前に全ての品質チェックを自動実行でき、品質基準を満たさないコミットを防げます 各ツール（Black 88文字、flake8例外設定、isort/Black互換、mypy厳密設定等）の推奨値を一覧で確認でき、プロジェクト構築時のリファレンスになります Pythonプロジェクトの開発環境をゼロから構築するエンジニア コードスタイルをチーム全体で統一したい開発組織 VSCode上で自動フォーマット・リントを実装したい開発者 品質基準をpre-commitフックで自動化し、コミット品質を保証したい組織 設定優先順位：①プロジェクト固有ファイル（pyproject.toml、.flake8等）が最優先、②ない場合はグローバル推奨設定を使用。Black設定：line-length=88、target-version=['py311']、ビルドディレクトリ除外。flake8設定：max-line-length=88、E203/W503無視。isort設定：profile="black"、line_length=88で整合性確保。mypy設定：python_version=3.11、warn_return_any/disallow_untyped_defs有効。VSCode設定：defaultFormatter=Black、formatOnSave=true、source.organizeImports（isort連携）。Lefthook設定：brew/scoop/npmいずれかでインストール、lefthook installで有効化。各ツールのコマンド例（black/flake8/isort/mypy src/）を付記。

TypeScript・JavaScriptコードの品質を自動チェック・修正できる - Oxlintと@stylistic/eslint-pluginを組み合わせた設定により、コードスタイル違反やバグの可能性を自動検出し、ワンコマンドで修正可能にします。 チーム全体で統一されたコーディング規則を強制できる - oxlint.config.tsで一元管理された設定をシングルパッケージ・モノレポの両構成に対応させ、すべてのプロジェクトで同一基準を適用できます。 導入と管理の手間を最小化できる - インストール手順から設定ファイルのテンプレートまで完全に提供されており、プロジェクト固有の設定がなければ即座に導入可能です。 暗黙的なバグを事前に防止できる - any型の禁止、非nullアサーション（!）の排除、一貫性のある型インポート（import type）の強制など、TypeScriptのよくある落とし穴を規則として組み込みます。 フロントエンド・バックエンド開発チーム - TypeScript/JavaScriptプロジェクトのコード品質を統一し、レビュー時の指摘を減らしたい開発者 テックリード・プロジェクトマネージャー - チーム全体のコーディング規則を一元管理し、新しいプロジェクトやメンバーへの教育コストを削減したい人 モノレポ運用者 - 複数のパッケージを同一のリント設定で管理し、一貫性を保ちながら運用したい人 CI/CDパイプライン構築者 - lint・fixのスクリプトをpackage.jsonに組み込み、自動チェックのしくみを整備したい人 Oxlintベースのリント・フォーマット設定で、@stylistic/eslint-pluginを組み合わせます。プロジェクト固有のoxlint.config.tsがある場合は優先します。シングルパッケージ構成ではnpm install --save-dev oxlint @stylistic/eslint-plugin でインストール後、package.jsonに lint・lint:fix スクリプトを定義、oxlint.config.tsで categories（correctness・suspicious をerror）、plugins（eslint・typescript・oxc）、env（browser・node・es2022）、jsPlugins（@stylistic/eslint-plugin）を設定し、rules で no-console・no-unused-vars・eqeqeq・no-var・prefer-const・typescript関連ルール・stylistic自動設定を適用します。モノレポ構成ではプロジェクトルートとサブパッケージそれぞれにpackage.jsonスクリプトを配置し、ルートのoxlint.config.tsで一元設定します。

「〜したい」というユースケースから、対応する React 実装パターンを逆引き表で素早く見つけられます。 単一責任の関数コンポーネント、カスタムフック、状態管理（useState / useReducer / Context API）、パフォーマンス最適化（React.memo / useCallback / useMemo）の具体的なコード例と選択基準を確認できます。 Props 型定義、イベントハンドラ、エラーバウンダリなど、よく使う実装パターンをテンプレートとして参照できます。 コンポーネント設計、Hooks、状態管理、パフォーマンスに関するコア原則を確認し、後続の実装にすぐ活用できます。 React 開発経験が1～3年のエンジニア — 何度も似た実装をするときにパターン集から素早くコピペしたいとき チームのコーディング規約を統一したい — 「このコンポーネント、どう書くのが正解？」という質問に「このリファレンスを見て」と案内 レビュー時に修正指摘をするとき — 「なぜそう？」の根拠として「このパターンを参照」と具体的に示せる React 学習中の初心者 — ベストプラクティスが何かを体系的に学びたいとき 本スキルは React 実装の逆引きリファレンスであり、Core Principles 4項目とその詳細、および逆引きリファレンス表で構成されます。コンポーネント設計: 関数コンポーネント必須、単一責任・1ファイル1コンポーネント、Props は TypeScript interface で型定義、小さく再利用可能に、プレゼンテーション層とロジック層分離。Hooks ベストプラクティス: 共通ロジックはカスタムフック化（1ファイル1フック）、useEffect の依存配列管理、複雑状態は useReducer。状態管理: ローカルは useState、複雑は useReducer、グローバルは Context API / Jotai / Zustand、Prop drilling 回避。パフォーマンス: 計測ありきの最適化、大量データは Virtual scrolling、React Compiler 環境外では React.memo / useCallback / useMemo で不要レンダリング防止。逆引き表は「コンポーネントを作りたい」「Propsの型を定義したい」「状態を管理したい」「副作用を処理」など、ユースケース別に該当パターン・詳細 PATTERNS.md リンクを示します。

テストケースの命名規約を統一し、実装詳細に依存しないテストを作成できます。DBへの登録・更新・削除など「何をしたか」が名前から一目瞭然になります。 正常系・バリデーション・エラーケースなど、テストすべき観点を網羅的にチェックリスト化できます。テスト漏れを防ぎ、品質の高いAPIテストを設計できます。 モックテスト（実装の詳細をテスト）ではなく、実際のDBを使った統合テスト中心の設計アプローチで、本当に動くかを検証できます。 テスト作成時やコードレビュー時に参照できるガイドが揃っており、チーム全体でテスト品質を統一できます。 バックエンド開発者がAPIの動作確認用テストを作成・レビューする際に テストケースの命名ルールやテスト観点を統一したいチームリード・QA担当者 「テストを書いているけど本当に十分か不安」という開発者

システムが遅い・重い・応答しない時に、CPU・メモリ・ディスク・ネットワークなどのリソース状態を素早く調べられます。初動診断コマンドだけで原因の大まかな方向性が分かります。 nvidia-smiやGPU関連のエラー、xrdpの黒画面表示、Dockerコンテナ内からのデバイスアクセス失敗など、よくあるトラブルの診断手順が体系的にまとまっています。 ユーザー権限エラーやACL設定ミスなど、デバイスアクセスが拒否される時の原因を的確に特定できます。 サービス起動失敗・ハング・ゾンビプロセスなど、各症状別に「次に実行すべき診断コマンド」がフローチャート形式で示されており、迷わず原因調査を進められます。 インフラ運用・DevOpsエンジニアがサーバー障害を素早く切り分ける必要がある時に 開発環境やLinuxシステムのトラブルシューティングに不慣れなソフトウェア開発者 GPU・コンテナ・ディスプレイ周りの複雑なエラーに対応するシステム管理者

型ヒント（type hints）の正しい使い方を学び、mypy（型チェッカー）で型安全なコードを書けます。引数と戻り値の型を明示することで、バグを事前に防ぎやすくなります。 PEP 8スタイルガイドに準拠したコードを自動フォーマットし、チーム全体で統一された読みやすいコードを保つことができます。BlackやFlake8といった自動化ツールの設定も備えています。 f-strings・コンテキストマネージャ（with文）・リスト内包表記など、モダンなPython機能を適切に使い分けられます。古いやり方から新しいベストプラクティスへの移行がスムーズです。 関数の命名規則・Docstringsの書き方・例外処理のパターンなど、保守性が高く他の開発者が読みやすいコードを書くための具体的な例が豊富です。 Python開発者が品質基準を満たすコードを書きたい・維持したい場合に チームとしてPythonコーディング規約を統一したいPythonリード・テックリード 型安全性や自動フォーマットに関心があるPython初心者から中級者まで

oxlintによる自動リント・フォーマットを導入し、TypeScript/JavaScriptのコード品質をプロジェクト全体で統一できます。プロジェクト固有の設定がない場合のデフォルト設定も提供します。 VSCodeやLefthook（Git フック自動化）の推奨設定をそのまま使用でき、ファイル保存時やコミット前に自動的にコード修正が走るようにセットアップできます。手動チェックの手間が大幅に削減されます。 セキュリティチェック（秘密情報の誤コミット検出）や型チェック、テスト実行などをGitフックで自動化し、品質の低いコードがリポジトリに入るのを防ぎます。 既存プロジェクトの設定ファイル（.eslintrc、.prettierrc等）を優先しながら、設定がない場合の適切なデフォルトを提案します。 TypeScript/JavaScript開発チーム全体で自動フォーマット・リント環境を統一したい場合に 新しいプロジェクトを始める際に「どうやってlint環境をセットアップするか」で迷っている開発者 oxlintやLefthookの設定ファイルの書き方が分からない初心者

型安全性を最優先し、any型を排除してTypeScriptの恩恵を最大限に活かせます。厳格なTypeScript設定で、バグになりやすいパターンをコンパイル時に検出できます。 関数・インターフェース・ジェネリック型など、TypeScriptの型定義パターンを実例で学べます。複雑な型安全なコード設計を型チェッカーで検証しながら書けます。 オプショナルチェイニング（?.）やnullish coalescing（??）など、モダンなJavaScript/TypeScript機能を適切に使い分けられます。エラーハンドリングも型安全に実装できます。 単一責任原則に基づいたコード構成・バレルエクスポート・インポート最適化など、大規模プロジェクトでも保守性の高い構造を実現できます。 TypeScript開発者が型安全性を重視した本番品質コードを書きたい場合に チームとしてTypeScriptのコーディング規約を統一したい技術リード・アーキテクト 「TypeScriptが複雑で使いこなせていない」という開発者が基本パターンから学び直したい時に

テストケースを「ユーザーから見た動作」で正確に記述でき、保守性が高いテストが書けるようになる 命名規約やベストプラクティスを参照することで、レビュー指摘やテストの書き直しが減る カスタムフック、コンポーネント、ユーザーインタラクションなど、様々なUIテストパターンに対応できるようになる テストが「何をチェックしているか」が瞬時にわかり、チーム全体のテスト理解度が上がる UIテストを作成・レビューするエンジニア テストの書き方がバラバラで統一したいと考えるチームリード 「テストが何をチェックしているか不明確」という悩みを抱えている開発チーム React/Vue などのコンポーネント開発を行っているフロントエンド開発者