FloatSoda: Skill for Claude Code

Phase2 リモート状況確認 → Codex /goal プロンプト生成

FloatSoda(%USERPROFILE%\projects\libs\FloatSoda)の Phase 2 は、Flutter の基礎ウィジェット約48個を Widget / Element / RenderObject の3層で移植するフェーズ。進捗はトラッキング Issue #178 の チェックリストで管理され、Codex が <issue番号>-<primary-area>-<slug> ブランチで Draft PR を作る運用(ブランチ命名規則は CONTRIBUTING.md が正典。エージェント名をブランチ名に含めない)。

このスキルの目的は「今リモートがどうなっているかを正確に把握し、進行中の PR と競合しない 次のタスクを選んで、Codex がそのまま自走できる /goal プロンプトを書く」こと。

手順

1. リモート状況の調査

FloatSoda リポジトリで以下を確認する(独立なコマンドは並列で実行してよい):

cd "$USERPROFILE/projects/libs/FloatSoda"
git fetch --all --quiet
git branch -a                # 進行中の作業ブランチの有無
git log --oneline -10 --all --date=short --pretty='%h %ad %d %s'
gh pr list --state open
gh issue view 178 --json body -q .body   # Phase 2 チェックリスト

オープン中の PR は gh pr view <番号> --json title,body,statusCheckRollup,mergeable で CI 状態(build-and-test)とマージ可否まで確認する。Draft かどうかも重要 (Draft = レビュー待ち。マージ済みと誤認しない)。

2. 次タスクの選定

選定基準(重要な順):

1. 依存関係を満たしている — #178 のチェックリストに「#XXX が前提」と書かれた依存を守る。 前提 Issue が「Draft PR になっているだけ」ならまだ未達。マージされて初めて着手可能。
2. 進行中の Draft PR とファイル競合しない — 同時に走らせるなら触るファイルが重ならない Issue を選ぶ(例: レイアウト系 PR が進行中なら描画・装飾系を選ぶ)。
3. Phase 2 スコープ内 — #178 で「後送り」「Phase 3/4」とされたものは選ばない。

判断に迷ったら、候補と理由をユーザーに提示して選んでもらうのではなく、 本命を1つ選んだ上で「別の Issue にしたければ言ってください」と添える。

3. /goal プロンプトの生成

以下のテンプレートで出力する。Codex はこのプロンプトだけを見て自走するので、 このセッションの文脈に依存しない自己完結した内容にすること。

/goal
GOAL: FloatSoda リポジトリ(<リポジトリの絶対パス>)で Issue #<番号> を実装する。
<対象ウィジェット群>を、既存の Widget / Element / RenderObject 3層パイプラインに接続して public 化する。
Flutter 本家の同名ウィジェットの設計を正典として踏襲しつつ、FloatSoda 既存の
RenderProxyBox・dirty layout/paint 設計・命名規約に合わせること。

コンテキスト:
- ブランチは origin/main (<最新mainのSHA>) から `<issue番号>-<primary-area>-<slug>` を切る(`<primary-area>` は Issue の `area:*` ラベルの主要領域)(CONTRIBUTING.md のブランチ命名規則に従う。`codex/` 等のエージェント名を含めない)。
- 進行中の Draft PR <#番号リスト> とはファイルを競合させない。<依存回避の具体的指示>
- 参考: docs/WidgetSystem.md、既存の類似ウィジェットの実装パターン。

完了条件:
1. <対象ウィジェット>が public API として動作する
2. 各ウィジェットに単体テストがあり、既存テスト含め全テストが通る
3. 不正入力(負数・非有限値など)の検証が既存ウィジェットと同水準
4. docs/WidgetSystem.md の実装状況を更新
5. コミットメッセージは以下の形式。件名は日本語、本文の最終行に
   GitHub の issue クローズキーワードを置く:

   feat: <対象ウィジェット>を実装する

   <変更内容の要約を数行>

   Closes #<番号>

   複数 issue を閉じるときは各 issue にキーワードを付ける
   (`Closes #59, #60` ではなく `Closes #59` / 改行 / `Closes #60`)。
   PR 本文にも同じ `Closes #<番号>` を記載する。
6. Draft PR を作成し CI (build-and-test) が成功する
7. 実装中に docs/ を読んで迷った箇所を PR 本文の末尾に
   「## ドキュメントで迷った点」として列挙する。迷わなかった場合は
   「迷った点なし」と明記する(省略しない)。
   各項目は「どのドキュメントの何を読んで / 何が判断できなかったか /
   最終的にどう決めたか(何を根拠に推測したか)」の3点を書く。
   ドキュメントに書いていないので既存コードを読んで真似した、という箇所も
   ここに含める。設計判断そのものへの疑問ではなく、
   「ドキュメントを読んでも分からなかったこと」に絞ること。

制約:
- 公開APIに Skia 型を露出させない(#131 の方針)
- Phase 2 は静的表示に絞る。AnimatedContainer 等の暗黙的アニメーションは
  Phase 3 のスコープなので提案・実装しない
- nullable 警告を新規に増やさないよう努める(ただし WarningsAsErrors=nullable は
  API 安定化段階まで導入しない方針なので、既存警告の一括解消はスコープ外)