ツール選択基準(測定可能な判断): ユーザーのスキル変更要求を精度最大化して実装
Installation
Details
Usage
After installing, this skill will be available to your AI coding assistant.
Verify installation:
skills listSkill Instructions
description: ユーザーのスキル変更要求を精度最大化して実装
変更要求: $ARGUMENTS
Think deeply ユーザーの変更意図を汲み取り、LLMが迷わない形で実装:
適用する9つの観点
- コンテキスト圧迫 vs 実行精度 - 最小記述で最大精度
- 重複排除 - スキルファイル内・スキルファイル間の一貫性
- 責務の適切な集約 - 関連内容は1ファイルにまとめる(読み込み回数最小化)
- 判断基準明確化 - 測定可能な基準
- NG→推奨変換 - 推奨形式(背景:NG例を含む)
- 表記統一 - 一貫した表現
- 前提条件の明示化 - 暗黙前提を言語化
- 記述順序最適化 - 冒頭:最重要、末尾:例外
- スコープ境界明示 - 扱う/扱わない範囲
実行フロー
1. 変更要求の理解
未指定時の質問テンプレート:
1. どのスキルを変更しますか?
例: typescript-rules / coding-standards / documentation-criteria
2. 変更種別を選択:
a) 新基準追加(新しい基準を追加)
b) 既存基準修正(曖昧な記述を明確化)
c) 基準削除(不要になった基準を削除)
3. 具体的な変更内容:
例:「any型の使用を禁止する基準を追加」
例:「エラーハンドリングの基準を明確化」
[ユーザー入力]
2. 変更設計案の作成
対象ファイル特定と現状確認:
# ツール選択基準(測定可能な判断)
if スキル名が明示されている:
Read: .claude/skills/{スキル名}/SKILL.md を直接読み込み
else if スキル名の一部のみ判明:
Glob: .claude/skills/*{キーワード}*/SKILL.md で探索
Read: 特定したファイルの現状確認
else:
Glob: .claude/skills/*/SKILL.md で全件確認
ユーザーに対象スキル選択を確認
変更設計テンプレート:
【現状】
「エラーは適切に処理する」(曖昧:「適切」の基準不明)
【ユーザー要求の理解】
「エラーハンドリングを厳格化したい」→ 測定可能な基準を設定
【変更案】
「エラーハンドリング実装基準:
1. try-catch必須条件:
- 外部API呼び出し(fetch, axios等)
- ファイルI/O操作(fs.readFile等)
- JSON.parse、parseInt等の変換処理
2. エラーログ必須項目:
- error.name(エラー種別)
- error.stack(発生箇所)
- タイムスタンプ(ISO 8601形式)
3. ユーザー通知基準:
- 技術詳細を含まない(NG例:スタックトレース表示)
- 対処法を明示(推奨:「再度お試しください」)」
この設計で進めますか? (y/n)
3. 3回見直しプロセス
第1回: 実行精度最大化の観点で追記【追記専用モード】
開始宣言: 「第1回:追記モードで実行。削除は一切行わない」
- 曖昧表現→測定可能基準に変換 例:「大きい」→「100行以上」「5ファイル以上」
- 暗黙前提→明示的条件として記載 例:「TypeScript環境で」「async関数内で」
- 例外ケース・エッジケースの定義 例:「null/undefinedの場合」「空配列の場合」 報告: 追記項目数をカウント(最低5項目)
第2回: 批判的修正で冗長性を削減【実修正モード】
開始宣言: 「第2回:批判的修正モードで実行。冗長と判断した箇所を実際に削除・統合」
修正作業:
- 第1回の追記内容を批判的に検証
- 以下の観点で実際に修正を実施:
- 同一概念の重複 → 統合
- 過度に詳細な説明 → 簡潔化
- 他スキルとの重複 → 参照に置換
- 修正前後の差分を記録(削除理由も明記)
報告フォーマット:
修正箇所数: X件
削除・統合した内容:
- [削除前]: 「詳細な記述」
[削除後]: 「簡潔な記述」
[理由]: 冗長性の排除
第3回: 差分評価による精度確保【復元判定モード】
開始宣言: 「第3回:差分評価モードで実行。第2回の修正を検証し、必要なら復元」
検証作業:
- 第2回の各修正について評価:
- この削除で実装時に迷う可能性があるか?
- エッジケースの考慮が漏れていないか?
- 精度低下リスクがある削除 → 復元
- 妥当な削除 → 維持
最終確認質問(必須回答): 「ユーザーの変更要求を正確に実装するための必要十分条件が揃っているか?」
報告: 復元項目数と最終的な削減率
4. 承認取得
変更前後の比較を提示し、ユーザー承認を取得。
5. 実装
- 適切なツールで変更適用(ユーザー承認後)
- git diffで変更内容を最終確認
/sync-skills実行提案
判断基準チェックリスト
- 「if-then」形式で表現可能(「~の場合は~する」)
- 数値・個数・状態で判定可能(主観的判断を排除)
- 関連内容は1ファイルに集約(読み込み回数最小化)
- 他スキルとの関係明記(依存・参照・委譲)
- NG例を背景情報として含む
- 前提条件が全て明示されている
削減パターン例
| パターン | 変換前 | 変換後 |
|---|---|---|
| 感情的表現 | 「必ずすべき」 | 「以下の場合に実行(背景:実行しないとビルドエラー)」 |
| 時間表現 | 「すぐに実行」 | 「エラー検出後、最初に実行」 |
| 暗黙前提 | 「エラーハンドリングを実装」 | 「TypeScript環境でasync関数のエラーハンドリング実装」 |
| 順序不明確 | 「以下を考慮:A、B、C」 | 「優先順:1.A(必須)、2.B(推奨)、3.C(任意)」 |
| 冗長説明 | 「型安全性を確保するため、型を定義し、型チェックを行い、型エラーを防ぐ」 | 「型安全性の確保(定義・チェック・エラー防止)」 |
| スコープ曖昧 | 「テストを書く」 | 「単体テストを書く(E2Eテストはtypescript-testingスキル参照)」 |
出力例
=== 変更実装完了 ===
【ユーザー要求】
「TypeScriptのエラーハンドリング基準を厳格化したい」
【変更内容】
対象: .claude/skills/typescript-rules/SKILL.md
セクション: ## エラーハンドリング
変更前:
「エラーは適切に処理する」
変更後(3回見直しプロセス完了):
「エラーハンドリング実装基準:
1. try-catchブロック必須条件:
- 外部API呼び出し(fetch, axios等)
- ファイルI/O操作(fs.readFile, fs.writeFile等)
- JSON.parse、parseInt等の例外発生可能な処理
2. エラーログ必須項目:
- error.name(エラー種別)
- error.stack(発生箇所)
- new Date().toISOString()(タイムスタンプ)
3. ユーザー向けメッセージ:
- 技術詳細を含まない(NG例:スタックトレース表示)
- 具体的な対処法を明示(推奨:「再度お試しください」)」
【改善指標】
- 判断基準明確度: 0% → 100%(全て測定可能)
- 曖昧表現: 1箇所 → 0箇所
- NG例を背景情報として含む
メタデータ同期のため /sync-skills を実行してください。
実行順序
- ユーザー要求理解
- 現状分析
- 9観点を適用した変更設計
- 3回見直しプロセス
- ユーザー承認
- 変更適用
- sync-skills提案
スコープ: ユーザー変更要求の理解と精度最大化実装
エラーハンドリング
- スキル未発見: 利用可能なスキル一覧を表示
- 大規模変更検出: 変更量50%以上の場合、段階的実施を提案
More by shinpr
View allfrontend/typescript-rules: Applies React/TypeScript type safety, component design, and state management rules. Use when implementing React components.
統合テストとE2Eテストを設計。モック境界と振る舞い検証ルールを適用。E2Eテスト、統合テスト作成時に使用。
Tool selection criteria (measurable decisions): Implement user skill change requests with maximum precision optimization
frontend/technical-spec: Defines frontend environment variables, component design, and data flow patterns. Use when configuring React environment.
