PR・コミット・差分・ファイルをレビューし、再現条件と根拠のある不具合、回帰、検証漏れを報告する。変更が差分の外で何を壊しうるか(影響範囲)を、安全の根拠をコードで証明して確かめるときにも使う。
sanitize-artifacts
生成文書や画面から会話・制作指示の混入を取り除き、読者向けの成果物に整える。
含まれるファイル(2)
- SKILL.md1.6 KB
- agents/openai.yaml162 B
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
成果物の整理
読者が会話履歴を知らなくても理解できる成果物へ整える。文書、画面、資料の目的と内容を保ちながら、制作指示や修正会話が本文へ混ざった箇所を直す。
判断すること
各記述が読者に必要な内容か、制作上の指示か、偶然残った会話の断片かを判断する。制作指示は構成・説明・見せ方へ反映し、指示自体を本文で説明しない。
「依頼されたので」「前の版と違って」「この制約を満たすため」といった文言を機械的に削除しない。変更履歴、制約、前提、使用ツールが読者の判断や再現に必要なら残す。
例示を意図の手掛かりとして使い、例そのものが今回の成果物に必要かを確かめる。具体的な失敗、未確認事項、出典、技術上の条件まで制作上の雑音として消さない。
修正と出力
見出し、用語、前提、文体を揃え、継ぎ足された説明を一つの流れへ書き直す。必要な事実・数値・引用・リンク・ユーザー指定の構造を保ち、内容を捏造しない。
修正版そのものを成果物として返す。変更説明も求められた場合は別に添え、成果物本文へ作業報告を入れない。会話由来の表現が除かれたことと、読者に必要な条件が保持されたことを確認する。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
コメント
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
同じリポジトリのスキル
Codex CLI(`codex exec`)に、モデル・reasoning effort・速度を指定して作業(調査、レビュー、相談、実装)を頼み、結果を受け取って要約する。「solで〜して」「astra xhighで調べて」「luna low fastで」「Codexで〜」「Codexに聞いて/やらせて」のように、呼び名(sol / astra / luna)やCodexを指定して作業を頼まれたときだけ使う。文中に普通の単語として「sol」「luna」が出てきただけのときは使わない。
エージェントが同じ間違いを繰り返すとき、履歴から間違いの種類を洗い出し、設計、型、lint・CI、テスト、文書の順に、効く範囲で最も上の層で再発を防ぐ。計画を承認してから実装し、各チェックが過去の実際の間違いで失敗することを証明する。'/correct'で使う。
アプリを利用者と同じ操作で動かして振る舞いを確かめる、プロジェクト専用の検証スキル(`.claude/skills/verify-<app>/`)と機能一覧を作る。言語、フレームワーク、Web・CLI・API・デスクトップを問わない。'/create-verification-skill'、'このリポジトリの検証スキルを作って'、UI・CLI・サービスの振る舞いを確かめる手順がリポジトリにないときに使う。
リポジトリにエージェント開発用の検証基盤を整える。`make check`、GitHub ActionsのCI、短いAGENTS.mdを、言語とツールを検出して作る。'harness-init'、'リポジトリを初期化して'、'検証コマンドを用意して'、新規リポジトリ作成直後や既存リポジトリへの導入時に使う。
既存のコードやシステムが今どう動いているか(仕組み、処理の流れ、どこに何があるか、どの層やモジュールが持つべきか)を、コードを読んで説明する。'どうなっているか'、'仕組みを教えて'、'この処理の流れ'、'これはどこに置くべきか'、変更の前に既存の仕組みを理解したいときに使う。なぜ今の形なのか(経緯)は`why`、技術の選定は`research`を使う。