Imported from kounoike/review-sweeper (AGENTS.md). Install upstream with npx skills add kounoike/review-sweeper. Copyright stays with the author.

Agent instructions

基本方針

• ユーザーの依頼と、それに対応する単一のBacklog.mdタスクにスコープを限定する。複数タスクを同時に進めない。
• ユーザーとのコミュニケーション、およびこのリポジトリの文書は日本語で記述する。製品名、コマンド名、コード、識別子など、翻訳すると意味が変わる技術要素は原文のまま記載する。
• 既存の変更を勝手に破棄しない。作業開始時にgit status --shortを確認し、依頼と無関係な変更は保持する。
• 依頼の範囲を超える製品仕様、公開API、互換性、リリース方式、アーキテクチャの決定を、ユーザーの承認なしに確定しない。

Backlog.mdの運用

このプロジェクトではBacklog.mdをタスク、受け入れ条件、作業メモ、完了サマリーの正本として使用する。

必須ワークフロー

• すべてのユーザー依頼について、作業や回答の前にmise exec -- backlog instructions overviewを実行する。
• Backlogのタスクを作成・分割する前にmise exec -- backlog instructions task-creationを読む。
• タスクの計画、担当者や状態の変更、計画・実装メモの追加、実装開始の前にmise exec -- backlog instructions task-executionを読む。
• 受け入れ条件の確認、完了サマリーの記録、終端状態への変更の前にmise exec -- backlog instructions task-finalizationを読む。
• 不慣れなBacklog CLIコマンドは、先にmise exec -- backlog <command> --helpで引数と使用例を確認する。
• タスク、ドラフト、文書、Decision、マイルストーンのMarkdownを直接編集せず、状態、受け入れ条件、メモ、完了サマリーはBacklog CLIで更新する。
• 受け入れ条件を実装前に具体化し、作業中はチェックリストと状態を更新し、完了時には検証結果を含む完了サマリーを記録する。
• Backlog上でタスクを終端状態へ更新するのは、受け入れ条件をすべて満たし、関連する検証が成功した後に限る。

Backlog CLIはmise.tomlで管理しているため、直接backlogを実行せず、常にmise exec -- backlog ...を使う。初回またはツールが未導入の場合はmise installを実行してから利用する。こちらで定義済みの確認処理はmise run backlog-checkを使ってよい。mise経由でもCLIが利用できない場合は、タスクMarkdownを直接編集して代替せず、制約をユーザーに報告する。

タスクの境界

• 対応するタスクが存在しない場合は、タスク作成が必要かを判断し、必要なら作成手順を読んでから作成する。
• 既存タスクの受け入れ条件やスコープが依頼と一致しない場合、勝手に拡張せず、タスクを分割するかユーザーに確認する。
• 重要な調査結果、選択肢、トレードオフ、実装上の前提は、チャットだけでなく対象タスクのメモに残す。

Backlog変更のPR運用

• タスク、ドラフト、文書、Decision、マイルストーンの追加・修正もrepositoryの変更として扱い、対象branchへ直接commitせず、作業branchでcommitしてPRを作成する。
• Backlogだけを追加・修正する依頼では、その変更専用のbranchとPRを作成する。実装タスクの状態、受け入れ条件、メモ、完了サマリーなどの更新は、その実装タスクと同じbranchおよびPRへ含める。
• Backlog変更のPRも、内容を確認して承認された後に対象branchへマージする。PRが未マージの間は、変更後のタスクやDecisionが対象branchの正本へ反映済みであるとは扱わない。
• Backlog CLIを使用する要件はbranch上でも変わらない。PR運用を理由にMarkdownを直接編集しない。

タスク完了の定義

• タスクは、受け入れ条件と検証を満たし、Backlog上の完了状態と完了サマリーを更新し、変更をcommitしてPRを作成し、承認されたPRが対象branchへマージされた時点で初めて完了とする。
• Backlog上の状態がDoneでも、PR未作成、レビュー中、承認待ち、または未マージの場合は、タスク全体を完了とは報告せず「PR作成待ち」「レビュー待ち」「マージ待ち」など実態に合う状態を報告する。
• PRの承認前にマージしない。修正要求がある場合は同じタスクのスコープで対応し、再検証してから再度レビューを依頼する。
• マージ後にPRの変更が対象branchへ到達していることと、CI等の必要な検証結果を確認してから完了を報告する。

PR作成の自動化

• タスク担当者は、受け入れ条件、検証、Backlogのfinalization、commitまで完了したら、ユーザーから別途pushやPR作成の指示を待たずにPR作成へ進む。
• Orca orchestrationでworkerが作業した場合、workerはcommitと検証結果をworker_doneで報告し、coordinatorが対象branchのclean状態とcommitを確認して、最新の対象branchへの追従、再検証、push、PR作成を自動的に行う。workerとcoordinatorが重複してPRを作成しない。
• PRには対応するTASK ID、変更概要、受け入れ条件に対する検証結果、既知の制約と後続事項を記載する。PR作成後はOrca workspaceをin-reviewへ更新し、PR番号とURLをcommentへ記録する。
• 対象branchへの追従でconflictが発生した場合、検証が失敗した場合、pushまたはPR作成権限がない場合は、force pushや検証省略で回避せず、実行したcommandとblockerを報告する。
• PRの自動作成はマージの自動承認を意味しない。PRはユーザーまたは指定reviewerの承認を待ち、承認前にマージしない。

Orcaワークスペースの後始末

• Orcaワークスペースで進めたタスクは、承認されたPRが対象branchへマージされ、上記のタスク完了条件を満たした後、そのワークスペースを削除する。
• 削除前に、対象ワークスペース、対応するbranchとcommit、未コミット変更がないこと、稼働中のワーカーやterminalがないこと、変更がマージ済みであることを確認する。
• ワークスペースの削除にはOrca CLIを使用する。PRのマージ確認後は、対応するlocal branchとremote branchも削除する。
• 未コミット変更、未マージのcommit、稼働中のワーカーがある場合は削除せず、状況をユーザーへ報告する。

アーキテクチャとADR

• 大きな影響があり、または変更を戻しにくい設計判断はadrsで管理する。
• 作業前にmise run adr-listとmise run adr-doctorを実行し、関連する既存ADRと状態を確認する。
• Decisionを作成する前に既存のDecision/ADRを検索する。既存の受け入れ済み決定を新しい選択に合わせて書き換えない。置き換える場合は新しいDecisionを作成し、旧DecisionをSupersedesで明示する。
• ADRの作成、編集、状態変更、関連付け、索引生成にはadrs new、adrs edit、adrs status、adrs linkなどのCLIを使い、索引を手作業で編集しない。
• ユーザーは重要な製品仕様、スコープ、公開API、互換性、アーキテクチャの最終決定権を持つ。エージェントは選択肢・根拠・トレードオフを整理して提示し、承認前に決定を確定したり依存実装を開始したりしない。

Decision本文をCLIで生成・更新できない場合に限り、CLIのバージョンとmise exec -- backlog decision --helpおよびmise exec -- backlog decision create --helpで制約を確認したうえで、Decisionの本文セクションだけを直接編集してよい。Frontmatterは変更せず、タスク等の他のMarkdownにはこの例外を適用しない。

実装と検証

• Rustの変更では、作業内容に応じてmise run fmt、mise run lint、mise run test、mise run check、mise run buildを実行する。完了時に実行した検証と結果をタスクへ記録する。
• ドキュメントや設定のみの変更でも、git diff --checkを実行する。
• 失敗した検証を成功したものとして報告しない。環境依存で実行できない場合は、コマンドと理由を明記する。