anti-slop-writing について
重要な文章の執筆や改稿向けのスキルです。曖昧な強調、定型的な表現、根拠のない主張を検出し、情報源の確認、段落の流れ、改稿パターンを案内したうえで、改稿にも同じ基準を適用します。
主な機能
- 01曖昧または誇張した表現の検出
- 02主張と根拠となる詳細の照合
- 03段落間の関係とつながりの改善
- 04具体的な改稿パターンの適用
- 05改稿後のよくある問題の再確認
活用シーン
- 01重要な文章を見直して定型句を削る
- 02段落間のつながりを明確にする
- 03根拠を創作せずに文章を改稿する
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ adewale/ anti-slop-writing --skill anti-slop-writingインストール後、Claude Code で/anti-slop-writingを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/anti-slop-writing-doctrine.mdflow-by-relation.mdrewrite-patterns.md詳細
反・凡庸な文章
重要な文章の作成や書き直しには、このスキルを使用します。
タスクで必要な場合にのみ、ローカルのリファレンスを読み込みます。
references/anti-slop-writing-doctrine.md — read for a full prose review or when changing the doctrine.
references/flow-by-relation.md — read when paragraphs are locally clear but list-like, or when fixing transitions/conclusions.
references/rewrite-patterns.md — read when producing multiple concrete rewrites or adding a new failure pattern.
基本原則
Sharp detail beats inflated significance.
AI による文章は、次のような場合にうまくいかないことがよくあります。
less detail, more importance
次のように修正します。
more detail, earned importance
文章を書く前に
次の問いに答えます。
What is the exact point?
What concrete detail proves it?
What sentence machinery is making it feel true?
What should the reader remember?
不明な点があれば、草稿を書く前に質問するか、情報源を確認します。
情報源に基づく検出項目
書き直す前に、次の点を確認します。
AI-writing signs: superficial analysis, undue significance language, canned emphasis, negative parallelisms, rule-of-three overuse, formulaic dashes, table/bold formatting as fake structure.
Rhetorical-style drift: watch noun-heavy abstractions, nominalizations, phrasal coordination, and informational density without mechanism.
Practical AI-editing tells: repeated “Not X. Y.” rhythm, symmetrical paragraph length, parallel headings, and bullet + bold-header + colon patterns.
Copula displacement: watch “serves as,” “stands as,” “features,” “marks,” and “represents” replacing plain “is/are.” Keep the verb when it does concrete work (enumerating, defining, locating); replace it when it only inflates a copula.
Hedged symmetry: watch “Whether you’re X or Y,” “While X, Y is also important,” and similar templates that address every reader or every value at once. Keep the structure only when it names a real branching condition with distinct downstream behavior.
Em-dash cadence: do not ban em-dashes; watch decorative clusters that use dashes for emphasis instead of for parenthetical or appositive insertion. Reduce count; keep dash insertions/pairs that bracket inline definitions or genuine asides.
Rhetorical staccato: do not ban antithesis/parallelism; watch antithetical parataxis where rhythm implies the relation before evidence is unpacked.
Hypotaxis preference: when the relation matters, prefer subordination and connective syntax over side-by-side clauses; use “because,” “although,” “when,” “while,” “where,” “once,” or an explicit summary noun to show which idea modifies which.
Flow-by-relation test: paragraphs should make the next question possible, not merely sit beside each other in a plausible order. At section boundaries, name the relation: cause, contrast, dependency, inference, resolution, scope change, or level-of-detail change.
Conclusion test: a conclusion should return to the concrete carrier, admit the limit if needed, and state the reusable structure. Avoid ending with a generic thesis sentence that could belong to any essay in the category. Reject outline templates such as “Despite challenges, X continues to thrive” and “Looking ahead, X will play an increasingly pivotal role” unless backed by a specific challenge or named next step.
Unseeing frame: unsee the polished sentence into the machinery that made it feel true; inspect cadence, contrast, omitted relation, evidence scope, and abstraction leaks.
Emphasis-source test: ask whether the emphasis comes from the idea or from a borrowed pattern. To apply, write the flattened version of the line in your critique (cadence removed, claim preserved) and judge whether the residual claim still names an actor, mechanism, or limit. If it collapses into a generic statement, the rhythm was carrying it; if it still lands, the idea was.
Syntax-relation test: ask whether the syntax clarifies the relation between ideas or only suggests one. To apply, restate the implied relation in plain prose using a connective (because, although, when, where, once, so that). If you cannot supply the connective without inventing it, the syntax was standing in for a relation that was not there.
Contribution bar: contribution must justify length; add judgment, framing, depth, or cut.
DevRel pressure test: durable prose needs judgment, evidence, runnable artifacts, and taste.
デフォルトの編集手順
文章を仕上げる前に、次の点を確認します。
1. Delete generic opening.
2. Find prestige vocabulary clusters.
3. Replace abstract nouns with concrete mechanisms.
4. Remove “not just X but Y” unless it is the exact point.
5. Cut superficial “highlighting/underscoring” clauses.
6. Check every claim of importance against evidence.
7. Replace vague actors with named sources, named uncertainty, or an `ask-author` note that says what to ask. Do not invent a name, count, tool, or timing to fill a `Concrete rewrite` slot.
8. Collapse redundant bullets.
9. Vary sentence rhythm deliberately.
10. Audit staccato contrast cadence by identifying the hidden relation: contrast, evidence scope, cause, consequence, exception, or scope control.
11. Prefer hypotaxis to parataxis when the relation matters: subordinate the secondary idea instead of placing equal-weight clauses side by side.
12. Check paragraph flow: each paragraph should answer the prior question or make the next question necessary. Add hinge sentences when sections read like a list.
13. Check the conclusion: return to the concrete carrier, name what was made visible or solved, state what transfers, and avoid a generic final sentence.
14. Replace rhythm with relation when the line still sounds good but has not named the mechanism.
15. Replace displaced copulas (“serves as,” “stands as,” “features,” “marks,” “represents”) with plain “is” or a specific action verb, unless the verb is doing concrete enumerating, defining, or locating work.
16. Cut hedged symmetry (“Whether X or Y,” “While X, Y is also important”) and commit to a specific reader and a named tradeoff.
17. Reject outline conclusion templates (“Despite challenges, X continues to thrive,” “Looking ahead, X will play a pivotal role”); replace with a carrier-bound ending or cut.
18. Thin decorative em-dash clusters; keep at most one earned dash insertion/pair per sentence unless multiple insertions carry distinct definitions.
19. End with a concrete remembered line.
原則として避けるもの
フレーズ:
In today's rapidly evolving landscape
In the realm of
When it comes to
At its core
Let's dive into
It's worth noting that
It's important to note that
A testament to
Not just X, but Y
Not only X, but also Y
Same X. Same Y. Different Z.
Not X. Y.
This is where X comes in
Whether you're X or Y
While X, Y is also important
Despite ongoing challenges, X continues to thrive
Looking ahead, X will play an increasingly pivotal role
In conclusion
Overall
Ultimately
I hope this helps
確認する単語:
delve
realm
landscape as metaphor
tapestry
testament
pivotal
crucial
underscore
intricate
meticulous
multifaceted
nuanced as filler
foster
bolster
garner
showcase
highlight
emphasize
encompass
utilize
facilitate
transformative
groundbreaking
seamless
robust outside engineering context
注:上記の単語とフレーズのリストは、特定の時点に基づく検出項目です。現在のモデル世代で見られるパターンを反映しているため、今後変化します。項目を追加または削除する前に、現在の人間と LLM のコーパスで再評価してください。delve は、LLM の出力における使用頻度が 2025 年に急激に低下した、高リスク単語の注意すべき例です。
serves as や stands as のようなコピュラ構文は、意図的に単語リストに含めていません。これらは 2 語からなるテンプレートであり、適切かどうかは文脈によって決まります。動詞が列挙、定義、位置づけを行う場合は残し、コピュラを水増しするだけの場合は置き換えます。
誤検出への配慮
検出項目への該当は、確定的な判定ではなく仮説として扱います。同じ文や近くの文脈に、その用語を使う根拠となる仕組み、失敗の形、測定値、境界が示されている場合は、Verdict: keep とし、その根拠を明記します。
例:
Keep: "The queue is robust because each job has an idempotency key, a retry receipt, and a dead-letter cutoff."
Why: "robust" is an engineering qualifier earned by the deduplication, retry-tracking, and dead-letter mechanisms.
監視対象の単語が含まれているというだけで、同義語に置き換えるだけの修正を提案してはいけません。
断片的な対比のテスト
短い対比をすべて凡庸な文章と見なしてはいけません。まず種類を判定します。テストの基準は、対比の話題に触れているかどうかだけではなく、対比の両側がそれぞれ先行する文章によって裏づけられているかどうかです。
Earned antithesis: both sides of the contrast are evidenced in the prior sentences. The contrast lands a distinction the reader can already verify. Keep or use once.
Compressed antithesis: one side is evidenced; the other side is a leap or a new claim. The cadence implies the contrast before evidence is given. Expand into the relation by naming the unsupported side directly.
Decorative antithesis: neither side is evidenced. The contrast supplies closure without content. Cut or replace.
同じ情報源(joe.dev/posts/thinking-out-loud)からの例:
根拠のある対比:この記事では、プラットフォームの失敗(Medium の方針転換、Twitter、LinkedIn)と代替手段(自分のドメインを所有し、自分でサーバーを運用すること)の両方が示されています。締めくくりの That's what I want. My words, at a URL I own, without anyone in the middle. は、対比の両側が示されたうえで、その違いを印象づけています。
圧縮された対比:直前の文では、移動可能性について ATproto lets you store structured records in a data server (your PDS) that you own and can move. と示されていますが、意図性については説明されていません。締めくくりの That's not incidental. It's the design. は、リズムだけを頼りに意図性を主張しています。書き直す際は、意図性を断言するのではなく、何がポータビリティを設計として実現しているのか(PDS 間を移動してもレコードの ID が変わらないプロトコルの性質)を明記します。
装飾的な対比:The point is not the pelicans. The point is the process. では、対比に先立ってペリカンを運ぶものもプロセスも示されていません。関係を明記するように書き直します。The pelican is useful because it gives the process a small, inspectable carrier.
書き直しのルール:
replace rhythm with relation
prefer hypotaxis to parataxis
よくある修正方法:
Although X, Y.
Because X, Y.
When X changes, Y no longer means the same thing.
Where X only shows final state, Y records process.
X matters because it changes Y.
Once X is visible, Y becomes inspectable.
Because the concrete example is small/memorable/inspectable, it can carry the larger claim.
書き直しのパターン
悪い例:
This underscores the importance of durable execution.
より良い例:
The workflow can fail on step 4, retry only that step, and keep the previous outputs.
悪い例:
Cloudflare is not just a CDN, but a platform.
より良い例:
Cloudflare turns the network boundary into a programmable runtime.
悪い例:
This empowers teams to build seamless experiences.
より良い例:
The team can ship a WebSocket room without running a room server.
弱い締めくくり:
A benchmark is stronger when you can inspect the run that produced it.
より良い締めくくり:
Because the pelican project is small enough to inspect and strange enough to remember, it works as a compact carrier for the larger claim: a benchmark is stronger when you can inspect the run that produced it.
最終セルフチェック
編集を完了したと判断する前に、次の点を確認します。
Did I answer the user's actual request: review, rewrite, draft, or all three?
Did every flagged slop tell get a concrete rewrite or a reason to cut?
Does each rewrite name the mechanism, relation, actor/action/result, or concrete carrier?
Did I preserve earned compression instead of expanding it into bland explanation?
Did I avoid introducing new prestige abstractions or banned fallback phrases?
Did I run the same detectors on my rewrite that I ran on the source? In particular, does my rewrite reuse the cadence I just flagged (em-dash antithesis, "X isn't A, it's B", short parallel clauses) under different punctuation?
When a rewrite needs a fact not in the source (a name, a number, a tool, a mechanism), did I ask the author or recommend cutting, rather than inventing a confident-sounding specific?
重要度の高い文章では、範囲を限定して、評価と改善を 1 回行います。具体性、根拠との適合性、関係の明確さ、リズムを 1~5 で評価し、最も弱い項目を 1 回改善します。
批評の出力形式
既存の文章をレビューする場合は、次の形式を使います。
Verdict: keep / revise / ask-author / reject
Slop tells:
Specificity missing:
Inflated claim:
Flow break:
Concrete rewrite:
Rewrite check:
Remembered line:
行に改善の余地があるものの、修正に必要な事実が元の段落にない場合(ツール名、人名、件数、時期に関する主張、名前の付いた仕組み、具体的な出来事など)は、ask-author を使います。Concrete rewrite 欄には、尋ねる内容を明記します。たとえば、Ask author: which coding tool? Cursor, Claude Code, Copilot, Aider, other? のようにします。そのうえで、代替案(削除するか、後続の文に説明を担わせる)を提示します。Concrete rewrite 欄を埋めるために、不足している事実を作り出してはいけません。同じルールは、ask-author ブロック内の代替案の書き換えにも適用されます。事実を作り出す代替案は、代替案がないよりも悪いものです。
Rewrite check は必須です。Concrete rewrite(ask-author の代替案を含む)に、次のいずれかが含まれるかを明記します。rule-of-three、X-not-Y 型の表現/否定的な並列構文、em ダッシュによる対比、デフォルトで避けるべき禁止表現、権威付けの形容詞、装飾的な締めくくり(「That was the point」「In conclusion」「Overall」「Ultimately」)、または創作した事実。元の段落に対する書き換えなら revise フラグが付く内容の場合、その書き換え自体にも revise フラグを付ける必要があります。書き直すか、ask-author に切り替えてください。問題がなければ、passes self-detectors と記載します。
対比表現や短く切った対照表現を分類するときは、まず同じ段落の直前の文を確認してください。その文で対比の仕組みが説明されていれば、その対比には根拠があります。文のリズムだけを理由に、根拠のある対比を圧縮的または装飾的だと評価しないでください。
トーンの目標
次のような表現を優先します。
specific
source-grounded
direct
varied rhythm
concrete mechanisms
named tradeoffs
memorable line
次のような表現は避けます。
safe essay voice
prestige abstraction
balanced filler
fake profundity
marketing fog