OttermindでLinearを使う：課題一覧から次のアクションを明確に

Linearの課題を会話に取り込み、次に何をすべきかを整理しましょう。OttermindでLinearスキルを設定すると、エージェントはアクセス可能な課題やコメントを読み、レビューの準備を手伝い、チームがすでに記録した文脈を使って後続の対応案を作成できます。承認後は、対応する書き込み操作を通じて、その内容をLinearに反映できます。

課題管理ツールには詳細がそろっていても、それぞれのつながりを整理する必要がある場面で役立ちます。どの課題に意思決定が必要なのか。2件の顧客報告は同じ不具合を指しているのか。次のチケットをエンジニアが着手できる状態にするには、どんな情報が必要なのかを考えられます。

以下では、招待リンクの問題を含む架空のリリースを例に手順を紹介します。課題ID、参照元の事実、出力例はいずれも説明用であり、接続済みワークスペースで実施したテストを示すものではありません。

作業対象のチームを接続する

byungkyuが公開しているLinear APIスキルを使用します。このサードパーティ製スキルはMatonを経由して接続するため、Maton認証と有効なLinear OAuth接続が必要です。エージェントがアクセスできるワークスペースやリソースは、この接続によって決まります。

Ottermindのスキルガイドに従い、スキルを有効にして、タスクを担当するエージェントに紐づけます。Linear接続が複数ある場合は、使用するワークスペースを指定してください。まずは既知の課題を読み取り、そのIDとタイトルを確認するようエージェントに依頼します。

スキルのドキュメントには、課題の検索、クエリ、作成、更新、コメントに関する操作が記載されています。書き込みには明示的な承認が必要で、操作によっては追加の権限スコープが必要になる場合もあります。要件はスキルの設定手順で確認できます。

チームが決めるべきことを軸にレビューを準備する

チームがリリースを準備していて、3件の課題に招待リンクへの言及があるとします。1件は担当者が決まっており、別の1件には最近、説明を求めるコメントが付いています。残る1件には、まだ再現できていない顧客報告が含まれています。

ボードを開けば、課題がどこにあるかは分かります。レビューを準備するには、どの事実をまとめて議論すべきかを理解する必要があります。説明と関連コメントを読み、根拠へのリンクを付けた短い議題一覧を作るようエージェントに依頼しましょう。

[チーム]のLinearワークスペースにある[プロジェクト]のリリースレビュー用議題を作成してください。
進行中の課題と、現在の状況を理解するために必要なコメントを読んでください。

各議題には課題ID、タイトル、ステータス、担当者、
記録されている問題または質問、根拠となる課題へのリンクを含めてください。
議題を「必要な決定」「不足している情報」「確認済みの阻害要因」に分けてください。
記録された事実を使ってください。古い課題というだけで、作業が阻害されていると推測しないでください。
確認した内容と、取得できなかった記録を明示してください。課題は編集しないでください。

効果的な議題一覧には、なぜ各項目を取り上げるのかをチームメンバーが理解できるだけの情報があります。架空の例では、次のように整理できます。

この依頼でエージェントが担うのは、根拠を集めて質問を整理することです。再現手順が足りないのは、具体的な情報の不足です。リリース全体が危険にさらされていると判断するには、さらに情報が必要です。

Linearでは、課題のプロパティや関係性を使って絞り込めます。特定のプロジェクト、チーム、課題群を対象にすることで、レビューの焦点が定まり、確認範囲も評価しやすくなります。

対象の課題群を読み取る: Linearのフィルタリングリファレンス · LinearのGraphQLガイド

議題ができたら、さらに短い版を依頼します。「レビューの冒頭で話す5分間の説明を作ってください。招待に関する決定を最初に、情報の追加依頼をその後にしてください」。誰かが詳細を確認したいときには、根拠をまとめた元の詳しい表を参照できます。

似た報告を、違いを残したまま比較する

「招待リンクが壊れている」という表現は、さまざまな不具合を指し得ます。あるユーザーは期限切れのリンクを開いたのかもしれません。別のユーザーは違うアカウントでログインしている可能性があります。有効な招待を承諾した後でエラーが表示されるケースも考えられます。

新しい課題を作る前に、検索で関連候補を探します。そのうえで、説明、発生条件、期待される動作の比較を依頼してください。単なる幅広いキーワード一致を、どの報告を一緒に扱うべきか検討できる仮説に変えられます。

[チーム]の課題から、招待リンクの期限切れや、リンクが開かない問題を検索してください。
関連する課題の説明とコメントを読んでください。

報告された動作、再現条件、影響を受ける状況、
期待される結果を比較してください。各行に課題IDと参照元リンクを含めてください。
重複の可能性がある組み合わせとして確認する価値のあるペアを提案し、それぞれ理由を示してください。
一致が不確かなものは分けておいてください。課題をクローズ、統合、変更しないでください。

依頼する比較の小さな例を示します。これらのIDと報告は架空のものです。

DEMO-41とDEMO-63は、同じ議論で扱う候補です。ただし、根本原因が同じだと確定したわけではありません。DEMO-58も招待に言及していますが、再現条件は別の検討事項を示しています。

続けて尋ねるなら、「DEMO-41とDEMO-63を1つの課題で扱うべきか判断するには、どんな根拠が必要ですか？」が有用です。回答として、対応するスクリーンショット、正確なエラーメッセージ、再現手順の比較などが求められるかもしれません。診断を作り上げるのではなく、報告の内容から必要な根拠を導くべきです。

トリアージでは、この区別が重要です。重複した調査を減らしつつ、エンジニアが後で必要とする可能性のある情報を残すことが目的です。

合意した動作を、実装に着手できるチケットにする

ここで、レビューにより次の決定がなされたとします。期限切れの招待では問題を説明し、ワークスペース管理者に新しい招待を依頼するようユーザーを案内する、というものです。この決定には、招待の有効期間のルール変更は含まれません。

これらのメモがあれば、範囲を明確にした課題を下書きできます。同じ会話で続けることで、関連する報告や決定の理由を利用できる状態に保てます。

次の承認済みプロダクト決定から、Linearの課題を下書きしてください：[メモ]。
[チーム]と[プロジェクト]を使用し、先ほど確認した関連報告へのリンクを付けてください。

簡潔なタイトル、観察された動作、期待される動作、
対象となる作業、メモに明記された対象外の事項、受け入れ基準を含めてください。
実装方法を勝手に考えないでください。メモで指定されていない限り、
担当者と優先度は未設定にしてください。作成前に下書き全体を見せてください。
私が作成を承認した後、課題IDとURLを返してください。

この架空の決定なら、下書きには次の内容を含められます。

• タイトル： 招待の期限が切れたときに、次の操作を説明する。
• 観察された動作： 報告された期限切れリンクのフローでは、有用な復旧操作がないまま処理が終わる。
• 期待される動作： 招待の期限が切れたことを説明し、管理者に新しい招待を依頼するよう案内する。
• 対象外： 招待の有効期間に関するルールの変更。
• 受け入れ確認： 期限切れの招待を開くと、合意した説明と復旧の案内が表示される。

これは文章作成の例であり、Ottermindが課題を作成またはテストしたという主張ではありません。要件を知らないうちに追加することなく、決定を実行可能な内容にする方法を示すものです。

期待される動作と受け入れ基準は、まとめて確認しましょう。復旧の案内をボタンにするのか、通常のテキストにするのかがメモにない場合は、未解決の事項として明示します。チケットに架空のデザイン詳細を加えるより、今の段階で的確な質問をするほうが役立ちます。

選択したスキルは、課題の作成とコメントの追加をサポートしています。具体的な書き込み内容を承認したら、作成された課題へのリンクを求めてください。その決定が既存の課題に属する場合は、同じ仕事を追跡する場所を増やすのではなく、その課題に要点を絞ったコメントを用意します。

次のステップを元の報告につなげる

充実したセッションでは、関連する3つの成果物を残せます。レビューの議題、課題の比較、そしてチームの決定を反映した下書きです。それぞれに、その仕事が必要になった理由を説明する記録へのリンクを付けましょう。

Linearスキル と、対応が必要な課題群から始めてください。スキル入門では、この機能をエージェントが使えるようにする仕組みを説明しています。より広い運用方法については、AIプロジェクト管理ガイドがレビューと引き継ぎを扱い、エージェントワークスペースガイドが複数のステップにまたがる作業を文脈がどう支えるかを紹介しています。