v0.20.0: 配布物からテストを外す

消費側の呼び出しが壊れる変更

なし。skill 名、登録経路、command と agent の名前と引数の形は v0.19.0 と同じ。

配布物の変更

• 削除: パッケージの中に置いていたテスト 13 本 (PR 99)。展開先へ届かなくなる。テストは配布元の scripts/package-tests/ へ移した。Python の 11 本は配布元の検査が引き続き走らせる (.mjs の 2 本に実行の経路が無いのは移す前と同じ)
  • plugins/dev-workflow/skills/commit-and-pr-message/scripts/test_check_leak_guard_denylist.py
  • plugins/dev-workflow/skills/commit-and-pr-message/scripts/test_check_outgoing_text.py
  • plugins/dev-workflow/skills/in-repo-issue/scripts/test_issue_id.py
  • plugins/security-blue-red-team/schemas/tests/cleanup-queue.schema.test.mjs (schemas/tests/ ごと無くなる)
  • plugins/web-monkey-qa/schemas/tests/findings.schema.test.mjs (schemas/tests/ ごと無くなる)
  • skills/devops/macos-vm-verification/test_macvm.py
  • skills/devops/windows-vm-verification/test_winvm.py
  • skills/tooling/jev-lint-curated/scripts/ の test_jevlint.py、test_jevlint_compat.py、test_jevlint_fs.py、test_jevlint_host.py、test_jevlint_result.py、test_jevlint_tree.py
• 変更: plugins/dev-workflow/skills/commit-and-pr-message/scripts/check-leak-guard-denylist.py の docstring。テストの所在を、配布元の scripts/package-tests/ (配布物には入らない) と書き直した。挙動は変わらない

同伴

• 配布元の scripts/check-package-shape.py を check() へ関数化し、規約 8 を足した。パッケージの中にテストのファイルがあると違反にする。テストとして scripts/test_check_package_shape.py を新設した。どちらも配布物ではない
• 配布元の scripts/run-python-tests.py の docstring、manifest、テストの置き場を前提にしていた記述を直した
• ISSUE-76 の更新と計画の追加。ISSUE-34、ISSUE-55、ISSUE-68 への追記

commit range

v0.19.0..2673c03

v0.19.0: in-repo-issue にタスクを消化せずに閉じる経路を足す

消費側の呼び出しが壊れる変更

なし。

配布物の変更

• 変更: plugins/dev-workflow/skills/in-repo-issue/SKILL.md (PR 97、PR 98)
  • Phase G「タスクを消化せずに閉じる」を足した。見送る、前提が消えた、別の場所で解決した、別の Issue へ移す、のどれでも同じ 1 本の経路を通る。手順が変わるのは「移した先があるか」と「親子リンクがあるか」の 2 点だけで、最後は D.1〜D.5 を通す
  • 閉じた理由の節は、H1 の直後に置く ## クローズ理由 (<YYYY-MM-DD>) に決めた。未チェックの箱は未チェックのまま残す
  • A.6「子を外す」(A.5 の逆) を足した。手順は 4 つ:
    • 両側のリンクを同じコミットで外す
    • 空になった children はキーごと消す
    • 親の ## タスク から外した子の行を消す
    • 親の完了の定義からその子を外したかを書く
  • E.4 に指示を足した。Phase G で閉じた子がいる親を Phase E で閉じるときは、その子の識別子と、親の完了の定義から外したかを親の本文に書く
  • C.3 で自動 close の対象外になった Issue は、Phase G で閉じる。F.0 (reopen) には、Phase G で閉じた Issue を戻すときの扱いを足した
  • コミット文言の表に A.6 と G の行を足した。E 行は「完了に伴う伝播」から「クローズに伴う伝播」へ直した (G で閉じた子から伝播する場合があるため)
  • D.1 / D.4 は、status: open だけを前提にした書き方をやめた。in_progress から閉じる経路があるため
  • テンプレートは変えていない。既に closed/ にある Issue を新しい規約へ揃え直す必要は無い

同伴

• このリポジトリの scripts/check-issue-closure.py に不変条件 D を足した。タスクを消化しないまま closed/ に居る Issue が理由の節を持たなければ違反にする。配布物ではない
• ISSUE-95 の起票・クローズ・reopen・再クローズと、ISSUE-45 へのタスクの追記

commit range

v0.18.0..2ec9a19

v0.18.0: cross-repo-learnings skill を足す

消費側の呼び出しが壊れる変更

なし。

配布物の変更

• 追加: skills/meta/cross-repo-learnings (PR 96)。別のリポジトリで作業したセッションの知見を、集約先へ送るまとめのファイルに書く skill。まとめの置き場を告げ、セッションの終わりに集約先へ届けるのは対になる hook の責務で、この skill には同梱しない。hook が無い環境でも使え、その場合は書いたファイルの場所をユーザーに伝える
• 変更: plugins/security-blue-red-team/SKILL.md と plugins/web-monkey-qa/SKILL.md の文面の手直し (PR 95)。呼び出しは変わらない

同伴

• README の再生成と、生成元の散文の手直し (PR 95、PR 96)
• ISSUE-94 の起票とクローズ

commit range

v0.17.0..c41b2fe

v0.17.0 description を短くし、blue-team-agent の検索と書き込みをツールで成り立たせる

消費側の呼び出しが壊れる変更は無い。skill 名、登録経路、command と agent の名前と引数の形は v0.16.0 と同じ。pin を上げる以外に消費側ですることは無い。挙動に関わる主な変更は 2 点で、skill / agent / command が選ばれる手がかりになる description が短くなったことと、blue-team-agent が受け取るツールが変わったこと。ほかに red-team-agent、e2e-scenario-impact-check、pre-merge-quality-gate の本文を書き直した (下記)。

消費側への影響

配る skill / agent / command の description — ISSUE-92

• 25 本のうち 23 本の description を、目安 200 字前後、上限 300 字で書き直した。何をするかと、いつ使うかを先に書く。合計は 8,300 字から 4,691 字になった (frontmatter の行の値を引用符ごと数えた字数)。いちばん長かった monkey-explorer-agent は 1,164 字から 276 字になった。security-blue-red-team と web-monkey-qa の plugin の SKILL.md は変えていない
• 公式の文書 (2026-10-19 に確認) によれば、skill と command の一覧の上限はコンテキストの 1% で、超えると呼ばれる回数の少ないものから説明が落ちて名前だけになる。短くしたのは、この予算を圧迫しないため。agent の description は別枠で、subagent の description の合計が 15,000 トークンを超えると起動時に警告が出る (読み込みは止まらない)
• 依頼の例として挙げていた語句のうち、次のものを description から外した。この語句で呼んでいた場合は、command を名前で呼ぶか、残した語句で頼むこと
  • /security-vulnerability-assessment: 「受動セキュリティスキャン」「月次セキュリティアセスメント」「OWASP top 10 静的チェック」
  • /security-redteam: 「攻撃面を能動的に検証」「セキュリティ侵入テスト」
  • /security-blueteam: 「改善計画立てて」「防御策を策定」
  • commit-and-pr-message: 「PR 本文を書いて」
  • in-repo-issue: 「作って」
  • context-loading-mechanics と e2e-scenario-impact-check は、同じ意味の言い換えに置き換えた
• README 用の説明は分けず、description 1 つのまま短くした。README は frontmatter から生成し直した
• e2e-scenario-impact-check の description にあった、staging E2E を前提にした主張 (「staging E2E は唯一の自動 E2E 検出網」「ローカル E2E は CI で動かない」) を外した。同じ前提で断定していた e2e-scenario-impact-check と pre-merge-quality-gate の本文は、「そういう構成のプロジェクトでは」という書き方にした。e2e-scenario-impact-check の検出パターンには getByLabel / getByText を足した (description から本文へ移した)
• monkey-explorer-agent の旧 description は値の途中に : を含み、厳密な YAML としては読めなかった。書き直しでこれも解消した

plugins/security-blue-red-team (blue-team-agent / red-team-agent)、plugins/web-monkey-qa (monkey-explorer-agent) — ISSUE-93

• blue-team-agent の tools: を Read, Glob, Grep, Write にした。これまでは Bash を挙げていたため、macOS / Linux / WSL では Glob / Grep が渡されず、「Glob / Grep / Read だけ」と定めた Mode B に Read しか残っていなかった
  • Bash はレポート (blue-team.md) を書く唯一の手段でもあったので、Write に置き換えた。レポートの書き込みは Bash ではなく Write の権限で判定されるようになった。Bash 向けに許可を書いていた場合は効かず、acceptEdits ではプロジェクト内への Write が確認なしで通る
  • 本文が HTTP を送らないと定めているので、WebFetch / WebSearch も外した
  • HTTP を送らないこととシェルを使わないことは、tools: で受け取るツールの範囲では効くようになった (自己申告のツール一覧と公式文書による)。ソースを書き換えないことと OUTPUT_DIR の外に書かないことは、Write がどこにでも書けるので文言のままである
• blue-team-agent の本文を新しいツールに合わせた
  • profile と findings.json の schema 検証は、読んで必須項目を確かめる形にした (schema validator は回さない)
  • blue-team.md が既にあるときは、Write の前に Read する
• red-team-agent は Bash を残した。Grep を前提にした手順には、Grep が無いところでは Bash の grep を使う道を書き足した
• 3 つの agent の tools: から、本文が使わず既定でも渡されない TodoWrite を外した
• v0.16.0 の「既知の問題」のうち、blue-team-agent の分はこの版で解消した。red-team-agent と monkey-explorer-agent は Bash を残したので、macOS / Linux / WSL では引き続き Glob / Grep が渡されない。red-team-agent は Bash の grep を代わりに使う手順を持ち、monkey-explorer-agent の本文は Glob / Grep を使わない
• 確認: plugin を別名でコピーし、Claude Code 2.1.303 (macOS のネイティブ版) のヘッドレス実行で読み込んだ。blue-team-agent が自己申告したツールは Read, Write, Glob, Grep (と harness が足すツール) だった。まだ無い日付ディレクトリの下へファイルを書かせ (ディスク上で確認)、Glob でそのファイルを見つけさせた (agent の報告で成功)。Grep は呼んでいない

同伴 (配布物に届かない変更)

• ISSUE-92 と ISSUE-93 は、実装の PR でクローズした
• ISSUE-64 の「description を README 用に分けるか」のタスクを済みにし、追記した

commit range: v0.16.0..v0.17.0 (9ae4082 と a95616c の 2 コミット、PR #93 と #94)

v0.16.0 jev-lint-curated のモデル ID を固定し、agent 定義を整える

消費側の呼び出しが壊れる変更は無い。skill 名、登録経路、CLI のサブコマンドと引数の形は v0.15.0 と同じ。コードの挙動が変わるのは、jev-lint-curated が上流へ送るモデル ID (jev-latest → jev-1.13.0) だけ。この ID は、キー無しの check --dry-run と compat に加えて、キーを使った実行でも確かめた (下の jev-lint-curated の節)。それでも pin を上げたあと jev-lint-curated の check が上流のエラーで止まったら、v0.15.0 の pin に戻して報告してほしい。ほかの配布物は、pin を上げる以外に消費側ですることは無い。

消費側への影響

skills/tooling/jev-lint-curated — ISSUE-90

• 上流へ渡すモデル ID を、alias の jev-latest から版付きの jev-1.13.0 に固定した。提供元の models ページ (2026-10-19 に確認) では、jev-latest は jev-1.13.0 を指していて、alias は新しいリリースで動く、とある。厳選した rule と cutoff の測定 (2026-09-25) は、送ったモデル ID も応答したモデルも記録していない (上流の既定は alias の jev-latest)。測定の 2 日後のキーを使った確認 (ISSUE-74) で応答したのが jev-1.13.0 だったので、その版に固定した。alias のままだと、ラッパの版は固定したままモデルだけが入れ替わりうる
• モデル ID は scripts/jevlint.py の MODEL_ID に、UPSTREAM_VERSION の隣で置いた。scripts/jevlint_host.py の fixed_tail / upstream_argv は、モデル ID を引数 model で受けるようになった (内部の関数で、CLI の形は変わらない)。SKILL.md の「版を上げる手順」に、モデル ID の更新と、モデルを変えたときの測り直しを足した
• 追記 (2026-10-19、リリースの後): キーを使って、この版 (288b5e4) の check を 1 ファイル (subject 27 件) に回した。要約の「応答したモデル」は jev-1.13.0 で、未回答 0 件、エラー 0 件、degraded 0 件だった。自分で確かめるときも、この行が jev-1.13.0 になることを見る

plugins/security-blue-red-team (red-team-agent / blue-team-agent)、plugins/web-monkey-qa (monkey-explorer-agent) — ISSUE-91

• 3 つの agent 定義の tools: から LS を外した。公式の tools reference に LS は無い。Claude Code 2.1.303 (macOS のネイティブ版) のヘッドレス実行で、外した版と残した版を比べた。どちらも 3 つとも起動し、agent が自己申告したツールの一覧も同じだった
• security-blue-red-team の「他の skill を呼ばない」の列挙にある playwright-test は残した。入っていない環境では何も起きない

plugins/dev-workflow (e2e-scenario-impact-check / retrospective-codify)、skills/tooling/chrome-devtools-debugger — ISSUE-91

• playwright-test / playwright-cli / ast-grep-practice を sibling skill のように書いていた箇所を、このリポジトリの外の skill だと分かる書き方に直した。e2e-scenario-impact-check は、playwright-test が入っていなければ対象プロジェクトの既存の E2E テストの書き方を根拠にする。retrospective-codify は、ast-grep-practice が入っていなければ ast-grep の公式ドキュメントに従う

既知の問題

• 上の 3 つの agent は tools: に Glob / Grep を挙げているが、公式の tools reference によれば macOS / Linux / WSL では既定で渡されない (Bash も挙げているので、subagent で戻る条件に当たらない)。macOS の Claude Code 2.1.303 で起動した確認でも、agent が自己申告した一覧に無かった。blue-team-agent の Mode B は Glob / Grep / Read だけを使うと定めているので、これらの環境では Read しか残らない。red-team-agent の Layer 1 (opt-in) も Grep を前提にした手順を含む。v0.15.0 の定義 (LS を残した形) でも同じ結果で、Claude Code 側の既定による。この版で悪くなったわけではない。ISSUE-93 で扱う

同伴 (配布物に届かない変更)

• 消費側の棚卸しで報告された 5 件を、ISSUE-90 / ISSUE-91 / ISSUE-92 として起票した。ISSUE-92 (description の短縮と、配布先に固有の主張) は open のまま
• ISSUE-90 と ISSUE-91 は、実装の PR でクローズした
• ISSUE-93 を起票した
• ISSUE-69 に、別リポジトリの実例と検出の案を追記した。closed の ISSUE-89 にも、ISSUE-69 の裁定との関係を 1 行足した

commit range: v0.15.0..v0.16.0 (e5bc134 から 288b5e4 までの 7 コミット、PR #86〜#92)

v0.15.0 herdr の skill の写しを撤去する

消費側の呼び出しが壊れる変更: skills/tooling/herdr を撤去した。この skill を apm で pin している消費側は、pin をこの版へ上げる前に、その依存の行を apm.yml から外す。行を残したまま pin を上げると、参照先の skill がこの版に無いので解決できない。

配布物の変更はこの撤去だけで、ほかの skill と plugin は v0.14.0 と同じ。skill 名、登録経路、CLI のサブコマンドと引数の形は変わらない。

消費側への影響

skills/tooling/herdr — ISSUE-89

• 撤去した。この skill は herdr 上流が配る skill の古い写しで、上流の本文や発火条件 (description) と離れていた。herdr 0.9.3 にも 0.9.5 にも無い CLI (トップレベルの herdr wait agent-status、1-1 形式の pane id) を案内していたが、herdr wait agent-status --help はトップレベルのヘルプに落ちて rc 0 を返すので、誤りがエラーとして表に出なかった
• 代わりの情報源は herdr 自身にある。herdr --help は、skill が文脈に無ければ herdr --skill を実行するよう案内する。このリポジトリは代わりの skill を配らない

同伴 (配布物に届かない変更)

• ISSUE-89 を起票し、同じ PR でクローズした
• ISSUE-64 (README の手直しを生成元へ移す作業) に、移す先の表にあった herdr の description は移す先が無くなったと追記した
• README の skill の表から herdr の行が消えた (gen-readme.py の生成物)

commit range: v0.14.0..v0.15.0 (35221a3 の 1 コミット、PR #85)

v0.14.0 VM 検証 skill の手順を実機に合わせ、winvm exec の出力と終了コードが消えないようにする

配布物の変更は skills/devops の 2 つの VM 検証 skill (macos-vm-verification と windows-vm-verification) だけで、ほかの skill と plugin は v0.13.0 と同じ。skill 名、登録経路、CLI のサブコマンドと引数の形は変わらない。

振る舞いが変わる点は 4 つある。winvm exec の出力や終了コードで判定している消費側は、2 つ目から 4 つ目を確かめてから pin を上げる。

• v0.13.0 で足した「検証 VM の扱い」の手順を、実機で通る形に直した。v0.13.0 の文面では、手順 1 と 6 はスナップショットが 0 件でも見出しの行が出るので「空か」の判定が成り立たず、手順 5 は一時停止の VM と起動中の macOS の VM を止められなかった
• winvm exec の標準出力が増えて、形が変わる。オブジェクトを出すコマンドは、これまで表とそれより後の出力が rc 0 のまま消えていたが、この版から出る。出力は exec が文字列に整えてから返すので、表の見出しの色の制御文字が無くなり、幅は 4096 になる
• winvm exec の終了コードが 1 つの形で変わる。native コマンドが失敗したあとに return / break / continue で抜けるコマンドは、v0.13.0 では rc 0 だったが、この版からその native の終了コードになる。最後まで走るコマンドの終了コードの決まり方 (native の終了コードを優先し、cmdlet の失敗は 1) は変わらない
• コマンドがエラーのレコードをオブジェクトとして出す形 (catch { $_ }、$Error[0]、-ErrorVariable で受けた変数) は、v0.13.0 では標準出力に出たが、この版から標準エラーへ出る。-WarningVariable で受けた警告のレコードを出すと、v0.13.0 には無かった WARNING: が付く。どちらも rc は変わらない

2>&1 などでストリームを混ぜた出力の行き先と接頭辞は、v0.13.0 と同じに保った (下の winvm.py の項)。

消費側への影響

skills/devops/macos-vm-verification と skills/devops/windows-vm-verification — ISSUE-87

• 手順 1 と 6: スナップショットの有無を prlctl snapshot-list "<vm>" -H の出力が空かどうかで判定する。-H は VM 名の後ろに置く。前に置くと VM 名がオプションとして読まれ、rc 255 になる
• 手順 5: prlctl list -a の状態で分岐し、stopped でなければ止める。prlctl stop は状態ごとに失敗の返し方が違うので、終了コードでは分岐しない。stopped と suspended の VM へ打つと Failed を出しながら rc 0 (suspended は --kill でも同じで、何も変わらない) で、paused の VM と起動中の macOS の VM へ素の stop を打つと rc 255 になる
• 一時停止 (suspended と paused) なら、先に prlctl resume で running へ戻す。macOS の VM は --kill で止める。止めたら stopped になったことを確かめ、なっていなければやり直す
• windows-vm-verification の SKILL.md の全角括弧を半角に揃えた。文面は変えていない

skills/devops/windows-vm-verification (winvm.py) — ISSUE-88

• winvm exec が VM へ送る .ps1 の形を変えた。.ps1 は自分自身を内側として呼び直してコマンドを動かし、外側でその出力を Out-String -Stream -Width 4096 で文字列にしてから終了コードを伝える。コマンドの中の exit、return、break、continue の手前の出力と、その終了コードが残る
• 2>&1 で出力へ混ぜた cmdlet のエラーは標準エラーへ、native の標準エラーは標準出力へ出す。3>&1 や *>&1 で混ぜた警告・詳細・デバッグには、各行に接頭辞 (WARNING: など) を付ける。どれも v0.13.0 と同じ側、同じ接頭辞になる (色の制御文字は付かない)
• 存在しないコマンドや 1/0 のように文だけを止めるエラーの後に、コマンドの続きが走るのは v0.13.0 と同じ
• 既知の限界の正本は winvm.py の docstring にある (ISSUE-88 の記録は配布物ではない)。v0.13.0 との違いとして効くもの:
  • native コマンドの出力も Out-String を通るので、UTF-8 として読めないバイトは置換文字になって戻せず、単独の CR は改行になり、最後に改行の無い出力には改行が足されて次の出力と同じ行につながらない。v0.13.0 は生のバイトのまま返していたので、UTF-8 以外の符号で書くプログラムの出力は、この版ではホストで読み直せない。VM の cmd が出す日本語は v0.13.0 とバイトまで一致したが、cmd 以外の native プログラムは確かめていない
  • コマンドの中から見える $MyInvocation、$PSBoundParameters、$input は呼び直しのものになる。トップレベルの Write-Error のエラーは、呼び直しの行を位置として示し、複数行で出る (v0.13.0 では 1 行。手元の pwsh で実測)
  • $ErrorView のような表示の設定は、コマンドの中で $global: を付けないと効かない
  • Format-Wide は列のあいだを幅いっぱいまで空け、表の 1 つの値は 4096 文字で切られる
• 既知の限界のうち v0.13.0 と同じもの: コマンドが throw すると手前の表は消える (rc 1 とエラーは出る。手を加えないスクリプトでも同じ)。コマンドの先頭の param() と using 文は効かない

確かめたこと: 手順の prlctl の一連と一時停止の扱いは、macOS (Apple の仮想化) と Windows の 2 台の実機で通した。winvm exec は手元の pwsh 7.6.4 で手を加えないスクリプトと v0.13.0 の形と比べたうえで、直した winvm.py を full chain (scp、pwsh -File、後始末) で Windows VM に通した。winvm.py のテストは、仕組みを 1 つずつ外す変異 (呼び直し、成功の初期値、1 回だけ回るループ、try/catch を足す形、振り分けの段、native の除外) で、狙ったテストが赤になることを確かめた。配布経路 (pin を上げた消費側) での確認はまだ。

pin を上げたあとで確かめること:

• Skill ツールで読み込んだ 2 つの VM 検証 skill の手順 1、5、6 が、この版の文面になっていること
• 実際に動く winvm.py が pin した版であること。winvm をシェルの関数などで別のパスへ向けているなら、その先のファイルに WinvmInner が含まれるかで確かめる
• その winvm.py で、VM 検証 skill の手順どおりに VM を扱ったうえで、次を打つ。<ホスト名> は ssh の設定のホスト名に置き換える
  • winvm exec --host <ホスト名> -- "Get-Item C:/Windows | Select-Object Name; Write-Output after"; echo "rc=$?": 表と after が出て rc=0。v0.13.0 では表も after も出ないので、pin が上がったことをこれで見分けられる
  • winvm exec --host <ホスト名> -- "cmd /c exit 3"; echo "rc=$?": rc=3
  • winvm exec --host <ホスト名> -- "Get-Item C:/nope 2>&1; Write-Output after" 2>/dev/null; echo "rc=$?": after だけが出て rc=0 (エラーは標準エラーへ行くので出ない)。v0.13.0 でも同じになるので、振り分けが壊れていないことの確認であって、版の見分けには使えない

同伴 (配布物ではない): ISSUE-87 と ISSUE-88 の記録 (実機の測定値と、作り直しの経緯)。

commit range: v0.13.0..9bc82e6 (3 commits)

v0.13.0 VM 検証 skill に原状へ戻す手順を足し、commit-and-pr-message からセッションのフッタと言い直しを消す

配布物の変更は 4 つの skill の SKILL.md、windows-vm-verification に足した references/gui-automation.md、jev-lint-curated の要約の出力 (とそのテスト)。skill 名、登録経路、コマンドの形は変わらないので、v0.12.0 から上げる場合に消費側の呼び出しが壊れる変更は無い。

エージェントの振る舞いが変わる点が 3 つある。

• VM 検証 skill (macos-vm-verification と windows-vm-verification) は、検証のたびに VM を原状のスナップショットへ巻き戻し、作業で取ったスナップショットを消し、VM を止めてから報告するようになった。VM の中の作業中の状態は巻き戻しで消え、次の検証は VM の起動から始まる。既存のスナップショットがある VM では、作業に入る前にユーザーへ扱いを確かめる。この手順は実機の VM でまだ通していない (下の「確かめたこと」)
• commit-and-pr-message は、コミット本文と PR 本文の末尾にセッションのフッタ (trailer のキー付きの行と、PR 本文の URL) を置く手順を持たなくなった。フッタを付けたい利用者は、harness が出す指示に従えばよい。その指示は skill とは別に届くので、この版でも届き方は変わらない。付けたくない利用者は、settings の attribution.sessionUrl を false にする
• jev-lint-curated は、キー付きの実行が失敗しても、エージェントがキーの所在の調査・確認・読み出しに進まないと明記した。要約の出力も増えた (下の jev-lint-curated の項)

消費側への影響

skills/devops/macos-vm-verification と skills/devops/windows-vm-verification — ISSUE-85

• 「検証 VM の扱い (スナップショットと停止)」の節を足した。内容は上の 1 つ目の点。CLI (macvm / winvm) はこの扱いを持たないので prlctl を直接使う
• windows-vm-verification に references/gui-automation.md を足した。UI Automation で GUI を操作したときに踏んだ落とし穴 3 件 (日付入力が年・月・日の別々の要素になる、画面遷移の直後に引いた要素が null になる、インストーラがサービスの開始の種類を戻してスナップショットへ焼き込まれる)。SKILL.md から辿れる

plugins/dev-workflow (commit-and-pr-message) — ISSUE-70, ISSUE-75

• フッタの記述を消した。A.1 の末尾の一文、C.1 の末尾にセッション URL を置く指示とフッタの非対称の段落、面ごとのフッタの既定の表、落とし穴の表のフッタの行 (ISSUE-70)
• 落とし穴 (Red flags) の節を消した。12 行のうちフッタの行 (上で消した) を除く 11 行は、右の列の規定が本文にもあった (ISSUE-75)
• 「既知の限界」から、送る前の入口の docstring と同じことを書いていた 3 項目 (公開範囲の誤判定、環境変数が届かない環境、Linux のホームディレクトリ形のパス) を消し、入口の docstring を指す 1 文を置いた。手順の側の 2 項目と、上限を超えたときの分け方は残した (ISSUE-75)
• 公開範囲の判定は、送る本文ごとに、その本文で最初に入口を呼ぶ前に 1 回だけ行うと文面で明確にした。前に送った本文の判定は使い回さない。手順の中身は変わらず、「最初に」が何の最初かを書いた (ISSUE-75)
• SKILL.md は 24,656 B から 21,198 B になり、呼ぶたびに載る量が減った。この skill の scripts/ (送る前の入口と gitleaks の config) は変わっていない

skills/tooling/jev-lint-curated — ISSUE-86

• キー付きの実行をユーザーに促す形を、エージェントが埋めてそのまま打てる形にした。ユーザーが置き換えるのはキーを取り出す部分の 1 語だけで、置き換えずに打ってもキーが空になり、コードを送る前にラッパが止まる
• 要約の出力が増えた。degraded になった batch と、関連テストが無く見送ったファイルを、件数の行の下に 1 件 1 行で出す。見送るファイルは --dry-run の要約にも出る。要約の文面を読んで判定している消費側は、行が増えることに注意する。終了コードと既存の行の文面は変わらない

確かめたこと: commit-and-pr-message の変更は、入口の定数と SKILL.md の終了コードの表を突き合わせるテストを含む Python テスト (1124 件、manifest と一致) と pre-commit の全 hook で確かめた。jev-lint-curated の出力は、追加したユニットテストで確かめた。VM 検証 skill の手順は散文として足しただけで、prlctl の一連のコマンドを実機の VM で通していない。prlctl の help でコマンドの形が正しいことだけを確かめた。

pin を上げたあとで確かめること:

• Skill ツールで読み込んだ commit-and-pr-message にフッタの記述が無いこと
• jev-lint-curated の --dry-run の要約が起動すること
• 各 VM (macOS と Windows) で、手順の prlctl snapshot / snapshot-switch / snapshot-delete / stop を 1 回通すこと。macOS の VM は Apple Silicon の仮想化で動くものがあり、その構成でスナップショットが取れるかは確かめていない。取れなければ、直るまで macos-vm-verification の手順を当てない
• スナップショットの無い VM で、最初の検証が手順 1 で止まらないこと。prlctl snapshot-list はスナップショットが無くても見出しの行を 1 行出すので、出力を字義どおり「空」で判定すると止まりうる

同伴 (配布物ではない):

• このリポジトリの commit-msg の検査に、コミットメッセージへのセッションの URL の混入を止める hook を足した (ISSUE-70)。配布物には足していないので、配布先の挙動は変えない
• 開いている Issue 56 件のトリアージ (PR 79) と、ISSUE-70、ISSUE-75、ISSUE-85、ISSUE-86 の記録。ISSUE-70 は実機の確認が残るので開いたまま

commit range: v0.12.0..5028fc8 (3 commits)

v0.12.0 jev-lint-curated の SKILL.md の後始末の手順を直す

配布物の変更は skills/tooling/jev-lint-curated/SKILL.md の1ファイルだけ。後始末の節の手順を直した。古い手順 (git worktree prune で消す) は、prune だけでは登録が消えないという git の挙動のために、版に依らず誤りだった (v0.10.0 でも同じ)。v0.11.0 で変わったのは、消し切れなかったときの告知の条件のほう。skill 名、登録経路、コマンドの形、スクリプトの挙動は変わらない。v0.11.0 から上げる場合、消費側の呼び出しが壊れる変更は無い。v0.10.0 から上げる場合は、下の「v0.10.0 から直接上げる消費側へ」の段落を読むこと。

消費側への影響: skills/tooling/jev-lint-curated — ISSUE-74

• SKILL.md の後始末の節が、正しい手順になった。後始末が走らない終わり方 (SIGKILL など) をすると、展開した worktree のディレクトリと登録が残ることがある。残ったときは、残った展開の一時ディレクトリ (一時ディレクトリの置き場の下の jevlint- で始まるもの。worktree はその中の tree で、隣の scratch に設定と記録が入る) を消してから、本体のリポジトリで git worktree prune を実行する。ディレクトリに .git が残っている間は、prune は登録を消さない (ISSUE-74)
• v0.11.0 のリリースノートは「この版の SKILL.md の後始末の節は、まだ古い手順 (git worktree prune で消す) のまま」と注記し、正しい手順をノートに書いていた。この版でその注記は解消した。v0.11.0 を pin している消費側は、この版へ上げると SKILL.md の手順がノートの手順と一致する
• scripts/ は v0.11.0 から変わっていない

v0.10.0 から直接上げる消費側へ: v0.11.0 の変更もあわせて受け取る。その中には、これまで動いていた形が終了コード2で止まるようになる変更 (相対の TMPDIR と、確かめられない host) と、要約の文面の変更がある。内容は v0.11.0 のリリースノートを読むこと。v0.10.0 から上げる場合も、変わる配布物は skills/tooling/jev-lint-curated だけで、ほかの skill と plugin は v0.10.0 と同じ。v0.11.0 の scripts/ の変更は、まだ配布経路 (pin を上げた消費側) で確かめられていないので、pin を上げたあとで、Skill ツールからの読み込みと、キーを使わない compat と check --dry-run の起動を確かめること。

確かめたこと: SKILL.md の手順は、git 2.55.0 の隔離したリポジトリで worktree を片付けずに残して再現した。prune だけでは登録が残り、ディレクトリを消してから prune すると消える。対照として .git だけを移すと prune が登録を消した。配布経路での確認は、このリリースのあとで消費側で行う。

同伴: なし。

commit range: v0.11.0..41a9fec (1 commit)

v0.11.0 jev-lint-curated の host の入れ替えを直列にし、後始末と要約の残りを片付ける

配布物の変更は skills/tooling/jev-lint-curated の10ファイル (追加2、変更8)。host の入れ替えを直列にし、Python の版で挙動が変わる stdlib の呼び出しを外し、後始末・TMPDIR・要約の残りを片付けた。skill 名、登録経路、コマンドの形は変わらない。これまで動いていた形のうち、相対の TMPDIR と、確かめられない host は終了コード2で止まるようになる。

消費側への影響: skills/tooling/jev-lint-curated — ISSUE-74, ISSUE-83

• TMPDIR が空でなく相対のときは、check・review・compat のどれも終了コード2で止まる。これまでは相対の値を cwd を基準に絶対化していたので、compat は一時ディレクトリを cwd (消費側のリポジトリであることが多い) の下に作り、check と review は置き場がリポジトリの中になるときだけ止まっていた。拒否するのは host の用意の後なので、compat では引数の版の取得を走らせてから止まる (ISSUE-74)
• host を取得するときは、置き場 ($XDG_CACHE_HOME か ~/.cache の下の jev-lint-curated/) に版ごとのロックファイル .lock-<版> を作って残す。同時に走った実行は、どちらかの取得が終わるのを待ってから、置かれた host を再利用する。これまでは同時の取得で、良い host を消して空のまま残す経路と、偽の終了コード2になる経路があった。再利用できる host があるときはロックファイルを作らない (ISSUE-74)
• host やその祖先、展開した木の設定ファイル、--json-out の保存先を、権限などで確かめられないときは、どの Python の版でも終了コード2で止まる。これまでは版で挙動が分かれ、たとえば Python 3.14 では読めない host を「無い」と読んで取り直そうとした (測った 3.14.7 と 3.9.6 で同じ挙動になることを確かめた。3.13 は測っていない) (ISSUE-83)
• 要約の文面が変わる。dry-run の見積もりは「費用 $X (1 パス分。3 パスで最大 $Y)」になる (上流の見積もりは 1 パス分で、ラッパは常に 3 パス聞く。実測では実行の費用が見積もりの約2.5倍だった)。未回答の行には、記録で答えの無い subject のファイルごとの件数が付く (例: 未回答: 133 件 (scripts/test_check_issue_closure.py 133))。要約の文字列を読んでいる消費側では形が変わる (ISSUE-74)
• check -- -x のような - 始まりの位置引数は引き続き終了コード2で止まるが、エラーの文面と止まる時点が、パスと版の検査の側 (git の後、host の前) のものになる (ISSUE-74)
• nohup の下のように SIGHUP が無視されている環境では、SIGHUP で中断しなくなる。これまでは無視されていても後始末に入って終わっていた (ISSUE-74)
• 展開した worktree を消し切れなかったときの告知の文面が変わり、prune が成功してもディレクトリが残ったときにも告げる。この版の SKILL.md の後始末の節は、まだ古い手順 (git worktree prune で消す) のままで、それだけでは登録が残る。ディレクトリに .git が残っている間は prune が登録を消さないため。残ったときは、展開の一時ディレクトリ (一時ディレクトリの置き場の下の jevlint- で始まるもの。worktree はその中の tree) を消してから、本体のリポジトリで git worktree prune を実行する。SKILL.md は PR #78 で直し、次の版に入る (ISSUE-74)
• scripts/ には本体6本とテスト6本が入る (jevlint_fs.py とそのテストが加わった)

--allow-build=@ast-grep/cli を付ける理由と、@ast-grep/cli の postinstall が走ったかの確かめ方を、コードのコメントに書いた (挙動は変えていない)。pnpm 12.3.4 で macOS arm64 と Linux x64 を測った結果で、走ったかは ast-grep --version の終了コードでは分からず、パッケージの中の ast-grep がネイティブのバイナリか Node のスクリプトかと、stderr の警告で見分ける (ISSUE-74)。

確かめたこと: テストは CI (ubuntu-26.04 の Python 3.14.4) と手元の Python 3.14.7 と 3.9.6 で通る。host の入れ替えは、2 つのプロセスを同時に走らせて取得が 1 回になることを、テストの外で確かめた。キーを使う check はこの版では走らせていない。配布経路 (pin を上げた消費側の Skill ツールからの読み込み) での確認は、このリリースのあとで消費側で行う。

同伴: CI の runner を ubuntu-26.04 に固定し (ISSUE-82)、python-tests の job で python3 の版を出すようにした (どちらもリポジトリの CI だけの変更)。リポジトリのテストで Python の版により期待値を分けることを、scripts/test_run_python_tests.py の検査がリポジトリ全体で禁じるようにした (ISSUE-83)。docs/issues/ の変更 (ISSUE-81 から ISSUE-84 までの起票、ISSUE-81 の結果の記録、ISSUE-81 / ISSUE-74 / ISSUE-82 / ISSUE-83 / ISSUE-84 のクローズ) と、Python テストの manifest を直した。

commit range: v0.10.0..bb12438 (7 commits)