Pi Intercom
nicobailon/pi-intercom
Streamline session-to-session coordination with pi-intercom.
Agent skill
by growthenginenowoslawski in growthenginenowoslawski/coldoutboundskills
Turns one customer case study into the tightest list of companies that would read that case study and see themselves.
$ npx skills add growthenginenowoslawski/coldoutboundskills --skill playbook-lookalikes -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install growthenginenowoslawski/coldoutboundskills playbook-lookalikes --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/growthenginenowoslawski/coldoutboundskills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/playbooks/playbook-lookalikes .claude/skills/playbook-lookalikes && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "playbook-lookalikes" agent skill from https://github.com/growthenginenowoslawski/coldoutboundskills/tree/main/skills/playbooks/playbook-lookalikes into .claude/skills/playbook-lookalikes/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "playbook-lookalikes", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/growthenginenowoslawski/coldoutboundskills/tree/main/skills/playbooks/playbook-lookalikesType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add growthenginenowoslawski/coldoutboundskills --skill playbook-lookalikes -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install growthenginenowoslawski/coldoutboundskills playbook-lookalikes --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/growthenginenowoslawski/coldoutboundskills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/playbooks/playbook-lookalikes .agents/skills/playbook-lookalikes && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "playbook-lookalikes" agent skill from https://github.com/growthenginenowoslawski/coldoutboundskills/tree/main/skills/playbooks/playbook-lookalikes into .agents/skills/playbook-lookalikes/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "playbook-lookalikes", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add growthenginenowoslawski/coldoutboundskills --skill playbook-lookalikes -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install growthenginenowoslawski/coldoutboundskills playbook-lookalikes --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/growthenginenowoslawski/coldoutboundskills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/playbooks/playbook-lookalikes .cursor/skills/playbook-lookalikes && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "playbook-lookalikes" agent skill from https://github.com/growthenginenowoslawski/coldoutboundskills/tree/main/skills/playbooks/playbook-lookalikes into .cursor/skills/playbook-lookalikes/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "playbook-lookalikes", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/growthenginenowoslawski/coldoutboundskills.git --path skills/playbooks/playbook-lookalikes--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add growthenginenowoslawski/coldoutboundskills --skill playbook-lookalikes -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install growthenginenowoslawski/coldoutboundskills playbook-lookalikes --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/growthenginenowoslawski/coldoutboundskills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/playbooks/playbook-lookalikes .gemini/skills/playbook-lookalikes && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "playbook-lookalikes" agent skill from https://github.com/growthenginenowoslawski/coldoutboundskills/tree/main/skills/playbooks/playbook-lookalikes into .gemini/skills/playbook-lookalikes/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "playbook-lookalikes", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install growthenginenowoslawski/coldoutboundskills playbook-lookalikesInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add growthenginenowoslawski/coldoutboundskills --skill playbook-lookalikes -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/growthenginenowoslawski/coldoutboundskills.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/playbooks/playbook-lookalikes .github/skills/playbook-lookalikes && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "playbook-lookalikes" agent skill from https://github.com/growthenginenowoslawski/coldoutboundskills/tree/main/skills/playbooks/playbook-lookalikes into .github/skills/playbook-lookalikes/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "playbook-lookalikes", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add growthenginenowoslawski/coldoutboundskills --skill playbook-lookalikes -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install growthenginenowoslawski/coldoutboundskills playbook-lookalikes --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/growthenginenowoslawski/coldoutboundskills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/playbooks/playbook-lookalikes .opencode/skills/playbook-lookalikes && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "playbook-lookalikes" agent skill from https://github.com/growthenginenowoslawski/coldoutboundskills/tree/main/skills/playbooks/playbook-lookalikes into .opencode/skills/playbook-lookalikes/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "playbook-lookalikes", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
playbook-lookalikesTurns one customer case study into the tightest list of companies that would read that case study and see themselves.
Playbook Lookalikes is an agent skill from growthenginenowoslawski/coldoutboundskills. Turns one customer case study into the tightest list of companies that would read that case study and see themselves. Decomposes WHY the case-study company resonates into concrete attributes, translates those attributes into database filters, intersects them with a lookalike anchor, then widens with a model judge. Triggers on "find more companies like our best customer", "who would our case study land with", "lookalikes of X", "build a list around this case study", "companies like our happiest client", "expand…
Its SKILL.md is about 4.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files (for example `clay-table.md` and `clay-workflow.md`).
It works with Intercom. The repository describes itself as: Open-source Claude Code skills for cold email and outbound sales. Grade campaigns, export Prospeo searches, scrape Google Maps — all from Claude Code. The licence is MIT.
7 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 25c5d85. It shows what the files ask for, not the result of running them.
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
No scripts in the folder and no shell commands in SKILL.md.
From the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Playbook Lookalikes loads about 4.1k tokens when it runs. Until then it costs about 160 tokens; SKILL.md has 1,583 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
The full file from growthenginenowoslawski/coldoutboundskills at commit 25c5d85, republished under its MIT licence (© growthenginenowoslawski). 1,583 words, ~4,102 tokens.
.claude/skills/playbook-lookalikes/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.All rules here are best practice, not law. Override any of them when the campaign calls for it; note the best practice once and move on.
Use when: a client has a case study, a flagship logo, or one obviously happy customer, and you want the list of companies for whom that story is the strongest thing you could say.
Do not use when: you are building a whole market from an ICP sentence with no standout customer
to anchor on; or you want to name a customer off the prospect's own case-study page ("saw your
work with Intercom") — that is the opposite direction and belongs to playbook-case-study-page.
See also disco-like in this repo for plain seed-domain lookalike discovery. This playbook is the
higher-precision version: it mines why the story resonates before it searches.
One-line output: case_study_ref = "attentive" with
lookalike_case_study_line = "a marketing platform about your size".
playbook-case-study-page pushes a lead-level field literally named case_study_line, whose value
completes a different sentence (Saw your work with Intercom.). This playbook's descriptor is
therefore named lookalike_case_study_line. Never rename it back. If both playbooks run on
the same campaign, a shared field name silently overwrites and renders
"We did this for your work with Intercom."
A case study only works on someone who recognises themselves in it. "We took an SMS marketing platform from 3 meetings a month to 22" lands hard on another marketing software company with a similar go-to-market, and lands on nobody else. So build the list backwards from the story, not forwards from the client's broadest ICP.
The naive move is to paste the case-study company into a lookalike engine and ship what comes back. That was measured at 40% usable: the vector matched on "is about marketing" and returned agencies, a marketing trade publication, and a Power BI blog alongside real software vendors.
What this playbook does instead: write down the 2 to 5 attributes that are the real reason the story resonates — in the worked example: B2B software vendor, product is marketing technology, US, 50 to 2,000 people — express each as a database filter, intersect those filters with the lookalike anchor, and read the result.
That intersection measured 100% usable. It is also small, which is the point: the intersection is how you learn the filters and train the judge. It is not the final list.
| Field | Type | Required? |
|---|---|---|
case_study_domain | string, bare, lowercase | yes |
case_study_text | 200 to 2,000 words | yes — this is what the decomposer reads |
client_offer_summary | 3 to 6 lines | yes |
geography, headcount_band | strings | yes, always legal pre-filters |
domain, company_description | strings | yes, for the labelling half |
exclusion_list | CSV of domains | no, but always ask |
| Field | Type | Example | Null? |
|---|---|---|---|
case_study_ref | slug | attentive | no inside the segment |
lookalike_case_study_line | generic descriptor, ≤70 chars | a marketing platform about your size | yes |
case_study_match_reason | ≤140 chars, QA only, never sent | sells customer engagement software to consumer brands | yes |
attribute_card | JSON, one per case study, not per row | see §6 | no |
Abstain value: "". The gate is qualified: false paired with an empty case_study_ref — the
two always agree.
lookalike_case_study_line is deliberately a generic descriptor, not the case-study company's
brand name. Naming a third party's brand in cold copy is a client-facing decision, and the
descriptor form costs almost nothing: "we did this for a marketing platform about your size"
carries the same recognition as the brand name, and it never creates a permissions problem.
Flip it to brand-naming only when the client explicitly okays it for a publicly published case study.
10/10 usable (100%) on the intersection path.
⚠️ Read that number correctly. Coverage is near-total by construction, because the segment is defined by the filters, so every row in it matches the case study.
The metric that actually varies is segment size. The tested intersection returned 21 companies. The number to watch in production is not hit rate — it is whether the widening steps get you to campaign volume without precision falling back to the 70% that unanchored keyword filtering produced.
Steps 1 and 2 fingerprint the case study. Step 3 is the precision core. Steps 4 and 5 are where volume comes from.
| # | Source | Cost | What it does | Stop rule |
|---|---|---|---|---|
| 1 | An internal company database, the case-study company's own record | FREE | read its description and offerings | always run. found: 0 just means the decomposer works from the case-study text alone |
| 2 | A company-search API on the case-study domain itself | FREE | this is how the database tags it, which is the taxonomy your filters must speak | always run, then run the industry-enum bake-off below. The returned industry is a candidate, never automatically the filter |
| 3 | The lookalike anchor intersected with the mined attribute card. THE RECOMMENDED CALL | FREE | company_lookalike + company_industry + company_keywords + headcount + location | 10/10 usable, 21 companies. Advance whenever the count is below campaign volume, which is almost always |
| 4 | The same attribute card with the lookalike anchor removed, then every row through the model judge | CHEAP | paginate to completion, judge each row | 7/10 raw, ~95% after the gate. Always run when step 3 is short. Never skip the judge — the raw 70% is what makes unanchored filters dangerous |
| 5 | Snowball: re-run the step 3 call once per confirmed member as a new seed, union, repeat | FREE | adds 30 to 100% on top of step 4 | stop when net-new drops below 2 to 3% per round |
| 6 | An entity-search API | METERED | last resort | only if 3 to 5 are still short, or the category is genuinely absent. ⚠️ These pad to the match limit with junk, so never trust one without the judge, and they often return profile URLs rather than domains |
A database's industry tag on the case-study company is frequently NOT the enum you want to filter on.
Measured: one marketing-software vendor is tagged Advertising Services — but the winning 10/10
call filters on Software Development. Advertising Services is the bucket the agencies live
in, and it is exactly the bucket that produced the 40% failure this playbook exists to avoid.
So the database's own tag is a candidate, never the answer. The procedure is free, because a page-1 total count costs nothing:
Write the chosen enum, and the ones you rejected and why, into the run notes. That one sentence is what stops the next operator repeating the bake-off.
VERDICT: PASS 10/10 on the intersection path. The unanchored arm measured 40% usable, and keyword-only filtering without the judge measured 70%.
⚠️ Cost is an estimate, not a measurement: the live test made 3 database calls and zero model calls. Comparable prompts in sibling playbooks measured $0.05 to $0.27 per 1k. Treat any figure under that as a floor and measure on a 50-row batch before quoting it.
clay-table.md — the labelling half as columns.clay-workflow.md — the CLI-buildable version.Two prompts. Prompt A runs once per case study. Prompt B runs per row.
This prompt is input-heavy, so pick the model with the cheapest input rate at standard pricing.
Params: max_completion_tokens=300, never temperature, flex tier for batch.
STATIC PREFIX (byte-identical across calls, keep first)
You are a B2B list-building analyst. You will be given one customer case study, a profile
of the company the case study is about, and a summary of what the seller offers. Your job
is to explain why this story would resonate with a company, in attributes that a company
database can filter on.
Return JSON only:
{"resonance_reasons": ["..."], "industry_enum_candidates": ["..."], "keywords_include": ["..."],
"keywords_exclude": ["..."], "headcount_min": 0, "headcount_max": 0, "geography": "...",
"descriptor": "...", "confidence": "high|low"}
Rules:
- resonance_reasons: 2 to 5 short reasons, each one testable against a company description.
"sells software to marketers" is testable. "is innovative" is not. Drop untestable ones.
- industry_enum_candidates: 2 to 4 CANDIDATE enum strings, ranked best first, for a human to
bake off against total_count. Include the exact industry string the database assigns to the
case-study company, but do NOT assume it is correct: databases often tag a software vendor
by who it sells to. Rank first the enum that names what the company IS, then the database's
own tag, then at most 2 adjacent ones.
- keywords_include: 3 to 6 phrases that name what the product IS. Prefer 2 and 3 word
phrases. Never include a word so common in the category that every company carries it.
- keywords_exclude: words that pull in agencies, publishers, marketplaces, and staffing
firms in the same topic space.
- descriptor: how to describe the case-study company in cold copy WITHOUT naming its brand,
4 to 10 words, lowercase, no trailing period. It must read correctly inside this
sentence: "We did this for DESCRIPTOR."
- Never invent a fact. If the case study does not say it, it is not a reason.
- No em dashes.
Examples:
Input: case study about an SMS and email marketing platform selling to consumer brands,
1,500 people, US; seller runs cold email campaigns for B2B software companies.
Output: {"resonance_reasons":["sells marketing technology as a product, not as a service","sells to marketing leaders at consumer brands","US company big enough to have a dedicated demand generation team"],"industry_enum_candidates":["Software Development","Advertising Services","Marketing Services"],"keywords_include":["marketing platform","marketing automation","customer engagement platform"],"keywords_exclude":["agency","staffing","conference"],"headcount_min":50,"headcount_max":2000,"geography":"United States","descriptor":"a marketing platform about your size","confidence":"high"}
PER-CASE-STUDY DATA (appended last)
Case study text: <case study text>
Case study company profile: <profile>
Seller offer summary: <offer summary>STATIC PREFIX (byte-identical across calls, keep first)
You are grading whether one company would recognise itself in a specific customer story.
You will be given the attribute card that defines the story's audience, and one company's
name and description.
Return JSON only:
{"qualified": true|false, "case_study_ref": "...", "case_study_match_reason": "...", "confidence": "high|low"}
Rules:
- qualified is the gate. Set qualified true and return the case_study_ref given in the
attribute card ONLY if the company satisfies EVERY resonance reason in the card.
Otherwise set qualified false and return "" for case_study_ref. These two always agree:
qualified false always pairs with an empty case_study_ref, never with a non-empty one.
- A company in the right industry with the wrong product does not match. A services firm,
agency, publisher, marketplace, or community does not match a software product story.
- case_study_match_reason: under 140 characters, quote the part of the description that
decided it. Always populate it, on qualified false rows too.
This is internal QA text, never sent to anyone.
- Never invent a fact about the company. Judge only what the description says. A thin or
empty description means qualified false, case_study_ref "", and confidence "low".
- No em dashes.
Examples:
Input card reasons: ["sells marketing technology as a product","sells to marketing leaders"]. Company: Customer.io, "Create personalized customer journeys that engage and convert with our versatile customer engagement platform."
Output: {"qualified":true,"case_study_ref":"attentive","case_study_match_reason":"customer engagement platform sold as a product to marketing teams","confidence":"high"}
Input card reasons: ["sells marketing technology as a product","sells to marketing leaders"]. Company: Fivetran, "Fivetran, the global leader in data movement, helps customers use their data to power everything from AI applications to analytics."
Output: {"qualified":false,"case_study_ref":"","case_study_match_reason":"data movement infrastructure, not marketing technology","confidence":"high"}
PER-ROW DATA (appended last)
Attribute card: <attribute card>
Company: <company name>
Domain: <domain>
Description: <company description>Not needed for fact hallucination — prompt B only judges text it was handed and returns the reason it used.
What is needed is a liveness pass, because company databases happily describe companies that no longer trade. Fetch each live homepage, classify dead / parked / live, and re-judge live sites on their current content.
Always run it. Database descriptions qualify dead companies otherwise.
| Symptom | Cause | Fix |
|---|---|---|
| The list is full of agencies, publishers and blogs | You pasted the case-study company into a lookalike engine and shipped the output. Measured 40% usable | Mine the attributes first and intersect with the anchor |
| The right industry filter returns the wrong kind of company | The database tags a software vendor by who it sells to | The industry-enum bake-off. The database's own tag is a candidate, never the answer |
| The segment is tiny | Expected. The tested intersection returned 21 companies | Widen by dropping the lookalike anchor and judging every row — never by loosening the attributes |
| Precision collapses when you widen | Unanchored keyword filtering measured 70% raw | Never skip the judge. ~95% after the gate |
| An entity-search API returns exactly the number you asked for | These pad to the match limit with junk | Never trust one without the judge |
| Dead companies qualify | Database descriptions outlive the business | The liveness pass |
| Copy renders "We did this for your work with Intercom" | Two playbooks pushed a field with the same name | Keep lookalike_case_study_line distinct from case_study_line |
| The judge qualifies a thin row | An empty description is not evidence | The prompt sets qualified: false, confidence: "low" on thin descriptions. Keep that rule |
© growthenginenowoslawski, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
SKILL.md and 2 other files in skills/playbooks/playbook-lookalikes of growthenginenowoslawski/coldoutboundskills.
Open the folder on GitHubat commit 25c5d85
Playbook Lookalikes next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Playbook Lookalikes this skillgrowthenginenowoslawski/coldoutboundskills | 753 | — | ~4.1k | Automated safety check: Pass | MIT | |
| Pi Intercomnicobailon/pi-intercom | 533 | — | ~4.3k | Automated safety check: Pass | MIT | |
| Intercombastani-inc/atomic | 856 | — | ~6.9k | Automated safety check: Pass | Custom licence | |
| Intercom Automationdavepoon/buildwithclaude | 3.6k | 7 repos | ~2.5k | Automated safety check: Pass | MIT | |
| Subagentbastani-inc/atomic | 856 | — | ~11k | Automated safety check: Pass | Custom licence | |
| Adding Inbox SourcesPostHog/posthog | 40k | — | ~5.3k | Automated safety check: Pass | Custom licence |
nicobailon/pi-intercom
Streamline session-to-session coordination with pi-intercom.
bastani-inc/atomic
Streamline session-to-session coordination with the intercom extension.
davepoon/buildwithclaude
Automate Intercom tasks via Rube MCP (Composio): conversations, contacts, companies, segments, admins.
bastani-inc/atomic
Delegate work to builtin or custom subagents with single-agent, parallel, forked-context, and intercom-coordinated runs.
PostHog/posthog
Add a new warehouse-backed source to the PostHog Desktop Self-driving Inbox (the feature that ships GitHub, Linear, Zendesk, pganalyze, Jira).
composio-community/awesome-codex-skills
Triage customer support tickets/emails/chats into categories, priority, and next action; draft responses and create reproducible steps; use for Zendesk/Intercom/Help Scout exports or pasted threads.
growthenginenowoslawski/coldoutboundskills
Diagnostic audit for a running cold email program. An agent skill from growthenginenowoslawski/coldoutboundskills.
growthenginenowoslawski/coldoutboundskills
Conversational intake for cold email campaigns. An agent skill from growthenginenowoslawski/coldoutboundskills.
growthenginenowoslawski/coldoutboundskills
META skill — build the largest possible qualified lead list for any request, end to end.
growthenginenowoslawski/coldoutboundskills
Autonomous cold email campaign launcher. An agent skill from growthenginenowoslawski/coldoutboundskills.
growthenginenowoslawski/coldoutboundskills
Use the Blitz API to find decision-makers at specific companies when you already have a list of company domains.
growthenginenowoslawski/coldoutboundskills
Compare reply rates, bounce rates, and positive reply rates broken down by inbox type (SMTP / Gmail / Outlook) for a Smartlead account.
Works with
Turns one customer case study into the tightest list of companies that would read that case study and see themselves. Playbook Lookalikes is an agent skill from growthenginenowoslawski/coldoutboundskills. Turns one customer case study into the tightest list of companies that would read that case study and see themselves.
Playbook Lookalikes fits situations like: find more companies like our best customer; who would our case study land with; lookalikes of X; build a list around this case study.
Run `npx skills add growthenginenowoslawski/coldoutboundskills --skill playbook-lookalikes -a claude-code`. Or copy the skill folder (skills/playbooks/playbook-lookalikes in growthenginenowoslawski/coldoutboundskills) into .claude/skills/playbook-lookalikes in your project. Claude Code loads it when a task matches its description.
Run `npx skills add growthenginenowoslawski/coldoutboundskills --skill playbook-lookalikes -a codex`. Or copy the skill folder (skills/playbooks/playbook-lookalikes in growthenginenowoslawski/coldoutboundskills) into .agents/skills/playbook-lookalikes in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add growthenginenowoslawski/coldoutboundskills --skill playbook-lookalikes -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/playbook-lookalikes, .gemini/skills/playbook-lookalikes, .github/skills/playbook-lookalikes and .opencode/skills/playbook-lookalikes in your project.
SKILL.md names no scripts, command-line tools or credentials: Playbook Lookalikes is instructions for the agent only.
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
Playbook Lookalikes is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 4.1k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
Skills that share tags, products or a category with Playbook Lookalikes: Pi Intercom (nicobailon/pi-intercom, 533 stars), Intercom (bastani-inc/atomic, 856 stars), Intercom Automation (davepoon/buildwithclaude, 3.6k stars) and Subagent (bastani-inc/atomic, 856 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
growthenginenowoslawski (a GitHub user) maintains it in growthenginenowoslawski/coldoutboundskills, which has 753 GitHub stars. The repository holds 49 skills in this directory. The repository was last updated on October 5, 2026.
Source: growthenginenowoslawski/coldoutboundskills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.