fpl-copilot

FPL Copilot

現在のFPLデータを分析し、保存済みのチームを管理し、単独で完結するレポートを作成します。このスキルでは操作と完了条件を定めています。実際の環境から適切なツールやコマンドを選択してください。

ワークフロー

1. 機能とストレージを確認する

利用可能なツールを調べ、このスキルのリソースがインストール先から見てどこにあるかを特定します。HTTP リクエスト、JSON 処理、SQLite 3 のクエリと書き込み、ドキュメントの永続化、レポートの配信に対応する機能を確認します。シェルを利用できるホストでは、インストール済みの適切なコマンドやスクリプトライブラリを見極めます。それ以外のホストでは、公開されているネイティブツールを使用します。ツール名や実行ファイルは実装上の選択肢です。

以下のルールに従ってストレージを一度だけ解決し、以降のすべての参照と操作で得られた対応関係を再利用します。FPLデータはエージェントアプリケーションの内部ストレージと分離してください。

ストレージの解決（優先順位順）：

1. ユーザーが明示的に選択したFPLの保存場所、または安定した名前空間 fpl-copilot に対するホスト提供のバインディングを使用します。両者が一致しない場合は、書き込み前にどちらを使うか確認します。
2. 明示的な選択もホストバインディングもない場合は、デスクトップのルート ~/.fplcopilot/ を使用し、現在のユーザーのホームディレクトリを基準に絶対パスへ展開します。作業ディレクトリや会話が変わっても、このルートを再利用します。
3. デスクトップのホームディレクトリがないホストでは、ストレージ機能を通じて名前空間 fpl-copilot の永続ストレージを要求します。既存のバインディングを再度開きます。ホストが安定したバインディングを提供できない場合は、状態を作成する前に、永続性のある保存場所をユーザーに選択してもらいます。会話限定のストレージは、その旨を明示して選択します。

fplcopilot.db、squads/、reports/、player-history-sync.json は、この1つのルートから導出します。ホストが個別のリソースハンドルを使用する場合は、ホストのストレージ設定を通じて、同じ名前空間のもとにそれらの対応関係を保存します。会話をまたいだ永続性を主張する前に、その対応関係を再度開けることを確認します。参照内の「解決済み」の場所に関する記述はすべて、この対応関係を指し、新たな場所の選択を意味しません。

初期化する前に、選択した場所を調べます。既存の対応関係に複数の候補が見つかった場合は、どれを正とするか確認します。ユーザーが移行を選択するまでは、既存データを保持してください。対応関係を初めて設定する際は、選択したルートまたはハンドルと永続性の範囲を報告します。

構造化されたFPLストレージにはSQLite 3が必要です。sqlite3 実行ファイルは利用可能なインターフェースの1つであり、必須の依存関係ではありません。利用可能なSQLiteインターフェース（CLI、スクリプト言語のライブラリ、またはExpo SQLiteなどのSQLiteを基盤とするネイティブのプリミティブ／ツール）を使用します。利用可能なインターフェースを確認し、一貫して使用してください。新しいデータベースは references/schema.sql から初期化します。参照SQLは、スキーマと計算の意味を保ったまま、選択したインターフェースで実行します。必須機能が不足している場合は、実行できない操作を明示し、対応可能な部分のみを完了します。未保存の出力と利用できないライブデータは、明確に区別してください。

完了条件： エージェントが依頼されたタスクに必要な操作と永続的な保存場所を特定できていること、または不足している機能を具体的に報告していること。

2. データの鮮度を確認する

データ分析の前に、references/sync.md と references/api.md の該当するマッピングを読みます。更新の成功に関するメタデータを確認し、その契約に従って、未取得または古くなったデータセットを更新します。依頼された計算に必要な選手の履歴だけを取得します。全選手を対象とした一括取得には、ユーザーからの明示的な依頼が必要です。

完了条件： 必要なデータセットについて、更新の成功時刻と保存済みレコードを確認できていること。または、利用可能なキャッシュ済みスナップショットの経過時間と制約を回答で明示できること。更新に失敗したことは、データが新鮮である証拠にはなりません。

3. スカッドを読み込み、分析する

「自分のスカッド／チーム」については、ユーザーに再度共有を求める前に、保存済みのスカッドを確認します。選択、永続化、検証については references/squad.md を読みます。指標と意思決定フレームワークについては references/analysis.md を読みます。利用可能なクエリ／計算機能を使って、記載されている計算式を適用します。保存済みの名前から選手IDを特定し、選手を選ぶ前に名前の曖昧さを確認します。

新たに共有されたスカッドと、確認済みの変更は、スカッドのリファレンスに従って保存します。仮定上の移籍は下書きプランにとどめます。変更をローカルに記録しても、ユーザーのFPLアカウントには送信されません。スカッドの分析後、重要な要点をNotesに保存します。

完了条件： 推奨事項が取得データと記載された計算に基づいており、必要なスカッドの書き込みがすべて検証済み、または未保存であることが明示されています。

4. 結果を提示する

すばやく参照できる情報、簡潔な根拠、締め切り、小規模な結果にはMarkdownを使います。以下の空間的または比較形式の出力には、references/html-output.md を読み、実データに合わせて該当するテンプレートを調整します。

出力	テンプレート
スカッドのフォーメーション、ベンチ、合計	templates/squad-view.html
対戦難易度マトリックス	templates/fixture-matrix.html
移籍の比較	templates/transfer-comparison.html
根拠付きのキャプテンランキング	templates/captain-ranking.html
ゲームウィーク戦略	templates/gameweek-report.html

インラインCSS、JavaScript、SVGを含む、自己完結型のHTMLレポートを1つ作成します。バニラHTML／CSS／JSを使い、レスポンシブなレイアウトにします。解決済みの reports/ の場所に {YYYY-MM-DD}-{slug}.html として保存します。サポートされているプレビュー、添付ファイル、共有リンク、またはアクセス可能なファイルパスを提示します。利用可能な場合は、適切な閲覧操作を判断します。レポートの作成または配信ができない場合は、主要な結果をチャットで提示し、利用できないレポート機能を明記します。

完了条件： ユーザーが実質的な回答を得ており、対応している場合はアクセス可能なレポートの参照先も提示されています。データの鮮度と制限事項も明記されています。

リファレンスの参照先

各リソースは、該当する操作を実行する前に読みます。

リソース	操作
references/sync.md	FPLデータセットの更新、正規化、永続化、検証
references/api.md	エンドポイント、およびAPIからストレージへのフィールド対応の特定
references/schema.sql	ストレージの初期化、またはテーブル、型、キーの特定
references/analysis.md	指標と推奨事項の算出
references/squad.md	スカッドの読み込み、検証、作成、更新
references/html-output.md	レポートの生成と配信

データ規約

• 名前は web_name、次に部分一致する表示名、最後にフルネームの順で照合します。一致候補が曖昧な場合は確認します。
• 価格の単位は0.1mです。130 は £13.0m を意味します。表示は £X.Xm とし、価格に対する価値を比較する際は、価格を百万単位に正規化します。
• ポジションはGKP、DEF、MID、FWDで、APIコード1～4に対応します。
• 出場可否コード：a は出場可能、d は出場が不確実、i は負傷、s は出場停止、u は出場不可です。
• FDRは1（非常に容易）から5（非常に困難）までです。