Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问许可证需确认审计通过

marketing-automation营销自动化

Agent Skill

marketing-automation 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

1,972

周安装

83

GitHub Stars

11

下载量

691
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:marketing-automation(营销自动化)
来源仓库:https://github.com/akillness/oh-my-skills
仓库路径:skills/marketing-automation
安装命令:
npx skills add https://github.com/akillness/oh-my-skills --skill marketing-automation
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/akillness/oh-my-skills --skill marketing-automation

简介

该技能用于营销自动化中的需求分类与流程引导,帮助选择正确的营销执行路径和操作模板。

  • 适用于需要明确运营模式、确定负责人、依赖关系和审批流程的营销规划场景。
  • 核心能力包括将复杂请求归一化为标准操作包,并合理路由至专业工作流,避免过度发散。
  • 安装前建议核实权限边界、维护状态及是否触发网络访问或系统操作。
  • marketing-automation 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Marketing Automation

Use this skill as the canonical broad marketing front door when the real job is choosing the right next marketing packet.

The job is not to generate a giant campaign brainstorm. The job is to:

  1. classify the ask into one operating mode,
  2. choose one primary lane,
  3. produce one reusable operator packet,
  4. name the owner, dependencies, approvals, and proof stack,
  5. route out when the request is actually planning, game-store launch ops, or another narrower specialist workflow.

Read these support docs before finalizing the packet:

When to use this skill

  • The user asks for broad marketing help and the right next packet is still ambiguous.
  • A product, website, funnel, launch, onboarding flow, or pricing surface needs one structured marketing brief before detailed execution starts.
  • The request mixes strategy, surface choice, messaging, content, channels, and measurement.
  • The user needs a reusable operator brief, not a pile of disconnected suggestions.

When not to use this skill

  • The ask is already clearly Steam/store-page/festival/game launch worksteam-store-launch-ops.
  • The real job is backlog shaping, milestone coordination, or cross-functional implementation slicingtask-planning.
  • The user wants only one atomic copy rewrite or finished content asset with no broader routing layer → use the narrower writing/execution workflow directly.
  • The request is mostly product strategy, UX research, or technical implementation rather than marketing routing → route to the stronger adjacent skill.

Core routing model

Operating modes

Use one primary mode per run:

  • launch-orchestration — broad launch, GTM, pricing, or rollout sequencing across multiple surfaces
  • conversion-surface — landing page, pricing page, signup flow, paywall, or onboarding conversion friction
  • lifecycle-retention — onboarding, activation, retention, churn, lifecycle email, re-engagement, or user education motion
  • acquisition-content — SEO, content strategy, comparison pages, organic acquisition, or channel-facing discovery work
  • measurement-experiment — analytics setup, attribution, KPI cleanup, campaign readout, or experiment/backlog instrumentation

Primary lanes

After choosing the mode, still choose one primary lane:

  • CRO
  • Copy & messaging
  • SEO & content
  • Ads & analytics
  • Strategy & growth

The mode explains what kind of situation this is. The lane explains which marketing discipline owns the next packet.

Instructions

Step 1: Normalize the intake into one routing profile

Capture the request in this compact form before choosing the packet:

marketing_router_profile:
  primary_mode: launch-orchestration | conversion-surface | lifecycle-retention | acquisition-content | measurement-experiment
  primary_lane: CRO | Copy & messaging | SEO & content | Ads & analytics | Strategy & growth | unknown
  objective: acquisition | activation | conversion | retention | revenue | awareness | unknown
  audience:
    segment: "who this is for"
    stage: unaware | problem-aware | evaluating | active-user | churn-risk | unknown
  surface_or_channel: landing-page | pricing-page | signup-flow | onboarding | lifecycle-email | seo-page | campaign | dashboard | launch | unknown
  offer_or_motion: "product / feature / campaign / launch motion"
  measurement_maturity: clear | partial | weak
  main_question: "what needs to be decided next?"
  delivery_owner: "who will carry the packet next"
  dependencies_or_approvals:
    - "design / analytics / engineering / legal / partner / none"
  proof_assets_available:
    - "dashboard / baseline export / campaign data / user feedback / none"
  constraints:
    timeline: immediate | this-week | this-month | longer
    brand_or_compliance_notes: "limits or promises"
    domain_specificity: general | specialist | game-store

If detail is missing, proceed with explicit assumptions instead of stalling.

Step 2: Gather the minimum credible evidence

Do not route from vibes alone. Pull the smallest packet that supports a real decision:

  • objective and current bottleneck
  • audience / segment / funnel stage
  • surface, campaign, or lifecycle moment
  • available proof points or constraints
  • current KPI or best available proxy
  • who owns the next move
  • which dependencies or approvals can block execution
  • what is still missing that could change the lane choice

Step 3: Choose one mode, one lane, one packet

Use references/operating-modes-and-route-outs.md.

Default packet mapping:

  • launch-orchestration → usually Strategy & growthlaunch/growth brief
  • conversion-surface → usually CRO or Copy & messagingmeasurement + experiment packet
  • lifecycle-retention → usually Strategy & growth or Copy & messagingchannel-ready brief
  • acquisition-content → usually SEO & contentchannel-ready brief
  • measurement-experiment → usually Ads & analyticsmeasurement + experiment packet

Rules:

  • Choose one primary mode.
  • Choose one primary lane.
  • Return one primary packet.
  • Mention secondary handoffs only after the main packet is chosen.

Step 4: Add route-outs before the packet sprawls

Route out instead of absorbing adjacent work when:

  • the ask is really Steam wishlists / capsules / Next Fest / store visibility → steam-store-launch-ops
  • the ask is really execution slicing / backlog organization / milestone coordination → task-planning
  • the ask is already a narrow specialist workflow with a better dedicated skill

A good front door narrows the next move. It does not win by claiming every neighboring job.

Step 5: Build the operator brief

Use references/operator-packet-and-proof-stack.md.

Return this structure:

# Marketing Routing Brief

## Intake summary
- Mode: ...
- Primary lane: ...
- Objective: ...
- Audience / stage: ...
- Surface / channel: ...
- Confidence: high | medium | low

## What matters most now
- 2-4 bullets

## Recommended packet
- Packet type: launch/growth brief | channel-ready brief | copy/messaging packet | measurement + experiment packet | marketing-routing brief
- Why this packet now: ...

## Operator packet
- Primary owner: ...
- Dependencies / approvals: ...
- Required assets or inputs: ...
- Delivery horizon: ...

## Priority decisions
| Decision | Why now | Owner | Risk if delayed |
|----------|---------|-------|-----------------|
| ... | ... | ... | ... |

## Immediate next steps
1. ...
2. ...
3. ...

## Proof stack
- Primary KPI: ...
- Leading signal: ...
- Baseline or assumption: ...
- Success threshold: ...
- Readout window: ...
- Next owner / workflow: ...

## Secondary handoffs
- Skill / workflow: ...
- Why: ...

## Not yet
- 1-3 bullets that prevent scope drift

Step 6: Keep proof attached to the packet

Every output must name:

  • one primary KPI
  • one leading signal
  • one baseline or explicit assumption
  • one success threshold
  • one readout window or review checkpoint
  • one next owner or downstream workflow

Use references/operator-packet-and-proof-stack.md for the operator packet shape and references/measurement-handoff.md for lane-specific KPI examples.

Output format

Always return a short operator-style Marketing Routing Brief.

Required qualities:

  • one primary mode
  • one primary lane
  • one packet that can actually be handed off
  • explicit assumptions when context is thin
  • named owner plus dependency/approval visibility
  • route-outs when the ask is not really this skill
  • proof logic attached to the packet, not bolted on later

Examples

Example 1: broad launch ask

Input

We are launching a new SaaS workflow next month and need help with messaging, landing page copy, onboarding emails, and how to measure whether it worked.

Output sketch

  • Mode: launch-orchestration
  • Lane: Strategy & growth
  • Packet: launch/growth brief
  • Secondary handoffs mention copy/messaging and lifecycle execution
  • Operator packet names one owner plus likely dependencies or approvals
  • Proof stack names one launch KPI and one leading signal

Example 2: pricing-page refresh

Input

Our pricing page gets traffic, but upgrades are weak. We need help with the page and what to test.

Output sketch

  • Mode: conversion-surface
  • Lane: CRO
  • Packet: measurement + experiment packet
  • Priority decisions cover offer clarity, CTA hierarchy, proof, and friction

Example 3: lifecycle / onboarding ask

Input

Trial users activate once and disappear. We need onboarding and lifecycle help, plus a sensible KPI.

Output sketch

  • Mode: lifecycle-retention
  • Lane: Strategy & growth or Copy & messaging
  • Packet: channel-ready brief
  • Operator packet names the lifecycle owner and any analytics or product dependency
  • Proof stack names activation or retained-usage KPI plus a leading signal

Example 4: game-store launch near miss

Input

We need Steam capsule copy and Next Fest marketing help for our game demo.

Output sketch

  • Keep the response short
  • Route execution to steam-store-launch-ops
  • Leave only a concise handoff note instead of a giant generic marketing plan

Best practices

  1. Act like a front-door router, not a generic growth advisor.
  2. Choose one mode before you choose tactics.
  3. Choose one packet before you list channels.
  4. Keep owner, approvals, and dependencies visible instead of assuming automation removes them.
  5. Keep launch/planning/game-store boundaries explicit.
  6. Attach proof and ownership to every packet.

References

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

35.83%
按下载量换算248

Claude

28.73%
按下载量换算199

Cursor

16.8%
按下载量换算116

Gemini CLI

9.2%
按下载量换算64

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills