shoji9x9

@shoji9x9 source repo

20 skills
0 followers
7 hours ago last updated

▌
Issue Batch · shoji9x9 bundle
複数の GitHub Issue を入力順に、Issue ごとの隔離 worktree・独立 branch / PR で連続処理し、実装、ローカルレビュー、検証、必要なブラウザ回帰、Kaizen、PR 収束、merge（GitHub の auto-merge／エージェントが PR の状況を実測してから merge、のいずれかを選択）、Issue close、deployment、branch cleanup まで追跡するスキル。初回は `issue-batch setup` で無人実行ポリシーとマージ方式を確定する。「複数 Issue をまとめて処理」「Issue を順番に最後まで」「issue-batch」や `run` / `setup` を伴う依頼で必ず使う。

0
installs
▌
Issue Start · shoji9x9 bundle
GitHub Issue を起点に作業開始フローを標準化するスキル。Issue URL や Issue 番号を受け取り、リポジトリ一致確認・feature ブランチ作成と checkout（gh issue develop）・調査・実装・commit・push・PR 作成までを段階的に進めたいときに使う。「Issue から始める」「この issue に着手」「issue-start」や、`--plan` / `--commit` / `--pr` を伴う依頼で発動する。

0
installs
▌
Parity Diff · shoji9x9 bundle
仕様を変えないアプリケーションリプレイスで、parity-suite が採取したベースライン・ノイズ基準値・強度ゲートで検証済みの差分器を使い、現行と新側の差分を決定論的ツールで検出して分類する replace-strategy の姉妹スキル。検出は画素・特性照合・aria の 3 経路が担い、LLM には「差分があるか」を聞かず「この差分は重要か」だけを 1 件ずつ crop 対で聞いて要対応／許容／環境ノイズに分類する。新側環境は --target で選び成果物は環境別。要対応は parity-replace へ差し戻し、収束は未説明差分ゼロかつ未修正回帰ゼロ。1 回で 1 機能。replace-strategy setup・golden-dataset・対象 slug の parity-suite・parity-replace の新側 green が前提で、未完了なら捏造せず停止する。「現新の差分を検出して」「差分を分類して」「parity-diff」や --feature / --target を伴う依頼で発動する。

0
installs
▌
Browser Test · shoji9x9 bundle
フロントエンド／バックエンドの変更が画面表示・コンソール・API 応答・主要コンポーネントの挙動に悪影響を与えていないかを、実ブラウザ（chrome-devtools MCP）で回帰確認するスキル。実施できる操作は環境ごとの設定（`forbidden_actions`）に従い、未定義の環境は読み取り専用として扱う。副作用を伴う操作は実施前にユーザーの承認を得る。環境とスコープからの影響ページ導出・console クリーンの確認・課題のクロス環境切り分けまで進める。バックエンドの変更もそれを呼ぶ画面を通して確認する。`browser-test setup` は対話的にプロジェクト設定を記録する。「ブラウザで確認」「画面で確認して」「browser-test」「動作確認して」「回帰がないか見て」や、`--env` / `--scope` / `--ignore-forbidden-actions` / `setup` を伴う依頼で発動する。

0
installs
▌
Git Worktree · shoji9x9 bundle
git worktree による作業隔離の機構を担うスキル。渡された branch に worktree を用意してセッションをそこへ移し、`.gitignore` 対象ファイルの運搬、検査ツールからの除外、clean 確認付きの後片付けまでを標準化する。「絶対パスで cd すれば隔離できる」は subagent・fork・background Bash が起動時の作業ディレクトリを継承するため成立しない。branch の作成と Issue との紐付けは行わず呼び出し側（issue-start / issue-batch 等）に委ねる。「worktree で作業して」「worktree を作って」「隔離して作業して」「git-worktree」や `setup` / `enter` / `cleanup` を伴う依頼で発動する。

0
installs
▌
Issue Create · shoji9x9 bundle
GitHub Issue の作成を `gh` で標準化するスキル。バグ・機能要望・タスクなどの短い説明を受け取り、対象リポジトリ確認・重複チェック・`.github/ISSUE_TEMPLATE/` のテンプレ検出・本文ドラフトのユーザー承認・`gh issue create` での起票までを進める。「Issue を作って」「課題として登録して」「バグを起票して」「issue-create」や、新しい機能要望・不具合・タスクを GitHub Issue にしたい依頼で必ず発動する。作業着手は姉妹スキル issue-start が担う。

0
installs
▌
Parity Suite · shoji9x9 bundle
仕様を変えないアプリケーションリプレイスで、新旧どちらの実装にも当てられる実行可能な合否判定基準（パリティスイート）を現行アプリに対して構築し、故障注入で強度を検証する 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>（対象環境）を伴う依頼で発動する。

0
installs
▌
Golden Dataset · shoji9x9 bundle
仕様を変えないアプリケーションリプレイスで、現行と新側の比較を成立させるための共通ゴールデンデータセットを構築する replace-strategy の姉妹スキル。データそのものではなく、冪等・決定論的な投入ツール（TypeScript か SQL）を作る。本番環境は参照せずデータを一から作る。新側スキーマは後から出来るため 2 フェーズに分ける（A は論理データ設計と現行テスト環境への投入・検証、B は新側スキーマへの写像・投入・現新一致検証）。投入先の環境は --target で選ぶ（フェーズ B の記録は target 別）。データセットにバージョンを持たせ parity-suite / parity-diff のベースライン陳腐化検出に使う。replace-strategy setup 完了が前提。「ゴールデンデータセットを作って」「テストデータを投入して」「golden-dataset」や --phase / --target を伴う依頼で発動する。

0
installs
▌
Parity Replace · shoji9x9 bundle
仕様を変えないアプリケーションリプレイスで、parity-suite が定義した論理名に対し新側を実装する replace-strategy の姉妹スキル。担うのは 3 つ——機能をページ単位のフェーズに分割し、新側ロケータマッピングの例外を充填し、実装役と分離した敵対的レビューを未コミット差分にかける。ブランチ作成・commit・PR は issue-start へ委譲。現行コードを一次情報源に読み、推測せず確信度を申告し、パリティスイートが新に対して green かつ検証コマンドが通れば完了（差分ゼロは parity-diff との往復の終了条件）。対象環境は --target で選び、証跡は環境別に残す。1 回で 1 機能。replace-strategy setup・golden-dataset・対象 slug の parity-suite 完了が前提で、未完了なら停止する。「新側を実装して」「parity-replace」や --feature / --target / --max-iterations を伴う依頼で発動する。

0
installs
▌
Dependabot Merge · shoji9x9 bundle
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 件ずつ影響判断してからマージする。

0
installs
▌
Multiagent Setup · shoji9x9 bundle
マルチエージェント環境（Claude Code / Codex / GitHub Copilot）向けのスキル・ルール・Hooks・ドキュメントのセットアップに必ず使用すること。スキルの作成・更新・削除、ルールの追加・管理、Hooksの設定、CLAUDE.md・AGENTS.md・.github/copilot-instructions.mdなどのドキュメントの整備・整理・分割・集約、プロジェクトのマルチエージェント初期化で参照する。加えて、知識・規約・処理を新たに追加する、またはドキュメントを整理・再配置するときに、それを skill / rule / hook / ドキュメントのどれに落とすか（rule なら paths を最小スコープに、ドキュメントなら基底ドキュメントか個別かを選ぶ）を判断する場面でも必ず参照する。

0
installs
▌
Pr Finalize Loop · shoji9x9 bundle
作成済み GitHub PR の CI エラー解消とレビュー指摘対応を、CI が成功しレビュー指摘が尽きるまで自律ループで回すスキル。PR URL を受け取り、CI 失敗の修正・レビュースレッドの返信/解決・commit/push・設定したレビューツール（Copilot/Claude Code/Codex/none）への再レビュー依頼を反復する。ループ中はユーザー確認を挟まず自律動作するが、人間判断を要する指摘だけは確認し、反映後にループへ戻る。`--max-iterations`（既定 5）で無限ループを防ぐ。レビュー対応単体は姉妹スキル pr-review-handle が担う。「PR を最後まで解決して」「CI とレビュー指摘がなくなるまで回して」「PR の CI とレビューを収束させて」「pr-finalize-loop」で必ず発動する。

0
installs
▌
Pr Review Handle · shoji9x9 bundle
GitHub PR のレビューコメント対応を `gh` で標準化するスキル。PR URL / PR 番号 / レビュー URL を受け取り、未解決レビュースレッドの確認・指摘の妥当性判断・必要な場合のみ修正・返信・解決（resolve）までを段階的に進める。全レビュアー（Copilot を含む）が対象。「レビューに対応して」「Copilot のレビューを処理して」「レビューコメントを解決して」「pr-review-handle」や、`--push` を伴う依頼で必ず発動する。ブランチ作成や Issue 着手は姉妹スキル issue-start が担う。

0
installs
▌
Replace Strategy · shoji9x9 bundle
仕様を変えないアプリケーションリプレイスの入口として、現行アプリを実測して戦略を決め、機能に分解して姉妹スキル（golden-dataset / parity-suite / parity-replace / parity-diff）へ振り分けるスキル。自分では実装しない。setup（依存確認・現行環境の由来確認・対話セットアップ・測定・戦略決定・レジストリ・機能インベントリ・パッケージ選定。受領資産からの再構築は current-environment-bootstrap へ委譲）／issues（対象機能を選択して GitHub Issue を起票。issue-create へ委譲）／status（Issue とリポジトリ内成果物から現況と未検証領域を導出）の 3 モードを持つ。測定できない場合は戦略へ進まず停止する。「リプレイス戦略を立てて」「リプレイスを始めたい」「現行アプリを測定して」「replace-strategy」や、setup / issues / status・--feature を伴う依頼で発動する。

0
installs
▌
Dependabot Alert Issue · shoji9x9 bundle
Dependabot alerts または外部 audit findings（例 pnpm audit の正規化 JSON）を確認し、解消 Issue を `gh` で作成するスキル。対象を「すぐ着手できるか」で分類し、着手可能なものは severity 毎、ブロック中のものは脆弱パッケージ＋解決バージョン毎にまとめる。既存 Issue/PR はスキップし、特定 alert の ignore/dismiss も設定できる。`pnpm.overrides` 等の品質が保証されない回避策は採らない。「Dependabot alerts から Issue」「pnpm audit の結果から Issue」「脆弱性対応の Issue」「dependabot-alert-issue」で必ず発動する。

0
installs
▌
AWS Architecture Diagram · shoji9x9 bundle
AWS 構成図を spec（ノード・エッジ・グループの配列）から SVG として生成・更新するスキル。IaC（AWS CDK / Terraform / CloudFormation 等）や説明を情報源に spec を起こし、環境（prod / staging / local 等）ごとに出し分け、PNG にラスタライズして作図ルール（交差最小・直交配線・軸整列・ラベル可読）で目視確認しながら反復する。初回は `setup` で対話的に導入（配置・アイコン取得・環境確定・初期作図）、以降は `update` で生成する。描画エンジン・環境レジストリ・render/preview・AWS アイコン取得を starter kit として同梱。「AWS 構成図を作って」「アーキテクチャ図を SVG で描いて」「構成図を更新して」「CDK/Terraform から構成図を」「aws-architecture-diagram setup」や、環境別の構成図を作りたい依頼で発動する。手描き GUI ではなくテキスト差分で管理できる図を作る。

0
installs
▌
Current Environment Bootstrap · shoji9x9 bundle
仕様を変えないアプリケーションリプレイスで、先方から受領した現行アプリの資産だけを起点に、比較基準として測定可能な現行テスト環境（current target）を再構築する replace-strategy の姉妹スキル。受領資産の棚卸しと「受領済み／導出可能／不足」の分類、DB スキーマ・設定の復元、データ意味論の根拠収集、先方・SME 向け質問票の生成、根拠のある範囲での最小の暫定起動データ構築、起動・認証・主要画面到達の実測、空環境からの再実行検証、current target の引き渡しを担う。型やカラム名からの推測でドメイン値を確定せず、来歴・利用許可が不明なデータは投入しない。replace-strategy setup が current.origin＝received-assets のときに委譲する。「受領資産から現行環境を再構築して」「現行テスト環境を建てて」「current-environment-bootstrap」で発動する。

0
installs
▌
Pnpm Audit Alert Issue · shoji9x9 bundle
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

0
installs
▌
Box · shoji9x9 bundle
Box のファイル/フォルダを Box REST API（curl）で参照・検索・更新するスキル。対象フォルダの一覧取得、ファイルのメタ取得・ダウンロード・検索、アップロード・新バージョン作成などを、アクセストークン（Dev Token または OAuth refresh）で実行したいときに使う。「Box のファイルを見て/取得して」「Box にアップロード」「Box フォルダを一覧」「Box を検索」「box」等で発動する。

0
installs
▌
Kaizen · shoji9x9 bundle
コーディングエージェントのセッションから失敗・修正・エラーを抽出し根本原因を分析。スキル・ルール・Hooks・ドキュメントへ反映することで同じ失敗を繰り返さない仕組みを構築する。「セッションを振り返る」「学びを抽出する」「kaizen」「改善を適用する」「学びを適用して」などで発動。

0
installs

20 published skills