Files
2025-11-30 08:51:41 +08:00

9.8 KiB
Raw Permalink Blame History

name, description
name description
convention-skill-generator ユーザーの規約・ガイドラインから、Convention Skillのマークダウンファイルを生成する。規約スキル作成時、ガイドライン文書化時、またはユーザーがConvention Skill、コーディング規約、ガイドライン定義、標準化に言及した際に使用する。

Convention Skill Generator

概要

このSkillは、ユーザーが提供する規約・ガイドライン情報を基に、Convention SkillのマークダウンファイルSKILL.mdを生成する。ユーザーとの対話を通じて必要な情報を収集し、適切なテンプレートを選択して、標準化されたコンベンションスキルのドキュメントを作成する。

責任範囲

このSkillは以下の範囲をカバーする:

  • 既存スキルの確認と重複チェック
  • ユーザーとの対話による規約・ガイドライン情報の収集
  • 規約のカテゴリ分類と整理
  • 良い例/悪い例の作成支援
  • テンプレートsimple版/full版の選択
  • SKILL.mdファイルの生成
  • プラグインアーキテクチャ規約の遵守確認
  • markdownlint検証の実施
  • ユーザーフィードバックの収集と反映

ワークフロー

フェーズ1: 既存スキル確認

スキル生成前に、既存のスキルを確認し、重複を避ける。

実施内容:

  1. プラグインディレクトリ内の既存スキルを確認する
  2. 作成予定のスキルと同じ目的のスキルが存在しないか確認する
  3. 作成予定のスキル内容と重複する記述が他のスキルに含まれていないか確認する
  4. 既存スキルで代用できる場合はユーザーに提案する
  5. 重複が避けられない場合は、どの内容を削除すべきかユーザーと確認する

確認対象:

  • プラグインディレクトリ内のskillsディレクトリ内のドキュメント

質問例:

【既存スキル確認】
プラグインディレクトリ内の既存スキルを確認しました。
以下のスキルと内容が重複する可能性があります:

- [既存スキル名]: [既存スキルの説明]

作成予定のスキルから、これらの重複内容を除外してよろしいですか?

既存スキルで代用可能な場合:

【確認】
作成予定のスキルと同じ目的のスキルが既に存在します:
- [既存スキル名]: [既存スキルの説明]

既存スキルで十分な場合は、新規作成は不要です。
それでも新規作成が必要ですか?必要な場合は、既存スキルとの違いを教えてください。

フェーズ2: 情報収集

ユーザーとの対話を通じて、コンベンションスキルに必要な情報を収集する。

実施内容:

  1. スキルの目的と対象範囲を確認する
  2. 規約・ガイドラインの全体像を把握する
  3. カテゴリ分類の可能性を検討する
  4. 良い例/悪い例の必要性を確認する
  5. チェックリストの粒度を確認する
  6. ユーザーとの対話時は、明確なタイトル付き質問、複数選択肢の提示、推奨オプションの明示を行う

フェーズ3: テンプレート選択

収集した情報を基に、適切なテンプレートsimple版/full版を選択する。

実施内容:

  1. スキルの複雑度を評価する
  2. テンプレートの選択肢simple版/full版を提示する
  3. 推奨テンプレートを明示してユーザーに確認する

テンプレート選択基準:

  • simple版: カテゴリが2〜3個程度のシンプルな規約
  • full版: カテゴリが4個以上の複雑な規約、良い例/悪い例が必要

フェーズ4: コンテンツ生成

選択したテンプレートを基に、SKILL.mdファイルのコンテンツを生成する。

実施内容:

  1. フロントマターname, descriptionを作成する
  2. 概要セクションを記述する
  3. 責任範囲を定義する
  4. 基本方針を記述する(該当する場合)
  5. カテゴリ別の規約を記述する
  6. 良い例/悪い例を記述するfull版の場合
  7. チェックリストを作成する

フロントマターの作成:

---
name: スキル名(ケバブケース、例: coding-conventions
description: スキルの簡潔な説明1行、50文字以内
---

概要の記述:

  • スキルの目的を明確に記述する
  • 定義する規約・ガイドラインの範囲を説明する
  • 簡潔に1〜2段落で記述する

責任範囲の定義:

  • 箇条書きで3〜5項目を記述する
  • 「〜の定義」「〜のガイドライン」「〜のルール」のような表現を使用する
  • スキルがカバーする範囲を明確にする

カテゴリ別の規約記述:

各カテゴリに以下を含める:

  • カテゴリ名(例: 命名規則、コードレイアウト)
  • カテゴリの説明1〜2行
  • 具体的なルール(箇条書き)
  • 良い例/悪い例full版の場合

良い例/悪い例の作成full版の場合:

良い例:

```language
[推奨される記述例]
```

悪い例:

```language
[避けるべき記述例]
```

チェックリストの作成:

  • カテゴリごとのチェックリスト
  • 最終確認チェックリスト
  • 具体的で検証可能な項目を記述する

プラグインアーキテクチャ規約の遵守:

生成するスキルは、プラグインアーキテクチャ規約に従う必要がある(独立性の原則、汎用性の原則、単一責任の原則など)。

重複最小化の確認:

既存スキルと重複する内容が含まれていないかを確認し、スキル固有の内容のみを記述する。

フェーズ5: 検証

生成したコンテンツを検証し、品質を確保する。

実施内容:

  1. 設計原則の遵守を確認する
  2. markdownlint検証を実施する
  3. テンプレート構造の整合性を確認する
  4. ユーザーにプレビューを提示する
  5. フィードバックを収集する
  6. 必要に応じて修正する

プラグインアーキテクチャ規約の確認:

  • プラグインアーキテクチャ規約に従っている
  • 既存スキルと重複する内容が含まれていない

アウトプット

このスキルは以下を生成する:

  • SKILL.md: コンベンションスキルの定義ファイル
    • フロントマターname, description
    • 概要、責任範囲、基本方針
    • カテゴリ別の規約・ガイドライン
    • 良い例/悪い例full版の場合
    • チェックリスト

想定されるエラーと対処法

エラー1: 責任範囲が曖昧

検出例:

このSkillは、いろいろな規約を定義する

対処法:

  • 具体的な表現を使用する(命名規則、フォーマット、セキュリティなど)
  • 責任範囲を明確に列挙する

エラー2: 良い例/悪い例が不明確

検出例:

良い例: これ
悪い例: あれ

対処法:

  • 具体的なコード例やテキスト例を記述する
  • なぜ良い/悪いのか理由を簡潔に説明する

ベストプラクティス

  • カテゴリは2〜5個に抑える多すぎると複雑になる
  • 各カテゴリのルールは3〜5項目程度にする
  • 良い例/悪い例は実用的で理解しやすいものを記述するfull版の場合
  • チェックリストは具体的で検証可能な項目にする
  • markdownlint検証は必ず実施する
  • ユーザーフィードバックを反映して改善する

チェックリスト

既存スキル確認完了時

  • プラグインディレクトリ内の既存スキルを確認した
  • 同じ目的のスキルが存在しないことを確認した
  • 重複する内容が他のスキルに含まれていないことを確認した
  • 既存スキルで代用できない理由が明確である
  • 重複する内容を除外する方針を決定した

情報収集完了時

  • スキルの目的が明確になっている
  • 規約・ガイドラインの全体像を把握している
  • カテゴリ分類の方針が決まっている
  • 良い例/悪い例の必要性が確認されている
  • チェックリストの粒度が確認されている

テンプレート選択完了時

  • スキルの複雑度を評価した
  • テンプレートsimple/fullを選択した
  • ユーザーの確認を得た

コンテンツ生成完了時

  • フロントマターname, descriptionが記述されている
  • 概要が簡潔に記述されている
  • 責任範囲が明確に定義されている
  • カテゴリ別の規約が記述されている
  • 各カテゴリに具体的なルールが含まれている
  • 良い例/悪い例が記述されているfull版の場合
  • チェックリストが作成されている
  • プラグインアーキテクチャ規約に従っている
  • 既存スキルと重複する内容が含まれていない

検証完了時

  • プラグインアーキテクチャ規約の遵守を確認した
  • markdownlint検証を実施したエラーなし
  • テンプレート構造の整合性を確認した
  • ユーザーにプレビューを提示した
  • フィードバックを収集した
  • 必要な修正を完了した

最終確認

  • SKILL.mdファイルが生成されている
  • すべてのセクションが適切に記述されている
  • プラグインアーキテクチャ規約が遵守されている
  • markdownlint検証に合格している
  • ユーザーの承認を得ている