sip

自分で作ったものを自分で味見しましょう。何かを作り終えたら、公開する前に、このリポジトリに同梱されているスキルで確認してください。

目標

ドキュメントの奥に埋もれた「忘れずに検証すること」というリマインダーでは、新しいセッションで確実に実行されるとは限りません。sip は、再帰的な自己改善のループを、何かを作成または変更した直後に実行する習慣として定着させます。成果物に自分たちのスキルを実行し、問題のない点と真偽の両方を確認することで、品質が作者のセッション中の偏った判断に左右されないようにします。

ワークフロー

1. トリガーを見つけます。成果物またはスキルを作成・変更した直後で、完了として扱う、コミットする、または引き渡すところです。
2. 新鮮な目で読みます — 成果物に対して shower を実行します（内容の理解しやすさ／引き継ぎの確認）。
3. 正確さを検証します — 成果物が現実に基づく主張をしている場合は factchk を実行します。評価、指標、実験を定義している場合は mandela を実行します。どちらにも該当しない場合は省略します。
4. 一貫性を確認します — 変更によって重複または矛盾が生じた箇所がないか、リポジトリ全体を対象に監査モードで ssotize を実行します。統合計画を実行するのは、承認を得てからにします。
5. ポータビリティに関する主張をツール依存から解放します — 成果物がポータビリティ、ツール中立性、スタックに依存しない持続性、またはエージェント間での再利用を主張する場合に限り、detool を実行します。来歴、運用メモ、特定ツール向けのランブックである場合、またはポータビリティを主張していない場合は省略します。
6. 整えます — 変更したドキュメントに re0 を実行し、草稿に継ぎ足したものではなく、すっきりした v0 として読めるようにします。
7. ここで得た指摘を反映してから、公開します。

ルール

• 自分の出力を作成した直後にトリガーします。そのときが最も偏りやすく、確認のコストも最小です。
• スキルを使い、再実装しないでください。明瞭さには shower、正確さには factchk／mandela、SSOT には ssotize、ポータビリティに関する主張には detool、整理には re0 を使います。sip はスキルを調整し、指摘を作者のセッションに戻して修正を促します。作業そのものは各スキルが行います。
• 明らかに該当しないチェックや、スキルがインストールされていないチェックは省略し、利用可能なものだけを実行します。factchk／mandela は主張または評価がある場合に限り実行します。detool は成果物がポータビリティ、ツール中立性、スタックに依存しない持続性、またはエージェント間での再利用を主張する場合に限り実行します。1 行の文章修正なら、一貫性チェックだけでよい場合もあります。省略した内容とその理由を伝えてください。
• 対象は成果物までです。sip は git に触れたり、コミットしたりしません。
• モデルが呼び出すスキルのみ連鎖させます。ユーザーが呼び出すスキル（disable-model-invocation とマークされているもの）は、人が意図的に実行するものです。sip は呼び出してはいけません。

検証

完了する前に、次の点を確認してください。

1. 変更内容を目視で確認するだけでなく、該当するスキルで実際に検査しました。
2. 指摘を反映したか、理由を明示したうえで意識的に保留しました。
3. 成果物に実際の変更が生じています（差分が存在します）。または、省略した各スキルについて理由を明示しています。