Marketing Agent Skills for Founders

Agent skills that help founders explain their company and raise money for it. Positioning, pitch, fundraising, marketing.

Built on the Agent Skills open standard. They run in Claude Code, the Claude apps, the Claude API and Agent SDK, VS Code, Codex CLI, and anything else that reads the format. No dependencies, no build step, no required tools.

The skills

They work together. If your deck fails the ten-second test, the review hands off to the one-liner skill first. Same for the page: when the five-second read fails, the problem is the sentence, not the layout. Each one also does that work inline if the other two are not installed.

More coming.

Install

Full instructions for every environment are in INSTALL.md. The short version, for Claude Code:

git clone https://github.com/lelephi/marketing-agent-skills-for-founders.git /tmp/masf
cp -r /tmp/masf/pitch-deck-review /tmp/masf/pitch-one-liner /tmp/masf/landing-page-review ~/.claude/skills/

For the Claude apps, zip the skill folder and upload it under Customize > Skills > Add. The zip's root must be the skill folder itself.

Repo conventions

Every skill in this repo follows the same shape. New ones should too.

skill-name/
├── SKILL.md          required
├── README.md         required
├── references/       optional
└── scripts/          optional

Naming

The folder name is the skill's name, and name: inside SKILL.md must match it exactly. Beyond the format rules (lowercase, hyphens, max 64 characters, no leading, trailing, or doubled hyphen), three rules:

Name it after the artifact, not the method. A founder searching a skill directory types pitch deck, not teardown. seed-deck-teardown failed this on both halves: seed is ambiguous outside venture, and teardown is insider vocabulary. pitch-deck-review is the same skill with a name people can find. The voice lives in the description and the body, where it costs nothing.

Include the word the user would type. Pitch deck. Landing page. One-liner. If the noun is not in the name, the name is decoration.

No namespace prefixes. Do not write founder-pitch-deck-review. When a skill ships inside a plugin, the plugin name is added as a prefix automatically, and a hand-written prefix breaks loading.

Frontmatter

Exactly three keys, in this order:

---
name: skill-name          # matches the folder name
description: ...          # what it does, then when to trigger it, one paragraph
license: MIT
---

The spec allows compatibility, metadata, and allowed-tools too. This repo skips them. compatibility implies a hard requirement these skills do not have, allowed-tools is experimental and support varies, and every extra key is one more thing an older or stricter loader can choke on. Three keys install everywhere.

Two formatting rules that exist for parser compatibility, not style. The description must be a single-line plain scalar: no wrapping quotes, no block scalar, no line breaks. Some loaders parse the frontmatter with a real YAML parser and some with a regex, and only the plain single-line form survives both. And it must contain no colon followed by a space, which would terminate the scalar and truncate the description silently.

The description does double duty. It tells a human what the skill is, and it is the only thing the model reads when deciding whether to load the skill at all. So it names the artifact (pitch deck, landing page, one sentence), and it lists the phrases a founder would actually type, including the ones that never use the skill's own name. Roast my website should fire the page skill.

Portability

Every SKILL.md opens with an environment check: a short table of what the skill would use each capability for, and what to do instead when it is absent. No skill in this repo hard-requires file reading, web fetch, a browser, or code execution. Each one degrades to an interview and still produces a real deliverable.

Two rules follow from that. A skill must state the mode it worked in at the top of its output, and it must never claim to have assessed something it could not see. A review that silently judges mobile behavior from a screenshot is worse than one that says mobile was not assessed.

Output defaults to markdown in the reply, with a documented file fallback for environments where deliverables are files. Do not assume either one.

references/ holds material the model pulls in only when it needs it. This is the point of splitting: SKILL.md loads into context on every single run, reference files load on demand. Split something out when it is long, when only one section of it applies to any given run, or when it needs its own maintenance cycle. Benchmarks that go stale, playbooks that branch by customer type, and checklists that need periodic updating all belong here.

References must never be load-bearing. If they fail to resolve, and in some environments they will, SKILL.md alone still has to produce a correct result. Depth can live in a reference file. Correctness cannot.

scripts/ holds executables. Standard library only, no install step, and a documented fallback for when the environment blocks network access. Invoke them with python3 scripts/name.py so the executable bit does not matter. A script may save time. It may never change the verdict.

Keep SKILL.md under 500 lines. Validate before pushing:

skills-ref validate ./pitch-deck-review

Data rule. No statistic goes into a skill without a traceable source. Where a skill quotes numbers, it grades them by provenance and names the fabricated ones it refuses to repeat. Quote one fake stat to a founder who checks it, and every true thing the skill said goes with it.

Quoting other people

These skills stand on published thinking from people who have done the work, and they credit it. The rules that keep credit from turning into reproduction:

Quote only when the wording is the point. If a paraphrase carries the idea just as well, paraphrase. Most of the time it does, and the prose is better for it.

Twenty-five words is the ceiling. A quote longer than that is usually doing work the surrounding analysis should be doing. Cut it down and keep the fragment that lands.

Always name the speaker, at the point of use. Not in a credits section at the bottom. The attribution is part of why the line works on a founder.

Never let a quote carry the argument. The quoted line is evidence for a point this project is making. If the quotes were stripped out, every file should still hold its shape.

Never invent a quotation. Do not put words inside quotation marks that the person did not say, including tidied-up or shortened versions. Paraphrase openly instead.

Ideas, methods, and principles are not anyone's property. Specific expression is. The frameworks, scorecards, taxonomies, and rubrics in this repo are original expression of unprotectable ideas, which is exactly what they should be.

Sources, trademark position, and license scope are set out in NOTICE.md.

Who made these

A marketing leader who has built pitch decks, positioning, and go-to-market with startup founders. Each skill encodes what actually moved the outcome, not what sounds good in a framework.

Sources and method are documented in each skill's README. Attribution, trademark position, and license scope are in NOTICE.md. This project is not affiliated with or endorsed by Y Combinator or any other organization named in it.

Contributing

Issues and pull requests welcome. Especially from investors, designers, and operators who disagree with a call one of these skills makes, or founders who acted on a note that turned out to be wrong.

License

MIT.