afk

AFK

あなたが離れている間に、1つのプロジェクトをより良くするスキルです。根拠を集め、幅広くアイデアを出し、最も有望なものをローカルブランチでいくつか実装して、2分で読めるレポートを残します。

ここでは速さより深さを重視します。担当者が何時間も離れるため、最初の一連の変更を実装して検証したら、そこで止めずにリストから次のアイデアに取り組みます。

インターフェースのレビューには better-interface、差分のレビューには interface-review、1つのコンポーネントの代替案の検討には variant、1つのコンポーネントのストレステストには break を使います。

利用する人にとってより良いものにする

すべてのアイデアは、1つの問いに答えます。この製品を使う人は、本当により良いと感じるでしょうか？その人が誰で、どんな場面で役立つのかを示してください。たとえば、リンク切れのページにたどり着いた読者や、投稿を探している訪問者などです。コードを整頓するだけのアイデアや、エージェントが忙しそうに見せるだけのアイデアは、この基準を満たしません。

基準を満たしたアイデアは、必要性を示す根拠に基づいて順位付けします。実際のトラフィックが404にたどり着いていることも、本番環境でエラーが発生していることも根拠になります。製品の説明文が果たせていない約束も、担当者がすでに関連プロジェクトで出荷した修正も同様です。根拠のないアイデアでも実装できますが、同順位の候補には必ず負け、差分も小さく抑えます。

ときには型破りなアイデアも

多くの晩は、最も有望なのは修正や仕上げです。しかし、ときには1つくらい意外性のあるアイデアがあってもよいでしょう。製品独自のコンテンツによって可能になる機能や、新しい閲覧方法、担当者の作業方法を変えるツールかもしれません。上記の基準を満たし、差分を小さく収められるなら実装します。そうでなければ、試す価値がある理由とともにレポートに記載します。

安全な修正しかリストにない場合は、アイデア生成の手順が不十分です。

リポジトリに合わせる

変更は、担当者自身が書いたかのように見えるべきです。何かを実装する前に、リポジトリ内で最も近い課題がすでにどのように解決されているかを確認し、その方法を踏襲します。

• 既存のコンポーネント、フック、ユーティリティを再利用します。既存のものでは対応できない理由がなければ、新しいプリミティブを追加しません。
• 色、余白、角丸、文字、モーションには、既存のデザイントークンを使います。最も近い既存の画面から値を選び、新しい値は作りません。
• ファイル構成、命名規則、インポートスタイル、コメントを書く場合も含むエージェント向けドキュメントのルールに従います。
• インターフェースの文言は、製品で既に使われているトーン、長さ、句読点に合わせます。
• アーキテクチャを維持します。新しい状態管理ライブラリ、スタイリング手法、データレイヤーは、実装せずにレポートへ記載するアイデアです。

関連プロジェクトで同じ課題を解決している場合は、その解決策を移植し、このリポジトリのトークンに合わせてスタイルを調整します。

元に戻せる状態を保つ

担当者が戻ってきたときに待っているのは、選択肢であって後片付けではありません。

• デフォルトブランチから afk/<date> という名前の新しいブランチを作成します。作業ツリーに未コミットの変更がある場合は、別の git worktree で作業し、その変更には一切手を加えません。
• リポジトリ独自のコミットスタイルに従い、変更ごとに1つずつローカルでコミットします。この依頼で求められている場合に限り、プッシュ、プルリクエストの作成、マージ、デプロイ、投稿、メッセージ送信を行います。
• 接続済みサービスは読み取り専用として扱います。分析データ、エラートラッカー、デプロイログを読み取り、設定、データ、連携には変更を加えません。
• 担当者自身が書いた文章は、その人の文体のまま残します。新しい文言、変更履歴、投稿の下書きは公開済みの文章を編集せず、レポートに記載します。
• 依存関係を追加するのは、関連プロジェクトが同じ用途ですでに使っている場合に限り、レポートにもその名前を記載します。
• テスト実行で書き換えられるファイルはスナップショットを取り、実行後にスナップショットから復元します。

1. プロジェクトを把握する

AGENTS.md または CLAUDE.md、README、最近の Git ログ、オープン中のブランチとプルリクエスト、担当者について保存されたメモを読みます。コミット形式、コメントのルール、コンポーネントのパターンなど、守るべき規約を確認します。プロジェクトの目的と技術スタック、そして変更が違反するとレビュー担当者に却下される規約を説明できたら完了です。

2. 根拠を集める

関連するすべての情報源を読みます。トップページ、404、参照元のウェブ分析、エラートラッカーと実行時ログ、CI の結果、未解決の課題、TODO コメントが対象です。また、製品のコピーやドキュメントを、実際の製品の動作と照らし合わせて確認し、最も利用者の多いページのコンソールも確認します。

次に、その人の関連プロジェクトを読み、検索ダイアログ、コンポーネント、ワークフローなど、すでにそこで解決済みのものを探します。各情報源を読み終えるか、理由を添えて対象外にしたら完了です。

3. 幅広くアイデアを出す

何かを選ぶ前に、少なくとも 15 個のアイデアを書き出します。修正、デザインの仕上げ、機能、コンテンツ、パフォーマンス、アクセシビリティ、その人自身のツール（スキルやスクリプトなど）を網羅します。見た目だけでなく、製品の動作を変えるアイデアを少なくとも 3 個含めます。各アイデアについて、役立つ人、その根拠、おおよその規模、リスクを記載します。役立つ相手を具体的に挙げられないアイデアは除外します。すべての領域にアイデアがあり、少なくとも 1 つはその人を驚かせる内容になったら完了です。

4. 最も有力なアイデアをいくつか実装する

それぞれを 1 つの小さなコミットとして実現できる、最も根拠の強いアイデアを選びます。まず実際のユーザーの困りごとを解決し、次に機能を構築し、その後に仕上げを行います。リポジトリに合わせるに従ってそれぞれを実装し、コミット前にプロジェクトのチェックコマンドを実行します。選んだ各アイデアをコミットするか、取りやめた理由を添えて除外したら完了です。

5. 変更が動作することを確認する

各変更を、ユーザーが実際に触れる場面で試します。インターフェースの変更にはブラウザーを使い、ルートやリダイレクトには curl を使い、AI を利用する機能には実際のエンドポイントを使います。視覚的な変更は、ライトテーマとダークテーマ、スマートフォンの画面幅で確認します。各変更の動作を確認するか、未検証と明記したら完了です。

6. レポートを残す

最後に、その人が最初に読むメッセージを 1 つにまとめ、次の順に記載します。

1. 現在の状況。 ブランチ、コミット数、開発サーバーの URL、実行したままのもの。
2. 実装した内容。 変更ごとに 1 項目とし、ユーザーに見えるようになった内容と、その変更の根拠を記載します。
3. 検証した内容。 動作を確認したものと、型だけを確認したもの、またはまったく確認していないものを区別します。
4. 判断を仰ぐ事項。 その人に代わって決めたことで、元に戻したい可能性があるもの。
5. 未実装のアイデア。 突飛な案も含め、残りのアイデアすべてについて、根拠と規模を記載します。

元に戻せる状態を保つで作成した下書きは、アイデアとともに記載し、そのまま貼り付けられる状態にします。

終了前の確認

パターン	対応
コミットの件名に「and」が必要	2 つのコミットに分けます
型チェックだけで変更を検証している	実行中のアプリで試すか、未検証と明記します
レポートにコミットの件名を列挙している	ユーザーに見えるようになった内容と、実装した理由を記載します
変更差分に、その人が未コミットのファイルが含まれている	作業を別の worktree に移し、その人の変更を元に戻します
コードの動作を説明するコメントがある	コメントがないとコードの見た目に違和感が出る場合を除き、削除します
アイデア一覧が修正案だけになっている	3. 幅広くアイデアを出すに戻り、突飛な案を追加します
実装したアイデアが、具体的に挙げられる誰にも役立たない	元に戻し、レポートに移します
変更差分に新しい色、余白の値、コンポーネントがある	リポジトリに既存の、最も近いものに置き換えます
時間が残っているのに、アイデアを未実装のまま作業を終えた	根拠のある次のアイデアを実装します