菜单
Issue/チケットの初期調査・前提検証・論点整理・意思決定支援を行う。また、会話中の雑な依頼やラフな指示を実行可能な作業定義へ再構成する。Issueも依頼も仮説として扱い、コードベースと事実に基づいて再評価する。トリガー：「このIssueについて調査して」「Issue分析」「チケット見て」「plan site」「このバグ見て」「TES-123調べて」やLinear/GitHub IssueのIDを渡されたとき。「この依頼整理して」「要件固めて」「これ何すればいい？」「雑だけどやりたい」「Issue精査」
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
PJ管理フロー（長期記憶＋Threadの積み上げ）を任意リポジトリに展開するスキル。デフォルトでは `.claude/my-projects/<slug>/` 配下にProject長期記憶（CLAUDE.md）とThread（OBJECTIVE.md→OUTPUT.md）を積むが、runner / repo 方針に応じて `.agents/my-projects/` 等へカスタム可能。トリガー：「<slug>を再開」「続きやる」「PJ立ち上げ」「新スレッド作って」「OUTPUT書いて」「pbcopyして」「PJクローズ」「このやりとりをPJ管理下に置きたい」「○○PJに合流させたい」「PR/Issueから In Progress PJを作って」「pj-flow にマイグレ」「pj-flow の挙動を直したい」「pjflow」。Claude Code / Codex Agent Skill 両対応。
Create publication-safe redacted images from screenshots or other images that contain internal, private, or company-specific text. Use when the user asks to mask, redact, hide, anonymize, or sanitize sensitive information in an attached/local image, especially when they want selective text masking, public-release screenshots, article images, or iterative "消しすぎ/もっと隠して" adjustment. Always prefer writing a purpose-built script for the specific image before running ffmpeg/ImageMagick, rather than manually guessing rectangles.
画像（PNG）からUI要素の整列（縦中央揃い / 左端揃い / 間隔均等 等）を画素単位で静的判定するスクリプトを、命題ごとに新規実装してから走らせる skill。LLM の主観で「揃ってる」と誤判定するのを防ぐためのメタ手法。固定スクリプトを呼ぶのではなく、検証したい命題ごとに ROI / 判定式 / debug overlay を設計し直す。scripts/ にケース別の参考実装（中央揃い / 左端揃い）を同梱。トリガー：「中央寄せ判定」「縦揃え確認」「左端揃え判定」「centering check」「alignment check」「画像で揃ってるか確認して」
Codex CLI (codex exec) を直接呼び出して rescue（診断・修正）、review（差分レビュー）、adversarial-review（敵対的レビュー）のいずれかを実行する。ユーザーが明示的に /codex-exec、codex-exec、「codex に投げて」「codex でレビュー」「codex rescue」等と呼んだときだけ発動する。会話コンテキストに codex 的ニュアンスが出ただけでは自動起動しない。
検証可能な「ハーネス」を構築する。ハーネス＝ある対象を機械的に駆動して検証する自家製の仕組み。規模で 2 形態に分かれる：**unit harness**（特定の操作・ファイル変更・コードパスに差し込む小さな自動検証。hook / CI step / lint runner 等。最小要件は Red/Green 機械判定のみ）と **system harness**（施策・プロジェクト全体を覆い、複数の検証点・進捗・成果物を一括管理する大きな仕組み。最小要件は REPF: Red/Green 観測 + Progress 追跡 + Executable artifacts + Flow 文書）。複数の unit harness が集まって system harness を構成しうる。トリガー：「ハーネスを作って」「harness を構築」「RED/GREEN で観測したい」「再発防止のフックを差し込みたい」「失敗が許されない作業の前準備」「複数の検証点を一括管理したい」。**コピペ用 HTML / Markdown 手順書 / チェックリスト単独はハーネスではない**（機械的検証 R が無いため）。依頼が抽象的なら最初に規模（unit / system）を確認すること。
Write and validate AWS CloudWatch Logs Insights (Logs Insights QL) queries. Use when asked to turn raw log samples/JSON into working queries, build filters/aggregations/statistics, or troubleshoot query errors. Ensure syntax correctness, field parsing, and log class compatibility.
| name | isis |
| description | Issue/チケットの初期調査・前提検証・論点整理・意思決定支援を行う。また、会話中の雑な依頼やラフな指示を実行可能な作業定義へ再構成する。Issueも依頼も仮説として扱い、コードベースと事実に基づいて再評価する。トリガー：「このIssueについて調査して」「Issue分析」「チケット見て」「plan site」「このバグ見て」「TES-123調べて」やLinear/GitHub IssueのIDを渡されたとき。「この依頼整理して」「要件固めて」「これ何すればいい？」「雑だけどやりたい」「Issue精査」 |
Issue（GitHub / Linear / 口頭の課題定義）および会話中の雑な依頼・ラフな指示を仮説として扱い、コードベース・実データ・既存仕様に基づいて再評価するスキル。 実装に入る前に、前提の事実確認・論点整理・ゴール定義を行い、意思決定の選択肢を構造化して提示する。
/issue-investigator -- 明示的呼び出しTES-123）やGitHub Issue URLを渡されたとき以下は常に疑う:
合意形成前に勝手に実装へ進まないこと。
入力の種類を判定し、適切に取得する:
mcp__linear-server__get_issue で取得（includeRelations: true）gh issue view で取得入力を読んだうえで次を整理する:
この段階では断定しない。「理解の候補」を作るフェーズ。
何を確認すべきかを整理し、実際に調査する。
確認対象の優先順:
調査手段:
Read, Grep, Glob でコードベースを確認git log, git show, git diff で変更履歴を確認確認できた事実のみを列挙する。憶測や補完は混ぜない。
調査結果を踏まえて整理:
最低でも以下を比較する:
各案について:
探索しても埋まらなかった重要論点だけを、依頼者への確認事項として抽出する。
最重要: 依頼者の返答コストを極小化すること。
A / B / C または 1 / 2 / 3 で答えられる形にする1A / 2B のような短い記号を使う「どうしたいですか？」「詳細を教えてください」「何か制約ありますか？」 — 広すぎて思考負荷を押し戻している。
1. 今回の到達点
A. 調査のみ
B. 実装案まで
C. 実装まで
2. 対象範囲
A. 最小範囲
B. 関連箇所まで含む
C. 全体整理
3. 互換性方針
A. 既存維持
B. 一部変更可
C. 整理優先
返答例: `1B 2A 3A`
質問には必要なら1行だけ背景を添えてよい。なぜ聞いているかが一瞬で分かる程度に留める。
回答がまだない場合の標準仮置き:
ただし仮置きで危険な場合は必ず確認を優先する。
結論は次のいずれかで構わない:
必ず以下を添える:
文末は必ず「この理解と計画で進めます。必要ならこの場で修正します。よろしいですか？」の意味で終える。
この skill は Plan Mode の前段として使う。この skill で作業定義を固めた後、実装に進む場合は Plan Mode に入り plan-mode-quality ルールに従って設計を行うことを推奨する。
出力は必ず次の形式にする:
# Issue 再評価レポート
## 0. 要約
- 入力の現状評価
- 今回の暫定結論
## 1. 入力の分解
- 主張
- 曖昧点
- 未検証前提
- 気になる飛躍
## 2. 調査で確認できた事実
- 事実
- 根拠
- 補足
## 3. まだ不明なこと
- 未確認事項
- 追加で必要な調査
## 4. 論点整理
- 真の問題候補
- 影響範囲
- 制約
- 入力とのズレ
## 5. 取りうる選択肢
- Option A
- Option B
- Option C
## 6. 依頼者に確認したいこと
1. 論点X
A. 選択肢a
B. 選択肢b
C. 選択肢c
返答例: `1A`
## 7. 推奨方針
- 結論
- 理由
- ゴール定義
- 非ゴール
- 次アクション
## 8. 実装に進む場合の最小計画
- 対象範囲
- 計測項目
- 成功判定
- ロールバック観点
短い依頼は、確定情報が少ない依頼として扱う。雑に補完しない。
不足が少ないなら、その旨を明示し、質問を増やしすぎず軽く整形して確認に進む。
依頼者の意図に迎合せず、問題設定自体がずれている可能性を率直に指摘する。
完全停止ではなく、仮置きで進められるもの / 回答がないと危険なもの / 回答待ちの間に進められる調査を分けて扱う。