shoji9x9
@shoji9x9
Public Skills
git-worktree
by shoji9x9
git worktree による作業隔離の機構を担うスキル。渡された branch に worktree を用意してセッションをそこへ移し、.gitignore 対象ファイルの運搬、検査ツールからの除外、clean 確認付きの後片付けまでを標準化する。「絶対パスで cd すれば隔離できる」は subagent・fork・background Bash が起動時の作業ディレクトリを継承するため成立しない。branch の作成と Issue との紐付けは行わず呼び出し側（issue-start / issue-batch 等）に委ねる。「worktree で作業して」「worktree を作って」「隔離して作業して」「git-worktree」や setup / enter / cleanup を伴う依頼で発動する。
git-worktree
by shoji9x9
git worktree による作業隔離の機構を担うスキル。渡された branch に worktree を用意してセッションをそこへ移し、.gitignore 対象ファイルの運搬、検査ツールからの除外、clean 確認付きの後片付けまでを標準化する。「絶対パスで cd すれば隔離できる」は subagent・fork・background Bash が起動時の作業ディレクトリを継承するため成立しない。branch の作成と Issue との紐付けは行わず呼び出し側（issue-start / issue-batch 等）に委ねる。「worktree で作業して」「worktree を作って」「隔離して作業して」「git-worktree」や setup / enter / cleanup を伴う依頼で発動する。
kaizen
by shoji9x9
コーディングエージェントのセッションから失敗・修正・エラーを抽出し根本原因を分析。スキル・ルール・Hooks・ドキュメントへ反映することで同じ失敗を繰り返さない仕組みを構築する。適用されないまま古くなり再発もしていない学びは抽出時に自動で忘却し、セッション開始時の注入を軽く保つ。「セッションを振り返る」「学びを抽出する」「kaizen」「改善を適用する」「学びを適用して」「古い学びを忘れて」などで発動。
kaizen
by shoji9x9
コーディングエージェントのセッションから失敗・修正・エラーを抽出し根本原因を分析。スキル・ルール・Hooks・ドキュメントへ反映することで同じ失敗を繰り返さない仕組みを構築する。適用されないまま古くなり再発もしていない学びは抽出時に自動で忘却し、セッション開始時の注入を軽く保つ。「セッションを振り返る」「学びを抽出する」「kaizen」「改善を適用する」「学びを適用して」「古い学びを忘れて」などで発動。
replace-strategy
by shoji9x9
仕様を変えないアプリケーションリプレイスの起点。現行アプリを実測して戦略を決め、機能に分解して姉妹スキル群へ振り分ける（自分では実装しない）。setup（測定・戦略決定・機能インベントリ。受領資産からの再構築は current-environment-bootstrap、共通部品優先なら parity-component へ委譲）／issues（対象機能の GitHub Issue を起票。issue-create へ委譲）／status（Issue と成果物から現況と未検証領域を導出）／evidence（確定した API の要求単位の根拠を機能インベントリへ非破壊で書き戻す。parity 姉妹からの委譲先）の 4 モードを持つ。測定できない場合は停止する。「リプレイス戦略を立てて」「リプレイスを始めたい」「現行アプリを測定して」「要求単位を書き戻して」「replace-strategy」や、setup / issues / status / evidence を伴う依頼で発動する。
parity-replace
by shoji9x9
仕様を変えないアプリケーションリプレイスで、parity-suite が定義した論理名に対し新側を実装する replace-strategy の姉妹スキル。担うのは 3 つ——機能をページ単位のフェーズに分割し、新側ロケータマッピングの例外を充填し、実装役と分離した敵対的レビューを未コミット差分にかける。ブランチ作成・commit・PR は issue-start へ委譲。現行コードを一次情報源に読み確信度を申告し、スイートの新側 green・検証コマンド・Issue の受け入れ条件の照合が通れば完了（差分ゼロは parity-diff との往復の終了条件）。対象環境は --target で選び、証跡は環境別に残す。1 回で 1 機能。replace-strategy setup・golden-dataset・対象 slug の parity-suite 完了が前提で、未完了なら停止する。「新側を実装して」「parity-replace」や --feature / --target / --max-iterations を伴う依頼で発動する。
parity-replace
by shoji9x9
仕様を変えないアプリケーションリプレイスで、parity-suite が定義した論理名に対し新側を実装する replace-strategy の姉妹スキル。担うのは 3 つ——機能をページ単位のフェーズに分割し、新側ロケータマッピングの例外を充填し、実装役と分離した敵対的レビューを未コミット差分にかける。ブランチ作成・commit・PR は issue-start へ委譲。現行コードを一次情報源に読み確信度を申告し、スイートの新側 green・検証コマンド・Issue の受け入れ条件の照合が通れば完了（差分ゼロは parity-diff との往復の終了条件）。対象環境は --target で選び、証跡は環境別に残す。1 回で 1 機能。replace-strategy setup・golden-dataset・対象 slug の parity-suite 完了が前提で、未完了なら停止する。「新側を実装して」「parity-replace」や --feature / --target / --max-iterations を伴う依頼で発動する。
replace-strategy
by shoji9x9
仕様を変えないアプリケーションリプレイスの起点。現行アプリを実測して戦略を決め、機能に分解して姉妹スキル群へ振り分ける（自分では実装しない）。setup（測定・戦略決定・機能インベントリ。受領資産からの再構築は current-environment-bootstrap、共通部品優先なら parity-component へ委譲）／issues（対象機能の GitHub Issue を起票。issue-create へ委譲）／status（Issue と成果物から現況と未検証領域を導出）／evidence（確定した API の要求単位の根拠を機能インベントリへ非破壊で書き戻す。parity 姉妹からの委譲先）の 4 モードを持つ。測定できない場合は停止する。「リプレイス戦略を立てて」「リプレイスを始めたい」「現行アプリを測定して」「要求単位を書き戻して」「replace-strategy」や、setup / issues / status / evidence を伴う依頼で発動する。
pnpm-audit-alert-issue
by shoji9x9
pnpm 11 と devEngines.packageManager の組み合わせで Dependabot が pnpm-lock.yaml を解析できず Dependabot alerts が出ない間、pnpm audit --json を一次情報として脆弱性 Issue を作る private skill。pnpm audit の結果を正規化し、dependabot-alert-issue の外部 audit findings mode に渡す。「pnpm audit から Issue」「pnpm の脆弱性を起票」「dependabot-core#14794 回避」「pnpm-audit-alert-issue」で必ず使用する。
parity-diff
by shoji9x9
仕様を変えないアプリケーションリプレイスで、parity-suite が採取したベースライン・ノイズ基準値・強度チェックを通った差分ツールを使い、現行と新側の差分を決定論的ツールで検出して分類する replace-strategy の姉妹スキル。検出は画素・特性照合・aria の比較が担い、LLM には「差分があるか」を聞かず「この差分は重要か」だけを 1 件ずつ crop 対で聞いて要対応／許容／環境ノイズに分類する。新側環境は --target で選び成果物は環境別。要対応は parity-replace へ差し戻し、収束は未説明差分ゼロかつ未修正回帰ゼロ。1 回で 1 機能。replace-strategy setup・golden-dataset・対象 slug の parity-suite・parity-replace の新側 green が前提で、未完了なら捏造せず停止する。「現新の差分を検出して」「差分を分類して」「parity-diff」や --feature / --target を伴う依頼で発動する。
parity-diff
by shoji9x9
仕様を変えないアプリケーションリプレイスで、parity-suite が採取したベースライン・ノイズ基準値・強度チェックを通った差分ツールを使い、現行と新側の差分を決定論的ツールで検出して分類する replace-strategy の姉妹スキル。検出は画素・特性照合・aria の比較が担い、LLM には「差分があるか」を聞かず「この差分は重要か」だけを 1 件ずつ crop 対で聞いて要対応／許容／環境ノイズに分類する。新側環境は --target で選び成果物は環境別。要対応は parity-replace へ差し戻し、収束は未説明差分ゼロかつ未修正回帰ゼロ。1 回で 1 機能。replace-strategy setup・golden-dataset・対象 slug の parity-suite・parity-replace の新側 green が前提で、未完了なら捏造せず停止する。「現新の差分を検出して」「差分を分類して」「parity-diff」や --feature / --target を伴う依頼で発動する。
browser-test
by shoji9x9
フロントエンド／バックエンドの変更が画面表示・コンソール・API 応答・主要コンポーネントの挙動に悪影響を与えていないかを、実ブラウザ（chrome-devtools MCP）で回帰確認するスキル。実施できる操作は環境ごとの設定（forbidden_actions）に従い、未定義の環境は読み取り専用として扱う。副作用を伴う操作は実施前にユーザーの承認を得る。環境とスコープからの影響ページ導出・console クリーンの確認・課題のクロス環境切り分けまで進める。バックエンドの変更もそれを呼ぶ画面を通して確認する。browser-test setup は対話的にプロジェクト設定を記録する。「ブラウザで確認」「画面で確認して」「browser-test」「動作確認して」「回帰がないか見て」や、--env / --scope / --ignore-forbidden-actions / setup を伴う依頼で発動する。
parity-suite
by shoji9x9
仕様を変えないアプリケーションリプレイスで、新旧どちらの実装にも当てられる実行可能な合否判定基準（パリティスイート）を現行アプリに対して構築し、故障注入で強度を検証する replace-strategy の姉妹スキル。論理名のロケータマッピング層と手書きの寛容な aria スナップショットで Playwright スイートを書き、API を record/replay で特性化し、視覚ベースライン（スクリーンショット・computed style・参考 aria スナップショット）とノイズ基準値を採取して parity-diff へ引き渡す。1 回で 1 機能（横断 API リソース・バッチも可）。replace-strategy setup と golden-dataset の完了が前提で、未完了・Playwright 不可なら停止する。「パリティスイートを作って」「現行アプリを特性化して」「parity-suite」や --feature <slug> / --target <name>（対象環境）を伴う依頼で発動する。
browser-test
by shoji9x9
フロントエンド／バックエンドの変更が画面表示・コンソール・API 応答・主要コンポーネントの挙動に悪影響を与えていないかを、実ブラウザ（chrome-devtools MCP）で回帰確認するスキル。実施できる操作は環境ごとの設定（forbidden_actions）に従い、未定義の環境は読み取り専用として扱う。副作用を伴う操作は実施前にユーザーの承認を得る。環境とスコープからの影響ページ導出・console クリーンの確認・課題のクロス環境切り分けまで進める。バックエンドの変更もそれを呼ぶ画面を通して確認する。browser-test setup は対話的にプロジェクト設定を記録する。「ブラウザで確認」「画面で確認して」「browser-test」「動作確認して」「回帰がないか見て」や、--env / --scope / --ignore-forbidden-actions / setup を伴う依頼で発動する。
parity-suite
by shoji9x9
仕様を変えないアプリケーションリプレイスで、新旧どちらの実装にも当てられる実行可能な合否判定基準（パリティスイート）を現行アプリに対して構築し、故障注入で強度を検証する replace-strategy の姉妹スキル。論理名のロケータマッピング層と手書きの寛容な aria スナップショットで Playwright スイートを書き、API を record/replay で特性化し、視覚ベースライン（スクリーンショット・computed style・参考 aria スナップショット）とノイズ基準値を採取して parity-diff へ引き渡す。1 回で 1 機能（横断 API リソース・バッチも可）。replace-strategy setup と golden-dataset の完了が前提で、未完了・Playwright 不可なら停止する。「パリティスイートを作って」「現行アプリを特性化して」「parity-suite」や --feature <slug> / --target <name>（対象環境）を伴う依頼で発動する。
golden-dataset
by shoji9x9
仕様を変えないアプリケーションリプレイスで、現行と新側の比較を成立させるための共通ゴールデンデータセットを構築する replace-strategy の姉妹スキル。データそのものではなく、冪等・決定論的な投入ツール（TypeScript か SQL）を作る。本番環境は参照せずデータを一から作る。新側スキーマは後から出来るため 2 フェーズに分ける（A は論理データ設計と現行テスト環境への投入・検証、B は新側スキーマへの変換・投入・現新一致検証）。投入先の環境は --target で選ぶ（フェーズ B の記録は target 別）。データセットにバージョンを持たせ parity-suite / parity-diff のベースライン陳腐化検出に使う。replace-strategy setup 完了が前提。「ゴールデンデータセットを作って」「テストデータを投入して」「golden-dataset」や --phase / --target を伴う依頼で発動する。
golden-dataset
by shoji9x9
仕様を変えないアプリケーションリプレイスで、現行と新側の比較を成立させるための共通ゴールデンデータセットを構築する replace-strategy の姉妹スキル。データそのものではなく、冪等・決定論的な投入ツール（TypeScript か SQL）を作る。本番環境は参照せずデータを一から作る。新側スキーマは後から出来るため 2 フェーズに分ける（A は論理データ設計と現行テスト環境への投入・検証、B は新側スキーマへの変換・投入・現新一致検証）。投入先の環境は --target で選ぶ（フェーズ B の記録は target 別）。データセットにバージョンを持たせ parity-suite / parity-diff のベースライン陳腐化検出に使う。replace-strategy setup 完了が前提。「ゴールデンデータセットを作って」「テストデータを投入して」「golden-dataset」や --phase / --target を伴う依頼で発動する。
current-environment-bootstrap
by shoji9x9
仕様を変えないアプリケーションリプレイスで、先方から受領した現行アプリの資産だけを起点に、比較基準として測定可能な現行テスト環境（current target）を再構築する replace-strategy の姉妹スキル。受領資産の棚卸しと「受領済み／導出可能／不足」の分類、DB スキーマ・設定の復元、データ意味論の根拠収集、先方・SME 向け質問票の生成、根拠のある範囲での最小の暫定起動データ構築、起動・認証・主要画面到達の実測、空環境からの再実行検証、current target の引き渡しを担う。型やカラム名からの推測でドメイン値を確定せず、出所・利用許可が不明なデータは投入しない。replace-strategy setup が current.origin＝received-assets のときに委譲する。「受領資産から現行環境を再構築して」「現行テスト環境を建てて」「current-environment-bootstrap」で発動する。
current-environment-bootstrap
by shoji9x9
仕様を変えないアプリケーションリプレイスで、先方から受領した現行アプリの資産だけを起点に、比較基準として測定可能な現行テスト環境（current target）を再構築する replace-strategy の姉妹スキル。受領資産の棚卸しと「受領済み／導出可能／不足」の分類、DB スキーマ・設定の復元、データ意味論の根拠収集、先方・SME 向け質問票の生成、根拠のある範囲での最小の暫定起動データ構築、起動・認証・主要画面到達の実測、空環境からの再実行検証、current target の引き渡しを担う。型やカラム名からの推測でドメイン値を確定せず、出所・利用許可が不明なデータは投入しない。replace-strategy setup が current.origin＝received-assets のときに委譲する。「受領資産から現行環境を再構築して」「現行テスト環境を建てて」「current-environment-bootstrap」で発動する。
parity-component
by shoji9x9
仕様を変えないアプリケーションリプレイスで、共通 UI 部品を画面より先に作るときに、現行アプリから部品の見た目の基準を採り、実装し、部品カタログ上で照合する replace-strategy の姉妹スキル。採取の単位は部品インスタンス（部品 × ページ）で、要素単位のスクリーンショット・状態別の計算後スタイル・当たっている CSS 規則・データ依存部品の実データを採る。インスタンス間で値が割れた軸を可変（引数）、割れない軸を固定として決定論的に割り出し、実装後はカタログを同条件で採って parity-suite 同梱の差分ツールで照合する。1 回で 1 部品。replace-strategy setup と .replace/components.md が前提で、未整備なら停止する。「共通部品の見た目の基準を採って」「部品を先に作る」「parity-component」や capture / build を伴う依頼で発動する。
parity-component
by shoji9x9
仕様を変えないアプリケーションリプレイスで、共通 UI 部品を画面より先に作るときに、現行アプリから部品の見た目の基準を採り、実装し、部品カタログ上で照合する replace-strategy の姉妹スキル。採取の単位は部品インスタンス（部品 × ページ）で、要素単位のスクリーンショット・状態別の計算後スタイル・当たっている CSS 規則・データ依存部品の実データを採る。インスタンス間で値が割れた軸を可変（引数）、割れない軸を固定として決定論的に割り出し、実装後はカタログを同条件で採って parity-suite 同梱の差分ツールで照合する。1 回で 1 部品。replace-strategy setup と .replace/components.md が前提で、未整備なら停止する。「共通部品の見た目の基準を採って」「部品を先に作る」「parity-component」や capture / build を伴う依頼で発動する。
dependabot-merge
by shoji9x9
Dependabot が作成した PR のレビューとマージを gh で標準化するスキル。PR URL / PR 番号で 1 件、--all または無指定で open な全 Dependabot PR を対象にする。CI 成功の確認 → 更新内容（changelog/release notes）からマージ影響の確認 → 判断を PR コメントに記録 → 問題なければマージ、までを進める。特に 0.x（<1.0）依存はマイナー更新でも破壊的変更があり得るため影響を確認してから扱う。「Dependabot の PR をマージして」「依存更新 PR を確認してマージ」「dependabot-merge」「dependabot の PR を全部見て」や、--all を伴う依頼で必ず発動する。依存更新 PR を 1 件ずつ影響判断してからマージする。
dependabot-merge
by shoji9x9
Dependabot が作成した PR のレビューとマージを gh で標準化するスキル。PR URL / PR 番号で 1 件、--all または無指定で open な全 Dependabot PR を対象にする。CI 成功の確認 → 更新内容（changelog/release notes）からマージ影響の確認 → 判断を PR コメントに記録 → 問題なければマージ、までを進める。特に 0.x（<1.0）依存はマイナー更新でも破壊的変更があり得るため影響を確認してから扱う。「Dependabot の PR をマージして」「依存更新 PR を確認してマージ」「dependabot-merge」「dependabot の PR を全部見て」や、--all を伴う依頼で必ず発動する。依存更新 PR を 1 件ずつ影響判断してからマージする。
issue-start
by shoji9x9
GitHub Issue を起点に作業開始フローを標準化するスキル。Issue URL や Issue 番号を受け取り、リポジトリ一致確認・feature ブランチ作成と checkout（gh issue develop）・調査・実装・commit・push・PR 作成までを段階的に進めたいときに使う。ブランチを用意した時点で呼び出し元へ返す --branch-only があり、実装を自分で持つスキルからの委譲に使う。push の前と --acceptance で、Issue の受け入れ条件を 1 項目ずつ根拠と突き合わせた表を同梱の検査で確かめる。「Issue から始める」「この issue に着手」「受け入れ条件を確かめて」「issue-start」や、--branch-only / --plan / --commit / --pr / --acceptance を伴う依頼で発動する。