copywriting-cta

作成者: samber

記事末のCTA(ブログ記事、ニュースレター、エッセイ、記事、または長文コンテンツの下部に配置する行動喚起)を設計します。ユーザーが記事、ブログ記事、エッセイの下部にあるCTAの作成、設計、レビュー、改善を依頼した場合、または「記事末CTA」「記事の下部」「行動喚起」「サインアップボックス」「ニュースレターCTA」「購読ブロック」「下部に何を置くべきか」「読者に購読/共有/通話予約/購入を促す方法」などに言及した場合に、このスキルを使用します。

npx skills add https://github.com/samber/cc-skills --skill copywriting-cta

End-of-Article CTA Designer

Designing an end-of-article CTA is a function of three inputs: the objective (what action), the audience (who reads it, in what relationship to the author), and the context (independent writing, newsletter, brand publication). Get those three right and the copy + form follow almost mechanically. Skip them and you get the universal failure mode: a generic "Subscribe for more" or "Learn More" that converts at the noise floor.

This skill runs a tight interview to capture those three inputs, then prescribes a CTA: copy (what it says), form (how it looks and sits on the page), mechanism (whether to use urgency, scarcity, curiosity, reciprocity, social proof, or none), an A/B test plan, and an accessibility check.


Workflow

Run the four steps below in order. Do not skip the interview. The user may have given partial context already; pull what's available from the conversation, then ask only for the missing pieces.

Step 1 — Interview

Use the ask_user_input_v0 tool. Ask one question at a time. Do not stack questions in prose. Each question must have 2-4 tappable options. Fall back to free text only if the answer genuinely cannot be enumerated.

Ask these in order, skipping any already answered:

Q1. Article context. Options: Personal / independent blog or essay · Newsletter / paid publication (Substack, beehiiv, Ghost, etc.) · Brand / company / content-marketing blog · Other (free text)

Q2. Primary objective. (Pick the one outcome you most want from a reader who finishes the article. If they say "all of them," push back: multiple objectives is the #1 cause of CTA failure.)

Options:

  • Newsletter / email subscription
  • Social follow / personal branding
  • Lead generation (download / gated asset)
  • Product or service signup / free trial
  • Demo or sales call booking
  • Direct purchase
  • Community join (Discord / Slack / forum)
  • Engagement (reply / comment / share / restack)
  • Reader support (paid subscription / tip / sponsorship)
  • Try-it / direct action (use the code, run the tool, fork the template, open the calculator)
  • Other (free text)

If the user lists more than one, ask which is primary. You can offer 1-2 secondaries later, but the primary must be singular.

Q3. Audience and relationship. Options: First-time visitor (organic search / social) · Returning reader, not subscribed · Existing subscriber / customer · Mixed / unknown

Q4. Funnel stage. (Where is the reader mentally?) Options: TOFU: discovery, learning, no buying intent yet · MOFU: evaluating options, comparing · BOFU: ready to act, just needs a nudge · Not applicable (no buying funnel — e.g., personal blog, journalism, hobby content)

Q5. Mechanism preference. (Only ask if a mechanism could legitimately help. See references/mechanisms.md. For sophisticated, skeptical, or repeat-reader audiences, default to "None / value-only" without asking.) Options: None: value statement only · Curiosity gap ("Want to know more?") · Reciprocity (free asset first) · Discount / offer · Urgency (real deadline) · Scarcity / FOMO (limited spots) · Social proof (count / testimonial)

Capture any free-text constraints the user volunteers (length limit, brand voice, no popups, multi-language, etc.). Note them.

Step 2 — Diagnose

Map the inputs to a CTA archetype. The decision logic:

context = INDEPENDENT / PERSONAL
├── objective = newsletter / email      → Archetype A: Author-signature subscribe
├── objective = try-it / direct action  → Archetype B: Inline action + source link
├── objective = reader support / tip    → Archetype C: Reader-supported funding link
├── objective = community               → Archetype D: Proof-counted community invite
├── objective = social follow           → Archetype A (variant: lead with social links)
├── objective = engagement              → Archetype E: Specific reply prompt
└── objective = product / demo          → ⚠️ FLAG. Only valid on personal/professional
                                          blog where the author IS the product
                                          (consultants, coaches, solo founders, indie devs).
                                          Frame as "if you hit this, here's how I help"
                                          — never "Book a Demo" verbatim.

context = NEWSLETTER PUBLICATION
├── objective = growth / subs           → Archetype F: Share/restack + native widget
├── objective = engagement              → Archetype E: Specific reply prompt
├── objective = paid conversion         → Archetype G: Value-gap tease
├── objective = monetization / sponsor  → Archetype H: Inline sponsor block (not bottom)
├── objective = community               → Archetype D
└── objective = direct purchase         → Archetype K (rare on newsletters; use BOFU only)

context = BRAND / CONTENT MARKETING
├── stage = TOFU                        → Archetype I: Transitional asset (lead magnet)
├── stage = MOFU                        → Archetype J: Direct + Transitional pair
├── stage = BOFU                        → Archetype K: Direct CTA + risk reversal
├── objective = community               → Archetype D
└── objective = engagement              → Archetype E (rarely the right call here)

Read references/taxonomy.md for the full archetype catalog with copy templates, form specs, when each works, and verbatim examples from named publications.

Step 3 — Compose the recommendation

Output the recommendation in this exact structure. Do not deviate. Do not add filler.

## Recommended CTA

**Archetype:** [letter + name from decision tree] **Why this fits:** [1-2 sentences naming the input combination]

### Content (copy)

**Headline / value line:**

> [exact text]

**Body / proof line (1-2 lines):**

> [exact text]

**Button copy:**

> [exact text]

**Risk reversal / subtext (if applicable):**

> [exact text, or "Omit: would feel forced for this audience"]

### Form (structure)

- **Placement:** [end-only / end + sticky / end + mid-article repeat]
- **Visual weight:** [low / medium / high, with justification]
- **Layout:** [single button / button + text link / native widget cluster / one-line signature]
- **Proof to co-locate:** [subscriber count / star count / testimonial / named recommenders / logo wall / none]

### Mechanism

[Named mechanism + 1 sentence on why it is appropriate, OR "None: value statement carries it. Mechanisms would erode trust for this audience."]

### A/B test plan

- **First test:** [single variable, e.g., button copy A vs. B]
- **Why this one first:** [1 sentence]
- **Sample size needed:** [rough estimate based on baseline traffic, or "skip A/B for now — traffic too low" with the alternative recommendation]
- **Next 2 tests to queue:** [in priority order]

### Accessibility check

- **Color contrast:** [target ratio + concrete pairing if colors known]
- **Touch target:** [size requirement]
- **Semantic markup:** [<button> vs. <a> vs. form]
- **ARIA:** [only if non-obvious]
- **Keyboard / focus:** [requirement]
- **Color-independence:** [non-color affordance]

After printing the recommendation, list 2-3 anti-patterns the user is at risk of falling into given their inputs, directly, as a contrarian check. Pull these from references/anti-patterns.md.

If the user is writing in a non-English language, translate the content section into that language but keep the structure (headings, labels) in English. Honor formality cues (e.g., tu vs. vous in French, du vs. Sie in German) based on prior conversation context, and flag the choice explicitly.

Step 4 — Offer next moves

Suggest 2-3 follow-up directions:

  1. Steelman the opposite. Offer to design the CTA you would recommend against — e.g., the hard-sell version on a TOFU post — so the user can see why it fails.
  2. Variant for a different audience or platform. If the article will be cross-posted (own site + Medium + LinkedIn + a syndication network), offer to rewrite per platform.
  3. End-to-end review. Offer to audit the rest of the article for CTA-supporting signals: author bio, related-post links, in-line proof.

Style inheritance

The copy templates in references/taxonomy.md are starting points, not finished copy. Always adapt them to:

  • The user's stated brand voice or any <userPreferences> in scope (formality, language, em-dash avoidance, length limits).
  • The language of the article. Output copy in the article's language; never default to English.
  • The publication's existing voice. If the user has prior posts visible, mirror their cadence and vocabulary.
  • The reader's expected level of expertise. A CTA for a beginner-finance blog uses different vocabulary than one for a quant-trading newsletter.

Never output a template verbatim if it conflicts with the user's stated style preferences.


Reference files

Read these as needed during diagnosis and composition. Read the relevant file in full before composing the recommendation; do not paraphrase from memory.

  • references/taxonomy.md: All 11 archetypes (A through K) with copy templates, form specs, verbatim examples from named publications, and conversion expectations.
  • references/mechanisms.md: When to use urgency, scarcity, FOMO, discount, curiosity, reciprocity, social proof, authority, unity. When NOT to use them.
  • references/ab-testing.md: Priority order of variables to test, sample-size rules of thumb, common pitfalls, when to skip A/B testing entirely.
  • references/accessibility.md: WCAG 2.2 specifics for CTA blocks: contrast ratios, touch targets, ARIA patterns, focus states, keyboard support, motion preferences.
  • references/anti-patterns.md: 12 failure modes to call out by name when they apply to the user's inputs.

Operating principles

  • One primary CTA per post. Multiple competing CTAs is the dominant failure mode (single-CTA pages convert ~30%+ better than multi-CTA pages in repeated case studies).
  • Match the voice of the publication. A personal-essay footer that reads like a SaaS landing page collapses credibility. A SaaS footer that reads like a casual signature converts at noise.
  • Specificity beats cleverness. "Get one essay a week on indie filmmaking" beats "Subscribe to our awesome newsletter." Joanna Wiebe's "I want to ___" completion test is the cleanest filter for button copy.
  • Proof co-located with the ask. Subscriber count, testimonial, customer logos, star count, named recommenders — whichever signal is honest for the context, place it inside or adjacent to the CTA block.
  • Mechanisms are tools, not garnish. Most well-written value statements need no mechanism. Add urgency, scarcity, FOMO, or discount only when the context genuinely supports them; theatrical mechanisms erode trust faster than they lift conversion.
  • Push back on bad asks. If the user wants "Book a Demo" at the bottom of a beginner tutorial for first-time visitors, say so. Do not produce a polished version of a CTA that will fail. Propose the alternative, explain why, then if the user still wants the original, deliver it with the failure mode flagged.

samberのその他のスキル

golang-code-style
samber
We need to translate the given text from English to Japanese, preserving the name "golang-code-style" and other technical terms. The instruction says: "Translate only the text inside <text>. Do not include the name unless it appears in the source text." The name "golang-code-style" appears in the source text? Actually, the source text does not contain the name "golang-code-style" explicitly. The name is given in the context: "Name to preserve: golang-code-style". But the instruction says "Do not include the name unless it appears in the source text." Since it does not appear in the source text, we should not add it. However, the source text contains references like "samber/cc-skills-golang@golang-naming" etc. Those should be preserved as is. We need to translate the description of the skill. The text describes conventions for Go code style. We'll translate into natural Japanese, keeping technical terms like "Go", "linter", "doc comments" etc. Also preserve the arrows and references. Let's break
developmentcode-review
golang-testing
samber
We need to translate the given text from English to Japanese, preserving the name "golang-testing" if it appears. The text is a description of a directory item type "agent skill". The instruction says: "Do not include the name unless it appears in the source text." The name "golang-testing" does not appear in the provided <text>? Actually, looking at the text: it starts with "Production-ready Golang tests — ..." and later mentions "samber/cc-skills-golang@golang-stretchr-testify". The name "golang-testing" is not in the text. So we should not add it. We just translate the content. We need to preserve product names, protocol names, URLs, numbers, technical terms. So "Golang", "testify", "goleak", "CI", "Go", "samber/cc-skills-golang@golang-stretchr-testify" should remain as is. Also "table-driven tests", "testify suites and mocks", "parallel tests", "f
developmenttestingcode-review
golang-design-patterns
samber
慣用的なGo言語のデザインパターン — 関数型オプション、コンストラクタ、エラーフローとカスケード、リソース管理とライフサイクル、グレースフルシャットダウン、耐障害性、アーキテクチャ、依存性注入、データ処理、ストリーミングなど。アーキテクチャパターンを明示的に選択する際、関数型オプションを実装する際、コンストラクタAPIを設計する際、グレースフルシャットダウンを設定する際、耐障害性パターンを適用する際、または特定の問題に適合する慣用的なGoパターンを尋ねる際に適用します。
developmentdesigncode-review
golang-error-handling
samber
We need to translate the given English text into Japanese, preserving the name "golang-error-handling" if it appears, but it does not appear in the text. The text is a description of a skill for idiomatic Go error handling. We must not add any extra commentary, labels, or formatting. Just the translation. The text includes technical terms: "Idiomatic Golang error handling", "creation", "wrapping with %w", "errors.Is/As", "errors.Join", "custom error types", "sentinel errors", "panic/recover", "single handling rule", "structured logging with slog", "HTTP request logging middleware", "samber/oops for production errors", "log aggregation 3rd-party tools", "Go code", "samber/cc-skills-golang@golang-samber-oops". These should be preserved as is or translated appropriately. For example, "Idiomatic Golang error handling" can be translated as "慣用的なGoのエラーハンドリング". But we need to keep technical terms like "errors
developmentcode-review
golang-performance
samber
Golangのパフォーマンス最適化パターンと方法論 - XのボトルネックがあればYを適用。アロケーション削減、CPU効率、メモリレイアウト、GCチューニング、プーリング、キャッシング、ホットパス最適化をカバー。プロファイリングやベンチマークでボトルネックが特定され、それを修正するための適切な最適化パターンが必要な場合に使用。また、パフォーマンスコードレビューを行い、改善点や迅速なパフォーマンス向上を特定するのに役立つベンチマークを提案する場合にも使用。測定方法論には使用しない(→...)
developmentcode-review
golang-security
samber
Golangのセキュリティベストプラクティスと脆弱性防止。インジェクション(SQL、コマンド、XSS)、暗号化、ファイルシステムの安全性、ネットワークセキュリティ、クッキー、シークレット管理、メモリ安全性、ログ記録をカバー。Goコードのセキュリティに関する作成、レビュー、監査時、または暗号、I/O、シークレット管理、ユーザー入力処理、認証を含むリスクのあるコードに取り組む際に適用。セキュリティツールの設定を含む。
securitycode-reviewdevelopment
golang-database
samber
Goデータベースアクセスの包括的ガイド — パラメータ化クエリ、構造体スキャン、NULL許容カラム、トランザクション、分離レベル、SELECT FOR UPDATE、コネクションプール、バッチ処理、コンテキスト伝搬、マイグレーションツール。PostgreSQL、MariaDB、MySQL、SQLiteと連携するGolangコードの作成、レビュー、デバッグ時、データベーステスト時、またはdatabase/sql、sqlx、pgxに関する質問時に使用します。データベーススキーマやマイグレーションSQLは生成しません。
developmentdatabase
golang-lint
samber
GolangプロジェクトにおけるLintのベストプラクティスとgolangci-lintの設定 — リンターの実行、.golangci.ymlの設定、nolintディレクティブによる警告の抑制、Lint出力の解釈、リンターの選択。golangci-lintの設定時、Lint警告やnolint抑制について質問がある時、コード品質ツールのセットアップ時、またはリンターを選択する時に使用します。また、ユーザーがgolangci-lint、go vet、staticcheck、reviveに言及した場合にも使用します。
developmentcode-reviewtesting