発端: 「LINEのエラーを何回直しても毎日届く」。実測したら、届いていた26件のうち本物の失敗は2件で、残り24件は判定の癖(設計どおりの休みを異常扱い/報告文の語彙を失敗扱い/週次の赤を次回走行まで毎朝全文再送)でした。判定側は今朝 main に反映済み(今日10:30 BLADE/10:40 DELL から効きます)。
このカルテで決めてほしいこと: ①使っていないスキル29本を退役させてよいか ②「同じ赤が続くだけの日」に LINE を鳴らすか。あとは私が決めた設計の追認です。
Otakeさんにしか答えが無いものだけ。ここをお願いします。
使っていないスキル 29本を `_archived/` へ退役させる(一括・可逆)要判断
毎セッションの一覧が 128→99本に軽くなる/可逆判定基準: 4月末以降に一度も明示起動が無く、定期実行・フック・他スキルからの参照も無く、8月以降の更新も無いもの。
退役候補 29本(4,222行):
・agents-sdk(221行・最終更新 07-31)
・booking-analytics(95行・最終更新 07-27)
・bw-label(96行・最終更新 07-09)
・cloudflare-one(176行・最終更新 07-31)
・cloudflare-one-migrations(110行・最終更新 07-31)
・diy-build(79行・最終更新 07-27)
・evangelion-preview-maker(234行・最終更新 07-05)
・excel-flow(131行・最終更新 06-20)
・floor-plan-to-render(312行・最終更新 07-10)
・invoice(64行・最終更新 06-20)
・lodging-simulation(577行・最終更新 03-29)
・morning-briefing(63行・最終更新 07-05)
・nlm-rebuild(273行・最終更新 07-09)
・overtime-application(50行・最終更新 06-20)
・owner-report-master(77行・最終更新 03-29)
・owner-report-send(92行・最終更新 07-31)
・parallel-enrich(100行・最終更新 06-20)
・pop-card(84行・最終更新 06-22)
・quick-fix(56行・最終更新 07-23)
・ringi-send(87行・最終更新 07-09)
・sandbox-sdk(177行・最終更新 07-31)
・turnstile-spin(192行・最終更新 07-31)
・update-file(74行・最終更新 07-09)
・video-analyze(93行・最終更新 03-29)
・video-hero(149行・最終更新 07-20)
・web-perf(201行・最終更新 07-31)
・webgl-snap(99行・最終更新 07-05)
・weekly-review(133行・最終更新 06-21)
・workers-best-practices(127行・最終更新 07-31)
残す側の内訳: 実際に使っている 31本/無人経路(routine・hook・setup)が使う 20本/参照はあるが起動記録が無い 20本/8月以降に作って未使用 16本/たまに使う 12本。
⚠ 記録は DELL の明示起動のみで、BLADE 側と説明文の自動マッチで起動した分は載っていません。だから「削除」ではなく `_archived/`(前例: daily-organizer・floor-plan)への移動にしています。戻すのはフォルダを戻すだけ。
根拠: ~/.claude/skill_invocations.jsonl(2026-04-25〜09-04・DELL の明示起動 1,364件)+ routine / hook / setup_scheduled_tasks.ps1 / 他SKILL.md からの参照 grep(2026-09-05 実測)
推奨 ① 29本まとめて退役 — ②は名指しが無ければ①と同じ。③は一覧が肥え続け、説明文の自動マッチの精度も落ちる
無回答なら 無回答なら ①で退役します(`_archived/<name>_retired_2026-09-05`)
「継続の赤だけ」の日(新規ゼロ)に、日次チェックの LINE を鳴らすか要判断
毎朝の LINE 1通の有無今朝の実装では 新規=全文/継続=1行(何日目・初出)/解消=名前だけ に分けました。週次タスクの赤は次回走行まで最長7日残るので、新規ゼロの日が続きます。
選択肢の違い: ①は毎日2〜3行の短文が来る(無音=健全が保てる)。②は新規と解消の日だけ来る(無音が「健全」と「既知の赤が続いている」の2通りになるが、継続分は `daily_alerts_<host>.json` と Black の週報に残る)。
根拠: scripts/health_check/weekly_health.py run_daily(2026-09-05 a09bbb76f)/data/health_check/daily_alerts_*.json の 08-22〜09-04 履歴(git)
推奨 ② 鳴らさない(新規・解消の日だけ) — ①は「毎日同じものが届く」が形を変えて残る。③は仕組みを1つ増やす割に②+週報で同じことが既に読める
無回答なら 無回答なら ②にします(新規・解消の日だけ鳴る)
自由記述要判断
私が決めました。違うものだけ触ってください(無操作=この通り進めます)。
明示の `RESULT: noop` と語彙推定の `suspect` は、即時 LINE をやめて日次の束へ追認
推奨 ① この線でいい — ②は 14日間で 6/6 が誤報だった安全網を残すことになる。本物の失敗は failed/StopFailure/途中死検知の3経路で別に届く
無回答なら この線で運用します(反映済み)
日次チェックの赤を「新規/継続/解消」に分け、継続は1行に畳む追認
推奨 ① この線でいい — ②が今までの形で、本物の新しい赤が同じ顔で埋もれていた
無回答なら この線で運用します(反映済み・初日は全件が新規扱い)
review-monitor-daily の「裏で継続中」partial(2件)は、routine の手順側を直す追認
推奨 ① 次に直す — ②は本物の partial(南房総KV 7009 等)と待機が同じ顔で並ぶ状態が続く
無回答なら 次の運用セッションで直します
「参照はあるが起動記録が無い」20本と「無人経路が使う」20本は残す追認
無人経路が使う 20本(routine・hook・setup から参照):
ai-stack-watch / airhost-availability-sync / booking-sync / brand-poster / composite / document / dreaming / equipment-curation / facility-hub / facility-tank / line-post / markey / ops-drive / order-import-amazon / pricing-reconciler / pricing-strategist / pricing-uploader / review-monitor / update-case-sheet / wrangler
参照はあるが起動記録なし 20本(他スキル2本以上 or スクリプト3本以上から参照):
cc-inbox / cloudflare / daily-closing / diagram-gen / durable-objects / enhance-visuals / gantt / health-check / infographic-embed / lodging-market-research / notion-memo / reasoning / site-clone / tabs / vibe-architect / visual-gen / visual-journalism / weekly-report / wip / zagumi
起動記録が無いのは、説明文の自動マッチや BLADE 側で使われている可能性があるため。
推奨 ① 残す — 参照を切らずに退役させると、無人経路が黙って壊れる(同じ轍)
無回答なら 残します
8月以降に作って未使用の 16本は、10月初めに再判定追認
cloudflare-email-service / concept-map / excel-presentation / facility-photo-consolidate / facility-photo-prep / floor-plan-layered / kakemono / mb / meeting-log-to-sot / ops-drive-tidy / photo-batch / photo-upgrade / session-resume / tidy-folders / visual-double-check / web-inbox
作って1か月未満のものは「使う機会がまだ来ていない」と「要らなかった」を区別できないので、今回は判定しない。
推奨 ① 10月に再判定 — 今判定すると、季節業務(月次レポート等)向けを早合点で消す
無回答なら 10月初めの棚卸しで再判定します
フック 46本は手を付けない(速度上の問題なし)追認
UserPromptSubmit 15本を実測: 1本 0.15〜0.30秒、合計 2.8秒(並列実行なので体感はこれ以下)。PreToolUse 16 / PostToolUse 10 / Stop 3 / StopFailure 1 / SessionStart 1。無効化済み 2本(.disabled)は放置で害なし。
推奨 ① 手を付けない — 削っても体感は変わらず、規律の網だけ減る
無回答なら 手を付けません
実装・反映済みの事後報告。読むだけで大丈夫です。
判定側の修正 3点を main に反映(今日の 10:30 BLADE/10:40 DELL から効く)済
A1・A2 と「明示 noop を赤に数えない」。実データで dry-run 済み(DELL: 新規1/継続0/解消0)。14日間の即時 LINE を同じ規則で数え直すと 26件→11件で、残る11件は failed 2・partial 8・APIエラー 1。
推奨 ① これでいい
「毎日直している」の実態: 監視の器を作り込む途中の判定側の穴を1日1個ずつ塞いでいた済
8/16〜9/5 の21日間で、監視・フック・定期実行まわりの修正コミットが 0件だった日は3日だけ(最多 20件/日)。本物の失敗は14日間で 2件(booking.com の CAPTCHA、Airbnb の接続アカウント違い)。器そのものは 9/3 でほぼ出来ており、今日の修正は「鳴らし方」の側。
推奨 ① 読んだ
回答テキスト(自動生成・差分だけ出ます)
下の枠内で Ctrl+A → Ctrl+C でコピー