humanize

name	humanize
description	LLM生成文に特有の表現パターンを検出・修正する。任意のテキストファイルに対して使える。「LLMっぽい」「人間らしく」「humanize」で起動。
user-invocable	true
allowed-tools	Read, Write, Edit, Bash, Glob
argument-hint	<file-path>

ヒューマライザー

対象ファイル: $ARGUMENTS

$ARGUMENTS 未指定なら案内して終了。 指定されたファイルが存在しなければエラーを案内して終了。

A. トーン基準の把握

修正案のトーンを決めるために、まず基準を取得する。

1. output/ 配下のファイルの場合: output/<プロジェクト名>/write/write-plan.md が存在すれば読み込み、「文体方針」セクションのトーン・語尾・参考スタイル・避けるべきことを把握する。write-plan.md で意図的に許容されている表現（例:「〜してみてください」）はパターン検出の対象外とする。
2. write-plan.md が存在しない場合: ユーザーに「どんなトーンの文章ですか？」と確認する。例: 技術ブログ（簡潔・事実ベース）/ エッセイ（語りかけ調）/ ドキュメント（客観的・硬め）など。

取得したトーン基準は、ステップC以降の修正案生成に使う。

B. パターン読み込み

patterns.md を読み込み、検出パターンと修正案のアンチパターンを把握する。

C. スキャン・診断

対象ファイルを読み込み、patterns.md の各カテゴリに照らしてスキャンする。

判断の原則:

• 1箇所の使用は許容する。繰り返し・集中して現れるパターンを重視する
• 文脈に応じて自然な場合はフラグを立てない
• カテゴリ6（結びの定型表現）は1回でも検出対象とする
• ステップAで把握したトーン基準に沿った表現はフラグを立てない（筆者が意図的に選んだ文体を尊重する）

D. 診断結果の提示

カテゴリごとに以下の形式で提示する。修正案はステップAで把握したトーン基準に合わせる。 patterns.md の「修正案のアンチパターン」も参照し、修正案自体がLLMの別の癖に寄らないようにする。

### カテゴリN: カテゴリ名（深刻度: 高/中/低）

> 該当箇所の引用

**問題**: なぜこの表現がLLMっぽく見えるか
**修正案**:
- Before: 該当箇所
- After: 書き換え案

• 該当がないカテゴリは省略する
• 全カテゴリで問題なしの場合は「LLM特有のパターンは検出されませんでした」と報告して終了

E. 対話的な改善

診断結果を元にユーザーと対話し改善する:

• 修正案をユーザーに提示し、採用・修正・却下を確認する
• ユーザーの文体や意図を尊重し、機械的な置換はしない
• 必要に応じて複数の書き換え案を提示する

F. 修正の適用

ユーザーが承認した修正を対象ファイルに適用する。

対象ファイルが output/ 配下の場合:

• プロジェクト名をパスから推定する（output/<プロジェクト名>/...）
• output/<プロジェクト名>/write/humanize-log.md にログを保存する。フォーマットは templates/humanize-log.md を参照。

完了条件

• LLM特有のパターンが検出・提示されている
• ユーザーと対話して修正方針が合意されている
• 承認された修正がファイルに適用されている
• output/ 配下のファイルならログが保存されている

改善余地があれば再度 /humanize $ARGUMENTS を案内。