remove-ai-style について
中国語または英語の記事から定型的なAI文体を減らし、事実、構成、書き手の声を保って改稿するスキルです。決定論的な分析と文脈に応じた確認を組み合わせ、編集後の再スキャンを求めます。
主な機能
- 01決定論的な文体分析
- 02指摘箇所の文脈確認
- 03意味を保った書き換え
- 04句読点と対比表現の制約
- 05編集後の再分析と確認
活用シーン
- 01公開前の記事の編集
- 02指摘された文体パターンの確認
- 03定型的な表現の削減
- 04改稿後に残る指摘の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ zc277584121/ marketing-skills --skill remove-ai-styleインストール後、Claude Code で/remove-ai-styleを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/chinese.mdenglish.mdscripts/analyze_ai_style.py詳細
AI らしさを取り除く
2 層のワークフローを使用します。
- 決定論的アナライザーを実行し、繰り返し現れる語彙、句読点、構造、アシスタントの残存表現に関するシグナルを特定します。
- 記事全体を読み、ルールでは判断できない文脈を考慮して判断します。
強力なデフォルト設定を 1 つ適用します。すべての重大度の確定した指摘を修正し、不自然な箇所を書き換え、指摘されていない定型的なリズムも取り除きます。その際、事実、意味、必須の構造、作者が意図した文体は維持します。ユーザーに強度を選ばせたり、軽度、中程度、重度、全面的なモードを提示したりしないでください。
アナライザーの指摘の多くは、文脈に基づく判断が必要です。編集可能な文章では、次の 3 つのルール群を厳守してください。
- すべての感嘆符を削除します。
- すべてのダッシュとして使われている em ダッシュ、en ダッシュ、二重ハイフンを削除します。
- 「不是……而是……」「并非……更是……」「看似……其实……」「not just X but Y」および類似の定型的な二項対比は、直接的な主張に書き換えます。
編集後のアナライザーで、zh-exclamation または en-exclamation、zh-dash または en-dash、zh-binary-contrast または en-binary-contrast の件数をゼロにする必要があります。例外は、コード、URL、Markdown のリンク先、原文のまま残す必要がある文章など、保護された領域のみです。ブランドへの熱意、くだけた口調、書き手が普段使う句読点は、これらの表現を残す理由として扱わないでください。
必須のワークフロー
1. 入力と言語を確認する
Markdown ファイルの絶対パスがあれば、そちらを優先します。ユーザーがテキストのみを提供した場合は、標準入力経由でアナライザーに渡します。
記事が中国語か英語かを判定します。自動判定が誤っている場合、またはユーザーが明示的に言語を指定した場合に限り、自動判定を上書きします。
対応するリファレンスをすべて読み込みます。
2. 決定論的アナライザーを実行する
編集前に実行します。
python3 <skill-root>/scripts/analyze_ai_style.py \
<article-path> \
--language auto \
--format json
レポートには次の項目が含まれます。
- 安定した指摘 ID
- ルールとカテゴリ
- 重大度
- 行と列
- 該当テキスト
- 周辺の文脈
- 推奨される対処
- ルールの繰り返しと文書構造の要約
このコマンドを、コピーした grep の断片に置き換えないでください。同梱のスクリプトが、決定論的な検出ロジックを一元的に担います。
3. すべての指摘を確認する
厳守対象のルール群に該当する編集可能な指摘は、すべて書き換えます。文法的に正しいというだけで、これらの指摘を意図的な表現や誤検出として分類しないでください。
それ以外の報告項目は、次のいずれかに分類します。
confirmed:書き換えるintentional:ジャンルや文体上必要なため残すprotected:コード、引用元資料、構造、その他の保持対象に含まれるため変更しないfalse_positive:変更しないsemantic_review:該当箇所の問題は実在するが、適切な修正方法はより広い文脈に左右される
報告された文脈を読み、判断する前に周囲の段落も確認します。文書全体で語句を一括置換しないでください。
4. 元の記事全体を読む
ユーザーが抜粋のみの処理を明示的に求めていない限り、必ず記事全体を読みます。アナライザーでは、次のようなものを確実に検出できません。
- 新しい表現で書かれた過剰な比喩
- 対称性が強すぎる論旨の構成
- 異なる語彙で繰り返される段落の論理展開
- 作為的な感情の高まり
- 洗練されて見えても、実質的な内容に乏しい曖昧な主張
- 読者の考えを決めつける表現や、読者に代わって要点をかみ砕く文
- 「很清晰」や「很重要」のような、内容を伴わない評価的な形容詞
- 仕組み、数値、例を示さずに重要性を主張する表現
- ジャンルとの不一致
- 作者の文体が均されている箇所
- 疑わしい事実や引用
この意味的な確認には、言語別のリファレンスを使用します。レポートは確認箇所を見つけるための補助資料であり、記事を読む作業の代わりにはなりません。
5. 保護対象の構造を記録する
編集する前に、維持すべき構造を記録します。
- YAML フロントマター
- フェンス付きコードブロック
- 意図的な構造を持つ Markdown テーブル
- 画像とリンク
- HTML コメント
VISUAL_TODOブロック全体- 引用された原文と引用情報
文章をより自然にするためだけに、事実、数値、URL、コード、画像パス、TODO ID、引用先を変更しないでください。
6. 大胆に書き直す
フレーズを置き換えるのではなく、文脈に合わせて編集します。
- 具体的な主語、行動、仕組み、結果を優先します。まず事実を述べ、その後に判断を示します。根拠からすでに明らかなことを強調しないでください。
- メタ的な文章、読者の心情を決めつける表現、ありきたりな重要性の主張、中身のない評価的な形容詞、アシスタントの残滓、装飾的なつなぎ表現を取り除きます。
- 現在のリズムが不自然な場合に限り、リズムに変化をつけます。人間らしさを装うために、スラング、誤り、無作為な断片を加えないでください。
- 意図された語り口、技術的な正確さ、ジャンルに適した構成を維持します。判断を説明のそばに置く場合は、それぞれの判断を事実または仕組みに基づかせます。
- 確認済みの指摘は、資料が許す限り徹底的に解消します。ハード制約ルールのカウントは、保護対象の領域を除いてゼロにする必要があります。
ファイルに対してサブエージェントとして実行された場合は、ファイルを直接編集してから、簡潔な変更報告を返します。書き直しを別のエージェントに委任しないでください。
7. アナライザーを再実行する
編集後、同じコマンドを再実行し、実行前と実行後の概要を比較します。
最終スキャンには、ハード制約ゲートを使用します。
python3 <skill-root>/scripts/analyze_ai_style.py \
<article-path> \
--language auto \
--format json \
--fail-on-hard-constraints
終了ステータス 2 は、スキャン対象の文章に感嘆符、ダッシュ、または定型的な二項対比が少なくとも1つ残っていることを示します。該当箇所がそのまま残す必要のある原文であると確認できない限り、書き直してください。
残った指摘はすべて個別に確認します。ハード制約ではない指摘が残っていても、意図的な表現、保護対象、正確さのために必要な表現、または誤検出として記録されたものなら許容できます。ハード制約の指摘が残っていてよいのは、保護対象であるか、そのまま残す必要がある場合に限ります。
最後に、修正した記事全体をもう一度読み、文章のつながりと語り口を確認します。指摘の数が減っていても、書き直しの質が高いとは限りません。
完了報告
以下を報告します。
- 言語
- 重大度別の実行前/実行後の指摘数
- ハード制約ルールのカウントがゼロになったことの確認、または保護された原文の例外の正確な一覧
- 対処した確認済みルール
- 残した意図的な指摘、または保護対象の指摘
- 全体を読み直して初めて見つかった重要な意味上の変更
- 保護対象の Markdown 構造が維持されたことの確認
- 人による確認が必要な事実または引用情報の問題