レルム作成
レルムは、エージェントがいつ任務に就いているか、次に何をすべきか、そしてそれが機能したことをどう知るかを示します。その規律に記憶に残る拠点の声を与えてください。
作成前に
対象ガイドとチャーターのトリガーテーブルを読んでください。合意された拠点の割り当てを維持し、隣接するレルムと区別してください。ユーザーが処理したい実際の開発状況から作業を始めてください。認識可能なテクニック名を使用してください：「モック、スタブ、フェイク」は「制御されたダブル」だけよりも発見に役立ちます。
選択をメインスキルに配置する
メインの realms-of-code SKILL.md は 各レルムをいつ使用するか を所有します。そのテーブルは、エージェントがガイドを読み込む前に選択できるようにしなければなりません。具体的な状況を使用してください：ファイル削除のテスト、API標準の選択、クエリカウント改善の保護など。トリガーは各ガイドで繰り返すのではなく、そこに一度だけ保持してください。
ベストプラクティスをレルムガイドに配置する
- 名前、規律、格言: 見出し、具体的なスコープ行、および格言。
- 伝承: 派閥をそのエンジニアリング上の役割に結び付ける短い生き生きとした段落。メタファーが作業を説明するようにしてください。
- 公理: 判断を導くいくつかのコンパクトな原則。既存のレルムを改訂するときは、確立されたコミットメントを維持してください。
- 何をするか: 動詞で始まる実践的な手順。検査または変更すべきもの、アプローチの選び方、検証すべきものを特定してください。明示的なテクニック名を使用し、プロジェクトのツールを再利用してください。意味のある代替案と落とし穴を説明してください。
- エビデンス: 完了をサポートする観察可能な結果または成果物、およびそのエビデンスが証明するものに対する重要な制限。
公理は判断を説明し、手順はそれを実行可能にします。両方で同じアドバイスを繰り返さないでください。各セクションは、その役割が許す限り短くしてください。レルム参照ファイルはプレーンなマークダウンです：ID、重複するYAMLフィールド、格言の出典ラベル、帰属の雑談はありません。発見可能なSKILL.mdだけがスキルのフロントマターを必要とします。
修正例
Faceless Men の場合、「依存関係の制御」は抽象的すぎます。有用なトリガーは「ファイルを削除するジョブや外部支払いサービスを呼び出すジョブのテスト」です。次のアクションは、その境界を分離し、モック/スタブ/フェイクを選択し、意図しない実影響なしに成功、失敗、および再試行動作を実行することです。エビデンスには、意図されたターゲットと結果の状態が含まれ、実際の契約が重要となる場合の統合証明が含まれます。ライブサービスを依然として呼び出すスパイは、名前を付ける価値のある落とし穴です。
companion realms-of-code スキルが利用可能な場合、その references/realms/faceless-men.md が完全な実例です。
Arryn の場合、「プロトコルの選択」はメインのトリガーテーブルに属します。そのガイドは、既存の標準とテクノロジーを見つけ、現在のメンテナンスと非推奨ステータスを検証し、実行可能性を評価し、サポートされている実装を再利用し、相互運用性をテストするように指示しなければなりません。
実装中の保護を教えてください：重要なルールをガードレールとしてエンコードし、検証された改善をラチェットとしてエンコードしてください。ラチェットは再現可能なベースラインを記録し、後退を拒否し、改善後に引き締めます。Citadel が保護を構築し、Iron Bank がそれを強制します。チェックに失敗した場合、それを静かに弱めることで解決しないでください。
公開前のレビュー
2つの現実的なマッチングタスクと、別のレルムに属する1つの近隣タスクを試してください。メインテーブルからレルムを選択し、次にそのガイドから最初の具体的なアクションと必要なエビデンスを特定してください。どちらかの手順が曖昧なままの場合は、責任のあるファイルを修正してください。タスクに関係のない包括的なゲートは避けてください。
味付けを格言、伝承、および「バグにはなんて言うの？今日はやめておくよ。」のような時折の作業フレーズで生き生きと保ってください。それを有用なエンジニアリングガイダンスと組み合わせてください。決定もキャラクターも追加しない言葉は削除してください。リポジトリの公開ワークフローに従い、相対リンクとスキルの発見可能性が影響を受ける場合は検証してください。