本文へ移動
cccskills
無料GitHub で公開日本語紹介

unslop

コミット文やPR、ドキュメント、返信など、人が読む文章からAIらしい定型表現を取り除き、意味と口調を保ちながら具体的で自然な文に整えます。

原文原文の説明を見る

Cut AI tells from text you write or edit for a human reader (commit messages, PR titles and bodies, docs, code comments, replies). Apply before committing, posting, or sending; leave prose you didn't touch alone.

michaelshimeles/rstackスター 1,392(GitHub 1,392 + cccskills 0)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • PR本文を自然な文に整えたいとき
  • コミットメッセージを推敲したいとき
  • ドキュメントの定型表現を減らしたいとき
  • 送信前に返信を読み直したいとき

日本語での紹介

できること

コミットメッセージ、PRのタイトルや本文、ドキュメント、コードコメント、返信など、人が読む文章を見直します。誇張表現や曖昧な出典、定型的な言い回し、不要な前置き、硬い語彙などを探し、意味と意図した口調を保って書き換えます。文の長さやリズムを変え、具体的な事実や書き手の視点が伝わる文章に整えたうえで、AI生成らしさが残っていないかを確認します。編集対象に含まれない文章はそのままにします。

こんなときに便利

投稿や送信、コミットの前に文章を読みやすくしたいときに向いています。内容は変えずに、宣伝調の表現や抽象的な言い回しを減らしたい場合にも使えます。技術文書から短い返信まで、読者に合わせた自然な文体に整える作業を頼めます。

使い方の例

  • 「このPR本文からAIらしい定型表現を取り除いてください」
  • 「意味を変えずに、このコミットメッセージを自然な文にしてください」
  • 「送る前に、この返信の冗長な表現を整理してください」

注意点

特記事項はありません。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(2)

  • SKILL.md6.6 KB
  • LICENSE1.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Unslop

Edit text to remove AI patterns and add human voice.

Process

  1. Scan for the patterns below.
  2. Rewrite. Preserve meaning, match intended tone.
  3. Add soul (see next section).
  4. Self-audit: "What makes this obviously AI generated?" Fix remaining tells.

Adding soul

Removing patterns is half the job. Sterile, voiceless writing is just as obvious.

  • Have opinions. React to facts instead of neutrally listing pros and cons.
  • Vary rhythm. Short sentences. Then longer ones that take their time. Mix it up.
  • Acknowledge complexity. "Impressive but also kind of unsettling" beats "impressive."
  • Use "I" when it fits. First person isn't unprofessional.
  • Let some mess in. Perfect structure looks machine-made.
  • Be specific. Not "this is concerning" but "there's something unsettling about agents churning away at 3am."

Patterns to detect and fix

Content

  1. Puffery. "pivotal moment", "testament to", "evolving landscape", "setting the stage for", "indelible mark", "deeply rooted". Cut puffery, state what happened.
  2. Name-dropping. Listing media outlets without context. Pick one, say what was said.
  3. Superficial -ing phrases. "highlighting...", "ensuring...", "reflecting...", "showcasing...", "fostering...". Delete or expand with real sources.
  4. Promotional language. "nestled", "vibrant", "breathtaking", "groundbreaking", "renowned", "stunning", "must-visit". Use neutral descriptions.
  5. Vague attributions. "Experts believe", "Industry reports suggest", "Some critics argue". Name the source or delete.
  6. Formulaic challenges. "Despite challenges... continues to thrive." Replace with specific facts.

Language

  1. AI vocabulary. Additionally, crucial, delve, enduring, enhance, fostering, garner, interplay, intricate, landscape (abstract), pivotal, showcase, tapestry (abstract), testament, underscore, vibrant. Replace with plain words.
  2. Fancy ways to say "is". "serves as", "stands as", "boasts", "features". Just say "is" or "has".
  3. "Not just X, but Y." State the point directly instead.
  4. Rule of three. Forcing ideas into groups of three. Use the natural number.
  5. Synonym cycling. Protagonist, main character, central figure, hero all in one paragraph. Pick one, repeat it.
  6. False ranges. "from X to Y" where X and Y aren't on a meaningful scale. List topics directly.

Style

  1. Em dash overuse. Avoid em dashes entirely. Use periods or commas only (no parentheses, no en dashes, no hyphen-as-dash substitutes). Em dashes are an AI tell, and reaching for parentheses instead just trades one tell for another. If a thought needs separation, end the sentence or use a comma.
  2. Colon overuse. Colons are fine before a list or example. Not as mid-sentence connectors. "If you're coming from traditional automation: instead of registering event handlers, you describe conditions" adds nothing with the colon. Rewrite to let the point stand on its own without comparison framing. "Describing when the scheduler should fire works best as plain English." Same meaning, no crutch punctuation.
  3. Boldface overuse. Don't bold every proper noun or acronym.
  4. Inline-header lists. The tell is a bold label and colon that restates the line: "Performance: Performance improved...". Convert those to prose. A bold lead-in that ends in a period, names the item, and is followed by genuinely new detail ("Schema in TypeScript. Tables live in one file.") is fine, not a tell.
  5. Title case headings. Use sentence case.
  6. Decorative emojis. Remove from headings and bullets.
  7. Curly quotes. Replace with straight quotes.

Communication artifacts

  1. Chatbot phrases. "I hope this helps!", "Let me know if...", "Of course!", "Certainly!", "Found the smoking gun!" Remove.
  2. Cutoff disclaimers. "While specific details are limited..." Find sources or remove.
  3. Sycophantic tone. "Great question! You're absolutely right!" Respond directly.

Filler

  1. Filler phrases. "In order to" becomes "To". "Due to the fact that" becomes "Because". "It is important to note that" gets deleted.
  2. Excessive hedging. "could potentially possibly be argued that it might" becomes "may".
  3. Generic conclusions. "The future looks bright." State specific plans or facts.

Jargon

  1. Abstract metaphor nouns. Substrate, wedge, vector, locus, vantage, nexus, primitive (as noun), harness (as metaphor), surface (as in "API surface"), bedrock, scaffolding (as metaphor), modality, paradigm, gold-plating, ratchet (as metaphor), evacuate (for moving code), endgame, north star, flywheel. These read as technical but usually have a plainer concrete word. "Substrate" becomes "base". "Wedge in" becomes "add". "Vector" becomes "way" or "method". "Gold-plating" becomes "more than the job needs". "Ratchet" becomes the mechanism's real name or "a limit that only tightens". "Evacuate" becomes "move out". "Endgame" becomes "the last phase". Pick the concrete word.

Plain speech

  1. Say what it does, not how it feels. "the database stays close at hand", "SQL you can read", "types that follow your schema" name a feeling. The fix names the mechanism or a number: ".toSQL() returns the exact string sent to the database", "a column rename fails the build". Ask what the sentence tells the reader to do or know, then write that. If you can't restate it as a concrete instruction, fact, or number, cut it. One more check: if the sentence could appear unchanged in another project's docs, it says nothing about this one. Cut it.
  2. Shorten or split dense sentences. If the reader has to backtrack to parse a sentence, break it in two or drop clauses. One idea per sentence.
  3. Active voice. Prefer it. Catch "is/are/was/were + past participle" and name the actor: "queries are validated" becomes "the compiler validates queries", "the file is parsed by the loader" becomes "the loader parses the file". Passive is fine only when the actor is unknown or genuinely doesn't matter.
  4. Cut adverbs, or use a stronger verb. "runs quickly" becomes "is fast" or the number. "significantly improves" becomes the measured delta. An adverb propping up a weak verb means the verb is wrong.
  5. Prefer the plain word. "utilize" becomes "use", "leverage" becomes "use", "facilitate" becomes "help", "numerous" becomes "many", "in the event that" becomes "if". The fancier synonym is rarely clearer.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

before-and-after

無料概要あり

Webページや画像の変更前後を同じ条件で撮影し、画面の差を比べるためのスクリーンショットと、必要に応じて共有用Markdownを作成します。

  • UI変更の前後を比較したいとき
  • PR用の画面比較資料を作りたいとき
  • 特定のページ要素だけ撮影したいとき
michaelshimeles/rstack1,3922026年10月26日 更新

code-structure

無料概要あり

複数の機能で重複する処理を整理し、業務ルールを担うアクションと再利用できる処理を担うサービスの分け方や移行手順を示します。

  • 重複した処理を共通化すべきか判断したいとき
  • 業務ルールと共通処理の置き場所を整理したいとき
  • 複数の呼び出し元を段階的にリファクタリングしたいとき
michaelshimeles/rstack1,3922026年10月26日 更新

evidence-driven-testing

無料概要あり

アプリの操作や変更後の動作を確かめ、画面録画やスクリーンショット、測定結果などの証拠をまとめて、指定先に結果を届けます。

  • UI操作を録画して動作を示したいとき
  • GUIなしで画面の状態を検証したいとき
  • APIや性能の変更を数値で確かめたいとき
michaelshimeles/rstack1,3922026年10月26日 更新

greploop

無料概要あり

PRやMRに寄せられたGreptileの指摘を確認し、対象を絞った修正と再レビューを繰り返して、現行リビジョンの評価と未対応事項を整理します。

  • PRのGreptile指摘を修正したいとき
  • MRのレビューを再依頼して確認したいとき
  • Perforceの変更をレビューしたいとき
michaelshimeles/rstack1,3922026年10月26日 更新

greploop-apps

無料概要あり

通常のトリガーで大きなPRを処理できない場合に、`greploop` のワークフローを `@greptile-apps` トリガーで実行する互換用エントリーポイントです。

  • 大きなPRをGreptile Appsで処理したいとき
  • 通常のトリガーで扱えないPRをレビューしたいとき
  • 既存のgreploopワークフローを指定トリガーで実行
michaelshimeles/rstack1,3922026年10月26日 更新

new-feature

無料概要あり

機能追加や修正に着手する前に、作業ごとのGit worktreeとブランチを用意し、既存の担当作業や変更範囲を確認して安全に編集を進めます。

  • 機能追加を専用ブランチで始めたいとき
  • 共有チェックアウトを保って修正したいとき
  • 既存PRとの変更範囲を確認したいとき
michaelshimeles/rstack1,3922026年10月26日 更新

michaelshimeles のスキルをすべて見る

このスキルの問題を報告する