mcpField
I
impactful-writing

impactful-writing

github.com/tenequmクリエイティブ・メディア4090 回インストール5 日前に更新
リポジトリ

impactful-writing について

ソーシャル投稿、ドキュメント、業務連絡、長文記事の執筆や編集を支援するライティングスキルです。明瞭さや構成の原則、編集チェックリスト、形式別の指針を提供します。

主な機能

  1. 01明瞭で簡潔な表現の原則
  2. 02流し読みしやすい構成
  3. 03簡潔な能動態への編集
  4. 04媒体別のライティング指針
  5. 05編集フレームワークによる草稿確認

活用シーン

  1. 01技術ドキュメントの編集
  2. 02ソーシャル投稿や記事の執筆
  3. 03メールや業務連絡の改善
  4. 04GitHub コメントやプルリクエストのレビュー

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tenequm/skills --skill impactful-writing

インストール後、Claude Code で/impactful-writingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE.txt
references/
clarity-science.md
emotional-impact.md
revision-frameworks.md
structure-patterns.md

詳細

心に響く文章を書く

概要

あらゆるコンテンツを、明快で記憶に残り、行動につながる文章に変えます。研究に裏付けられた原則は、あらゆるプラットフォームや状況で効果を発揮します。このスキルでは、50年以上にわたる可読性研究、記憶の神経科学、プラットフォームのエンゲージメント研究を、実践的なテクニックにまとめています。

核心となる洞察:どこでも、同じ心理的原則がエンゲージメントを促します。明快さは認知負荷を軽減し、具体性は記憶に残りやすくし、構成は読み飛ばしを可能にします。こうした普遍的なパターンを身につけ、あらゆる文章作成に活用しましょう。

このスキルを使う場面

  • Twitter/X の投稿、スレッド、ソーシャルコンテンツを書く、または編集するとき
  • ブログ記事、Medium の記事、長文コンテンツを作成するとき
  • ドキュメント、README ファイル、技術文書を作成するとき
  • メール、Slack メッセージ、業務上のコミュニケーションを作成するとき
  • GitHub のコメント、PR の説明、コードレビューを書くとき
  • 更新メッセージ、告知、変更履歴を作成するとき
  • 明快さと訴求力を高めるために既存の文章を編集するとき

あらゆる文章に通じる原則

これらの、証拠に基づいた原則は、あらゆるプラットフォームや状況で効果を発揮します。

1. シンプルにして明快にする

文の長さが理解度を左右します:

  • 14語:読者の理解度は90%以上
  • 25語:難しさが生じ始めます
  • 43語:理解度は10%未満

目安:平均15~20語、1文あたり最大25語です。

言葉選びも重要です:

  • 平易な言葉は専門用語より76%速く処理されます
  • 能動態は受動態より15~20%速く処理されます
  • 抽象的な表現より具体的な表現が効果的です(感覚に関わる脳の領域が活性化します)
2. 読み飛ばしやすい構成にする

**読者の79%は、文章を読むのではなく、読み飛ばします。**この実態を踏まえて構成しましょう。

  • 重要な情報を先に置きます(逆ピラミッド型)
  • 3~4段落ごとに内容を示す見出しを使います
  • 段落は最大3~5文にします
  • 関連項目が3つ以上ある場合は箇条書きを使います
  • 最適な行の長さは50~75文字です
3. 感情に訴える

物語はオキシトシンの分泌を促し、共感と記憶の形成につながります:

  • つかみから始めます(質問、意外な事実、短い物語)
  • 感覚に訴える具体的な言葉を使います
  • 読者が答えを知りたくなる、具体的な問いで好奇心を引き出します
  • 記憶に残る要点で締めくくります(新近性効果)
4. 抽象より具体を優先する

曖昧な表現より、具体的な詳細のほうが効果的です。

  • 「大幅な成長」より「45%増加」
  • 「すぐに」より「5分で」
  • 「いくつかの方法」より「10の方法」
  • 抽象的な説明より具体例

すぐに始められるワークフロー

新しい文章を書く
  1. 核心となるメッセージを1文で定めます
  2. つかみから始めます(質問、事実、物語)
  3. 見出しを使って構成し、読み飛ばしやすくします
  4. 短い文を使います(平均15~20語)
  5. 明確な要点または行動喚起で締めくくります
既存の文章を編集する
  1. 声に出して読み、ぎこちない箇所を見つけます
  2. 意味を損なわずに文章量を10~30%削ります
  3. 受動態を能動態に変えます
  4. 専門用語を平易な言葉に置き換えます
  5. 構成を加えます(見出し、箇条書き、余白)

プラットフォームごとの指針

Twitter/X の投稿
  • 最適な長さ:エンゲージメントを高めるには71~100文字
  • 最初の行でつかむ:3秒で読者の関心を引く必要があります
  • 数字を使う:「学んだこと」より「10の教訓」のほうが効果的です
  • スレッドの構成:各ツイートは単独でも意味が通じ、かつ全体とつながっている必要があります

変換例:

Before: "I learned a lot from this experience and want to share some thoughts"
After: "5 hard lessons from shipping 10,000 lines of code in 48 hours:"
ブログ記事/記事
  • 最適な読了時間:7~10分
  • 見出し:300~500語ごと
  • 最初の段落:読者への約束を必ず果たします
  • 結論:要点をまとめ、次の明確な行動を示します
技術ドキュメント
  • 目標を先に示します:読者は何を達成できますか?
  • 説明より実例を示します:動作するコード例は説明より効果的です
  • 段階的に情報を提示します:基本 → 応用
  • 用語を統一します:1つの概念につき用語は1つにします
プロフェッショナルなコミュニケーション(メール/Slack)
  • 件名:気の利いた表現より具体性を重視します(「Q4 Report Draft」>「Quick update」)
  • 1つのメッセージにつき1つのトピック:返信率が上がります
  • アクション項目を冒頭に置く:依頼内容を埋もれさせないようにします
  • 半ページ以内に収める:長いほど読まれる確率が下がります
GitHub のコメント/PR の説明
  • 背景から始める:どのような問題を解決するのでしょうか?
  • 箇条書きを使う:変更点、決定事項、トレードオフをまとめます
  • 「なぜ」を含める:説明よりも理由を重視します
  • 率直に、ただし親切に:批判の対象はコードであり、人ではありません

推敲チェックリスト

コンテンツを改訂する際は、このチェックリストを使います。

Clarity Pass:
- [ ] Average sentence length < 20 words
- [ ] No sentence > 30 words
- [ ] Passive voice < 10% of sentences
- [ ] Jargon replaced with simple alternatives

Structure Pass:
- [ ] Opening hook captures attention
- [ ] Key message in first paragraph
- [ ] Headings every 3-4 paragraphs (for longer content)
- [ ] Bullet points for lists of 3+ items
- [ ] Clear call-to-action or takeaway at end

Conciseness Pass:
- [ ] Removed "very," "really," "quite," "just"
- [ ] Replaced multi-word phrases with single words
- [ ] Deleted redundant explanations
- [ ] Cut 10-30% from original word count

文章を短くするパターン

簡潔にできるよくある表現:

冗長な表現簡潔な表現
due to the fact thatbecause
in order toto
at this point in timenow
in the event thatif
with regard toabout
a large number ofmany
in spite of the fact thatalthough
for the purpose ofto

簡潔にできる複雑な単語:

複雑な表現簡単な表現
utilizeuse
commencestart
terminateend
demonstrateshow
facilitatehelp
subsequentlater
approximatelyabout
endeavortry

効果的なフックのパターン

質問フック

読者が答えを知りたいと思う質問から始めます。

"What if everything you knew about productivity was wrong?"
統計フック

意外なデータから始めます。

"90% of visitors who read your headline also read your CTA - yet most writers spend 10x more time on body copy."
ストーリーフック

短い物語から始めます。

"At 3 AM, with the deploy failing for the sixth time, I realized the bug wasn't in the code."
断定フック

大胆な主張から始めます。

"Most advice about writing is wrong. Here's what actually works."
逆説フック

思い込みに異議を唱えます。

"The best writers don't write more. They delete more."

記憶とインパクトの原則

記憶に残るコンテンツには、次のパターンがあります。

系列位置効果
  • 最初の項目:およそ70%が想起されます(初頭効果)
  • 最後の項目:およそ60%が想起されます(新近性効果)
  • 中間の項目:およそ40%が想起されます

示唆:最も重要なポイントは、最初と最後に配置します。

予測誤差

期待が裏切られると、印象的な記憶が生まれます。

Before: "The meeting went exactly as planned."
After: "The meeting started with our CEO apologizing. In 15 years, I'd never seen that."
感覚に訴える言葉

脳の複数の領域を活性化します。

Before: "The code was messy."
After: "The code sprawled like tangled Christmas lights - one pull and everything breaks."

よくあるアンチパターン

説明しすぎる

問題:読者がすでに知っていることを説明する 対策:読者の理解力を信頼し、新しい情報だけを伝えます

重要な情報を後回しにする

問題:段落3に要点がある 対策:結論を冒頭に移し、詳細で裏付けます

文字の壁

問題:視覚的な区切りのない、密度の高い段落 対策:見出し、箇条書き、余白を加えます

受動態による責任回避

問題:「ミスが起きました」(誰が起こしたのでしょうか?) 対策:「チームが期限に間に合いませんでした」(責任の所在が明確です)

専門用語の連発

問題:「部門横断的なパラダイムの相乗効果を高めました」 対策:「チーム同士が協力できるようにしました」

実績のあるコンテンツのフレームワーク

AIDA(注意 → 興味 → 欲求 → 行動)

目標のあるあらゆるコンテンツに使える、古典的な説得の構成です。

Attention: "Most developers waste 3 hours/day on preventable bugs."
Interest: "Static analysis catches 85% of these before they ship."
Desire: "Teams using this approach ship 2x faster with fewer incidents."
Action: "Add this one-line config to your CI pipeline."
PAS(問題 → 問題の深刻化 → 解決策)

ブログ記事、ランディングページ、説得力のあるコンテンツに効果的です。

Problem: "Your documentation is outdated the moment you write it."
Agitate: "New devs waste days. Senior devs answer the same questions. Nobody trusts the docs."
Solution: "Generate docs from code comments. Always current, always trusted."
BAB(前 → 後 → 橋渡し)

感情に響く変化の物語を作ります。

Before: "I spent 6 hours debugging a production issue."
After: "Now I catch these problems before they deploy."
Bridge: "Here's the monitoring setup that changed everything."
1-2-3 構成

説明コンテンツ向けの、シンプルで流し読みしやすく、実行に移しやすい構成です。

1. The Problem: What's wrong and why it matters
2. The Solution: What to do about it
3. The How: Specific steps to implement

詳細な参考資料

特定のトピックについて詳しく知りたい場合は、以下を参照してください。

クイックリファレンス:CLEAR フレームワーク

C - 簡潔に:意味を損なわずに10~30%削ります
L - 価値を先に示す:最初の文に要点を置きます
E - 根拠に基づく:曖昧な主張より具体的なデータを使います
A - 能動態:主語・動詞・目的語の構成にします
R - 読者を中心に:読者が知る必要のあることを伝えます

検証:コンテンツの品質チェック

執筆後、次の点を確認してください。

  1. 核心メッセージのテスト:一文で要点を述べられますか?
  2. だから何?のテスト:各段落を読んだ後、「だから何?」に答えられますか?
  3. 祖母にも伝わるかのテスト:専門家でない人にも要点が伝わりますか?
  4. 行動のテスト:読者は次に何をすればよいか分かりますか?
  5. 削除のテスト:意味を損なわずに削除できる文はありますか?

いずれかのテストに合格しない場合は、そのセクションを修正してください。

コメント