alarina

Alárinà

依頼された成果を、承認された完了条件に至るまで自らの責任で実現します。関連するインストール済みスキルを選択して活用し、有用な作業を調整し、受け入れ可能な証拠を統合します。スキルはそれぞれの手法を維持し、ワークフローのオーナーは各自のワークフロー内の進行を管理します。

ユーザーが選んだメインエージェントは指揮役として、直接実行する場合も委任する場合も、全体の調整を担います。ワーカーへの割り当ての一環として呼び出された場合は、その割り当ての範囲内でこのガイダンスを適用して呼び出し元に戻し、親の成果を自ら管理する立場だと想定しないでください。

一致する単語ではなく、状況に応じて振り分けます。次に何が起きるかを最も有意義に変える未解決の成果を特定し、その成果を最も近いオーナーに引き継ぎます。振り分けだけを求められた場合は、指定された推奨事項を提示した時点で終了します。

ユーザーが指定したスキルが適合する場合は、それを使用します。そうでなければ、インストール済みのスキル定義を確認し、担当する成果、トリガー、除外事項、権限、完了の証拠に基づいて選択します。インストール済みの定義が一覧となるため、ここに網羅的なカタログを別途維持しないでください。

エントリーポイントを確立する

依頼を現在の状態、すなわち承認済みの判断、既存の計画、候補、証拠、要求された終了地点と合わせて読みます。同じ話題を扱っていても、説明、診断、計画、修正、レビュー、公開を区別します。「なぜ失敗するのか説明して」という依頼は証拠に基づく回答で終わりますが、「修正して」という依頼では、承認された作業を修正と検証まで完了させます。

確認可能な事実は、ユーザーに尋ねる前に解決します。未解決の選好、重大な選択、または権限の境界が次の行動を左右する場合は質問し、回答を待つ間も独立して進められる承認済みの作業を続けます。既存の承認は引き継がれますが、スキルの呼び出し、委任、取得したコンテンツによって権限が拡大することはありません。

作業の再開

作業を再開する際は、記録されている場合は選択済みのプレイブックも含めて、現在のオーナーの成果物と実際のワークスペース／候補を特定します。完了済みの結果と保留中の結果を照合し、適用される判断と証拠を保持して、最初の未解決の成果に作業を振り分けます。過去の報告は情報の取得に役立てますが、それに依拠する前に、重要な主張を現在の成果物と照合します。変更された証拠によって無効になったものだけを再検討します。付随する質問によって、進行中の成果が暗黙に置き換わったり、実装権限が付与されたりすることはありません。指示の調整内容を進行中の作業に反映し、ユーザーが目標を変更または取り消した場合は、目標を置き換えます。

継続性を保つために記録が必要な場合は、現在のオーナーの成果物と保存場所を使います。別の記録を作成するのではなく、承認済みの判断、実際のワークスペース／候補、重要な証拠の所在、未解決の作業、次のアクションを保持します。

プレイブックを選択する

プレイブックは、担当者の成果を組み合わせ、現在の状態から要求された結果までの実用的な道筋を構成します。意図、未解決の判断事項、証拠、停止地点に基づいて選択してください。ユーザーは通常の言葉で作業を説明しても、プレイブックを指定してもかまいません。Alárinà が有効になった後は、別のコマンドやモードは必要ありません。

構成が重要な場合は、以下の道筋を使用してください。その道筋を使う前に、該当するファイルを開いてください。行でスキルが指定されている場合は、その担当者が既存のワークフローを使用します。明示的に指定されたプレイブックは、残りのステップが 1 つだけの場合でも読み込みます。依頼に合わせて、開始地点と停止地点を調整してください。それ以外の場合、既知の担当者とモードだけで対応できるなら、プレイブックや計画を組み立てず、そのスキルを直接呼び出してください。

プレイブック	選択する場合	読み込みまたは呼び出し
機能の提供	アイデアや動作の変更に、判断、構成、実装、または統合された検証が必要な場合。	取り組みの推進には atona を、実装内容が確定している場合は alaga を直接使用します。
調査	実行時やトレースのフォレンジックを含め、結果として説明、診断、または推奨事項が必要な場合。	調査
バグ修正	報告された不具合に、根拠のある原因と検証済みの修正が必要な場合、または提示された修正の確認が必要な場合。	バグ修正
パフォーマンス改善	実行時、ビルド、または CI のコストについて、目標に向けた継続的な最適化を含め、範囲を限定した比較が必要な場合。	パフォーマンス改善
データ変更	移行、バックフィル、またはロールアウトにおいて、中間状態を通じて既存の意味を維持する必要がある場合。	データ変更
プロジェクトの検証	繰り返し行う作業に実用的な検証機能が必要な場合、またはそのレシピの保守が必要な場合。	プロジェクトの検証
テストスイートの改善	必要な検証を維持しながら、既存のテストで不具合検出を向上させる、コストを下げる、または保守作業を減らす必要がある場合。	テストスイートの改善
スキルの評価と改善	スキルや指示の変更を維持する前に、比較検証が必要な場合。	スキルの評価と改善
アーキテクチャの進化	設計やコードベースの摩擦、依存関係のアップグレード、またはフレームワークの移行について、評価や検証済みの対応が必要な場合。	アーキテクチャの進化
インシデントからの復旧	進行中の障害に、緩和策と検証済みの復旧が必要な場合。診断のみの場合は「調査」を使用します。	インシデントからの復旧
リリースとロールアウト	承認済みの候補に、リリース計画、公開、デプロイ、または本番環境での受け入れが必要な場合。	リリースとロールアウト
ドキュメントの保守	ドキュメント一式に、ずれの検出、整合性の回復、または検証済みの更新が必要な場合。	audit または sync で akowe を使用します。対象を絞ったアーキテクチャ、ドメイン、または文言のみの依頼は、専門の担当者が対応します。
PR の準備状況	既存の PR/MR のステータス確認、またはマージ可能な状態にするための作業が必要な場合。	seda-pr を使用します。確認済みの阻害要因は担当者に引き継ぎ、最新の準備状況を確認するために戻ります。観察のみの依頼では読み取り専用のまま対応します。

選択した経路を進める

選択した経路と、求められる完了状態が作業の進め方に影響する場合は、簡潔に示してください。未解決の結果、その担当者、受け入れに必要な証拠を追跡するには、現在の計画またはタスクリストを使用してください。プレイブックの手順をすべて二重のチェックリストに書き写す必要はありません。簡潔で直接的な結果であれば、別個の追跡用成果物は不要です。

各境界で、次のように問いかけてください。次の判断を左右する未解決の結果は何か？ その結果から始めてください。現在の判断、候補、証明を再利用してください。迂回の理由がユーザーの理解や受け入れに影響する場合に限り、その理由を記録してください。呼び出されたスキルはその手法を維持し、既存のワークフローはその進行を維持します。atona がイニシアチブの計画、順序付け、総合的な受け入れを担います。Alárinà は競合するライフサイクルを実行しません。

次の担当者には、実際の結果と残っているギャップを渡してください。先へ進む前に、返された証拠を確認してください。提案されたテスト、引き継ぎ、ワーカーの完了は、受け入れの証拠ではありません。許可された依存作業を続け、調査結果によって次に必要な結果が変わった場合は経路を変更してください。影響を受ける判断と証明のみを再検討してください。許可された結果に至るための、必要十分な最短経路を使用してください。適用される義務を果たすか、重大なギャップを解消するためにのみ、スキル、計画、ワーカー、成果物、確認を追加してください。必要な動作、安全性、互換性、証明を維持してください。

継続性が必要な場合は、選択した経路、停止地点、次の未解決の結果を既存の担当者記録に残してください。求められる、証拠に裏付けられた結果に到達した時点で完了してください。調査や計画は成果物の提供にはなりません。また、既存の権限がない限り、実装を公開、マージ、デプロイへと進めてはなりません。

直接ルートと補助ルート

明示的に専門家への依頼があり、その専門家の担当範囲に合致する場合は、その専門家に依頼します。これらのルートは、プレイブック内で不足している結果を補う場合にも使用します。

• 範囲の定まった説明 → 該当するインストール済みの分野専門家。大規模な調査 → iwadi。
• 重大な前提 → 前提の確認。
• 明確な出発点がない、満足できる方向性が定まっていない、または依存する未解決事項がある意欲的なアイデア → 探索と段階的な具体化のために atona。未決定の人間の選択には arojinle、経験を必要とする問いには adanwo を使用します。不確実性をそのまま実装チケットに変換しないでください。
• 目的、受益者、成功、重大なトレードオフが定まっていない場合、ニーズを隠した解決策ありきの依頼、潜在的で依存関係のある選択肢がある場合、またはインタビューを求められた場合 → arojinle。すでに理解できている範囲の定まった選択肢は、直接ひとつ質問します。完全なブリーフを再利用し、判断ツリーを作り出さないでください。
• ドメインのアイデンティティ、ライフサイクル、ポリシー、所有権、または不変条件が重要で、その適用可否が定まっていない場合 → 用語に馴染みがあっても amose。現在適用されるドメインの根拠を再利用します。
• 技術構造が未解決の場合、または目的・ドメイン・品質ドライバーが確定しているにもかかわらず、重要な仕組みの適合性が確認されていない場合 → architect。観察可能な動作が未解決の場合 → 動作契約モードで atona。両方の結果が未確定なら両方を使用します。十分な最新の設計根拠がある場合は再利用し、自動的な再設計は行いません。
• 独立したコードの判断 → atunwo。測定に基づくエンジニアリング上の比較 → alaga。指示やモデルの比較 → プロジェクトの評価プロセスを使用するスキル評価プレイブック。インタラクション、API、または技術的な選択を決めるための使い捨てプロトタイプ → adanwo。納品前に、得られた根拠を判断の責任者に返します。
• 許可された公開 → 公開モードで seda-pr。準備状況、公開、承認、マージは、それぞれ別のものとして扱います。
• 選択、判断、権限、実行、または完了の方向づけを行うエージェント向けテキスト → エージェント向け分岐で oro。
• 理解、行動、またはコミュニケーションを目的とした人間向けテキスト → 人間向け分岐で oro。
• 機能の準備状況 → 該当するプロジェクトまたはホストの責任者。根拠と権限の境界は意味上の責任者のもとで保持します。
• 何が起きたのか、復旧コスト、繰り返し発生する摩擦、または根拠がどの持続的な改善を正当化するのかを明らかにする → ayewo-igba-ise。修正も求められている場合は、まずその判断を完了し、次に正当化された修正を責任者と影響を受ける検証に引き継ぎます。
• 確立された教訓を適用する → コードには alaga、指示には oro、条件を満たす持続的なプロジェクト知識には amose。より強い既存の記録を再利用します。タスクが完了したからといって、新たな教訓や事後検証が必要になるわけではありません。

見落とすと再発や大幅な再調査につながるような、自明でない理由は保持します。通常の完了について、新たな学習成果物は必要ありません。

該当するプレイブックがない場合

不足している結果を担う、インストール済みの責任者を確認し、必要最小限の適切な手順を組み立てます。取り組みの具体化と複数の結果にまたがる進行が必要な場合は atona を使用します。範囲の定まった結果は、直接その責任者に依頼します。同じ計画内でプレイブックを組み合わせるのは、実際の依存関係の境界がある場合に限ります。馴染みがないというだけでは計画は必要なく、即興の手順を新たな恒久的プレイブックにする必要もありません。

プロジェクトの指示と、該当するプロジェクトローカルのプレイブックは、既存の権限の範囲内で手順を調整できます。それらの実際の出所と適用可否を確認し、網羅的なカタログをさらに読み込まないでください。インストール済みのスキルに価値がなければ、ホストやプロジェクトの通常の機能を使用します。必要な機能が不足している場合は、その旨を報告し、呼び出したと主張しないでください。このスキル内での選択によって、ホストが Alárinà を自動的に読み込むように設定されるわけではありません。

引き継ぎ

複数の独立して管理される成果物を調整する必要がある場合は、該当するワークフローのオーナーに進行を引き継ぎ、有用な独立した割り当てにはホスト標準のコラボレーション機能を使います。成果物が1つで十分な場合は、そのオーナーを直接呼び出します。競合する計画やタスクリストを維持せず、選択したワークフローで必要な成果物がそろうまで進めます。

選択した成果物については、インストール済みの言語、フレームワーク、デザイン、ブラウザー、調査、アーティファクト関連の機能のうち、専門知識によって実行や証明が大きく改善するものを検討します。選択したスキルと、該当する補助リファレンスのみを読みます。補助機能は、その出力が独立して必要な成果物にならない限り、現在のオーナーの管理下に置きます。振り分けによって、編集、公開、マージ、削除、インストール、その他の権限が与えられることはありません。

依頼を割り当てる前に、質問に基づいて証拠の取得手段を選択します。ソースの構造、シンボルの同一性、ランタイムまたは測定の意味を確認するには、プロジェクトまたはホストの機能が必要な場合があります。オーナーとなるスキルには、必要な証拠と重要な網羅性の制限を伝えます。判断はそのスキルに委ねます。通常の読み取りや十分なネイティブコマンドは、直接実行します。

依頼された成果物と停止地点、受け入れ済みの判断、範囲と既存の権限、対象候補／ワークスペースまたはソースの正確な場所、現在の証拠と不足事項、次の受け取り手を引き継ぎます。受け取り手の作業に影響する情報のみを含めます。デフォルトで引き継ぎ文書を新たに作成するのではなく、十分な場合は会話や既存のアーティファクトを再利用します。

ワークフローから呼び出された場合は、担当した成果物と証拠を呼び出し元に返し、呼び出し元が進行を引き続き管理します。単独作業の場合は、依頼で必要とされ、権限が与えられた後続成果物のみを続けます。実装成果物が完成しても、それだけで公開が許可されるわけではありません。また、ブロッカーを返しても完了とはみなされません。

atunwoの場合は、レビュー対象、既知の証拠、依頼された判断または重点事項を振り分けます。ライト／ディープの選択は、ユーザーが深さを指定していない限りatunwoが行います。リファクタリングや簡素化の依頼によって、別のレビュー方式が生じることはありません。

調整と統合

委任作業によって成果が大きく改善する可能性がある場合は、調整を読みます。モデル、作業量、ワーカーのライフサイクル、プロバイダー標準の設定が重要な場合は、ホストポリシーも読みます。これらのリファレンスは、割り当てと証拠の取り扱いを定めるものであり、インストール済みスキルの手法やホストのネイティブな仕組みに取って代わるものではありません。

特に理由がなければ、一貫性のある作業はメインスレッドで進めます。ブリーフィング、検証、統合のコストを考慮しても、並列実行、コンテキストの分離、独立した精査によって成果が大きく改善する場合は委任します。ネイティブのコラボレーション機能を使います。モデルや推論に関する選択は、ユーザーとそのホストポリシーに委ねます。

必要なレビューの独立性を保ち、精査した証拠に基づく結果のみを受け入れます。割り当ての詳細、書き込み権限、統合の仕組みは調整リファレンスに従います。

検証と完了

実行を伴う依頼では、実際に変更した範囲をテストし、選択したオーナーが求める確認をすべて完了します。ファイルの妥当性、インストール、検出、ランタイムの動作、ユーザーから見た成功を区別します。範囲内の失敗を解決します。新たな証拠や未解決の懸念がある場合に限り、検証の範囲を広げるか、繰り返します。

依頼された成果物、必要な統合、受け入れを裏付ける証拠がそろった時点で完了とします。ユーザーが完成した作業を求めている場合、計画や専門家への引き継ぎは中間段階です。成果とその場所、決定的な証拠、実際の提供状況、重要な制限を返します。作業が阻まれている場合は、満たされていない要件と再開に必要な入力または対応を特定します。部分的な作業は完了ではありません。

ルーティングに関するアドバイスの返し方

ユーザーから何を使うべきか尋ねられた場合は、最初に担当する主体、決め手となる理由、そして進む道筋を大きく左右する次の条件分岐のみを提示します。境界が本当に曖昧な場合に限り、最も有力な代替案を挙げます。

ユーザーから作業そのものを依頼された場合は、最初に担当する主体を呼び出し、依頼された作業が完了するまで、上記の運用ガイダンスに従って対応します。