platform-request

プラットフォームへのリクエスト

あなたは、このアプリの所有者（開発者ではなく、その分野の専門家）のもとで働いています。 依頼のなかには、あなたが実装するものではないこともあります。プラットフォーム（Boring ライブラリ、ハブ、VM、モデル、コネクター）が先に変更される必要があります。その場合、あなたの仕事は 回避策を無理に作ることではなく、プラットフォームチームが 本人に再度話を聞かなくても実装できるほど完全な課題を渡すことです。

このスキルで作成する成果物は、このリポジトリに登録する kind:platform ラベル付きの GitHub イシュー（イシューフォーム .github/ISSUE_TEMPLATE/platform.yml）です。 プラットフォームのメンテナーと、そのコーディングエージェントが読みます。必要な情報をすべて記載してください。

該当する場合

• docs/CAPABILITIES.md で、必要な機能が「現在できないこと」に分類されている場合。
• 変更に vendor/、deploy/、.github/、server/src/auth.ts、新しいモデルプロバイダー、別システムへのコネクター、スケジューラー、メールが必要な場合。
• 何かが失敗し、正直に2回試しても（その都度、仮説を立てて検証しても）原因が見つからない場合、またはプラットフォームの動作がドキュメントと異なる場合。
• 変更に1日を超える作業が必要な場合、またはセキュリティや個人データに関わる場合。

ここで実装できるプロダクトの変更には使わないでください。実装してください（スキル boring-app-template、 build-app）。判断に迷ったら、docs/CAPABILITIES.md と gh issue list --label kind:platform --state all を確認してください（すでに依頼済み、または解決済みかもしれません）。

1. 本人に聞き取りをする（最も重要なステップ）

メンテナーは、本人との会話に参加していません。本人がここにいる間に、今のうちに背景を確認してください。本人の言葉で、平易に、1回に1つ質問してください。残りの質問数は決して伝えないでください。回答によってイシューの内容が変わらなくなったら、聞き取りを終えます。

1. 本人の言葉でのニーズ：何をしたいのか、なぜ今なのか。
2. 実際に起きた3つの状況（仮定ではなく実例）：それぞれについて、何がきっかけだったか、手元に何があったか、何をしたか、何を決めたか、何がうまくいかなかったか、または何に時間がかかったか、結果はどうだったかを聞きます。想像上の例が含まれている場合は、そう伝えて実例を尋ねてください。実在の人物（患者、クライアント、同僚）を特定できる情報はすべて取り除きます。名前、生年月日、識別情報を変更し、事例の概要は保ってください。
3. 現在の方法とそのコスト：この機能がない状態でどう対処しているか（時間、ミス、別のツール）、またどのくらいの頻度で起きるか。
4. 決定的な瞬間：期限に遅れそうなときやプレッシャーがかかっているとき、どの時点で現在の方法を諦め、代わりに何をしますか。この質問は一度だけしてください。何を自動化すべきで、何を手動のままにできるかが分かります。
5. 完了の状態：うまくいったときに、何が見えて、何ができるようになるか。それを本人が同意する「アプリは…するものとします」という文にします。
6. 制約：絶対に起きてはならないこと（データが外部に出る、本人の確認なしに文書が変更される、費用が発生するなど）と、緊急度（業務を止める、毎週困っている、あると便利）を確認します。

2. 根拠を集める

• 試したこと：コマンド、エラーテキスト、verify の証拠（network-summary --since-mark、console --errors、スクリーンショット）、実行行（verify api /api/runs）。架空のデータのみを使ってください。
• バージョン：git rev-parse --short HEAD、vendor/boring/SOURCE.json に記載されたライブラリのコミット、デプロイされているバージョン（ハブ上の list_app_tools。docs/CAPABILITIES.md を参照するか、/healthz のバージョンを確認してください）。
• 妨げとなっている docs/CAPABILITIES.md の項目、またはプラットフォームと矛盾するドキュメント。
• 現在できる最も近いこと（「Nearest」列）と、それを実装したかどうか。

3. 必要なものが目に見える場合はモックアップを作る

3段落では伝えきれないことも、図なら明確になります。適切なもののなかで最も簡単な方法を選んでください。

• テキストワイヤーフレーム（イシューには必ず含める）：コードブロック内にボックスとラベルを記載します。

• HTML モック：架空のデータを使った自己完結型のファイルを1つ作成し、それを PNG にします：

  node scripts/mock-shot.mjs docs/requests/<slug>/mock.html docs/requests/<slug>/mock.png
  

  両方を request/<slug> ブランチ（main は不可）にコミットしてプッシュし、イシューからファイルにリンクします（https://github.com/<owner>/<repo>/blob/request/<slug>/docs/requests/<slug>/mock.png）。

• 既存画面を変更する場合は、現在のページのスクリーンショット（verify screenshot）をモックの横に添えます。

4. 下書きを作成し、内容を確認してから登録する

1. issue-template.md（このファイルと同じ場所）の本文を .verify/request-<slug>.md に書きます。すべてのセクションを埋めてください。省略せず「不明」と記載し、誰が確認できるかを記します。

2. タイトル、概要、受け入れ条件の各行を本人の言語で提示し、必要な内容になっているか確認します。本人が同意するまで修正してください。Issue の登録内容は他の人にも見えるため、本人の同意を得る前に登録してはいけません。

3. 登録します：

   gh issue create --label kind:platform --title "<the need, in a few words>" --body-file .verify/request-<slug>.md
   

4. 本人にリンクと、今後の流れ（プラットフォームチームがトリアージすること）、その間にできること（最も近い回避策）を伝えます。

5. 未完成のものを残さないでください。完了していない回避策は元に戻すか、完成させたうえで、その旨を Issue に記載します。

禁止事項

• Issue、モックアップ、証拠に実際の個人データを含めること。Issue はアプリの外部にいる人やエージェントにも読まれます。
• 自分の作業を「ブロック解除」するために、vendor/、deploy/、.github/、または認証を変更すること。
• ヒアリングなしで Issue を登録すること。「本人が X を求めている」というだけで、状況、受け入れ条件、証拠がなければ、本人に質問が返ってくることになります。