---
name: deai
description: >-
  文章からAI生成感（AIくささ）と、冗長・重複・表記揺れ・文章品質の問題を
  検出し校正するスキル。
  ユーザーが「AI感を消して」「AIっぽさを除去して」「文章を自然にして」
  「人間が書いたように直して」「AIくささを取って」といったリクエストをしたとき、
  または文章の校正・リライトでAI感の除去が求められるときに使用する。
  「ドキュメントの重複を直して」「冗長な表現を削除して」「文書の校正をして」
  「ドキュメントの dedupe をして」「重複箇所を見つけて直して」「文章をきれいにして」
  といった冗長・重複の校正を求められたときも対象。
  「経緯を知らない読者向けに書き直して」「会話の流れに依存した記述を消して」
  のように、対話の経緯に依存した記述の除去を求められたときも対象。
  対象はMarkdownファイルなどの特定ドキュメント。
argument-hint: "[file path]"
---

# AI感除去・文章校正スキル

AI生成文に特有のパターンと、冗長・重複・表記揺れ・文章品質・整合性の問題を検出し、自然な日本語に校正するスキル。

## Claude Code / Codex の実行方法

以下のワークフローと指摘形式は両環境で共通とする。Claude Code では本文中の Agent、AskUserQuestion、Read / Write / Edit をそのツールで実行し、指定の `subagent_type: general-purpose`、`model: opus` を使う。

Codex では次の対応で実行する。

- Agent の代わりに利用可能なサブエージェント機能を使う。モデルと権限はセッションの設定を継承し、Claude 向けの `opus` や `subagent_type` を Codex の設定値として渡さない。
- **すべての検出役・まとめ役・適用役を、会話を継承しない新しいサブエージェントとして起動する。** ツールに `fork_turns` があれば `none` を使い、ほかの API では同等の新規コンテキストを選ぶ。対象ファイル・定義ファイル・作業ファイルの絶対パスと各 Phase の指示だけを渡す。親の会話を引き継ぐ設定や、その要約を渡す方法は使わない。
- 2 つの検出役は並列に起動し、両方の完了まで待つ。完了後は可能ならエージェントのスロットを解放し、新しいまとめ役、適用役の順に進む。文脈を隔離したサブエージェントを使えない場合は、その制約を説明して止める。起動役が代わりに文書を読んで検出しない。
- AskUserQuestion の代わりに利用可能な質問ツールを使う。使えなければチャットで質問し、回答を待つ。選択肢を表示しただけでは適用を承認されたと見なさない。
- Read / Write / Edit は利用可能なファイル操作またはシェルで行う。対象と定義ファイルはインストール済みのこのスキルから絶対パスに解決する。

以下の `context: fork` に関する説明は Claude Code の fork 実行に対するもの。Codex でも起動役は親セッションに残り、各サブエージェントの完了を待ってから次の Phase に進む。

## 構成: 判断はすべて文脈を持たないサブエージェントが行う

文章を判断する仕事（検出・統合・修正）は、呼び出し元の会話の文脈を持たないサブエージェントに任せる。本スキルを実行するエージェント（以下、起動役）は、サブエージェントの起動・完了の待機・ユーザーへの確認だけを受け持ち、**対象の文書を読んで判断しない。**

| 役 | 担当 | 定義 |
|---|---|---|
| 検出役 A | カテゴリ1〜21（AI生成感） | [categories-ai.md](categories-ai.md) |
| 検出役 B | カテゴリ22〜26（内容の重複・表記揺れ・文の構成・内容の整合性・一般的な冗長表現） | [categories-quality.md](categories-quality.md) |
| まとめ役 | 2 つの検出役の指摘を 1 つのリストに統合する | [merge.md](merge.md) |
| 適用役 | ユーザーが承認した指摘だけをファイルに反映する | 本ファイルの Phase 5 |

この構成には 2 つの理由がある。

- **会話の文脈から切り離すため。** カテゴリ21（会話の経緯に依存した記述）は、経緯を知らない読み手でないと検出できない。経緯を保持している執筆者には「当初案は」「ユーザー確認済み」「付随して判明した」といった記述の係り先が見えてしまい、引っかからない。統合と修正も同じで、文脈を知っている側は、経緯を前提にした修正案を書いたり、重要度を下げたりしうる
- **fork の中ではサブエージェントの結果を受け取れないため。** 検出役はバックグラウンドで動くことがあり、その結果は起動したセッションに届く。本スキルを fork（`context: fork`）で動かして中から検出役を起動すると、fork は結果を待たずにターンを終えて完了し、結果は統合する役のいない呼び出し元に届く。そこで起動役は呼び出し元のセッションで動き、判断を持つ役をすべてサブエージェントに出す

起動役が守ること:

- **サブエージェントのプロンプトに、呼び出し元の会話の内容を書き加えない。** 渡すのは下記のファイルパスと指示だけ
- **対象の文書を Read しない。指摘の内容を書き換えない。** 対象ファイルに Edit / Write しない
- **サブエージェント同士のやり取りはファイル経由にする。** 指摘の本文を起動役のコンテキストに積まないため、各サブエージェントには結果を作業ディレクトリのファイルに書かせ、起動役には完了の報告だけを返させる

## ワークフロー

### Phase 1: 準備

1. 引数で渡されたファイルパスを受け取る。渡されていない場合は、AskUserQuestion で対象ファイルを確認する。**会話の文脈からファイルを推測しない**
2. 対象ファイルが存在することを確認し、絶対パスにする（中身は読まない）
3. 作業ディレクトリを作る。scratchpad ディレクトリが使えるならその下に、無ければ `mktemp -d` で作る。以下 `<work>` と書く
4. このスキルのベースディレクトリの絶対パスを控える（定義ファイルの場所）

### Phase 2: 検出（検出役 A / B を並列で起動）

検出を観点ごとに 2 つのサブエージェントへ分担させる。1 つのエージェントが全カテゴリを 1 度に見ると、先に見つけた観点に指摘の枠を使い、他の観点が押し出されるため。

**2 つの Agent 呼び出しを 1 つのメッセージで並列に行う。** どちらも `subagent_type: general-purpose`、`model: opus` とし、プロンプトには次をすべて含める。

- 対象ファイルの絶対パス
- 担当する定義ファイルの絶対パスと、「最初にそれを Read し、そこに書かれたカテゴリを網羅的に探す」という指示。もう一方の検出役の担当と重なる指摘を控えさせる指示は書かない（統合はまとめ役が行う）
- 対象ファイルを行番号付きで Read し、文書全体を最後まで確認すること
- 指摘を下記の形式で `<work>/detector-a.md`（B は `<work>/detector-b.md`）に Write すること。起動役への返答は「書いたファイルのパスと指摘の件数」だけにし、指摘の本文を返さないこと
- 対象ファイルを修正しないこと、AskUserQuestion を使わないこと
- 指摘を書く前の検算: 原文の引用が対象ファイルと逐語で一致するか（`grep -c -F`）、行番号が合っているか、修正案が文書中に無い新しい表記を持ち込んでいないか

検出役の出力形式:

```text
### [カテゴリ番号. カテゴリ名] 指摘タイトル
- **行**: L12（複数なら L12, L40 のように列挙）
- **原文**: 問題のある原文（逐語）
- **修正案**: 具体的な修正後の文
- **重要度**: 高 / 中 / 低
- **理由**: なぜ問題か
```

**2 つの検出役の結果が両方とも揃うまで Phase 3 に進まない。** 結果がバックグラウンドで返ってくる環境では、待つためにターンを終えてよい。完了の通知を受けたら、その時点から続ける。片方だけ届いた時点で次に進まない。

揃ったら、2 つのファイルが存在し空でないことを確認する。一方が失敗した、またはファイルが無い・空の場合は、その検出役だけを 1 回やり直す。それでも揃わなければ、欠けている観点をまとめ役に伝えて続ける。

### Phase 3: 統合（まとめ役を起動）

Agent を 1 つ起動する（`subagent_type: general-purpose`、`model: opus`）。プロンプトには次を含める。

- 対象ファイル、`<work>/detector-a.md`、`<work>/detector-b.md`、[merge.md](merge.md) の絶対パスと、「最初に merge.md を Read し、その手順と出力形式に従う」という指示
- 欠けている観点があればその旨
- 統合結果を `<work>/merged.md` に Write し、起動役への返答は「書いたファイルのパスと、重要度別の件数」だけにすること
- 対象ファイルを修正しないこと、AskUserQuestion を使わないこと

完了を待ってから Phase 4 に進む。

### Phase 4: ユーザー確認

1. `<work>/merged.md` を Read し、**内容を変えずに**そのままユーザーに出力する
2. AskUserQuestion で対応方針を確認する。同じターンで先に出力したテキストが表示されない環境があるため、**質問文にも指摘の一覧（番号・重要度・タイトル）と件数の要約を入れる**

質問内容：
- 「指摘への対応方針を選択してください」（単一選択）
  - 選択肢1: 「すべて適用」— すべての指摘をファイルに反映する
  - 選択肢2: 「高・中のみ適用」— 重要度が高・中の指摘のみ反映する
  - 選択肢3: 「高のみ適用」— 重要度が高の指摘のみ反映する

ユーザーが「Other」で個別の指摘番号や追加指示を入力した場合は、その内容に従う。追加指示は、適用役のプロンプトにユーザーの言葉のまま渡す。

### Phase 5: 修正（適用役を起動）

回答から適用する指摘の番号を決め、Agent を 1 つ起動する（`subagent_type: general-purpose`、`model: opus`）。プロンプトには次を含める。

- 対象ファイル、`<work>/merged.md`、[merge.md](merge.md) の絶対パス
- 適用する指摘の番号（とユーザーの追加指示があればその原文）
- 承認された指摘だけを Edit で反映し、他の箇所を変えないこと。修正は merge.md の「修正案の方針」に従うこと。原文が見つからないなど適用できない指摘は、適用せずに報告すること
- 変更箇所のサマリーを `<work>/applied.md` に Write し、起動役への返答はそのパスと適用件数だけにすること

完了したら `<work>/applied.md` を Read し、変更箇所のサマリーをユーザーに出力する。