kaizen
コード品質向上のためのカイゼン手法の適用
ソフトウェアチームは、一貫性のないコード品質と事後的なエラー処理に苦労しています。このスキルは、継続的改善、エラー防止設計、標準化されたパターンの追従のための構造化されたカイゼン手法を提供します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「kaizen」を使用しています。 注文合計を計算するこの関数を改善するためにカイゼンを適用する
期待される結果:
- イテレーション 1 - 入力検証の追加：計算前に null/空のアイテム配列と負の価格をチェックします。これにより実行時エラーを防止します。
- イテレーション 2 - 可読性の向上：より明確な意図のために for ループを reduce() に置き換えます。型シグネチャは number を返すことを明示します。
- イテレーション 3 - エラーメッセージの追加：サイレントフェイルではなく、無効な入力に対して説明的なエラーをスローします。各イテレーションはテスト済みで動作します。
「kaizen」を使用しています。 ポカヨケを使用してエラー防止 Order 型を設計する
期待される結果:
- シンプルな文字列ステータスを持つオブジェクトの代わりに、各注文状態に必要なデータを持つ直和型を使用します。
- 保留中の注文には createdAt タイムスタンプが必要です。発送済みの注文には追跡番号が必要です。配達済みの注文には署名が必要です。
- 型システムにより、追跡情報なしに発送済み注文を持つことは不可能になります。コンパイルエラーにより、バグのクラス全体を防止できます。
セキュリティ監査
安全This skill is a documentation-only guide for Kaizen software development methodology. Static analysis flagged 73 patterns in code examples within markdown documentation, but all findings are false positives. The backtick operators are TypeScript template literals (not shell commands), fetch calls are educational examples (not actual network requests), and environment variable references teach secure validation practices. No executable code exists in this skill.
低リスクの問題 (3)
品質スコア
作れるもの
コードレビューの改善
コードレビュー中にカイゼン原則を適用し、完全な書き直しを要求するのではなく、小さな段階的な改善を提案します。各提案は、次に進む前に検証およびテストされます。
エラー耐性 API 設計
ポカヨケ手法を使用して、TypeScript API を設計し、無効な状態をコンパイル時に表現できないようにします。型システムが実行前にエラーを検出します。
レガシーコードのリファクタリング
反復的洗練アプローチを適用します：動作するようにする、明確にする、効率的にする。各イテレーションは、次に進む前に完了しテストされます。
これらのプロンプトを試す
この関数をレビューし、カイゼン原則に従って小さな改善を 1 つ提案してください。この変更がなぜ品質を向上させるのかを説明し、他の提案をする前に動作することを確認してください。
ポカヨケ原則を使用してこの API インターフェースを分析してください。TypeScript 型を使用して無効な状態を表現できないようにする方法を示してください。型定義を含む前後の例を提供してください。
このコードベースに新機能を追加しています。[機能タイプ] の既存のコードパターンを分析し、同じ標準化されたアプローチに従って新機能を実装する方法を示してください。コードベース内の具体的な例を指摘してください。
このコードを YAGNI 違反についてレビューしてください。「念のため」の機能、時期尚早の抽象化、未使用の複雑さを特定してください。各問題について、現在の要件を満たす最もシンプルなバージョンを示し、何を削除すべきかを説明してください。
ベストプラクティス
- 品質を向上させる最小限の実行可能な変更を行い、動作することを確認してから、次の改善に進む
- システム境界で入力と設定を検証し、明確なエラーメッセージで早期に失敗する
- 一貫性のために既存のコードベースパターンに従う。チームによって合意され、著しく優れている場合にのみ新しいパターンを導入する
回避
- 段階的な改善ではなく、大規模なリファクタリングプロジェクトを試みること
- 複数の実証された使用例を持つ前に、汎用的なフレームワークや抽象化を構築すること
- 実際のパフォーマンス問題を測定せずに「念のため」の機能を追加したり最適化したりすること