copywriting

copywriting — プロダクト自身の声で書く

super-ux の一部です — system-map.md を参照してください。 変更後は、以下の説明に従ってブランドリンターを解決して実行してください。

毎回、最初に行うことはブランドパックを読むことです。 docs/brand/voice.md、 terminology.md、そして執筆対象のサーフェスに対応する channels.md の記録を確認します。

パックがありませんか？そこで止めて、brand-voice に引き継いでください。 声をでっち上げてはいけません。 推測して外す損失は、一時停止する損失より大きく、サーフェスごとにコピーを作り上げることで生まれるプロダクトのブレこそ、 このレイヤーが解消するものです。

オプトアウトの意思表示は明確に行われた場合のみ有効です。 「no brand」／«без бренда»、 または 「draft it」／«черновиком» は、オペレーターがこの手順を使わないと意思表示する言葉です。 その場合は直接執筆し、依頼によりパックを省略したと伝えてください。黙って省略してはいけません。

所有権はディレクトリではなく、ファイル単位です。 brand-voice はパックの信頼できる情報源である voice.md、用語辞書、facts.md、チャネルのプレイブック、ロケールポリシーを管理し、このスキルはそれらを決して編集しません。 辞書にない用語や、facts.md に記載のない数値は、文を完成させるために作り上げず、報告します。追加するかどうかは brand-voice の判断です。このスキルが所有するのは strings.md（Status: proposed として記録するインターフェース文字列のレジストリ）と、プロダクトのテキストそのものです。 どちらも docs/brand/ にありますが、所有権を決めるのはディレクトリではなくファイルです。 strings.md に項目を追加するのはこのスキルの役割であり、保存先について追加の承認は不要です。連携作業では編集前にファイルの担当を確保し、 同じ作業内でボイスとファクトには手を加えません。

トリガー

このスキルに振り分ける英語とロシア語のフレーズです。スキル一覧が予算内に収まるよう、説明には最も強いトリガーだけを残しています（2026-10-20）。ファミリーの振り分けフックはこの一覧に対応します。

「write copy」／「напиши текст」、「App Store description」／「описание для App Store」、「store listing」／「описание в сторе」、「rewrite this」／「перепиши」、「headline」／「заголовок」、「CTA」／「кнопка」、「microcopy」／「микрокопия」、「error text」／「текст ошибки」、「this sounds like AI」／「звучит как нейросеть」、「post for X」／「пост в твиттер」、「reel script」／「сценарий рилса」、「video hook」／「хук ролика」、「build a landing page」／「сделай лендинг」（コピー部分。ビジュアルレイヤーは sheleg-design が担当します）。

参考資料

読む資料	場面
ui-copy.md	プロダクト内のあらゆる文字列
marketing-copy.md	ページ、長文、7つのスイープ、根拠付け
landing-pages.md	ランディングページの構成：オファー、認知度、証拠、アクション
channel-playbooks.md	ソーシャル、ブログ、変更履歴、広告、メールのサーフェス、またはクリエイター／アンバサダープログラム
video-script.md	リール、ショート、TikTok、動画広告：切り口、構成、タイミング、ショットリスト、ゲート
hooks.md	最初の3秒：トリプル、26の公式、40のテンプレート、B044 フィルター
research-outliers.md	動画を作る前に：自身のアカウントで通常以上の成果を上げた動画
store-copy.md	App Store または Google Play
seo-aeo-safety.md	クローラーや回答エンジンが読むもの全般
ai-tells.md	テキストを生成するすべてのモード：この確認工程はデフォルトで実施
localization.md	プライマリ以外のロケール
surface-registers.md	サーフェスに適した文体

モード

テキストを生成するすべてのモードでは、ヒューマナイズ処理がデフォルトで実行されます。 これは選択して入るモードではなく、Write、Edit、Adaptの最後に行うステップであり、ai-tells.md に記載された必須のガードに従います。オプションではなくデフォルトなのは、誰も見直していない草稿には、そのファイルで評価される特徴が残り、読み手は理由を言葉にする前にそれを感じ取るからです。

voice.md には、異なる問いに答える2つのフィールドで状態を記録します。Humanization: on | off は処理を実行するかどうかを示し、フィールドがない場合は on がデフォルトです。Humanization pass: は実行する実装を示し、フィールドがない場合は own となります。own は、このパックのレジスターと正規の事実を参照する唯一の実装です。処理を無効にするのは正当な判断であり、その判断をした人がいなくなった後も記録に残ります。そのため、off の場合は理由と日付を記した Humanization declined: 行が必要です。B064 はこの3つの状態すべてを確認します。

**コピーを納品する際は、何を行ったかを1行で明記します。**コピーの前、または直後に記載します。

Humanization: on (own pass): 7 markers at 2 densities, 4 addressed, 11% changed
Humanization: off (declined 2026-08-30): wording fixed by counsel

この行は飾りではありません。処理が見えないまま実行されると、実行されなかった場合と区別がつきません。また、コピーを読む人は通常、設定を選んだ人ではありません。

作成

1. 使用する媒体を明示します。channels.md に存在している必要があります。存在しない場合は、ここで即興で対応するのではなく、brand-voice に関する判断が必要です。 マーケティング業務の場合に限り、marketing-copy.md →「執筆前」を読み、templates/brand/copy-brief.md をもとに現在のブリーフを作成または更新します。未解決の入力は unknown のままにします。インターフェースのみの業務では、ブリーフを追加で読み込む必要はありません。
2. レジスターを適用します。voice.md の軸に、その媒体固有の差分を加えます。差分で変えてよいのは軸だけです。不変条件を越えてはいけません。
3. 執筆します。すべての主張は facts.md に基づく必要があります。製品用語はすべて terminology.md から使用します。
4. まずコピーを納品し、その後に理由を説明します。見出しとCTAは、それぞれ何を犠牲にするかを添えて2〜3案提示します。
5. インターフェース文字列の場合は、strings.md の行を追加または更新します。項目はキー、file:line、シナリオ、Status: proposed です。
6. 以下のヒューマナイズのガードに従ってヒューマナイズ処理を実行し、その後にステータス行を出力します。新しいテキストでは、変更率は今書いた草稿を基準に測定するため、編集の場合と同じように50％の上限は適用されません。それでも変更率は報告してください。

編集

marketing-copy.md に記載された7つの見直しを、順番に行い、各見直しの後に最初へ戻ります。明瞭さ、声とトーン、意義、根拠の提示、具体性、感情、リスクゼロの順です。読む順ではなく、影響度の高い順に、見直しごとに内容を提示します。

ヒューマナイズ処理は最後に実行し、その後にステータス行を出力します。見直しでは文全体を書き換えるため、その前にヒューマナイズ処理を行うと、すでに存在しないテキストを基準に測定することになります。また、意味の保持に関するチェックリストは、もう一度書き換える予定のないバージョンに適用するのが最も効率的です。

適応

1つのコンテンツを複数の媒体向けに展開します。媒体ごとに書き直し、ある媒体のレジスターを別の媒体にそのまま貼り付けないでください。展開後も維持するのは主張とその根拠です。変えるのは長さ、構成、CTAの方針、レジスターです。

各バージョンから何を省いたかを明確に示します。スレッドは、改行を入れただけのページではありません。

**ヒューマナイズ処理は元のコンテンツに対して一度だけ行うのではなく、媒体ごとに行います。**各バージョンは異なるレジスターで書かれた別のテキストです。ブログ記事では問題のない特徴の密度も、ランディングページのヒーローでは適切でない場合があります。ステータス行は媒体ごとに1行記載します。

Humanize

既存のテキストを、書き換えずに監査するスタンドアロンモードです： 引き継いだページ、競合他社のコピー、他の人が書いた草稿などが対象です。どこで実行しても同じガードが適用され、任意ではありません：

• 500語あたり約10個を超えるマーカーがある場合は、その旨を伝え、論旨に沿って書き直してください。部分的な修正では、表現が改善されても同じパターンが残ります。
• 変更率が50％を超える場合は、公開してはいけません。 変更率を報告し、確認を求めてください。それはもはや編集ではありません。
• 出力前に、意味が保たれているかのチェックリストを実行してください：数値、日付、固有名詞がそのままであること、因果関係の方向が変わっていないこと、否定が反転していないこと、引用が変更されていないこと、中心となる主張が同じであること。
• すでに自然に読めるテキストは、そのままにします。処理が実行されたことを示すために、問題のない文章を編集するのは、このモードの失敗です。
• マーカー数は判定ではなく、いかなる処理の実行条件にもなりません。 どのマーカーがどの程度の密度で含まれているかを伝えてください。テキストがAIによって書かれたとは決して言わないでください。マーカーの数は著者を証明するものではありません。誤検出の影響は、第二言語で書いている人に最も強く及びます。また、書き手は、本人が望んでいない流暢さへと編集で矯正すべき欠陥ではありません。人間らしさを加える処理は、全体を通してあくまで助言です：B060 は警告を出しますが、エラーにはしません。ai-tells.md には測定内容と、その測定が適用される範囲が記載されています。唯一の例外は em dash（AT-06）です。これは自分が書くテキストでの厳格な禁止事項であり、数える対象ではありません。また、Non-negotiables に記載されています。
• 引用、登録済みの用語、明示的な off は、書き換えを強制するものではありません。 引用内のマーカーは原文の表現です。terminology.md にある用語は繰り返し使うことを意図しています。また、理由を添えた Humanization: off は、テキストをそのまま保持します。ブランド上の禁止事項は、ユーザーの別個のポリシーです — 禁止語は機械生成の兆候ではなく、ブランドが terminology.md で独自に定めたものであり、確認するのはこの処理ではなく、そのチェックです。
• まず voice.md の2つのフィールドを確認してください。 Humanization: は処理を実行するかどうかを示し、既定値は on です。Humanization pass: は使用する実装を指定し、記載がない場合は own になります。どちらも未設定だからといって作業を止めてはいけません。既定の設定で実行し、それが既定値であることを示すステータス行を出力して、一度だけ記録することを提案してください。指定されたツールがインストールされていない場合は own に切り替え、その旨を伝えてください。任意のツールがないからといって、コピーの作成を止めてはいけません。
• ほかの実装もあります。知っておく価値があるものが2つあります — npx sshlg-skills humanizers を実行すると、このマシンで利用できるものを確認できます。書き換えを伴わない監査、長文の文章、自分の文章に合わせるためのサンプルが書き手から提供されている場合は、別の実装を選んでください。製品コピーにはこのモードを使ってください。ブランドパックにあるレジスターと正式な事実が制約であり、汎用のヒューマナイザーはそれらを読み取りません。

絶対に守ること

• 作成するテキストに、どの言語でもエムダッシュ（U+2014）を使わないでください（オーナーの決定、2026-10-18）。頻度の目標ではありません。1つでもあれば、納品前に修正する必要があります。エムダッシュの代わりに --、エンダッシュ、ダッシュの役割をする前後に空白を置いたハイフンを使うこともできません。ピリオド、コンマ、コロン、括弧を使うか、文を書き換えてください。ロシア語の文法上、自然な書き換えができない場合に限り、例外としてダッシュを使用できます。引用、コード、コマンド、パス、過去の記録では、元のダッシュを維持してください。機械的に確認できる項目は B062 と B067 で確認します。それ以外は ai-tells.md の AT-06 を参照してください。

• 見出しやラベルに、装飾目的のピリオドを付けないでください。入れ子になった HTML、書式付き Markdown、「あなたのエージェント。あなたのツール。」のような短い断片も対象です。単なる平文のコピーではなく、レンダリング後の表示上の役割を確認してください。実際の疑問文、省略記号、略語、バージョン、URL、通常の段落の句読点はそのままにしてください。プロジェクトによっては、このルールをヒーローサマリーやキャプションにも適用できます。その場合はブランドポリシーに適用範囲を記録し、生成されたページもテストしてください。 過去のコピーを復元する場合も、現在のプロジェクトの句読点ポリシーを適用してください。過去の完全一致スナップショットは、意図的な例外ではありません。

• 事実、統計、引用、専門家を捏造しないでください。 締め切りが迫っていても、ベンチマークのためでも、プレースホルダーの見栄えをよくするためでも同じです。依頼を断り、理由を説明し、実在するものを探すことを提案してください。

• error、destructive confirm、billing and receipts、paywall and upgrade では、どのパックでもユーモアを使わないでください。 ユーザーが何かを失う状況だからです。

• 1つのアクションには、1つの名称を使ってください。 アクションに名前を付ける前に、strings.md で検索してください。既存のアクションに別の名前を付けることは、類義語ではなく欠陥です。

• facts.md に記載されていない数字は、絶対に引用しないでください。

完了の定義

• すべての文字列またはセクションが、サーフェスの記録と文体にたどり着けます。
• どの状態を報告する場合でも、ヒューマナイゼーションのステータス行を出力します。
• 新しいインターフェース文字列は、場所とシナリオを添えて strings.md に記載します。
• リンターを実行する前に解決します。docs/brand/lint.py があれば使用します。なければ、インストール済みの super-ux リンター brand_lint.py をスクリプトディレクトリで探し、プロジェクトの docs/brand パスを渡します。プロジェクト内にスクリプトがあると決めつけたり、シェルでプラグインルートの変数がエクスポートされていると想定したりしないでください。どちらも存在しない場合は、不足しているツールと手動で確認した範囲を明記します。これをリンター合格として扱ってはいけません。
• Sources: が変更したサーフェスを参照していることを確認します。HTML の見出しロールは、コピー投影後も保持されている必要があります。フラットな段落では見出しの網羅性を証明できません。タイトルの句読点が必須のゲートである場合は、解決済みのスクリプトを --fail-on B063 を付けて実行します（すべての警告を対象にする場合は --strict を使用）。このフラグを受け付けない古いスクリプトは更新が必要です。ゲートを黙って外して再試行してはいけません。
• リンターに加えて、トーン・オブ・ボイスのチェッカーによるスイープを必ず行います。リンターの代わりにはなりません。 設定の有無ではなく、セッション内のツールの有無で判断します。ボイスチェック MCP ツール（*.check と *.voices.list を公開するもの）がある場合は、自分が作成した公開テキストごとに、そのテキストの locale、ボイス一覧にプロジェクトで保存されたボイスがある場合はそれを voiceRef として指定し、スキーマが提供する register と format を使って実行します。目標は、ページでは register: web と format: web-page です。スキーマにまだこれらがない場合は、register: marketing を使い（該当するサーフェスでは ad または store）、format は省略し、web-page パックが利用できなかったことを伝えます。レポート ID を報告し、各指摘に対応するか、受け入れない理由を示します。指摘は B060 と同様、助言です。ツールがない場合は voice checker: not connected, brand_lint only と出力して続行します。
• スキャンしたサーフェス、残っている警告、正確なコマンドと終了コードを報告します。警告が助言扱いであっても、終了コードがゼロだからといってレビュー完了とは見なしません。レンダリング後のコピーとジェネレーターを確認します。ソースだけのチェックでは外部 CSS や実行時のテキストを確認できません。
• 不足していると報告された用語、事実、サーフェスは、回避策で済ませず、それぞれ明示します。

references/ にはほかに何があるか。 このスキルでは契約を 13 件直接指定していますが、references/ には 15 件あります。このスキルで指定した契約がほかの契約を参照しているため、依存関係の全体をスキルに同梱しています。skills CLI はディレクトリを 1 つインストールするため、別のスキルにあるファイルは参照先のない状態で届いてしまいます。ここで指定したファイルを開いてください。残りのファイルは、契約から指示されたときに、その名前で参照できます。