away

Away

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

ここでは速さより深さが大切です。ユーザーは何時間も戻ってこないため、最初の一連の実装と検証が終わったら、止めずにリストから次のアイデアに取り組みます。

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

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

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

基準を満たしたアイデアは、必要性を示す根拠に基づいて順位を付けます。実際にユーザーがアクセスしている404ページも、プロダクション環境で発生したエラーも根拠になります。プロダクトの文言が果たせていない約束や、すでに姉妹プロジェクトで実装されている修正も同様です。根拠のないアイデアも実装できますが、同順位なら必ず後回しにし、差分も小さく保ちます。

ときには型破りに

多くの場合、最も有望なアイデアは修正や仕上げです。しかし、ときには意外性のあるアイデアを1つ選ぶべきです。プロダクト自体のコンテンツを活用した機能や、新しい閲覧方法、ユーザーの作業方法を変えるツールなどが考えられます。上記の基準を満たし、差分を小さく抑えられるなら実装します。そうでなければ、試す価値がある理由を添えてレポートに記載します。

無難な修正だけのリストになっているなら、アイデアを生み出す工程が不十分です。

リポジトリに合わせる

変更は、その人自身が書いたように見えるべきです。何かを実装する前に、リポジトリで最も近い問題をどう解決しているかを調べ、その方法を踏襲します。

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

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

いつでも元に戻せるようにする

ユーザーが戻ってきたときに確認するのは選択肢であり、後片付けではありません。

• デフォルトブランチから away/<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. 幅広くアイデアを出すに戻り、突飛な案を追加します
実装したアイデアが、具体的に挙げられる誰にも役立たない	元に戻し、レポートに移します
変更差分に新しい色、余白の値、コンポーネントがある	リポジトリに既存の、最も近いものに置き換えます
時間が残っているのに、アイデアを未実装のまま作業を終えた	根拠のある次のアイデアを実装します