cycle-review

サイクルレビュー

サイクルレビューは、GitHub ディスカッションを通じたラウンドトリップです。ブランチ A では会議メモをディスカッションとして公開し、メールのアジェンダとして下書きします。会議ではその内容に沿って進行し、プロジェクトマネージャーが決定事項をコメントとして投稿します。その後、ブランチ B でその決定事項をトラッカーに反映します。ブランチ A または B に進む前に、house-rules と writing-lean を読み込んでください。

記録となるのはディスカッションであり、次のサイクルのメモを差分確認する際の基準です。ディスカッションの場所と読み書きの方法については、ディスカッションの編集を参照してください。

**会議中にメモを編集することはありません。**プロジェクトマネージャーが同じ見出しを使ってコメントを投稿し、ブランチ B でその後に反映します。

サイクルは Cycle フィールドの反復単位で、作業状況は Status フィールドで示します。どちらも CLHbid Delivery プロジェクトにあります。**フィールドの仕組み、Status の値、参照の規約、およびすべてのボードクエリは issue-tracker スキルから確認してください。**このスキルでは必要な手順を挙げるだけで、内容を再掲しません。そのため、両者が食い違うことはありません。

ビジネス向けの文章

**メモはビジネス向けに書く、一つの文書です。**ビジネス側は GitHub にアクセスできないため、各項目は平易な言葉で単独でも理解できるようにし、プロジェクトマネージャー向けに最後に対象の課題への参照を付けます。エージェントによるコメントは含めません。ツールの状態、手順に関する注意事項、プロセスのメモは、会話でプロジェクトマネージャーに伝えるか、自分の TODO リストに記載します。

**プロジェクトマネージャーの口調で書きます。**メモとメールはプロジェクトマネージャー本人のものであり、その代わりに下書きします。開発者がプロジェクトマネージャー一人だけの場合、開発作業は「私」（「私は修正に取り組んでいます」）とし、「私たち」とはしません。

メモはメールのアジェンダでもあります。会議の2 営業日前（土日は除く）に送信します。たとえば火曜日のレビューなら金曜日です。返信で決定できることは事前に決め、会議ではメールで解決できなかったことだけを扱えるようにします。**プロジェクトマネージャーが送信する Outlook の下書きとして作成し、送信はしないでください。**会議の招待先に記載された参加者を宛先にし、メモの内容をそのまま使います。ただし、ビジネス側は開けないため GitHub 参照を削除し、「決定事項」を先頭に置いて、最後に会議リンクを記載します。

**メールを先に送ります。決定が必要な事項やトリアージは、バグも含め、発生したらすぐにメールでビジネス側に伝えます。issue-tracker の「メールでビジネス側に確認する」**を参照してください。開発者のみのトリアージは、メールでもメモでもビジネス側に伝えません。

**件数を除き、ビジネスの作業のみを扱います。メモの各項目はビジネスの作業とし、開発者の作業は「前回のサイクル」のボード全体の件数にのみ記載します。issue-tracker の「ビジネスとデリバリー」**を参照してください。business フィルター（トップレベルの課題とエピックの子課題）は出発点であり、答えそのものではありません。どの項目をビジネスの作業として扱うか提案し、プロジェクトマネージャーに項目ごとに判断してもらってください。 フィルターで見落としてはならないのは、質問です。ビジネス側からの入力待ちでブロックされている課題が通常の親課題のサブ課題である場合は、親課題の作業を説明し、子課題を参照してください。そうすれば、ブランチ B で回答を反映する課題が分かります。

**全体で約 60 行、表は最大 5 行を目安にします。**これは目標であり、厳密な上限ではありません。各セクションの分量は、次の配分に従って 30 分の会議に収まるようにします。メモには順序のみを示します。

セクション	分数
前回のサイクル	3
今後の日程	4
次回レビュー	1
メールで決定済み	1
決定事項	12
今回のサイクル	4
次のサイクルとバックログ	4
次のアクション	1

読む順に番号を付けます。「メールで決定済み」の項目は E1、E2…、「決定事項」は D1、D2…とします。アジェンダをメールで送るまでは、項目が移動するたびに番号を振り直し、読む順に連番となるようにします。**メール送信後は番号を固定します。**後から追加した項目には未使用の次の番号を付け、該当するセクションに置き、(アジェンダ送信後に追加) と記載します。

サイクルの役割

役割は、Cycle フィールドの configuration を会議日に照らして解決します。今日の日付や配列順、タイトルから判断することはありません。

役割	参照元
終了	会議の前日に終了するイテレーション。iterations または completedIterations 内のもの
現在	会議日に開始するイテレーション
次回	現在のイテレーションの後に開始する2つのイテレーション

イテレーションは、それを終了させる会議の前日に終了します。そのため、会議前に準備するメモでは、終了対象のサイクルはまだ進行中です。ブランチAでは会議日が必要で、日付がなければ停止します。ブランチBではメモのタイトルから会議日を取得します。会議がないブランチCでは、issue-tracker の説明に従い、今日の日付を基準に進行中のサイクルを解決します。役割を解決できない場合は、停止してその旨を伝えてください。割り当てを決して作り上げないでください。

メンバーシップの変更はすべて、確定済みの作業単位（トップレベルのイシューまたはエピックの子）に対し、Cycle フィールドを使って gh project item-edit で行います。子孫は継承するため、エピック自体には Cycle を設定しません。状態の変更にはすべて、issue-tracker の役割マップにある Status 値を使用します。このスキルではマイルストーン API は使用しません。

変更を加える各ステップの前に確認を取ってください。 変更案として、サイクルとステータスの値、クローズ対象、イシュー本文の編集、メモ本文、イテレーション設定の差分を提示し、明示的な承認を得てから書き込み、その後に書き込み結果を読み戻してください。書き込み直後の読み戻し結果が一致しない場合は、失敗ではなく未確認です。再実行するのではなく、少し待ってから再確認してください。

呼び出し方法

• A. 準備する — /cycle-review prepare for the 2026-08-28 meeting, next one is 2026-09-11
• B. メモを処理する — /cycle-review process the notes from discussion 2323
• C. 調整する — /cycle-review move clhbid/clhbid.com#2325 into the current cycle; defer clhbid/CLHbid-LiveAuction#922 to the next one

ブランチA — メモを準備する

ブランチAではメモのディスカッションを公開し、トラッカーへの書き込みは事務処理のステップ2～5でのみ行います。これらは最初に実行します。メモの内容に影響するため、草案を書き始める前に実行してください。会議によって決まるものではありません。調査結果と提案するすべての書き込みを、最初の grill-me ラウンドとしてプロジェクトマネージャーに提示してください。質問には番号を付け、それぞれに推奨案を添えてください。回答を承認として扱います。

1. Microsoft 365 を確認します。 Microsoft 365 コネクターを通じてメール検索と会議のカレンダー検索を実行し、機能を手がかりにツールを見つけます。どちらか一方でも失敗した場合は、そこで中止し、続行する前にコネクターを修正するようプロジェクトマネージャーに伝えます。Outlook は、メールで決定した事項、返信待ちの質問、会議の招待者と参加リンク、メールだけで話し合った課題の状況を確認する情報源です。
2. 次のサイクルを開始します。 現在のサイクルと、今後 2 つのサイクルが存在している必要があります。どちらかが欠けている場合は追加します。会議の日程が予定日から移動している場合、新しい日付が書き込まれるまで役割は解決されません。これは破壊的な設定の書き込みです。issue-tracker の手順に従い、保留中のほかの変更もすべて同じ書き込みにまとめます。2 回目の書き込みには、ボード全体の復元がもう一度必要になるためです。
3. 整理作業。 issue-tracker の stale closed items レシピを実行し、返された項目と、ボードにあるべきなのに載っていない課題を報告します。どちらも正常な状態では結果が空なので、結果が返ってきた場合は、その背後にある一括処理が機能していない兆候です。会議を待てない場合に限り、archiveProjectV2Item を使って手作業でアーカイブします。次に Epic candidates レシピを実行して各結果を確認し、見落とされたものや、未完了の子課題が明らかに 1 サイクルを超えるものを取り上げます。「今のサイクルとその次の数サイクル」にわたって確約された作業がその典型です。エピックへの変換は、会議前にプロジェクトマネージャーが判断します。Decision にしてはいけません。 合意されたものごとに、タイプを PATCH し、Cycle をクリアし、確約する子課題に Cycle を設定し、Status を段階に沿って進めます。issue-tracker の Epics を参照してください。Epics ready to close レシピの結果も取り上げます。エピックを Decisions に含めるのは、ビジネス上の判断が必要な場合に限ります。これらはすべて議事録に含めません。
4. マージ済みで、まだオープン。 issue-tracker の merged pull request, open issue レシピを実行します。GitHub ではこれらをクローズしていません。レシピに理由が示されるため、どの行も、サイクルのレポートで一度も実績として計上されていない完了済み作業です。各行は、2 つのいずれかの形で処理します。プルリクエストを記載して completed としてクローズするか、プルリクエストが意図的に一部のみの対応だったため、引き続き対応が必要と判断します。ステップ 3 と同じ理由で、これも議事録に含めません。
5. サイクル外で作業した項目の遡及登録。 終了するサイクルの期間を対象に、issue-tracker の worked off-cycle レシピを実行し、ビジネス上の成果に関わる項目（トップレベルの課題とエピックの子課題）を対象にします。通常の親課題のサブ課題には書き込みは不要です。親のサイクルを引き継ぐためです。これは記録上の整理であり、トリアージではありません。会議での決定事項はありません。
   • クローズ済みの作業は終了するサイクルの実績とし、Cycle を設定します。前サイクルのハイライト候補にもなります。
   • 終了するサイクル中に更新された In progress の作業は、そのサイクルに確約されないまま着手されていました。現在のサイクルの実績にします。未完了の作業は、それを完了するサイクルに属するためです。今サイクルの項目として記載します。
   • 休止中の作業（同じレシピの dormant バリアントで検出される、終了するサイクルの開始前から更新されていない作業）には、書き込みません。ステータスに suspect のフラグを付けて取り上げます。自動的に実績として計上してはならず、Backlog に戻してもいけません。
6. ボードを確認します。 プロジェクト項目、Cycle の設定、前サイクルの議事録での話し合い、前回のレビュー以降の Outlook を確認します。
7. ドラフトを開きます。 ドキュメントコネクターを通じて Claude Doc を作成し、議事録のドラフトを直接そこに作成します。プロジェクトマネージャーはそこでコメントし、編集します。書き込みの前には必ず編集内容を読み、その内容を維持します。 ドキュメントコネクターがない場合は、ローカルの Markdown ファイルでドラフトを作成し、その旨を伝えます。
8. 前サイクルの要約を、終了するサイクルのテーマと日付に沿って作成します。
   • 目標の一語での判定：達成、一部達成、未達成。
   • ボード全体の件数：新規、クローズ済み、オープンの各件数と、前回のレビューからの推移。さらに、新規課題のうち開発者の作業が何件かを示し、一覧にしなくてもビジネスがその存在を把握できるようにします。
   • 最大 5 件のハイライト。ビジネスが重視するエピックの進捗と、期間中にクローズしたエピックを含めます。
   • 持ち越し項目。それぞれの理由は、終了したプルリクエスト、コメント、サブ課題の状態など、直接確認できる証拠だけから記載します。理由を推測せず、推測が必要なら記載しません。前回の議事録との項目の差分を確認し、持ち越しが黙って反映されるのではなく、分かるようにします。
9. 今後の日程を、終了するサイクルの次に来るサイクルの末日までの Date | What テーブルとして作成します。日付ごとに 1 行とし、セール、コンベンションなどのビジネス関連の日付、個別の行に記載するリリース案、休暇を含めます。日付は目立つように太字にし、各行は種類（Sale:、Release (proposed):）で始めます。計画に影響する情報だけを記載します。前回の議事録に記載されていて、この期間内にある日付はすべて引き継ぎます。 セール日とリリース日のルールは、ホームページではなく clhbid/CLHbid-LiveAuction の RUNBOOK にある Checking the Sale Schedule と Choosing a Release Date に従います。ホームページには今後数件のセールしか掲載されていません。欠けている情報がないか参加者に尋ねてセクションを締めくくり、さらに次のように尋ねます。リリースを避けるべき、リスクの高いセールはありますか？
10. 次回レビューを作成します。日付、時刻、場所は、呼び出し時に指定された情報を使うか、提案します。現在のサイクルの終了時期を定め、そこにどれだけの作業を含められるかが決まるため、Decisions より前に置きます。セール当日は避けます。
11. メールで決定した事項を作成します。前回のレビュー以降にメールで決まった事項を記録として残す、簡潔な ID | Description | Decision テーブルです。Outlook と、それ以降に課題に記録された回答から見つけ、一覧をプロジェクトマネージャーと確認します。
12. Decisionsを作成します。ID | Description | Recommendation テーブルです。引き続き Waiting on input のすべての課題、返信待ちの Outlook の質問、その他、実質的な話し合いが必要な事項（プロジェクトマネージャーがトリアージして意見を求めるものとして持ち込んだ古い作業など）を、それぞれ 1 行ずつ記載します。件数にまとめてはいけません。説明は平易な言葉で書いたタイトルを太字で冒頭に置き、根拠を添えます。推奨案には、チームがそのまま受け入れられる内容を記載します。 質問はすでにされていなければなりません — イシューへの通常のコメントでも、メールでも十分です。どちらにも質問がない場合はエラーです。誰にも質問されていないため、タイトルから質問を推測して作り上げるのではなく、その旨を伝えてください。
13. 今サイクルのドラフト — 今サイクルのテーマと日付、その理由を1文で示し、主な作業を箇条書きにします。バックフィルですでに計上したものも引き継ぎます。始めたことは最後までやり遂げます。すでに In progress の作業を優先し、それが残っている間は新しい作業をサイクルに受け入れないでください。残作業がどれほどあるかをプロジェクトマネージャーに伝えます。
14. 次のサイクルとバックログのドラフト — 最初の次サイクルのテーマと主な作業を示し、その後に、サイクルを意図的に割り当てていないビジネス項目と、チームから問い合わせがあったもののサイクルがない作業を記載します。2番目の次サイクルに確約した作業も、そのサイクル名の下に記載します。バックログに残す前に、そもそも取り組む価値があるかを確認してください。価値がない場合は、計画対象外としてクローズすることを推奨し、再検討すべき場合はリマインダーを設定してください。issue-tracker の作業の延期を参照してください。
15. 次のアクションのドラフトを最後に置きます。項目はありますが空欄のままにし、オーナーを先頭にする形式を示します。
16. 公開前に確認し、不足を注記するのではなく、ドラフトを修正します。ドラフトで浮かび上がった不足や判断事項は、grill-me を使って一度に1ラウンドずつ解決します。
    • 前回のドラフト以降にクローズしたエピックと項目がサイクルに計上され、ハイライトに反映されている。
    • チームから問い合わせがあった作業にサイクルが割り当てられているか、バックログに記載されている。
    • 販売日は RUNBOOK の情報源に基づいている。
    • すべての項目が、GitHubを見なくても単独で意味が通じる。
    • D番号とE番号は、アジェンダ送信後に追加された項目を除き、読み進める順に並んでいる。
17. ライブボードと照合します。 各サイクルのセクションは、項目ごとにボードの実際の内容と一致していなければなりません。
18. 公開します。 プロジェクトマネージャーがノートを最終版としたら、ドキュメントのテキストからディスカッションを作成するか、今サイクルのノートがすでにある場合は更新し、その後メールの下書きを作成します。プロジェクトマネージャーから依頼されたら、ドキュメントを削除します。ブランチAは何度でも再実行できます。ボードが変更されるたびに再実行すると、同じディスカッションが改訂されます。更新の前には必ずライブ本文を読み、その内容を反映してください。プロジェクトマネージャーもGitHub上でノートを編集します。

ノート（#the-notes）では、決定列を設けず、次のアクションを空欄にした状態の形式を確認できます。どちらも戻ってきた段階で記入します。

ブランチB — 返送されたノートを処理する

ディスカッション番号を使って、APIから公開済みの本文とプロジェクトマネージャーのコメントを読み込みます。

issue-tracker の参照情報に従って参照を解決します。コメントでは番号のみや別名が使われることがあり、#<number> のみの場合は、ディスカッションをホストするリポジトリ clhbid/clhbid.com の項目として解決します。

1. 前回のサイクル — 議論が記録であり、バックフィルですでにブランチ A のすべての Cycle が設定されています。書き込む必要はありません。

2. 棚卸し。 終了サイクルのままになっている未完了項目があってはなりません（ボード上で cycle:@previous is:open）。取り残された項目はすべて gh project item-edit で再割り当てします。通常は現在のサイクルに割り当てるか、作業が取り下げられた場合はフィールドをクリアします。取り残された項目は、その後、サイクルを対象とするすべてのビューで見えなくなります。

3. 今後の日付 — 参考情報であり、トラッカーへの書き込みはありません。次回のメモに引き継ぎます。

4. 次回のレビュー — 合意した日付を現在のサイクルの終了日として設定します。Cycle フィールドの設定に反映してください。この書き込みは破壊的です — issue-tracker の手順に従ってください。通常、ブランチ A ですでにこのサイクルの書き込みを1回済ませているため、合意した日付もそのときに設定されているはずです。その後、レビューの2営業日前に、参加者なしの非公開の1時間のサイクルレビュー準備カレンダーイベントを作成します。

5. メールで決定済み — 各回答が届いた時点で書き込みは済んでいます。各課題に回答が反映されていることを確認し、反映されていないものがあれば、Outlook から決定事項として記録します。

6. 決定事項 — 回答済みの質問ごとに、課題の2か所に記録します。質問を引用したコメントを追加し、> *Recorded from the <date> planning meeting.* を先頭に付けます。メールでの決定の場合は email とします。また、回答を課題本文に組み込みます。これにより、初めて作業を引き継ぐ人が仕様全体を把握できます。コメントは監査記録であり、本文は仕様です。既存の記述は決して削除しないでください。会議で解決できなかった項目は、Waiting on input を含め、そのまま変更しません。

   その後、課題にあるすべての質問に回答が得られた場合に限り、Waiting on input から移動します。更新後の本文が、エージェントが何の予備知識もなく作業できる完全なブリーフになっている場合に限り Ready for Agent にします。判断、外部アクセス、設計上の決定、または手動テストが必要な場合は Ready for Human にします。回答済みでも仕様が不十分な場合は Backlog にします。回答によって新たな質問が生じた場合、ブロックは解除されていません。同じ形式で新しい質問をコメントとして投稿し、課題は Waiting on input のままにします。

   作業を実施または延期する決定では、Cycle を設定するか、issue-tracker の作業の延期に従います。エピックの終了が合意された場合は gh issue close --reason completed を実行します。エピックを継続する場合は、残作業を新しい子課題として登録し、進捗が完了と表示されないようにします。

7. 今サイクルおよび次サイクル以降とバックログ — ブランチ A のバックフィルですでに計上された項目を除き、確定した作業単位ごとに Cycle を設定します。いずれかのサイクルに確定したエピックの最初の子課題があれば、エピックをまだ In progress にしていない場合はその状態にします。実施する価値がないと合意したバックログ作業は --reason "not planned" でクローズし、再開すべき場合はリマインダーコメントを追加します。それ以外は Backlog のままにし、Cycle は設定しません。

8. 次のアクション — 担当者ではなく、行に記載された内容に基づいて判断します。プロジェクトマネージャー自身の行には、委任したトラッカー作業と本人が対応するフォローアップの両方が含まれるため、担当者を見ても分かりません。サイクルやステータスの変更、クローズ、新規課題の下書きといったトラッカーのアクションを実行します。個人間のフォローアップには手を付けません。

9. ボード上のどの項目にも一致しない、メモに記載された作業について課題の下書きを作成します。カテゴリタイプのみを指定し、状態は設定せず、本文にはメモの内容を反映します。新たに受け付けた作業なので、テンプレートから登録する項目と同様に Backlog に入れます。

10. 決定事項を反映して議論を更新します。決定事項の表に決定列を追加し、次のアクションを記入します。その後、メモの公開後にクローズされた課題がないか再確認します。会議当日の朝にマージされた項目は締め切り後に反映されるため、再確認しないと誤ったサイクルに計上されます。

ブランチ C — 調整

Cycle に対して gh project item-edit を実行して所属を変更するか、作業が取り下げられた場合は所属をクリアします。その後、次回のメモの議論に変更を記録します。

議事メモ

以下は完成済みの議事メモです。ブランチ B が受け取る入力であり、Decision 列と Next Actions が記入されています。また、ブランチ A が作成する際の目標でもあります。同じ見出し、 同じ順序、同じプロンプトで、それらの記入はありません。この形式を再現してください。

文体に注目してください。結果はビジネス向けの表現で記述し、Next Actions では担当者を最初に記載し、 各項目の末尾には必ず参照を付けます。フィールド名や gh の構文は一切登場しません。チームはこれを読み、 ブランチ B は、説明されている内容からトラッカーのアクションを認識します。

説明用の例です。組織、人物、リポジトリ、課題番号、タイトルは架空のものです。ここに実際の作業はありません。

# Cycle Review — 18 Mar 2026

## Last Cycle: Faster checkout (4 Mar → 17 Mar)

**Met.** 41 issues opened and 47 closed, leaving 212 open, down from 218 at the last review. 29 of
the new issues were behind-the-scenes developer work.

- Checkout finishes in under two seconds, even on sale days. (acme/shop#412)
- Customers can save a card for next time. (acme/shop#418)
- Gift cards are 5 of 8 steps done; balance lookup went live on 12 Mar. (acme/shop#400)
- Refund rounding is fixed, after finance flagged it mid-cycle. (acme/shop#430)

**Slipped:** moving saved cards to the new payment provider. The provider limits how fast cards can
be imported, so it runs in batches this cycle. (acme/shop#424)

## Upcoming Dates

| Date                | What                                |
| ------------------- | ----------------------------------- |
| **Sat 21 Mar**      | Sale: Spring sale                   |
| **Tue 24 Mar**      | Release (proposed): better search   |
| **Tue 24 – 26 Mar** | Jordan out                          |
| **Sat 28 Mar**      | Sale: Clearance sale                |
| **Tue 7 Apr**       | Trade show; Priya and Sam attending |
| **Thu 9 Apr**       | Release (proposed): gift cards      |
| **Sat 11 Apr**      | Sale: Easter sale                   |

Anything missing? Any high-risk sales we should avoid releasing around?

## Next Review

**Wed 1 Apr 2026, 10:00 AM MT**, by video call — link in the calendar invite.

## Decided by Email

| ID  | Description                                                              | Decision         |
| --- | ------------------------------------------------------------------------ | ---------------- |
| E1  | **Delivery estimates on product pages.** (acme/shop#441)                 | Yes, this cycle  |
| E2  | **Coupons that expire mid-checkout show an error.** (acme/shop#447)      | Fix after search |

## Decisions

| ID  | Description | Recommendation | Decision |
| --- | ----------- | -------------- | -------- |
| D1  | **Who sees the new prices first?** Switching everyone at once risks confusing regulars mid-order; a staged rollout lets us watch support calls. (acme/shop#433) | Returning customers first, everyone two weeks later. | Agreed. |
| D2  | **Pay for a hosted search service?** Our search struggles on sale days, but the service costs about $400 a month and this cycle's work may fix it. (acme/api#96) | Decide after this cycle, with real sale-day numbers. | Agreed; back as a Decision on 1 Apr. |
| D3  | **Close the old admin project?** Everything is done except one old web address still pointing at the retired server. (acme/shop#380) | Close it once the address is removed this cycle. | Agreed. |

## This Cycle: Search that finds things (18 Mar → 31 Mar)

Empty search results are our biggest source of complaints, and customers give up on sale days.

- Finish moving saved cards to the new provider. (acme/shop#424)
- Search copes with hyphens and misspellings. (acme/shop#437)
- Delivery estimates on product pages. (acme/shop#441)

## Cycle After & Backlog

**Gift cards (1 Apr → 14 Apr):** finish gift cards and launch them before the Easter sale.
(acme/shop#400)

**Backlog:**

- Loyalty points, asked about by Priya — waits until gift cards have launched. (acme/shop#450)
- Dark mode for account pages — nobody has asked since it was filed; close it, and reopen if that
  changes. (acme/shop#444)

## Next Actions

- **SAM:** Remove the old web address, then close the old admin project.
- **SAM:** Close dark mode as not planned.
- **JORDAN:** Collect sale-day search numbers for the hosted-search decision on 1 Apr.

議論の編集

議事メモは Meetings カテゴリーに記載します。

組織全体のすべての議論は、github.com/orgs/clhbid/discussions の表示にかかわらず、clhbid/clhbid.com リポジトリでホストされます。 API が議論にアクセスする際に使用するのはこのリポジトリです。そのため、議事メモ内の単独の #<number> は clhbid.com を対象として解決されます。

gh には議論用のコマンドがないため、書き込みには gh api graphql の createDiscussion と updateDiscussion を、本文とコメントの読み取りには repository { discussion(number:) } を使用します。

スキルの反復改善

出力ではなく、スキルを修正してください。 ドキュメント内でも GitHub 上でも、下書きを手作業で編集する必要が生じた場合、その編集はバグ報告です。議事メモを手作業で修正するのではなく、スキルを変更して再実行してください。