update-backlog-comments

書き方の正本は /format-post です。 量・流れ・表と図への畳み方・1文の長さは、あちらの references/writing.md に従う。ここには写さない。

このスキルが持つのは、課題管理ツールに固有の事情です。

事情	何が変わるか
書式のフックが走らない	bee や API で投稿するので、`gh` のコマンドを見る検査が効かない。自分で測る
使える操作が限られる	更新できるものと、できないものがある（下記）
経緯のコメントが要るかを判定する	閉じる条件の外にある成果物にだけ要る
長さを測る前に引用と URL を除く	課題票の文面をそのまま引くので、素で測ると誤判定する

次の3つは常駐のルールが既に持っています。 ここでは参照するだけで、中身を写さない。

主題	持っている場所
Alert が使えない投稿先での生成者表示の形	`github_note_generated_by_claude.md`
使う記号が `[fyi]` と `[memo]` の2つだけであること	`github_writing.md`
編集するか別コメントで足すかの判定軸	`keep_records_current.md`

判定軸はあちら、痕跡の見方はこちらが持ちます。課題管理ツールにはスレッドが無いので、GitHub の返信関係では判定できません（手順5）。

進め方

1. 自分のコメントを集める

投稿者で絞り、本文の無いものを外す。 状態の変更（担当者・ステータス）もコメントとして返るが、本文が空なので点検の対象にならない。

本文が null や空のものを外す
自分が投稿したものだけに絞る（他の人のコメントは読むだけ）
他人が起票した課題の本文と件名は書き換えない（ verify_before_asserting.md ）

測るためにファイルへ落とす。 応答のまま読むと、次の検査が目視になる。

2. 過不足を見る

判定は「閉じる条件に入るか」。 課題に紐づく成果物を列挙し、閉じる条件の外にあるものへ経緯が残っているかを見る（判定は ~/.claude/references/karma_commit_style.md の「PR に番号を付けるか」）。

	経緯のコメント
受入基準を直接満たすもの	要らない。課題を読めば何をするか分かるので、書くと量が増えるだけ
閉じる条件の外にあるもの	要る。課題から開いた人には、なぜ並んでいるのか読めない
調査の結果、起きないと分かったもの	要る。省くと、読み手がその記述を探しに行く

過剰の判定は「課題の記録か、作業の段取りか」。 段取り（どれをどの順で入れるか・壊れたときの直し方）は、作業が終われば読む人がいない。恒久的に要る知見は規約やドキュメントへ移し、課題側は消す。

進捗そのものは、ツールが持っていることがある。 紐づいた成果物の状態や課題のステータスで読めるなら、コメントで二重に持たない。

3. 実態とのずれを見る

記述ごとに確かめ方が違う。 1つの検査で全部は見られないので、1件ずつ手を選ぶ。

記述の種類	確かめ方
「〜で修正済み」	その成果物の状態を引く
「〜と〜が揃っている」「N件」	両方を数える
「〜という制約がある」	スキーマ・型・遷移の定義
「〜の設定が無い」	設定ファイルを走査する
「原因は〜だった」	直した差分を読む

時点を織り込んだ記述は対象から外す。 [memo] のように日時付きのスナップショットとして書いたものは、古くなって当然なので直さない。

背景の1文がいちばん古くなりやすい。 「〜の仕組みが無いので〜になる」のような環境の事実は、誰かが変えても通知が来ない。確かめなければ気づけない。

4. 読みやすさを測る

引用と URL を除いてから測る。 課題票の文面をそのまま引く場面が多いので、素で測ると誤判定する。

実測では、1つの課題に残した7件のコメント（散文105行）を通して、素だと11行が70字超と出て、引用と URL を除くと4行だった。

除くもの。

URL
成果物への参照（ OWNER/REPO#123 の形）
鉤括弧の引用
強調とインラインコードの記号

そのうえで次を数える。どの基準の出どころも行ごとに書く。

観点	直す目安
1文の長さ	70文字以上か、読点が3つ以上の文を拾い、1行へ複数の事柄を詰めた形だけ直す（ `/format-post` の `references/writing.md` の「投稿前に拾うもの」）
1段落の強調	3つ以上なら減らす（ `/japanese-tech-writing` の「演出の抑制」は1節に1〜2箇所まで）
散文の量	表へ畳めるものが散文のままになっていないか

生成者表示の文言が揃っているかも見る。 固定された定型文なので、揺れていたら直す（文言は github_note_generated_by_claude.md が持つ）。

5. 直し方を決める

判定は「読まれた痕跡があるか」（ keep_records_current.md の「まだ誰も読んでいない投稿は、書き換える」）。

スレッドが無いので、GitHub の返信関係では判定できない。 代わりに次を見る。

痕跡	見るもの
反応が付いている	そのコメントのスター・いいね
後から他の人が書き込んでいる	投稿より後のコメントの有無
時間が経っている	課題を見ている人がいる状態で日が空いた

痕跡が無ければ書き換える。 あれば前を残して別コメントで足す。

事実の記述は、読まれていても直してよい。 古い記述に価値は無い。残すのは判断とその根拠のほう。

6. 直す

直した本文は .md に書き、/japanese-tech-writing と /yomiyasu:yomiyasu を通してから投稿する（ no_ai_style_writing.md ）。通していないと投稿の直前でフックに止められる。

更新できるものと、できないものがある。 着手する前に、その場で使える操作を確かめる。

操作	確かめ方
コメントの更新	使える道具に更新用のものがあるか
コメントの削除	同上。取り消せないので、消す前に中身を控える
文書（ドキュメント）の更新	更新の口が無いことがある。その場合は画面で複製してもらう

無いものを「作れないか」と考える前に、提供元の仕様を見る。 道具に無いのか、提供元の API に無いのかで、打てる手が変わる。

7. 報告

3つの観点それぞれについて、確かめた件数と結果を並べる。 「過不足なし」だけでは何を見たのかが伝わらない。

過不足: 列挙した成果物の数と、経緯が要るもの / あるものの内訳
実態とのずれ: 記述ごとの確かめ方と結果を表で
読みやすさ: 測った数値（長い行・強調）

出力の目安

3つの観点を表で1つずつ。確かめ方の列を入れる（何をどう見たかが伝わる）
直した場合は、何をどう直したかを1行ずつ
直さないと判断したものは、理由を1行

やってはいけないこと

/format-post の中身を写すこと。量・流れ・畳み方はあちらが正本で、写すと片方だけ古くなる
投稿先の検査が走ると前提すること。bee や API ではフックが効かないので、自分で測る
1文の長さを、引用と URL を含んだまま測ること。長さの責任が書き手に無いものまで拾う
受入基準を直接満たす成果物にまで、経緯のコメントを求めること。量が増えるだけ
作業の段取りを課題へ残し続けること。恒久的に要る知見は規約やドキュメントへ移す
進捗を、ツールが既に持っているのに書くこと
読まれた痕跡を確かめずに書き換えること。判断を消すと、訂正した事実ごと消える
時点を織り込んだ記述を「古い」として直すこと。日時付きのスナップショットは残す
削除を、中身を控えずに実行すること。取り消せない
他人が起票した課題の本文・件名を書き換えること。訂正はコメントで残す

例外

ユーザーが観点を絞った場合（「読みやすさだけ見て」等）はそれに従う
課題のコメントを投稿してよいか自体は、依頼の範囲で決まる

update-backlog-comments

SKILL.mdhome/.claude/skills/update-backlog-comments/SKILL.md

進め方