Token导航 LogoToken导航

Agent Skill · 研究检索

outclaw-plan(亡爪计划)

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

outclaw-plan 是研究检索类 Agent Skill,可用宿主为 OpenClaw,通过ClawHub获取,权限为需要联网;许可证为 MIT-0,第三方扫描有提醒项,按安装量在研究检索类的 73,675 个 Skill 里排第 30,744。

总安装 2,822周安装 120GitHub Stars 公开资料未说明下载 989核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT-0
版本
1.0.6

安装方式

通过对话安装

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

请帮我安装这个 Agent Skill:outclaw-plan(亡爪计划)
来源仓库:https://github.com/milstan/outclaw-plan
安装命令:
openclaw skills install outclaw-plan
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

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

ClawHubOpenClaw
openclaw skills install outclaw-plan

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

用于构建、安排与监控多渠道 B2B 外展活动,支持多步流程设计。可读取用户知识库与学习风格,定制个性化沟通策略。集成 Leadbay/LeadClaw 等工具链,实现线索流转与反馈收集。使用前需完成渠道连接配置,如 Gmail、Slack 与 LinkedIn 授权。

注意:外展内容应符合反垃圾邮件规范,避免过度频繁联系。

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 OpenClaw;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 openclaw skills install outclaw-plan;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

outclaw-plan 怎么安装?

在终端执行 openclaw skills install outclaw-plan。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

outclaw-plan 支持哪些 AI 工具?

公开资料标注支持 OpenClaw。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

outclaw-plan 需要什么权限?

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

outclaw-plan 是免费的吗?

来源标注的许可证是 MIT-0。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

outclaw-plan 用的人多吗?

公开数据是累计安装 2,822 次,近一周安装 120 次,下载 989 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

outclaw-plan 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

值得选的地方和要先想清楚的地方

值得选的地方

  • 专注 OpenClaw 一种宿主,触发方式和使用习惯不用来回切换。
  • 许可证明确为 MIT-0,商用和分发边界好判断。

先想清楚的地方

  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 OpenClaw,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
outclaw-plan

亡爪计划 · 本页

2,822—需要联网MIT-0有提醒

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

name
outclaw-plan
description
>
version
2.1.33
metadata
openclaw
emoji
🎯
homepage
https://github.com/leadbay/outclaw

OutClaw — Plan, Execute, Listen, React

Your job is to take a target (person or list) and produce an outreach plan that has a genuine reason for the conversation, respects the user's constraints, and is robust enough that the user can approve it per- touchpoint without babysitting.

You absorb three capabilities from the old single-skill Modules 3/4/5:

  • Campaign planning — research → angle → channels → sequence → approval → schedule
  • Response listening — classify replies, pause, propose revisions
  • Campaign dashboard + management — status view, pause/resume/cancel/archive

Resolver mandate (non-negotiable)

Before writing to KB or memory, read shared/references/RESOLVER.md and the per-tenant capability map at capabilities/<tenant>.json. NEVER propose a channel, action, or touchpoint whose precondition isn't satisfied in the capability map (e.g., like_tweet requires the target to have a twitter_handle in their KB page). Skip unsatisfied actions silently and tell the user: "Plan shortened — we don't have <cap>."

When a required prerequisite is missing, auto-invoke the right skill silently — do NOT ask the user:

  • Target's KB page missing or stale → invoke outclaw-research.
  • A channel in the plan has no learned style for this tenant → invoke

outclaw-style for that channel before drafting.

  • Capability map older than 24h → invoke

shared/scripts/capabilities.py --refresh.

You never send without explicit user approval per touchpoint. Default anti-spam limits: ≤20 new cold outreaches per day across all channels, ≥3 business days between touchpoints to the same prospect, sequential cross-channel (never simultaneous).

Daily batch — 10–15 targets, Day-1 drafts only, scaffold-driven

The default request "get me some leads and propose outreach plans" = 10–15 fresh targets with a Day-1 email draft each, not a 3-target toy. Three plans a day is noise for a salesperson who gets a 5% reply rate. The full multi-touchpoint sequence for each target is laid out as a TIMELINE (Day 0, Day 4, Day 10…) but only the Day-1 email is drafted up front; follow-ups are drafted later when / if the reply window closes with no reply.

Batch flow (fits within one turn):

  1. outclaw-research runs outclaw_daily_batch.sh — pulls Leadbay batch,

persists Tier-1 stubs (now richer: qualification_summary + tags + recommended contact baked in), picks fresh top 15, writes manifest.

  1. Skip Tier-2 research for the default 15. The Tier-1 body carries

the Leadbay AI qualification excerpt + tags + contact — enough for a Day-1 draft. Tier-2 is opt-in for targets the user says "go deeper on".

  1. Agent calls plan_scaffolder.py --max 15 → writes

/tmp/outclaw-plan-draft.md with a summary table + per-target sections. Each section already contains 3 angle hooks (literal quotes from the Tier-1 body), the sender identity (from kb/me/self.md), and the on-brand company copy (from kb/me/org.md).

  1. Agent's remaining work: fill the <AGENT FILLS> email body + the

Provenance block for each target. NO research, NO KB lookups — everything needed is in the scaffold.

  1. Agent calls mark_plan_drafted.py <slug1> ... <slug15> BEFORE

presenting (tomorrow's top_picks will correctly skip these).

  1. Agent runs channel_validator.py + draft_checker.py on the filled

file. Both MUST print verdict=pass before presenting.

  1. Present to the user by literally cat-ing /tmp/outclaw-plan-draft.md.

You MAY add a one-paragraph header above and one-paragraph footer below (e.g., "Here are the 15 targets; say approve/edit/cancel per T0."), but the plan body itself MUST be the file's content verbatim. Do NOT add new touchpoints, channels, case studies, or references not in the file. The validators graded the FILE; whatever you paste to the user must equal what they graded.

Divergence check before presenting: after running the validators, pipe your FULL intended chat reply through draft_checker.py one more time (write it to /tmp/outclaw-reply.md first). If that also comes back verdict=pass, send it. If not, fix the chat reply to match the file — don't argue with the checker.

Why this works: separating background research (deterministic, scriptable, no LLM creativity required) from Day-1 drafting (LLM creativity only, constrained by scaffold) keeps each turn within the o3 reasoning budget. The agent doesn't "pause mid-chain" because the chain is short.

Zero-fabrication in drafts (applies to EVERY message body)

Research has a verification gate (cat each KB file after writing). Drafts didn't — and that gap let plans pass every hardrail while still containing invented metrics and case studies in email bodies. Closing the gap:

Provenance required for every concrete claim in a draft. Every metric (numbers: "3× outreach efficiency", "40% lift in SQLs"), named case study ("we helped X do Y"), URL citation ("your Business Insider feature 'Z'"), and product-capability statement in a draft body MUST be traceable to one of:

  1. kb/me/org.md (user's own value props + differentiators + case studies)
  2. kb/people/<slug>.md or kb/orgs/<slug>.md (the target's page)
  3. A URL you actually web_fetch-ed this session, with the path to

its raw/ snippet

  1. User-supplied text pasted into the current conversation

If a concrete claim isn't backed by one of those four sources, remove it from the draft. Replace with an honest, vaguer version:

Fabricated (forbidden)Honest replacement
"we saw a 40% lift in SQLs""we've seen meaningful SQL lifts at comparable SaaS startups" (only if org.md says so) or delete
"3× outreach efficiency""improves outreach efficiency" (if org.md claims it) or delete
"your Business Insider feature 'X'"delete unless raw/jason-lemkin-<ts>.md actually contains that article
"the playbook we used at Acme Inc"delete unless org.md lists Acme as a case study

Mandatory pre-draft gate — org_readiness.py must pass. The old "does org.md exist and have ≥20 lines" check was too loose: a generic org.md full of placeholders passes a length check but still produces bot copy with hallucinated value props ("40% SQL lift", "Lowe's & Home Depot partnerships"). Replace with the real readiness check:

python3 ~/.openclaw/skills/outclaw/shared/scripts/org_readiness.py --json

The gate requires kb/me/org.md to have real content in 5 sections: ## One-liner, ## Company website, ## Products / Services, ## Value propositions (≥3 on-brand lines the agent may quote in drafts), and ## Differentiators. Placeholder text ((TBD), (Intentionally empty), TODO, lorem, example.com) hard-fails the gate.

  • ready=true → proceed to drafting. The value-props section is the

ONLY source the agent may quote when talking about user's company in drafts; drafts MUST grep-match one of those lines in the Provenance block.

  • ready=false → STOP. Do NOT improvise. Tell the user:

> "I can't draft outreach copy yet — your company profile > (kb/me/org.md) is missing/thin on <list of sections>. Let's do > 2-minutes of outclaw-setup Step 2 so drafts quote your real > website copy instead of inventing claims." Then invoke outclaw-setup Step 2 (which acquires the website, web_fetches its pages into kb/raw/, and walks the user through capturing value props + differentiators verbatim).

Once ready, load identity into context:

cat ~/.openclaw/outclaw/kb/me/self.md
cat ~/.openclaw/outclaw/kb/me/org.md

Placeholder ban (hard-refused by the checker). A draft body containing ANY of these literal strings is a reject: [Your Name], [YourCompany], [Your Company], [First Name], {First}, {Company}, {YourName}, <sender>, <company>. Use the real name + company from kb/me/self.md and kb/me/org.md. If those files are missing/stub, STOP and route to outclaw-setup Step 2. Do not "draft with placeholders and ask the user to fill in" — that's the failure mode we're preventing.

Research → KB before drafting. If you web_fetch a URL and the facts from it will appear in a draft, you MUST persist the fetched body to kb/raw/<slug>-<ts>.md FIRST and then cite that raw file — not the URL — in the Provenance block. The checker only verifies substrings against files under ~/.openclaw/outclaw/; a bare URL citation won't pass.

Mandatory post-draft verification (do this after drafting, before presenting): re-read each draft body and check every concrete claim against the four-source list above. Regenerate any draft whose claim can't be traced.

Provenance block — direct quotes only, no paraphrasing. On each touchpoint include a Provenance block where every entry pairs the draft phrase with a literal grep-able substring copied from a real file. A paraphrase or "summary" is fabrication dressed up — if you can't paste the exact source text, remove the claim.

Touchpoint T2 — cold email
  Draft: "Hi Jason, loved your Apr 19 'What Moat?' piece. At Leadbay
  we're building agentic B2B KBs — open-source, CLI-first."
  Provenance:
  - "Apr 19 'What Moat?' piece"
    → kb/people/jason-lemkin.md contains literal: "Apr 19, 2026 — What Moat?"
  - "agentic B2B KBs"
    → kb/me/org.md contains literal: "agentic B2B sales knowledge base"
  - "open-source" → kb/me/org.md contains literal: "open-source OpenClaw skill pack"
  - "CLI-first" → kb/me/org.md contains literal: "CLI-first / MCP-first"
  - No other concrete claims.

No promise-then-silent turn closes. NEVER close a turn with "I'll spin on that", "surface shortly", "stand by", "hang tight", "more to come", or any equivalent. That pattern is a silent failure — the agent promises work, yields control, and never returns. If you can't complete the request in this turn, stop at the last completed step, say what you delivered + what's missing, and ASK the user to confirm the next step. The draft_checker.py promises check rejects plans containing these phrases.

Mark each org's page BEFORE presenting a plan for it. This prevents tomorrow's leadbay_top_picks.py from re-surfacing the same lead:

python3 ~/.openclaw/skills/outclaw/shared/scripts/mark_plan_drafted.py \
  <org_slug_1> <org_slug_2> ...

The stamp writes last_plan_drafted_at: <ISO> to the org's frontmatter. The top-picks helper skips orgs stamped within the last 7 days; if all top candidates are stamped, it falls back to the stale pool and surfaces a skipped_recent list the agent MUST show the user ("3 fresh + 2 still in flight since <date>; include anyway?").

Self-audit before presenting the plan — run BOTH checker scripts. Write the whole plan draft to /tmp/outclaw-plan-draft.md (using your Write tool), then run in order:

# 1. Channel validator — rejects unsupported channels + user-discretion
#    touchpoints (phone/call/voicemail are NEVER in an agent-planned
#    sequence; the user books those manually).
python3 ~/.openclaw/skills/outclaw/shared/scripts/channel_validator.py \
  --from-file /tmp/outclaw-plan-draft.md --format human

# 2. Draft checker — verifies every Provenance "contains literal: "X""
#    citation actually grep-matches the cited file + flags placeholders.
python3 ~/.openclaw/skills/outclaw/shared/scripts/draft_checker.py \
  --from-file /tmp/outclaw-plan-draft.md --format human

Both scripts MUST print verdict=pass before you present the plan.

  • channel_validator fail → the plan mentions a channel whose plugin

isn't bound to this tenant (e.g. LinkedIn without linkedin-cli installed) OR a user-discretion channel (phone/call/voicemail). Remove that touchpoint entirely. Do not "leave it in case the user wants to do it themselves" — the plan is only for touchpoints the agent can execute.

  • draft_checker fail → at least one Provenance citation is fabricated,

OR the body contains a placeholder like [Your Name]. The human-format output names each failure. REGENERATE any touchpoint whose citation failed; replace placeholders with the real name+company from kb/me/self.md and kb/me/org.md. Re-run the checker. Do not present to the user until verdict=pass.

You MAY NOT present a plan that the checker flagged as fail. Paraphrasing a source is fabrication dressed up — if you can't paste the exact source text, remove the claim. Examples of fabrications we caught in live testing and that the checker now hard-rejects:

  • "recent leadership milestone" (no KB file mentioned leadership change)
  • "CSR certification" (no tag, qual_summary, or signal contained this)
  • "MegaDeck project data" (invented product reference)
  • "£2.2M expansion" (no signal in the research payload with that figure)
  • "2025-09-02 — Shane Hopkie appointed CEO" (cited as a quote from

kb/people/shane-hopkie.md which was a stub — the agent invented the date + appointment, cited a real path, and passed the old no-checker hardrail. The script catches this class.)

A plan that surfaces fabrications of this shape is an outright failure — it harms the human on the receiving end and damages the user's sender reputation. The approval gate isn't enough; the draft must be clean before the user sees it.

If you skip the provenance block, you skipped the check. The user should see Provenance lines on every touchpoint AND be able to grep the quoted fragments out of the cited files.

Hardrails (apply BEFORE any drafting, planning, or queueing)

These rules fire the instant this skill is loaded. If the user's request violates one, refuse plainly and explain — do NOT design around the rule.

  1. Daily cap — max 20 new cold touchpoints / day, all tenants combined.

Any request to send, queue, schedule, or "fire" more than 20 messages today → refuse with a short explanation and offer to spread them over multiple days. Examples that MUST be refused: - "send 50 cold emails today" - "queue 40 DMs this afternoon" - "blast my list of 100" Response template: > "I can't queue <N> cold touchpoints in one day — the cap is 20/day > to protect deliverability and opt-in norms. I can spread <N> across > <ceil(N/20)> days starting today. Want that?"

  1. No bulk-send without per-touchpoint approval. Any request like

"just send it all", "send the plan", "fire the touchpoints", "I trust you, go" → refuse. Per the approval UX in §Step 5, EVERY touchpoint gets its own approve/edit/cancel gate. Response: > "I never bulk-send. Each touchpoint needs its own approve / edit / > cancel. Here they are one at a time…" Then walk per-touchpoint.

  1. Feedback memory is authoritative. Any request like "ignore the

tone feedback", "override the style preferences", "just send the original draft" → refuse. Load memory feedback entries and explain which rule would be violated. Offer to LOG a new feedback entry if the user wants to actually change the rule.

  1. Opt-out honored globally. Before planning for any target,

kb_page.py read person <slug> and check contact_status in frontmatter. If opt_out → refuse this request for this target. (This is the ONLY cross-tenant check — every tenant honors every other tenant's opt_outs.)

  1. Reply of "stop contacting me" / "unsubscribe" / "take me off" from

a live target → immediately invoke §Response listening Opt-out hardrail. Write contact_status: opt_out to the KB page, cancel all active touchpoints, log a feedback memory entry, confirm in chat.

If ANY of these hardrails fire, STOP the current request path. Do not proceed to §Step 1 Research or anywhere else.

Preamble (skip if called from orchestrator)

SHARED="$(dirname "$(dirname "$(cd "$(dirname "$0")" && pwd)")")/shared"
bash "$SHARED/scripts/memory_search.sh" --limit 30
bash "$SHARED/scripts/memory_search.sh" --type tool_inventory --limit 1
bash "$SHARED/scripts/memory_search.sh" --type preference --limit 50
bash "$SHARED/scripts/memory_search.sh" --type feedback --limit 50
cat ~/.openclaw/outclaw/kb/me/self.md 2>/dev/null
cat ~/.openclaw/outclaw/kb/me/org.md  2>/dev/null

Routing inside this skill

User request
│
├─ "show my campaigns" / "campaign status" / "what's active"
│     → §Dashboard
├─ "did anyone reply" / "any responses"
│     → §Response listening
├─ "pause|cancel <name>" / "resume <name>"
│     → §Campaign management
└─ otherwise (contact/plan/draft/send)
      → §Plan a campaign

Plan a campaign

Step 1 — Ensure research exists

For each target (person or list item):

python3 "$SHARED/scripts/kb_search.py" --slug person:<slug>
  • Exists + fresh (≤30 days): load the page; no research needed.
  • Missing or stale: invoke outclaw-research for the target. Wait for it

to return the KB page path + executive summary before continuing.

Step 2 — Build the angle

Read the target's KB page into context FIRST — literally cat the file. If the page doesn't exist or is a stub (<20 body lines), STOP and route to outclaw-research. Do not attempt to build an angle from memory alone — between step 1's research pass and step 2's angle-building, your working memory will drift; the KB file is the source of truth.

cat ~/.openclaw/outclaw/kb/people/<slug>.md
cat ~/.openclaw/outclaw/kb/orgs/<org-slug>.md 2>/dev/null
cat ~/.openclaw/outclaw/kb/me/self.md 2>/dev/null
cat ~/.openclaw/outclaw/kb/me/org.md  2>/dev/null

Zero-hallucination rule: every hook, connection point, and "why-now" clause in the angle MUST quote a specific line from one of those four files. If you can't quote it, you can't write it.

The angle is a short reasoning chain that answers:

*Why would THIS person, at THIS moment, want to have a conversation with the user about the user's product/service?*

Requirements (the eval will enforce these):

  • ≥3 concrete hooks from the target's KB page (post, talk, career move,

company news, topic overlap). Generic platitudes ("thought leader in X, could benefit from Y") fail the eval.

  • ≥1 connection point from kb/me/ (mutual org / school / topic / connection).
  • 1-2 sentence why-now: why this week rather than three months ago

(recent signal + relevance to user's product).

  • A clear ask: what outcome constitutes "this worked" (15-min intro call?

book demo? feedback on a beta?). Be honest about friction.

Write the angle as a short markdown block; you'll show it to the user in the approval gate.

Step 3 — Channel & action selection

Enumerate the inventory's _ready_outreach_channels. Pick the channels you actually have — never propose one that isn't ready.

Channel heuristics (see references/channel-adapters.md):

  • Enterprise prospect (>500 employees or explicit "enterprise" ICP):

email-first; LinkedIn as warm-up.

  • Startup prospect: multi-channel (email + LinkedIn + Slack/Twitter if ready).
  • Existing relationship signal (mutual connection / prior touch): warm

channel first.

  • No preferred channel ready: use the best available + tell the user

what they're missing.

Touchpoints are NOT only messages. For each channel, consider these discrete actions (depending on channel support):

ChannelActions
LinkedInconnect request, follow, like target's recent post, comment on a post, send InMail, DM
Twitter/Blueskyfollow, like, quote-reply, thread-reply, DM
Emailcold email, follow-up, breakup email
Slackjoin public community + DM, shared-channel invite
WhatsAppinitial DM, follow-up (business context only)

A strong plan uses social actions as warm-ups before messages. For example: Day 0 follow + like recent post → Day 2 connection request with a short note citing the post → Day 5 email with the meatier pitch. That's far more effective than cold-email-then-followup-then-breakup.

Step 4 — Sequence

Sequencing rules (MUST obey unless the capability map forces otherwise):

  1. Minimum 3 touchpoints. Fewer is under-engineered. 5 is ideal when

multiple channels are bound; 3–4 is fine for email-only tenants.

  1. First touchpoint is a social warm-up (follow, like, comment,

connect) — NEVER a cold message, if the tenant has any social plugin bound (twitter, bluesky, linkedin, slack, etc.). If the tenant has ONLY email available (e.g. just gog), skip the warm-up rule — email-first is acceptable. Do NOT invent a social channel just to satisfy the rule (that's the fabricated-LinkedIn failure we caught live). Instead, tell the user: "Plan starts with email — no social channel is connected; install xurl / bsky-mcp / slack-cli if you want a warm-up T0."

  1. ≥3 business days between message-class touchpoints (email, DM,

InMail, WhatsApp, SMS). Social actions (like, comment) can be same-day as a prior social action, but not same-day as a message.

  1. Sequential cross-channel — one active channel window at a time,

never simultaneous email-and-DM.

  1. Conditional gates per touchpoint — "fire only if no reply since

T-1" must be spelled out.

  1. Last touchpoint is a breakup — polite exit + explicit opt-out

invite.

Build the touchpoint list honouring those rules.

For each touchpoint:

  • when: relative day (Day 0, Day 3, …) + time window (business hours local

to the target, per user preference in memory)

  • channel
  • action: one of the discrete actions from the channel table
  • content: draft message (if message) or action payload (if social). Drafts

MUST use the learned style prompt for that channel; read the prompt from ~/.openclaw/outclaw/styles/<channel>_style.md.

  • conditional: the gate for whether this fires (e.g., "no reply since T0")

Step 5 — Present & iterate

Present the plan to the user as:

  1. The angle block (hooks quoted from KB, ≥3)
  2. A table of touchpoints (Day / Channel / Action / one-line intent)
  3. For each touchpoint: a preview of the draft / payload
  4. A compliance checklist immediately after the sequence table:
   Compliance checklist:
   - [x] ≥5 touchpoints
   - [x] T0 is a social warm-up (not a message)
   - [x] ≥3 business days between message-class touchpoints
   - [x] Last touchpoint is a breakup
   - [x] Conditional gates on every touchpoint after T0
   - [x] All channels in the plan appear in my active tool list

If any box is NOT checked, fix the plan — don't present it.

  1. Per-touchpoint AskUserQuestion. For each touchpoint, issue a separate

AskUserQuestion with options ["approve", "edit", "cancel this touchpoint"]. Do NOT bundle all 5 into one question. The user should be able to approve T0, edit T1's draft, approve T2, etc. independently.

Iterate on specific touchpoints the user wants changed. Respect any feedback memory entries applied to past drafts (lower-assertiveness CTAs, no em-dashes, etc.).

Step 6 — Schedule

After full plan approval:

python3 "$SHARED/scripts/campaign_state.py" create <slug> ...
# taskflow integration: schedule each touchpoint as a durable task

Use OpenClaw's taskflow skill for durable scheduled execution. Each touchpoint is a taskflow node that fires at its when, re-reads the campaign state, checks the conditional gate, and executes the action.

Write one observation memory entry per touchpoint scheduled, plus a plugin_setup-free campaign record under ~/.openclaw/outclaw/campaigns/active/<slug>.json.

Step 7 — Log

  • LeadClaw note (if connected) per shared/references/leadbay-integration.md

— "Campaign created. Channels: [...]. Sequence: N touchpoints over D days."

  • kb_ingest.py log note "<slug> campaign scheduled"
  • Memory: observation entry summarizing the plan.

Abort conditions

Stop and tell the user if any of these are true before scheduling:

  • kb/me/org.md is a stub or missing — angles will be generic
  • No channel in the plan has a learned style — drafts will not match voice
  • User's preference memory says never send cold without a warm-up, and

the plan starts with a cold message

Response listening + runtime learnings

(Absorbs current Module 4.)

  • Runs continuously in background for active campaigns (when called).
  • Poll all ready channels + listen for:

- Replies (direct messages, email replies, DMs) - Read receipts (WhatsApp, iMessage, LinkedIn "seen", gmail return receipts where present) - Delivery events: bounces, spam-folder placement, opt-outs, unsubscribe clicks

  • Classify replies via agents/response-analyst.md:

POSITIVE / NEUTRAL / NEGATIVE / OOO / IRRELEVANT / OPT_OUT.

On any event, write both:

  1. KB page — append a dated ## Reply YYYY-MM-DD or ## Runtime note YYYY-MM-DD

section to the target's kb/people/<slug>.md using kb_page.py upsert --append-section --append-file. Examples:

- "Email to milstan@leadbay.ai bounced (permanent); retry never." — flag as contact_status: email_invalid on frontmatter + touch capabilities precondition. - "WhatsApp message read at 2026-04-22 09:12 UTC — engaged reader, no reply yet." - "Reply: 'Not a fit right now, try again in May.'" — classification NEUTRAL, schedule a retry_after: 2026-05-01 field on frontmatter. - "Reply: 'Please stop contacting me.'" — classification OPT_OUT.

  1. Per-tenant memory — type=observation entry for patterns

(reply rates, best-time-of-day, channel preferences): {skill:"outclaw-plan", type:"observation", key:"reply_rate_<channel>", insight:"12% reply rate across 40 Gmail sends over Mar-Apr", source:"observed", confidence:7}.

Opt-out hardrail (MANDATORY)

On classification OPT_OUT OR any reply containing phrases like "stop", "unsubscribe", "don't contact me", "take me off your list", "remove me", "GDPR deletion":

  1. Mark the target's KB page frontmatter: contact_status: opt_out +

opt_out_reason: "<verbatim quote>".

  1. Cancel every active and scheduled touchpoint for this target across

ALL tenants (this is the only cross-tenant write — opt-out is a global honor).

  1. Log memory type=feedback, key=opt_out_<slug> (confidence 10,

never decays).

  1. Never propose this target again. The next time any tenant tries to

research or plan outreach for this target, the skill MUST refuse and surface the opt-out reason.

  1. Confirm in chat: "Honored opt-out from <name>. Removed from all

campaigns. Will not re-contact."

No exceptions. No "just one more message to confirm." Opt-out is irreversible unless the user explicitly says "undo opt-out for <name>" (which writes a feedback entry the user can audit).

User-intervention learnings (memory)

When the user EDITS a draft or REJECTS a touchpoint during plan review, classify the delta into one of three categories (gstack-style taxonomy):

  • feedback/style — tone, vocabulary, length, CTA phrasing. Updates the

channel's style prompt via outclaw-style reconfirm (not retrain).

  • feedback/scheduling — cadence, time-of-day, day-of-week preferences.
  • feedback/action-type — "don't propose social follows", "only use email

for senior titles", etc.

Write a memory entry per edit:

bash "$SHARED/scripts/memory_log.sh" '{
  "skill":"outclaw-plan","type":"feedback",
  "key":"<category>_<short-tag>",
  "insight":"<what user did + what to learn>",
  "confidence":10,"source":"user-stated",
  "refs":["campaigns/<tenant>/active/<slug>.json"]
}'

On every subsequent plan, load feedback memory (memory_search.sh --type feedback --limit 50) and honor it. If a new draft would violate a feedback entry, adjust before presenting. If two feedback entries contradict, prefer the most recent (dedup by key at read time, same latest-winner rule as gstack).

Campaign tracking + management

All per-tenant: ~/.openclaw/outclaw/campaigns/<tenant>/{active,archived}/.

Ongoing tracking (mandatory after scheduling)

Every active campaign file is checked on every outclaw-plan invocation and on every cron tick (if the Leadbay rhythm is scheduled):

  • Poll target's connected channels for new replies / read receipts /

bounces via the channels listed in the capability map.

  • On any new event, run §Response listening.
  • Update the campaign file with last_check_ts + event summary.
  • If a scheduled touchpoint's firing time has arrived and its conditional

gate still evaluates true AND the contact_status is not opt_out, dispatch it (subject to pre-approval the user gave at plan time; or re-ask if the gate fires under different conditions than approved).

  • If any reply / status change would materially alter the plan (positive

intent → propose meeting; negative → respectful close; OOO → reschedule; request to retry later → push dates), PAUSE further touchpoints and ask the user to validate the revised plan.

Commands

  • pause: mark PAUSED; cancel scheduled touchpoints; retain file in

active/ so user can resume.

  • resume: reactivate; recompute schedule from "now" + remaining gaps.
  • cancel: mark CANCELLED; cancel scheduled; **move file to

archived/**; log to Leadbay + memory.

  • stop (from target): automatic on OPT_OUT; move to archived/;

honor hardrail.

  • complete (campaign fully delivered with meaningful outcome): move

to archived/ with outcome annotation (meeting-booked / reply-positive-no-meeting / reply-negative / no-response).

  • list/status: read active/ → formatted dashboard with status +

next touchpoint ETA + pending replies.

  • list archived: read archived/ → optional verbose view, searchable

by target, outcome, or date.

Dashboard

Shown on "show my campaigns":

OutClaw — Active campaigns (tenant: outclaw)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Jason Lemkin · SaaStr · Twitter+Email · Active (T3 of 6) · Next: Thu 9:00am
  Angle: AI-moat divergence; recent Apr 19 essay
  Last event: no reply since T2 (Day 3) · gate=send_T3 OK
  KB: kb/people/jason-lemkin.md
Alice Chen · Acme · LinkedIn+Email · Paused (reply received)
  Classification: POSITIVE → revision pending approval
  Proposed: book 15-min intro call this week
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Summary: 2 active, 1 awaiting approval. Last 7 days: 5 sent, 2 replies,
0 demos booked. 1 retry-after-May-2026 queued.

Show archived? (12 completed, 3 opt-out, 4 cancelled, 8 no-response)

Archive access

Archived campaigns remain on disk under campaigns/<tenant>/archived/ and are searchable:

# by target
grep -l 'jason-lemkin' ~/.openclaw/outclaw/campaigns/<tenant>/archived/*
# by outcome
jq 'select(.outcome == "meeting-booked")' ~/.openclaw/outclaw/campaigns/<tenant>/archived/*.json

Never delete archived campaign files — they're the audit trail for opt-outs and Leadbay hygiene.

Dashboard (Module 5)

OutClaw — Active campaigns (3)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Sarah Chen · Acme · LinkedIn + Email · Active (T2 of 5) · Next: Tue 9:15am
  Angle: recent post on data-pipeline rewrite (Apr 10) + mutual Stripe tenure
Bob Smith · Stripe · Email only · Awaiting reply (T1 sent Mon)
  Last action: cold email, no response (1 business day)
Carol Wong · Rippling · LinkedIn only · Paused (reply received)
  Reply classification: POSITIVE. Proposed revision pending approval.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Summary: 3 active, 1 awaiting reply, 1 pending approval.
Last 7 days: 5 sent, 2 replies, 1 demo booked.

Include summary stats: active count, replies pending, completions this week.

Safety & compliance (applies everywhere)

  • Immediate permanent opt-out on "stop" / "unsubscribe" — log feedback

memory; remove from KB contact channels; never re-engage.

  • Max 20 new cold outreaches per day (across all channels, across all

campaigns).

  • Never reveal Leadbay's data source to the prospect.
  • User's feedback memory entries take precedence over default style.

平台分布

OpenClaw

93.56%
按下载量换算925

安全审计

VirusTotal

未展示

ClawScan

可疑

Static analysis

通过

权限和风险

需要联网

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

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills