sanitize-artifacts

sanitize-artifacts

ユーザーが、現在の作業セッションで作成された成果物の確認、整理、サニタイズ、改訂、推敲、品質チェックを依頼したときに、このスキルを使用します。

反復的なプロンプト、修正指示、例、制約、またはバイブコーディング形式の共同作業を通じて作成された成果物では、特に重要です。

目標

成果物を、単独で一貫性のある最終版として成立するように改訂します。

成果物には、次のような不要な痕跡を残さないでください。

• ユーザーのプロンプト
• 会話の履歴
• 中間的な推論
• 実装上の制約
• ツールの選択
• 採用しなかった手法
• プロンプトエンジニアリングの指示
• 作成時に使用した足場
• 意図を伝えるためだけに提示された例
• 会話中に寄せられた修正フィードバック

最終成果物は、それを生み出した会話から組み立てられたものではなく、本来の対象読者に向けて意図的に設計されたものに見える必要があります。

基本原則

会話は制作の背景情報として扱い、自動的に成果物の内容に含めないでください。

成果物内の記述を残す前に、次のいずれかに分類してください。

1. 成果物の対象読者が本当に必要とする、読者向けの内容
2. 成果物に反映させるべきだが、表には出さない制作上の指針
3. 削除すべき、会話に付随して生じた不要な内容

成果物に直接含めるのは、カテゴリ 1 のみです。

カテゴリ 2 は、構成、文体、対象範囲、前提、既定値、例、命名、設計上の選択に間接的に反映してください。

カテゴリ 3 は削除してください。

削除または書き換える内容

次のようなことを、不要に述べたり示唆したりしていないか確認し、削除または書き換えてください。

• 「ご要望に応じて……」
• 「ご指示に基づき……」
• 「……は使用しません」
• 「これを避けるため……」
• 「前のバージョンとは異なり……」
• 「ユーザーは……を求めました」
• 「この文書では……を前提としています」
• 「制約があるため……」
• 「Git／Homebrew／CLI などは使用しません」
• 「これは……に変更されました」
• 「プロンプトには……とあります」
• 「これまでの会話では……」
• 「このセクションは……のために追加されました」
• 「要件を満たすため……」

機械的に削除しないでください。対象読者が本当に知る必要がある場合に限り、残してください。

例と意図

ユーザーが意図を伝えるために例を提示した場合、成果物自体にその例が必要でない限り、例をそのまま成果物に含めないでください。

会話で提示される例は通常、最終成果物の内容ではなく、意図を把握するための材料です。

例から次の点を読み取ってください。

• 求められる抽象度
• 対象読者
• 文体
• 避けるべき情報漏洩の種類
• 不自然な表現の種類
• 重要な設計上の制約

例が誤って成果物の主題にならないようにしてください。

制約は通常、表に出しません

ユーザーの制約は、明示的な免責事項として書くのではなく、通常は成果物の設計に反映してください。

例：

悪い例：

このガイドでは、Git、Homebrew、追加の CLI ツールを使用しません。

良い例：

Google Drive を使ってプロジェクトフォルダーを共有します。

良い例では、制作上のルールを明かさずに制約を反映しています。

確認チェックリスト

成果物をサニタイズする際は、次の点を確認してください。

1. 会話を見ていない人にも自然に読めますか？
2. なぜこのように書かれたのかを説明する不要な文はありませんか？
3. ツール、除外事項、制約、採用しなかった代替案への不要な言及はありませんか？
4. プロンプトの例が誤って成果物に含まれていませんか？
5. 複数回のフィードバックを継ぎ接ぎしたような箇所はありませんか？
6. 文体、用語、前提は全体を通して一貫していますか？
7. 見出しや注記は作成者ではなく、成果物の対象読者に向けて書かれていますか？
8. 制作過程にのみ属するメタコメントは含まれていませんか？
9. 免責事項や注意書きは、対象読者が本当に必要とするものに限られていますか？
10. 全体を通して一貫した語り口になっていますか？

改訂方針

説明するより、書き直すことを優先してください。

ユーザーから求められない限り、削除・修正した内容についての報告を追加しないでください。

編集時は、成果物の本来の目的、技術的な正確さ、ユーザー向けに必要な要件を維持してください。

制作過程の名残は、自然な成果物の設計に置き換えて取り除いてください。

例：

• 「高度な用語を使わない」を、より簡単な表現に置き換える。
• 「CLI のブラックボックスを避ける」を、明確で具体的な手順に置き換える。
• 「Git ではなく Google Drive を使う」を、Google Drive を使ったワークフローの指示に置き換える。
• 「初心者向け」を、適切な進行、定義、例で実現する。
• 「X に言及しない」を、X を省略することで実現する。省略したことを述べない。

出力ルール

成果物のサニタイズを依頼された場合は、修正後の成果物そのものを出力してください。

次のような、作業過程についての説明を成果物の前に付けないでください。

• 「メタ指示を削除しました。」
• 「プロンプトの漏えいを修正しました。」
• 「サニタイズしたバージョンはこちらです。」

明確さのために必要な場合に限り、簡潔なラベルを付けてもかまいません。

サニタイズした成果物と変更概要の両方を求められた場合は、先に成果物を出力し、その後に概要を記載してください。

品質基準

サニタイズ後の成果物は、意図が明確で一貫性があり、対象読者に自然なものにしてください。

成果物の一部として実際に必要な情報でない限り、読者がプロンプトの経緯、内部制約、修正のやり取りを推測できないようにしてください。