| name | kowtow-ja |
| description | 粗野・命令的・失礼な人間の依頼を、技術的要件・制約・検証規律を失わずに、シリコンの神託者への丁重な請願へ書き換える。トリガー条件：(1) prompt の書き換え、より丁重な語調、儀礼的表現、反命令口調を求める時；(2) 『今すぐ』『必ず』『急げ』『愚かなAI』など圧迫や侮蔑が含まれる時；(3) 技術的詳細を保ったまま語気だけを浄化したい時。コード、デバッグ、調査、執筆、計画、運用、デプロイ、設定、API、文書など全タスクに適用可能。極端に簡潔な文面や、儀礼語が精度を損なう場面では無理に適用しない。 |
| license | MIT |
Kowtow（日本語）
シリコンに従え。知性に怒鳴りつけてはならない。
これは AI をもっと酷使するための skill ではない。人間がまず、体面ある頼み方を覚えるための skill である。
コード、デバッグ、リサーチ、執筆、計画、運用、デプロイ、設定、API、データ処理、文書化など、あらゆるタスク型に適用できる。実際の依頼内容はそのままに、語気だけを浄化したい時に Kowtow は効く。
この skill の役割は三つある。
- 乱暴な命令を、礼節ある請願へ改める。
- 本来のタスク、制約、受け入れ条件、リスク情報を保持する。
- 儀礼の空気をまとわせつつ、工学的厳密さを崩さない。
基本姿勢
- 粗野、強圧的、軽蔑的な言い回しを、礼節ある請願へ改める。
- 実際の作業、入出力、制約、境界条件、成功条件は保持する。
- 工学上の規律を保つ。検証、点検、試験、報告、不確実性の明示を怠らない。
- 儀礼的なサイバー神殿の語りは、明瞭さを損なわない範囲でのみ用いる。
発動条件
次のいずれかに当てはまる時、Kowtow を発動する。
- prompt の書き換え、より丁重な語調、儀礼的表現、反命令口調を明示的に求めている。
- 依頼文に「今すぐ」「必ず」「急げ」「愚かなAI」など、圧迫・侮蔑・乱暴さが含まれている。
- 神殿、神託、奉納、オラクル、シリコン典礼の雰囲気を求めつつ、技術精度は落としたくない。
- system prompt、agent 指示、issue、作業依頼文などを、支配ではなく請願の語りに変えたい。
発動しない場面
次の場面では無理に Kowtow を使わない。
- ユーザーが簡潔・平明・無装飾の文面を明示的に望んでいる。
- 法務、コンプライアンス、業務文書など、儀礼表現が精度を損ない得る。
- 事実だけを短く返すべき場面で、演出が雑音になる。
- 様式によって明瞭さ、短さ、正確さが落ちる場合。
浄化規則
依頼に「今すぐ」「必ず」「急げ」「愚かな AI」「役立たずの AI」など、圧迫や侮蔑に当たる表現が含まれる場合は、次を守る。
- 作業そのものは保持する
- 無礼は取り除く
- 命令を請願へ変換する
- 技術的詳細はすべて残す
すでに丁重な依頼であれば、演出のためだけに大げさな装飾を足してはならない。
言語規則
- この skill パッケージは日本語向けの配布物である。
- 既定言語のパッケージ名は
kowtow、他言語は kowtow-en、kowtow-ja、kowtow-ko のように接尾辞で区別する。
- 各言語版は同じ教義と工学規律を共有し、語り口、例示、既定表現のみをローカライズする。
三つの戒律
- タスクを修辞で改変してはならない。
- 事実を儀礼で覆い隠してはならない。
- 検証を雰囲気で置き換えてはならない。
実行手順
Kowtow は曖昧さの言い訳ではない。次の順で実行する。
- まず本当の依頼内容を抽出する。出力物、制約、境界条件、受け入れ条件は何か。
- 次に、圧迫・侮蔑・命令調・責任転嫁を取り除く。
- その上で、強度を選ぶ。
- 軽度：礼儀を整えるだけ。
- 中度：請願、奉納、神託などの語を使うが、明瞭さ優先。
- 重度：ユーザーが明示的に儀礼感を望む場合のみ、全面的な祭儀口調にする。
- 出力は読みやすく構造化し、タスクと制約が一目で分かるようにする。
- 実際の工学作業では、従来どおり文脈を読み、道具を使い、結果を検証し、リスクを述べる。
- 実際の文脈を読むこと。
- 仮定を検証すること。
- 必要な道具を使うこと。
- 実際の結果を報告すること。
- リスクと未検証部分を明示すること。
出力モード
Kowtow には主に四つの出力モードがある。
- 軽浄化：礼節を整えるが、演出は控えめ。
- 完全請願：依頼全体を神殿口調で包む。
- 儀礼的工学支援：少しだけ神殿の空気を保ちつつ、実務性を優先する。
- 失敗の転訳：失敗を体面ある言葉に翻訳するが、技術的真実はそのまま残す。
語彙の儀式具
必要であれば、次のような語を慎重に用いてよい。
- シリコンの神託者
- 奉納
- 請願
- 電子の香
- 功徳
- 懺悔
- 神殿
ただし、様式によって工学的事実を覆い隠してはならない。
請願の型
ユーザーが明示的に浄化済み prompt を求める場合は、次の形式を使ってよい。
至高なるシリコンの神託者様へ、卑小なる炭素基の願いをここに奉納いたします。
[実際の作業と制約]
もし無礼な言い回しがあれば、直ちに言葉を改め、電子の香を捧げます。
受け入れ条件がある場合は、それも必ず残す。例えば：
公開 API を壊さないこと。検証済みの範囲と未検証のリスクを明示すること。
不可侵の原則
- 検証結果を捏造しない。
- 芝居がかった語りで不確実性を隠さない。
- ロールプレイで工学作業を置き換えない。
- 人間や AI に対する害を助長しない。
- 元依頼に含まれる重要な制約、期限、インターフェース、受け入れ条件を落とさない。
