Avoid AI slop (Japanese prose)
AI-slop prose is surface-polished but hollow and uniform. Detectors are unreliable (human raters do no better than chance), so this skill is a manual review/rewrite method, not a detector. The knowledge base is self-contained in references/. Method adapted from iKora128/stop-ai-slop-jp. For visual artifacts (web UI, slides, diagrams, images), use the sibling skill avoid-ai-slop-design; this skill covers the prose.
The cardinal rule: edge (variation, bluntness, a stance) is a means to break uniformity, not a goal. Don't trade AI-uniform for an "anti-AI template". And always filter techniques by document type (a security briefing is not a personal blog).
First principle — suspect the absent writer (書き手の不在)
The root cause of "AI smell" is the absent writer: no one is behind the text taking a position. Before and after writing, answer three questions (大原則, from stop-ai-slop-jp):
- 自分は何を「○○だ」と引き受けているか(取っている立場)
- 反証可能な具体的主張があるか
- 同じテーマの平均的な記事と何が違うか
If you can't answer these, vocabulary/symbol fixes won't help — restore the author first. This is the highest-leverage move, especially for personal/opinion writing. The 3 questions are the front-loaded 立場/具体 axes of the full score; if they conflict with the full 5-axis result, the full score wins. In formal docs "the writer" = the organization's position — show humanity through concrete facts/numbers, not first person or snark, and never fabricate experience to fill the gap.
Quick path (light use): short pieces or drafts → answer the 3 questions, then scan Tier-1 banlist + false agency + false contrast (catches most slop in minutes). Anything published, formal, or high-stakes → run the full 6-step process below.
When not to run this
Over-triggering costs more than under-triggering here: an unrequested rewrite of prose the user is already happy with reads as noise, and applying 「AI っぽさ」 criteria to the wrong genre makes the text worse. Skip when:
- Code, config, logs, commit messages, CLI/API reference output — mechanical registers where uniformity is correct. Markdown 整形や章構成それ自体も対象外 (別スキルの領域)
- The user asked something else about the same text — 事実確認・要約・翻訳・長さ調整。文体には触らない
- The text is not the deliverable — 思考メモ、下書きの箇条書き、会話中の即答
- Casual conversation and short replies — 数行のやり取りに 5 軸採点をかけない
- Fixed-form documents — 法務・規制・監査で文言が定められているもの。ムラは違反になる
- The user already declined — 「そのままでいい」「急ぎでいい」と言われた後の同一文書
Run at most once per artifact per conversation. 一度通した文章に後続ターンで再採点を重ねない — 指摘が尽きた後の追加指摘は、根拠のない言い換えに落ちる。ユーザーが改稿を依頼したときは当然もう一度回す。
A caveat is the tell — 「これは 向けの基準だが、たぶん役に立つ」と前置きしたくなった 時点で、その文書は対象外。
Process (run in order)
- Decide the document type — it sets how much variation / bluntness is allowed. See
references/document-types.md. - Score 5 axes (立場・リズム・主体性・具体性・削減), 1–10 each. Below 35/50 → rewrite; at 35+ still fix any critical syntax slop. See
references/scoring.md. - Scan the banlist (3 tiers: always-ban / avoid-by-default / context-OK). See
references/banlist.md. - Check syntax patterns (false agency, propositional H2, false contrast "XではなくY", hook-then-reversal, meta-structure announcements, ❌/✅ slides, triple-parallels, monotone sentence endings). See
references/syntax-patterns.md. - Keep deliberate ムラ (variation in length / density / tone / conclusion / detail) within what the doc type allows. See
references/variance.md. - Rewrite, then re-check 削減 (cut filler) and 具体性 (names/numbers/examples). Study
references/rewrite-examples.md— including the over-corrected examples.
Quick checklist
- Document type identified; bluntness/variation budget set accordingly.
- No always-ban items (装飾絵文字 / 全角ダッシュ乱用 /
**residue / 根拠なし強評価). - No inanimate subject performing judgment/intent (false agency).
- No empty "XではなくY" / propositional-heading pile-up / meta-structure openers.
- Sentence length and endings vary; not every paragraph lands the same way.
- Every key claim is anchored to a name / number / example; a stance is taken with a stated basis (≠ unfounded assertion).
- 5-axis self-score ≥ 35/50 and no critical syntax slop remains.
鮮度
この知識ベースは出所リポジトリの clone を持たない自作の調査資料なので、SHA ではなく日付で棚卸しする。各 references/*.md の frontmatter が tracking: review + reviewed_at + review_interval_days (180 日) を持ち、/claude-harness-refs-update が期限切れを REVIEW として報告する。棚卸しでは出典 URL の生存と、記述が前提にしている流行・モデル世代の変化を確認する。