frontier-scan

スキル：frontier-scan

fdk/wiki/concepts/frontier-gap-scan.md にある runbook の呼び出し-INSTANT 版です。目的は、overstack のフロンティアを包括的に把握し、現状に満足して取り残されないようにすることです。GitHub への接続が必要なためブロックされている定期クラウド実行の代わりに、いつでも手動で実行でき、人間がループに参加します。

WHAT

目的とコンテキスト

• 目的： 過去30日間のエージェントフレームワークのフロンティアを調査し、8つの軸（同等／先行／劣後）で overstack を評価し、前回との差分を取り、ギャップについて issue を作成または更新して、レポートを更新します。
• トリガー（使用するタイミング）：
  • 「frontier scan」、「競合をスキャン」、「スカウトを実行」、「週次スカウト」、「世界と比べて何が劣っているか」、「/frontier-scan」。
  • 定期的（週次を想定）、または比較対象として注目すべき新しいフレームワークや技術の情報を得たとき。
• 対象外： 一般的なトピックの調査（/last30days が該当）；既知の単独 issue の作成（/raise-issue が該当）；ギャップのコード修正（担当セッションの作業であり、/fdk で開始）。

メンタルモデル

runbook + 前回のベースライン → 5回のWebSearch（固定4回 + 自由1回） → CAPABILITIESと比較した8軸の判定 → 前回との差分（評価低下／新しい軸） → issue（新規作成または更新コメント） → レポート + ログ。

入力と出力の契約

	フィールド	必須？	意味
In	runbook fdk/wiki/concepts/frontier-gap-scan.md	はい	8つの軸 + 評価方法
In	前回のレポート llmwiki/html/overstack-vs-world-30d.html	はい	差分比較のベースライン
In	llmwiki/wiki/sources/ISSUES.md + fdk/CAPABILITIES.md	はい	オープン中の issue + 現在の能力
Out	8軸の判定 + 前回との差分	はい	評価が下がった軸／新しい軸を明記
Out	新しい issue（台帳 + GH）または gh issue comment	ギャップに応じて	既存の issue と重複しない
Out	更新したレポート + llmwiki/wiki/log.md の1行	はい	以前のベースラインを保持し、今回の差分セクションを追加

ルールと機能

• RULE-01 (MUST)：スキャン + issue の作成／更新 + レポートのみを行います。コード変更、自動マージ、issue のステータスを open より先に進めることは禁止です。
• RULE-02 (MUST)：差分を有意義なものにするため、4つの固定スキャンクエリを各回で維持します。5つ目のクエリは自由です。
• RULE-03 (MUST)：issue を作成する前に wiki + ISSUES.md を検索します（R7-f）。すでに issue があるギャップについて、重複して issue を作成しないでください。
• RULE-04 (MUST)：「勝ち」の定義：実施中の issue がないまま、いずれかの軸が 劣後 の状態を2回を超えて連続させないこと。
• RULE-05 (MUST)：リポジトリではコミットへの AI attribution が禁止されています（R15）。コミットする場合は Co-Authored-By を追加しないでください。
• RULE-06 (MUST)：タスクに必要なものだけを変更し、便乗した変更は行わないでください。
• 機能：Web検索；前回のレポート + 台帳の読み取り；レポート + ログ + 台帳の記録；リモートトラッカーへの issue 登録。

失敗時の境界

• 前回のレポートがない → 差分を比較できません：これが最初のベースライン（partial）であることを明記し、前回の判定を捏造しないでください。
• リモートトラッカーにアクセスできない（gh が未認証）→ 台帳 + ISSUES.md のみを記録します（partial）。ユーザーに報告してください。
• ギャップに issue があるか確信できない → 追加で確認／検索し、重複する issue を作成しないでください（RULE-03）。

HOW

メインワークフロー

ステップ	種類	入力	アクション	出力／終了	失敗時／次の処理
W01	deterministic	runbook, report, ISSUES.md	runbook とベースラインを読む	8 つの軸 + 前回の verdict + オープン中の issue	report がない場合 → partial（初回のベースライン）
W02	effect	5 つのクエリ	5 件の WebSearch を実行（固定 4 件 + 自由 1 件）	検索結果	—
W03	judgment	結果 + fdk/CAPABILITIES.md	8 つの軸を「同等／迫りつつある／劣る」で評価	verdict	—
W04	judgment	新しい verdict + 古い verdict	前回との差分：順位低下／新しい軸	変更一覧	—
W05	effect	gap	Raise（B01）またはコメントで更新（B02）	issue	重複 → B02
W06	effect	verdict + 差分	report と log を更新	report + log	—
W07	deterministic	—	停止し、コード修正は行わない	レポート	—

各ステップの詳細（W01～W07 の正本）：

1. runbook とベースラインを読む：fdk/wiki/concepts/frontier-gap-scan.md と直近の report llmwiki/html/overstack-vs-world-30d.html を確認します。8 つの軸、前回の verdict、オープン中の issue（llmwiki/wiki/sources/ISSUES.md、GH#9-13 + Ralph #15）を読み込みます。
2. スキャン（WebSearch を 5 件）：(a) 今月の Claude Code／エージェントフレームワークの更新、(b) AI エージェントのメモリ + コンテキストエンジニアリング、(c) 自己改善型エージェント + ハーネス評価、(d) エージェントスキルのマーケットプレイス + サプライチェーンセキュリティ、(e) 話題のニュースをもとに選んだクエリ 1 件。期間をまたいで比較できるよう、最初の 4 件は固定します。
3. 比較：8 つの軸（Harness、Orchestration、Memory、Self-evolving skills、Knowledge/context、Eval/observability、Skill security、規模）を fdk/CAPABILITIES.md と比較し、「同等／迫りつつある／劣る」の verdict を付けます。
4. 前回との差分：どの軸の順位が下がりましたか？新たに登場した軸はありますか？これは最も重要なシグナルです。明確に記載します。
5. Raise／更新（重複を避けるため、先に R7-f クエリを実行します）：
   • issue がなく、新しい gap または悪化した gap がある → /raise-issue（ledger のドラフト + ISSUES.md の行 + gh issue create --assignee Rheinmir。本文から ledger へのリンクを記載し、「参考リポジトリ／論文」の項目を追加します）。
   • すでに issue がある gap → gh issue comment で証拠のみを更新し、重複して raise しないでください。
6. Report + log：llmwiki/html/overstack-vs-world-30d.html を更新します（古いベースラインは保持し、新しい期間の差分セクションを追加します）。さらに llmwiki/wiki/log.md に 1 行追記します。
7. 停止し、コード修正は行わない：このスキルは偵察と raise のみを行います。gap の実装は受け取り側のセッションの作業です（/fdk で開始します）。

分岐

ID	種類	条件	動作	スキップ／失敗	再合流
B01	conditional_required	新しい gap または悪化した gap があり、issue がない	/raise-issue（ledger + ISSUES.md + gh issue create）	—	W06
B02	conditional_required	gap に対応する issue がある	gh issue comment で証拠のみを更新	—	W06

検証と停止

新しい issue ごとに R7-f クエリを実行し、重複を避けます。report では古いベースラインを保持します。8 つの軸の verdict は判断を要するため、読者による確認が必要です。W07 の後で停止し、コード作成には進みません。

例

• 成功例： 今週の「/frontier-scan」で Memory の軸が「同等」から「迫りつつある」に低下し、issue がない場合 → /raise-issue + ISSUES.md に行を追加。report に新しい期間の差分セクションを追加し、log に 1 行追記します。
• 境界／失敗例： Skill security の軸は引き続き「劣る」ものの、ISSUES.md にオープン中の issue がある場合 → 新しい証拠を gh issue comment で追加するだけにし、2 つ目の issue は作成しません。