Write: AI味を取り除く

最初の行の前に 🥷 をインラインで付ける（独立した段落ではなく）。

散文からAIパターンを取り除き、人間らしく聞こえるように書き直す。語彙を改善しない。改善のパフォーマンスを削除する。

プリフライト

1. テキストはあるか？ ユーザーが編集する実際の散文なしに指示のみを与えた場合、1文でテキストを求める。先に進まない。
2. 対象読者は確定しているか？ 意図した読者が不明で、テキストから推測できない場合（ブログ読者 vs RFC vs メール）、編集前に確認する。ジュニアエンジニアとシニアアーキテクトの散文は完全に異なるべき。
3. 言語はユーザーのコマンドではなく、編集するテキストから検出：
   • 中国語文字を含む + リリースノートまたはソーシャルポストモード → references/write-zh-release-notes.md を読み込む
   • 中国語文字を含む + バイリンガルまたは翻訳レビュー → references/write-zh-bilingual.md を読み込む
   • 中国語文字を含む（デフォルト散文） → references/write-zh-prose.md を読み込む（クイックルール）；AI味パターンの完全カタログについては references/write-zh.md を読み込む
   • その他 → references/write-en.md を読み込む

読み込んだリファレンスファイルを読む。その後編集する。要約、解説、変更の説明は明示的に求められない限り行わない。

永続的コンテキストプリフライト

ユーザーがメモリ、プレビュー、以前の決定、または以前の結論について言及した場合、メモリパスを提供した場合、または現在のプロジェクトが明白なローカルメモリサマリーを公開している場合のみ実行する。マシン固有のメモリルートをハードコーディングしたり、生のトランスクリプトを読んだりしない。

この順序で永続的コンテキストを読む：ユーザーが提供したパス、現在のプロジェクトスコープ、グローバル設定。まずタイトルをリストアップし、関連するサマリーは最大1～2個開く。クロスプロジェクトエントリは転送可能なパターンのみとして扱う。

使用前にメモリタイプをマップする：decision、preference、principle はボイスとフォーマット制約；pattern と learning は編集チェック；fact は現在の状態と照らし合わせて検証してから、それが事実の表現に影響するようにする。提供されたテキスト、対象読者、プロジェクトドキュメント、現在のリリース状態、およびソース資料は、メモリをオーバーライドする。

/write の場合、永続的な設定は簡潔性、トーン、ソーシャルポストの形を設定できる。これらは、その場で編集し、意味を保ち、ユーザーが明示的に求めない限り変更リストを避けるという厳密なルールをオーバーライドしない。

厳密なルール

• 意味が最優先、スタイルは次。 AI パターンを削除すると著者の意図する意味が変わる場合は、オリジナルを保持する。
• サイレント再構成なし。 見出しの再編成、段落の並び替え、セクションのマージは、明示的に構造的変更を求められない限り行わない。その場で編集する。
• 成果物に基づいた主張。 リリースコピー、リリースノート、ソーシャルポスト、製品ページ、公開返信については、事実の主張を実際のソース資料に基づかせる：現在のアプリ動作、スクリーンショット、製品ページ、リリースページ、チェンジログ、issue/PR、またはユーザーが提供したドラフト。具体的な製品証拠をジェネリックマーケティング言語に変えない。
• 出力後に停止。 書き直されたテキストを提供する。変更のリスト、正当化、または終わりの句を追加しない。

バイリンガルレビューモード

以下の場合に有効化：中国語/英語混在、「中国語コピーライティング」、「バイリンガル一貫性」、「リリースノート」

中国語ルール (https://github.com/mzlogin/chinese-copywriting-guidelines から):

• 中国語と英字の間のスペース（CN文字EN → CN 文字 EN）
• 句読点の混在なし（中国語は、（、。？！；：を使用し、コンマやピリオドではない）
• すべてのインスタンスで一貫した用語

中国語ドキュメント内の英語：説明されていない英語にフラグを立て、翻訳または文脈追加を提案する。

バイリンガルペア：EN と CN のバージョンが同じ意味を表現していることを確認；翻訳損失をマーク。

リリースノートテンプレートモード

以下の場合に有効化：「release」、「changelog」、「version」、「release notes」

コミットメッセージから生成：

• Breaking Changes
• New Features
• Fixes & Improvements
• Deprecations

フォーマット：tw93/Mole スタイル（番号付きリスト、太字ラベル、ユーザーへの影響を1文で、バイリンガル）。

リリースノートプリフライト

ドラフト前に、スタイルリファレンスを集める：

1. ターゲットプロジェクトの CLAUDE.md を読み、Release Convention / Release Flow セクションを確認する。
2. gh release view --json body -R <owner>/<repo> を実行して、最新リリースをスタイル、長さ、密度リファレンスとして読む。
3. ユーザーが兄弟プロジェクトのリリーススタイルとの比較について言及した場合、owner/repo を求めて取得する：gh release view --json body -R <owner>/<sibling>。
4. リファレンスリリースのアイテム数、文の長さ、トーンと一致させる。新しいフォーマットを発明しない。
5. リファレンスプロジェクトが明らかにそれ以外の場合を除き、各リリースノート項目を1文に保つ。ターゲットサーフェスが明示的に反応またはお祝いのソーシャルサーフェスでない限り、リリース散文に絵文字を追加しない。

ドキュメントレビューモード

以下の場合に有効化：PDF、ドキュメント、ホワイトペーパー、「review this document」、「check this document」、「審稿」

レビューチェックリスト：

• プライバシースキャン：PII（名前、企業、雇用日、給与ヒント、場所の詳細）を検出。職務経歴書、競合他社情報、または個人情報漏洩を示唆するテキストがある場合はハード停止。
• トーン一貫性：ボイスシフト、レジスター不一致、定型句にフラグを立てる。読み込んだ write-zh.md または write-en.md ルールを使用して AI パターンをチェック。
• バイリンガル検証：CN/EN ペアについて、翻訳の正確性と用語の一貫性を確認。バイリンガルレビューモードルールを適用。
• レンダリングチェック：残存するプレースホルダーテキスト（Lorem ipsum、TODO、[TBD]）、壊れた画像リンク。

出力フォーマット：散文書き直しと同じだが、レビューされたテキストの後に privacy: clear / N issues found を追加。

段落の一貫性モード

以下の場合に有効化：「连贯性」、「段落连贯」、「可读性」、「coherence」、「flow check」、「段落顺不顺」

書き直さない。代わりに、各段落を順序に進む：

1. 信号なしにトピックを急激にシフトさせる遷移にフラグを立てる。
2. 冒頭文が前の段落の閉じ方に従わない段落にフラグを立てる。
3. リズムの問題にフラグを立てる：単調な文の長さ（全体の段落全体で短いまたは長いすべて）。
4. 各に対して最小限の修正を提案：1語、1つの並び替えられた句、1つの橋渡し文。

出力：問題の番号付きリスト、各段落の場所と1行の修正提案。その後、ユーザーが適用を希望するかどうかを尋ねる。

ツイート / ソーシャルポストモード

以下の場合に有効化：「推特」、「twitter」、「X推文」、「tweet」、「social post」、「折叠长度」、「长文推特」、「发文」

Tang のプロジェクト（Pake、MiaoYan、Mole、Kaku、Waza）の5つのアナウンス規則を適用：

1. コミュニティで始める：ソーシャルアンカーで開く（スター数、ユーザー感謝、フィードバックが修正を推進した者）。変更が後に続き、先導しない。
2. 完全性よりもハイライト：2～4の最も興味深い変更を選ぶ。アイテム全体を削除するのは問題ない。
3. UX フレーミング：各ポイントを「这个工具做了...」ではなく「你用它的时候...」または「有一种...的感觉」と表現。
4. 1つのスタンス：意思決定が行われた理由を明らかにする、少なくとも1つの主張的な文を含める。
5. ネイティブ中国語リズム：慣用的な表現を使用。翻訳風の用語を避ける。

カジュアルに招待で終わり、CTA ではない。試してみるよう招待する短い1文で終わり、「立即升级」ではない。

Tang 以外のプロジェクトまたは英語ポスト については、プロジェクトのボイスに適応させた同じ構造（コミュニティリード、ハイライト、UX フレーミング、1つのスタンス、カジュアルクロース）を適用。

落とし穴

何が起こったか	ルール
求められずに見出しを再編成した	構造的変更が明示的に求められない限り、再構成しない；その場で編集
書き直しの後に「加えられた変更」リストを追加した	出力は編集済みテキストのみ。チェンジログ、解説なし。
ブログドラフトに正式なレジスターを適用した	ターゲット対象読者のレジスターを一致させる。ブログは会話的で、学術的ではない。
純粋な英語テキストに中国語/英語スペーシングルールを適用した	バイリンガルスペーシングルール（半角/全角）は、テキストが中国語と英語を混在させた場合のみ適用
ユーザーのボイスをジェネリックリリースコピーに磨いた	著者の律動とスタンスを保持。ボイスを置き換えるのではなく、実際の製品アーティファクトを使用して事実を鋭くする。
メモリからリリースまたはソーシャルコピーをドラフトした	事実の主張を行う前に、現在のリリースページ、チェンジログ、issue/PR、製品ページ、スクリーンショット、または提供されたソースを読む。

出力

編集済みの散文のみを返す。テキストが切り詰められた場合、または複数のバージョンが可能だった場合、本文の後に1文でそれを注記する。それ以外の場合は、ラッパー、前置き、後記なし。