list-open-work

/list-open-work

1 つの質問に答えます。このリポジトリで、自分がオープンにしているものと、それぞれに紐づくチケットは何ですか？まず一覧を示してください。それ以外の内容は、その後に文章で記載します。

このリポジトリのみ

対象は、現在いる git チェックアウト（worktree またはプライマリ）です。その origin を確認してください。 そのリモートに対する、自分のオープン中の MR／PR を一覧表示してください。そこで終了します。

• git リポジトリではない場合は、その旨を伝えて終了してください。別のプロジェクトを探してはいけません。
• 記憶、別のセッション、別の worktree から、別の origin、組織、フォージ、トラッカーを一覧表示してはいけません。
• チケットキーは、このリポジトリのブランチ名／タイトルから推測してください（例：feat/PROJ-123-slug の PROJ-123）。別の場所で見たプレフィックスを再利用してはいけません。

git rev-parse --show-toplevel
git remote get-url origin

出力形式

通常のレンダリング済み Markdown として、チャットに直接記述してください。コードフェンスで囲んではいけません。リンクをクリックできる状態にする必要があります。

各項目の間には空行を入れてください。 Markdown では、単一の改行はスペースとして扱われるため、隣接する行は 1 つの段落になります。これは誤りです。各 MR はそれぞれ独立した段落にしてください。改行し、空行を挟み、次の行を記載します。

形式は次のとおりです。見出しは Open MRs: または Open PRs: です。箇条書きや絵文字は使いません。 番号とチケットキーは、どちらもリンクにします。チケットは末尾の [KEY] に配置します。

Open MRs:

!42 - 保存パスを短縮する [PROJ-101]

!41 - 新しいフラグをデフォルトで有効にする [PROJ-99]

!30 - 公開 API でステータス履歴を公開する

• 番号の降順に並べます。GitLab では !N、GitHub では #N を使います。「MRs」と「PRs」も同様に使い分けます。
• 各項目を 1 つの段落にします：<!|#><N> - <title> [<KEY>]。太字にはしません。
• チケットは末尾の [KEY] に配置します。投稿者がタイトルの途中に埋め込んでいる場合は、末尾に移動します： perf: PROJ-77 — 過剰な取得を削減 は perf: 過剰な取得を削減 [PROJ-77] になります。
• チケットがない場合は [KEY] を省略します。捏造したり、(no ticket) と記載したりしてはいけません。
• MR／PR のタイトルはそのまま維持します（キーを移動する場合を除く）。書き換えてはいけません。

誤り（1 行に折り返されて表示されます）：

Open MRs:
!42 - shorten the save path [PROJ-101]
!41 - default the new flag on [PROJ-99]

Slack への貼り付けは別の依頼です。フォージ／トラッカーの連携機能では !42 と PROJ-101 がそれぞれ自動的にリンクになるため、その形式ではリンク構文を取り除いた同じ行を使います。項目は引き続き 1 行に 1 つです。

収集

「自分」とは、自分が作成者であることを意味します。API からユーザー名を解決してください。推測してはいけません。

GitLab origin：

glab api user
glab api "projects/<url-encoded-path>/merge_requests?state=opened&scope=all&per_page=100"

作成者 = 自分、で絞り込みます。<url-encoded-path> は、この origin のパスです。別のリポジトリのパスではありません。

GitHub origin：gh pr list --author @me --state open --json number,title,headRefName,body

チケットは、タイトル、次にブランチ、次に説明の順で、最初に見つかった \b[A-Z][A-Z0-9]+-\d+\b とします。このリポジトリで使用しているチケットキーのトラッカーホストを使ってください。別の会社のサイトを推測してはいけません。

Jira アカウントの確認

実際の Jira 検索結果が、このリポジトリのトラッカープロジェクトと一致していることを確認してください。acli jira auth status だけでは、検索が別のアカウントに接続していても、意図したサイトを報告することがあります。プロジェクトキーまたは API ホストが想定されるワークスペースと一致しない場合は、acli jira auth switch --site <repo-tracker-host> --email <verified-email> を使って、保存済みアカウントを明示的に選択してください。その後、信頼できる一覧として扱う前に、既知のチケットを読み戻してください。誤ったサイトからの検索結果を再利用してはいけません。

acli jira workitem search --paginate を使い、取得した件数と、同じ JQL での --count の結果を比較してください。検索で使えるフィールドは制限されています。タイムスタンプ、説明、コメントを取得するには、代わりに workitem view --fields summary,description,status,priority,assignee,updated,comment,issuelinks --json を使ってください。Testing チケットを新規実装作業に分類する前に、コメントを読んでください。

その後、文章で報告します

次に取るべき行動が変わる情報だけを伝えます。

• デフォルトブランチとの競合がある場合 — レビュー中ではなく、ブロックされています。GitLab はマージ可能かどうかを遅延して再計算するため、通常の MR GET では古い has_conflicts: false がそのまま返されます。強制的に再計算させて merge_status を確認します。

glab api "projects/<path>/merge_requests/<iid>?include_diverged_commits_count=true"
# cannot_be_merged + has_conflicts → needs a rebase; diverged_commits_count = how far behind

• パイプラインが失敗している場合（head_pipeline.status）。
• チケットの状態が MR と矛盾している場合：すべてのスレッドが解決済みで状態も問題ないのに、チケットはまだ In Progress になっている。
• チケットがなく、作成から数か月経過している場合 — 経過期間を示し、クローズを提案します。

依頼されない限り、承認については省略します。何も変わらないフィールドを説明しません。

GitHub の準備状況を確認する際は、ページネーションされたインラインスレッドに加えて、提出済みのレビュー本文と人間による PR コメントも確認します。未解決のインラインスレッドがゼロで CI が成功していても、COMMENTED レビューに明確なマージブロッカーが含まれている場合があります。各レビューを、そのレビュー対象のヘッドに対応付けます。古い指摘は現在も該当するか再確認し、現時点の欠陥だと断定しないでください。

CI の結論、競合状態、実質的なレビュー上のブロッカーは、それぞれ分けて扱います。現在のヘッドごとに gh pr checks を実行します。UNKNOWN のマージ可能性は未確認であり、競合がないことを意味しません。報告する前に、インベントリと集計件数をプログラムで保存します。

このリポジトリでトラッカーのキーではなく GitHub の issue を使っている場合は、closingIssuesReferences に加えて、PR 本文に明記された issue へのリンクも確認します。意図的にクローズしない参照が、実際に紐づいているチケットである可能性があります。状態を変更する前に、issue の状態と議論を確認します。一部のみの修正や、保留中の実環境での検証がある場合は、オープンのままにする必要があります。