mcpField
S
skill-improve

skill-improve

github.com/donchitosエージェントワークフロー28.5k447 回インストール1 週間前に更新
リポジトリ

skill-improve について

テスト、的を絞った修正、再テストを繰り返して単一のスキルを改善し、スコアに応じて変更を保持または復元する Claude スキルです。静的チェックとカテゴリーチェックで文章を評価し、実行時の動作は検証しません。

主な機能

  1. 01静的・カテゴリー基準チェック
  2. 02個別チェック失敗の診断
  3. 03対象を絞った編集案
  4. 04再テストとスコア比較
  5. 05変更の保持または復元

活用シーン

  1. 01スキルチェックの失敗解消
  2. 02スキル評価ルーブリックの警告対応
  3. 03編集によるテストスコア改善の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/donchitos/claude-code-game-studios --skill skill-improve

インストール後、Claude Code で/skill-improveを入力して読み込まれたか確認します。

詳細

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

自動化モード:modes.automation を解決します(project.local.yaml → project.yaml → デフォルトの collaborative)。すべての AskUserQuestion の呼び出しと すべてのファイル書き込みは、.claude/docs/automation-modes.md に従います (collaborative は常に質問 · guided は主要な変更のみ質問 · autonomous は記録して続行; automation_always_ask カテゴリーでは常に確認します)。

スキルの改善

単一のスキルに対して改善ループを実行します: テスト → 修正 → 再テスト → 維持または取り消し。

スコアは /skill-test の静的チェックとカテゴリー別チェックから算出されます。これらは スキルを実行するのではなく、内容を読み取ります。スコアが高いほど、スキルの記述が優れていることを意味しますが、 動作が改善した証明にはなりません。動作を確認するには、変更の前後で実際のリクエストに対してスキルを実行してください。


フェーズ 1:引数の解析

最初の引数からスキル名を読み取ります。指定されていない場合は、使用方法を出力して停止します:

Usage: /skill-improve [skill-name]
Example: /skill-improve tech-debt

.claude/skills/[name]/SKILL.md が存在することを確認します。存在しない場合は、次のメッセージを表示して停止します: "Skill '[name]' not found."

CCGS Skill Testing Framework/catalog.yaml を Glob で検索します。見つかった場合は、最初に次のように伝えます: "CCGS Skill Testing Framework/ was renamed studio-tests/ in 1.2.0, and this skill reads only studio-tests/. Move any specs you wrote there; UPGRADING.md (v1.1.3 → v1.2.0, studio-tests/) says how." Then go on.


フェーズ 2:ベースラインテスト

/skill-test static [name] を実行し、ベースラインスコアを記録します:

  • FAIL の数
  • WARN の数
  • 失敗した具体的なチェック(チェック 1~7)

ユーザーに次の内容を表示します:

Static baseline:   [N] failures, [M] warnings
Failing: Check 4 (no ask-before-write), Check 5 (no handoff)

静的チェックの結果が NOT ASSESSED(スキルファイルを読み取れない、または解析できない)の場合は、その理由を報告して停止します。改善対象となるスコアはなく、 誰も読み取れなかったファイルの FAIL が 0 件でも、問題がないとは言えません。

ベースラインが FAIL 0 件、WARN 0 件の場合は、その旨を記録してフェーズ 2b に進みます。

フェーズ 2b:カテゴリー別ベースライン

studio-tests/catalog.yaml でスキルの category: フィールドを確認します。

category: フィールドが見つからない場合は、次のように表示します: "Category: not yet assigned — skipping category checks." その後、フェーズ 3 に進みます。

カテゴリーが見つかった場合は、/skill-test category [name] を実行し、カテゴリー別ベースラインを記録します:

  • FAIL の数
  • WARN の数
  • 失敗した具体的なカテゴリー評価基準

ユーザーに次の内容を表示します:

Category baseline: [N] failures, [M] warnings  ([category] rubric)

カテゴリー別の結果が NOT ASSESSED(スキルテストが評価基準のセクションを見つけられない、または適用できない)の場合は、その理由を報告します。これはゼロとして扱わず、以降の「すでに合格」判定からはカテゴリーの評価軸を除外します。

静的チェックとカテゴリー別チェックの両方で FAIL が 0 件、WARN が 0 件であり、どちらも NOT ASSESSED でない場合は、次のように表示して停止します: "This skill already passes all static and category checks. No improvements needed."


Phase 3: 診断

スキル全体を読みます:.claude/skills/[name]/SKILL.md と、references/ フォルダーがある場合はその中のすべてのファイルを読みます。長いスキルでは、各フェーズがそこに分けられています。各問題がどのファイルにあるかを明記してください。

失敗または警告となった 静的チェックごとに、具体的な問題を特定します。

  • Check 1 fail → 不足している frontmatter フィールド
  • Check 2 fail → 見つかったフェーズ数と必要な最小数
  • Check 3 fail → スキル本文のどこにも判定キーワードがない
  • Check 4 fail → allowed-tools に Write または Edit があるが、書き込み前に確認する旨の記述がない
  • Check 5 warn → 最後にフォローアップまたは次のステップのセクションがない
  • Check 6 warn → context: fork が設定されているが、見つかったフェーズが5つ未満
  • Check 7 warn → argument-hint が空、または文書化されたモードと一致しない

失敗または警告となった カテゴリチェックごとに(Phase 2b でカテゴリが割り当てられている場合)、スキルのテキストにある具体的な問題を特定します。例:

  • G2 が失敗(ゲートモード、ディレクターパネルの幅)→ スキル本文で modes.workflow に基づいて PHASE-GATE パネルの幅を調整していない(minimal では PR、standard では TD + PR、full では4つすべて)
  • A2 が失敗(オーサリング、セクションごとの May-I-write がない)→ 各セクションを書き込む前ではなく、最後に一度だけ確認している
  • T3 が失敗(チーム、BLOCKED が表面化されない)→ ブロックされたエージェントに依存する作業を停止しない

変更を提案する前に、診断全体をユーザーに示します。


Phase 4: 修正案の提示

失敗と警告それぞれに対して、対象を絞った修正を記述します。修正案は、変更前/変更後を明確に示したブロックで提示します。失敗している箇所だけを変更し、問題のないセクションを書き換えないでください。スキルに references/ フォルダーがある場合、フェーズの手順に対する修正は SKILL.md ではなく、そのフェーズの references/ ファイルに記述します。その場合、以下の質問では修正する各ファイル名を挙げます。

次のように尋ねます:「この改善版を .claude/skills/[name]/SKILL.md に書き込んでもよろしいですか?」

ユーザーがいいえと答えた場合は、ここで終了します。


Phase 5: 書き込みと再テスト

修正する各ファイルの現在の内容を記録します。正確なテキストをこの会話内に保持し、Phase 6 で復元できるようにします。

改善したスキルを .claude/skills/[name]/SKILL.md と、修正する各 references/ ファイルに書き込みます。

/skill-test static [name] を再実行し、新しい静的スコアを記録します。スコアはその実行で測定されたものを記録し、編集内容から推測してはいけません。カテゴリが割り当てられている場合は、/skill-test category [name] も再実行し、新しいカテゴリスコアを記録します。

比較を表示します:

Static:   Before [N] failures, [M] warnings  →  After [N'] failures, [M'] warnings
Category: Before [N] failures, [M] warnings  →  After [N'] failures, [M'] warnings  (if applicable)
Combined: [before] → [after] (improved / no change / worse)

[before] と [after] は、Phase 6 の合計数(失敗と警告の両方の次元を合算した数)です。例:Combined: 3 → 0 (improved)。


Phase 6: 判定

失敗の合計数を数えます:静的 FAIL + カテゴリ FAIL + 静的 WARN + カテゴリ WARN。 再テストの結果が NOT ASSESSED の場合(たとえば、編集によって frontmatter が壊れ、ファイルを解析できなくなった場合)、数値にかかわらず改善とはみなしません。以下の「改善しなかった」分岐に進みます。

合計スコアが改善した場合(失敗の合計数がベースラインより少ない場合): 「スコアが改善しました。変更を維持します。」と報告します。 各次元で修正した内容の概要を示します。

合計スコアが同じか悪化した場合: 「合計スコアは改善しませんでした。」と報告します。 変更内容と、改善につながらなかった可能性がある理由を示します。 次のように尋ねます:「.claude/skills/[name]/SKILL.md を今回の実行前の内容に戻してもよろしいですか?」 Phase 5 で書き込んだすべてのファイル名を挙げます。 はいの場合は、Phase 5 で記録した内容を各ファイルに Write で書き戻します。いいえの場合は、ファイルを現在の内容のままにします。決して git checkout を実行してはいけません。これは最後に コミットされた バージョンに戻すため、今回の実行前に行われた未コミットの編集が破棄されます。


Phase 7: 次のステップ

  • /skill-test static all を実行して、次に失敗があるスキルを見つけます。
  • /skill-improve [next-name] を実行して、別のスキルでこの作業を続けます。
  • /skill-test audit を実行して、全体のカバレッジの進捗を確認します。

コメント