shinpr

commands-ja

@shinpr/commands-ja
shinpr
157
15 forks
Updated 1/18/2026
View on GitHub

ツール選択基準(測定可能な判断): ユーザーのスキル変更要求を精度最大化して実装

Installation

$skills install @shinpr/commands-ja
Claude Code
Cursor
Copilot
Codex
Antigravity

Details

Path.claude/commands-ja/refine-skill.md
Branchmain
Scoped Name@shinpr/commands-ja

Usage

After installing, this skill will be available to your AI coding assistant.

Verify installation:

skills list

Skill Instructions


description: ユーザーのスキル変更要求を精度最大化して実装

変更要求: $ARGUMENTS

Think deeply ユーザーの変更意図を汲み取り、LLMが迷わない形で実装:

適用する9つの観点

  1. コンテキスト圧迫 vs 実行精度 - 最小記述で最大精度
  2. 重複排除 - スキルファイル内・スキルファイル間の一貫性
  3. 責務の適切な集約 - 関連内容は1ファイルにまとめる(読み込み回数最小化)
  4. 判断基準明確化 - 測定可能な基準
  5. NG→推奨変換 - 推奨形式(背景:NG例を含む)
  6. 表記統一 - 一貫した表現
  7. 前提条件の明示化 - 暗黙前提を言語化
  8. 記述順序最適化 - 冒頭:最重要、末尾:例外
  9. スコープ境界明示 - 扱う/扱わない範囲

実行フロー

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. 第1回の追記内容を批判的に検証
  2. 以下の観点で実際に修正を実施:
    • 同一概念の重複 → 統合
    • 過度に詳細な説明 → 簡潔化
    • 他スキルとの重複 → 参照に置換
  3. 修正前後の差分を記録(削除理由も明記)

報告フォーマット:

修正箇所数: X件
削除・統合した内容:
- [削除前]: 「詳細な記述」
  [削除後]: 「簡潔な記述」
  [理由]: 冗長性の排除

第3回: 差分評価による精度確保【復元判定モード】

開始宣言: 「第3回:差分評価モードで実行。第2回の修正を検証し、必要なら復元」

検証作業:

  1. 第2回の各修正について評価:
    • この削除で実装時に迷う可能性があるか?
    • エッジケースの考慮が漏れていないか?
  2. 精度低下リスクがある削除 → 復元
  3. 妥当な削除 → 維持

最終確認質問(必須回答): 「ユーザーの変更要求を正確に実装するための必要十分条件が揃っているか?」

報告: 復元項目数と最終的な削減率

4. 承認取得

変更前後の比較を提示し、ユーザー承認を取得。

5. 実装

  1. 適切なツールで変更適用(ユーザー承認後)
  2. git diffで変更内容を最終確認
  3. /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 を実行してください。

実行順序

  1. ユーザー要求理解
  2. 現状分析
  3. 9観点を適用した変更設計
  4. 3回見直しプロセス
  5. ユーザー承認
  6. 変更適用
  7. sync-skills提案

スコープ: ユーザー変更要求の理解と精度最大化実装

エラーハンドリング

  • スキル未発見: 利用可能なスキル一覧を表示
  • 大規模変更検出: 変更量50%以上の場合、段階的実施を提案