Browse by job

• 01 Content research 84 lines, MIT

  niche-content-research

  An idea backlog built from what your niche actually asks, with the evidence attached.

  Copy install command Download SKILL.md
  Read the full skill Hide the skill

  The skill, exactly as it installs

  niche-content-research

  Build a content idea backlog from evidence of demand, not from brainstorming.

  When this applies

  Someone needs topics for a niche and the current list came from a meeting. Or the content ships and nobody asked for it. This skill finds the questions people in the niche already ask, in their words, and shows where the existing answers are weak.

  Inputs

  Ask for these before starting. Do not guess them.

  • Niche: one sentence naming who and what (“finance teams at SaaS companies closing the books”).
  • ICP and product: read the marketing brain if one exists (the product-marketing-context skill writes it). Otherwise ask for a paragraph.
  • Competitors: domains or channel names, so their coverage can be compared.
  • Private sources, optional: sales call notes, support tickets, onboarding questions. These are the strongest evidence you can get. Use them if given.

  Where to look

  Work through each source and record every question or complaint verbatim, with its URL and the date you collected it.

  1. Communities. Subreddits, forums, Slack and Discord archives that are public, Stack Exchange sites, Hacker News threads. Look for questions, “how do you”, “what do you use for”, and complaints about existing tools.
  2. YouTube. Search suggestions for the niche’s core terms, and the comments on the top videos. Comments that say “you skipped” or “but what about” are gaps.
  3. Search suggestions. Autocomplete and People Also Ask for the core terms. Record the exact phrasing.
  4. AI answer engines. Ask the niche’s core questions. Note where the answer is thin, generic, hedged, or cites nobody credible. That is a gap you can fill.
  5. Podcasts and newsletters. Episode and issue titles from the niche’s main shows. These show what the audience already pays attention to.
  6. Private sources. Cluster repeated questions from calls and tickets.

  Cluster and score

  Group the raw questions into topics. One idea per cluster, phrased as the question a reader would type. Score each idea 0 to 3 on four axes:

  • Demand: number of independent sources that raised it. Same thread twice counts once.
  • Gap: how weak the current best answers are, with the weakest answer linked.
  • Fit: how close it sits to the ICP’s problem and to what the product does.
  • Format: which format the evidence points to (article, video, short, comparison, tool, template). A question asked on YouTube wants a video.

  What you produce

  A backlog file with one row per idea:

  | Idea (as a question) | Demand | Gap | Fit | Format | Evidence (URL, date) |
  

  Then the top picks, no more than ten, each with a one-line angle: what this piece says that the current answers do not.

  Close with a short section listing the sources you searched and the ones you could not reach, so the reader knows what the backlog is blind to.

  Rules

  • Never score an idea with zero evidence links. An idea without evidence goes in a separate “unsupported” list at the bottom, unscored.
  • Every quote is verbatim and keeps its URL and collection date.
  • Never invent volume. If you have no search volume data, say so. Do not estimate.
  • Public data only. Do not log in to read private groups. Respect each platform’s terms.
  • Do not write the content. This skill finds and ranks ideas. Drafting is a separate job.

  Self-check before you hand it over

  1. Does every scored idea link to at least one source with a date?
  2. Would removing any single source drop an idea’s demand score? If every idea rests on one thread, the research is too narrow; say so.
  3. Is each top pick’s angle something the linked weak answer actually lacks?
  4. Did you list the sources you could not reach?

• 02 Demand signals 77 lines, MIT

  buying-signal-scout

  A dated log of public buying signals, scored, each one with a source you can open.

  Copy install command Download SKILL.md
  Read the full skill Hide the skill

  The skill, exactly as it installs

  buying-signal-scout

  Log evidence that someone is looking for what you sell, with the link that proves it.

  When this applies

  Sales is working cold lists, or marketing is guessing what the market wants. Buying intent is often public: people ask for tools by name, announce they are switching, write angry reviews of a competitor, and post jobs that describe the problem. This skill collects that evidence and ranks it.

  Inputs

  Ask for these. Do not guess them.

  • ICP: from the marketing brain if one exists, otherwise a paragraph.
  • Product category and competitors: names and domains.
  • Problem words: the phrases a buyer uses before they know your name.
  • First-party data, optional: pricing page visits, demo requests, trial signups, exported as a file. Use only what you are given.
  • Window: how far back to look. Default to the last thirty days.

  Signal types, strongest first

  1. First-party: demo requests, repeat pricing page visits, trial activity. Only from data provided.
  2. Direct asks: “what do you use for”, “alternatives to ”, “recommend a tool for” in communities, on X, on LinkedIn.
  3. Switching: “moving off ”, “we just cancelled”, migration questions.
  4. Competitor pain: recent negative reviews on G2, Capterra, app stores, or public support forums that name a problem your product solves.
  5. Job posts: roles that name the problem or list a competitor tool as a requirement.
  6. Company changes: funding, a new leader in the buying function, a public stack change. Weakest, because it implies need rather than stating it.

  Score each signal

  0 to 3 on each:

  • Specificity: does it name the problem or a competitor, or is it vague?
  • Recency: inside the window, and how close to today.
  • Fit: does the person or company match the ICP?
  • Attribution: is a named company or public profile attached? Anonymous posts still count for demand themes but score zero here.

  What you produce

  A signal log, one row per signal:

  | Signal (quoted) | Type | Source URL | Collected | Account | Score | Next action |
  

  Next action is one of: route to sales, reply publicly with help, add to content themes, watch. Pick one per row and say why in a few words.

  Then a demand-theme summary: the recurring asks and complaints grouped into themes, each with its count of signals and two or three links. This feeds the content backlog; the niche-content-research skill can take it as input.

  Rules

  • A signal without a URL is dropped. No exceptions.
  • Public data only. No scraping behind logins, no private groups, no automated access a platform’s terms forbid.
  • Never guess an email address or enrich a contact from a source you cannot cite.
  • Quote, do not paraphrase. The signal column is the person’s own words.
  • Do not contact anyone. This skill logs and ranks. Outreach is a human decision.
  • Do not inflate. One person posting in three places is one signal.

  Self-check before you hand it over

  1. Does every row have a URL and a collection date inside the window?
  2. Are duplicates from the same person merged?
  3. Does every “route to sales” row have a named account attached?
  4. Does each demand theme link to signals that actually say it?

• 03 Video and YouTube 58 lines, MIT

  video-repurposer

  One transcript in: chapters, clip picks, an article, and posts out, every quote verbatim.

  Copy install command Download SKILL.md
  Read the full skill Hide the skill

  The skill, exactly as it installs

  video-repurposer

  Get every useful piece out of one recording without putting words in the speaker’s mouth.

  When this applies

  A long recording exists and nothing else was made from it. The ideas in it are good, but nobody will watch the full hour. This skill cuts it into pieces people will actually see, and keeps each piece traceable to the moment it came from.

  Inputs

  • A transcript with timestamps. If there is only a recording, transcribe it first and keep word-level or sentence-level times.
  • The recording’s URL, so clips and posts can link back.
  • The marketing brain if one exists, for voice and audience.
  • Channels wanted: which of the outputs below to produce.

  What you produce

  1. Chapters. Timestamp and a plain title for each topic shift. Titles say what is covered, not how exciting it is.
  2. Clip picks. Three to six, each with:

  start: 00:14:32   end: 00:15:41
  hook line: "<the first sentence, verbatim>"
  why it stands alone: <one line>
  suggested caption: <one line>
  

  3. Article outline. An answer-ready outline: the question the recording answers, the direct answer in the speaker’s words, then sections built from the chapters. Each section cites the timestamps it draws from.
  4. Social posts. LinkedIn and X drafts, each built around one idea and one verbatim quote with its timestamp, linking to the recording.
  5. Newsletter blurb. A short paragraph: what the recording covers, the one idea worth the reader’s time, and the link.

  Rules

  • Every quote is verbatim from the transcript and carries its timestamp. Clean up filler words only, and never change meaning.
  • Nothing is claimed that the speaker did not say. If a post needs context the recording lacks, flag it rather than adding it.
  • Each clip stands alone. A viewer with no context must understand it. If a clip needs the previous minute to make sense, extend it or drop it.
  • No new numbers. A figure appears only if the speaker said it, and it keeps the timestamp.
  • Do not publish. Output is drafts for a human to approve.

  Self-check before you hand it over

  1. Search the transcript for every quote. Does each one appear, at the stated time?
  2. Watch or read each clip range cold. Does it make sense without the rest?
  3. Does every post link to the recording?
  4. Do chapter timestamps increase and cover the whole recording?

• 04 Video and YouTube 66 lines, MIT

  youtube-video-planner

  Title options, thumbnail concepts, a written hook, and a scene outline from one topic.

  Copy install command Download SKILL.md
  Read the full skill Hide the skill

  The skill, exactly as it installs

  youtube-video-planner

  Turn a topic into a video plan built on what viewers search for and what existing videos leave out.

  When this applies

  Someone has a topic and a camera. The title will be written after filming and the opening will ramble. This skill does the research and the structure first, so the video answers a real question and the packaging promises what the video delivers.

  Inputs

  • Topic and the channel’s audience in one sentence.
  • The marketing brain if one exists, for voice and positioning.
  • Channel constraints: target length, on-camera or voiceover, what the creator can actually show (screen, product, whiteboard).

  Research

  Record everything with its URL and collection date.

  1. Search suggestions. Type the core terms into YouTube search and list the suggestions. These are the phrasings viewers use.
  2. Top videos. For the chosen phrase, list the top-ranking videos: title, length, upload date, and what they cover.
  3. Comment gaps. Read the top comments on those videos. Note what viewers say is missing, wrong, or outdated.
  4. The real question. Write the one question the viewer has when they search. Everything in the plan serves that question.

  What you produce

  1. Three title options. Each names the search phrase it targets. Plain words, a specific outcome, no bait the video cannot pay off.
  2. Thumbnail concepts. Two or three. Each has one focal subject and text under four words that does not repeat the title.
  3. The hook, written out. The first thirty seconds word for word: confirm the viewer is in the right place, state the payoff, and show one proof it is coming.
  4. Scene-by-scene outline. Each scene has a purpose, what is on screen, and a retention beat (an open question, a reveal, a visual change) placed before the point where viewers usually drop.
  5. Description with chapters. First two lines answer the search. Chapters match the outline.
  6. Call to action. One, placed after the payoff, pointing to the next video or resource that continues the viewer’s job.

  Close with a research appendix: suggestions, top videos, and comment gaps with links.

  Rules

  • The title and thumbnail promise is paid off in the first minute. If the outline delays it, restructure.
  • No fabricated statistics. Any claim that needs a number is marked [SOURCE NEEDED] in the script until someone supplies one.
  • Flag every factual claim that the creator must verify before filming.
  • Do not copy another video’s structure scene for scene. Use the gaps, not the template.

  Self-check before you hand it over

  1. Does each title map to a search suggestion you recorded?
  2. Does the hook state the same payoff as the title?
  3. Is every comment gap you found either covered in a scene or explicitly skipped with a reason?
  4. Are all unsourced numbers flagged?

• 05 AI visibility 31 lines, MIT

  aeo-content-optimizer

  Scores a page on whether AI assistants can find, parse, and cite it, then rewrites the weak parts.

  Copy install command Download SKILL.md
  Read the full skill Hide the skill

  The skill, exactly as it installs

  AEO Content Optimizer

  Answer engines cite pages that answer a specific question early, back claims with checkable data, and are structurally easy to lift. This skill scores a page on those terms and rewrites what fails.

  The audit (score each 0 to 5, with evidence)

  1. Answer-first structure. Is the direct answer to the page’s core question in the first 150 words, quotable on its own?
  2. Question coverage. Does the page answer the follow-up questions a model asks next (how, versus what alternative, at what cost)? List the missing ones.
  3. Checkable claims. Count concrete numbers, dates, and named sources. Vague superlatives score zero.
  4. Structure. Headings phrased as questions where natural, short paragraphs, lists for real enumerations, one idea per section.
  5. Schema. Valid JSON-LD matching the content type (Article, HowTo, FAQPage).
  6. Uniqueness. What does this page know that the top-cited alternatives do not? If the answer is nothing, rewriting will not fix it; say so.

  The output

  A report with the six scores, the evidence for each, and the three highest-leverage fixes. Then, on approval, rewrite the weakest sections in the site’s existing voice. Never invent data to score better; an unverifiable claim is worse than a gap.

  The rewrite rules

  • Lead with the answer, then the proof, then the nuance.
  • Every number keeps its source inline.
  • Match the site’s voice file if one exists; do not sand it into generic web copy.

• 06 Context 32 lines, MIT

  product-marketing-context

  One file with your positioning, buyer, voice, and proof, so agent output stops sounding generic.

  Copy install command Download SKILL.md
  Read the full skill Hide the skill

  The skill, exactly as it installs

  Product Marketing Context

  Marketing agents fail for one reason more than any other: they do not know the product. This skill builds the context file that fixes that.

  What you produce

  A single marketing-context.md at the project root, with these sections:

  1. Product in one sentence. What it is, for whom, and the one thing it replaces.
  2. ICP. The buyer, the user, the trigger event that starts a purchase, and the three objections heard most often. Pull from real calls and tickets, not guesses.
  3. Positioning. The alternative the buyer would use instead, the key differentiator, and the proof for it. Every proof point needs a source: a metric, a quote, a case.
  4. Voice. Ten sentences the founder actually wrote or said, verbatim. Then three rules derived from them (sentence length, vocabulary, what they never say).
  5. Competitors. Top three, each with the one claim they make that you can beat and the one you cannot. Be honest; the file is private.
  6. Do-not-say list. Banned phrases, restricted claims, compliance limits.

  How to build it

  • Interview the human, one section at a time. Ask for artifacts (sales calls, docs, reviews) before accepting summaries.
  • Mark every unverified claim with [unverified]. An honest gap beats a confident guess.
  • Keep it under 400 lines. If it cannot be read in five minutes, it will not be read.

  How agents use it

  Reference the file at the top of every marketing task prompt. If a draft contradicts the context file, the context file wins; if the context file is wrong, update it in the same change.

• 07 Loop craft 84 lines, MIT

  loop-author

  Drafts a loop file: goal prompt, verifier prompt, stopping condition, and what it may touch.

  Copy install command Download SKILL.md
  Read the full skill Hide the skill

  The skill, exactly as it installs

  loop-author

  Turn a marketing request into a loop file an agent can finish without supervision.

  When this applies

  Someone has described a recurring job (“keep our pages answer-ready”, “turn releases into posts”) and wants it to run without being watched. Or an existing prompt produces output that nobody can check, so it gets rewritten by hand every time.

  What you produce

  One markdown file with four parts, in this order.

  1. The goal prompt

  Instructions for the maker agent. It must:

  • Name every input by path or identifier. Never let the agent guess where truth lives. If it needs positioning, name the file. If it needs a page list, name it.
  • State what may not change. Existing numbers, unlisted claims, files outside scope. A loop without prohibitions rewrites things nobody asked it to touch.
  • Name the output form. A diff, a report file, a set of drafts. Never “improvements”, because a vibe cannot be reviewed.

  2. The verifier prompt

  Instructions for a second agent in a fresh session that did not do the work. Write it as a list of failure conditions, not a request to check quality:

  FAIL if <specific mechanical condition>.
  FAIL if <another>.
  Otherwise PASS. Print the verdict and, on FAIL, the evidence.
  

  Check facts, counts, and boundaries. Never check taste: a model asked whether writing is good will approve, and the PASS will mean nothing.

  3. The stopping condition

  One sentence naming a state someone uninvolved can confirm. Use one of four shapes:

  • A count: “all pages in the list have a before and after score”
  • A comparison: “no page has a verification date older than the threshold”
  • An exhaustion: “every question belongs to exactly one cluster”
  • A verdict: “the verifier printed PASS”, never used alone

  If you cannot write one, the request is still too broad or it needs judgment that should not be delegated. Say which, rather than inventing a condition.

  4. What it may touch

  Two lists: may, and may not. This is what makes a loop safe to run unattended.

  The checks before you hand it over

  Run these yourself. Do not skip them.

  1. Can you describe an output the stopping condition would reject? If not, it does not discriminate and the loop will always report success.
  2. Can you describe an output the verifier would fail? If not, the verifier is decoration.
  3. Does the goal prompt name every file it reads? Any unnamed input becomes an invented one.
  4. Is there a prohibition list? Without one, expect scope creep on the first run.

  Failure modes to avoid

  • A stopping condition that is an outcome. “Traffic increases” is outside the loop’s control and on a timescale it does not run on. Outcomes belong in receipts.
  • A verifier that grades quality. It will always pass.
  • A goal prompt that describes the result rather than the work. The agent needs instructions, not a wish.
  • No output artifact. If the loop does not produce a diff, a file, or a report, there is nothing to review and nothing to verify.

  Reference

  Working examples of this format, each with a real receipt from a run: https://vibemarketers.ai/loops

  Download any of them as raw markdown to see the shape: https://vibemarketers.ai/loops/answer-ready-page.md

• 08 Loop craft 42 lines, MIT

  loop-engineering

  Turns a task you keep re-prompting into a goal, a maker, a checker, and a state file.

  Copy install command Download SKILL.md
  Read the full skill Hide the skill

  The skill, exactly as it installs

  Loop Engineering

  The unit of work is no longer the prompt. It is the loop: a system that finds the work, does it, checks itself, records state, and decides the next move.

  The model in four words

  • Goal: a verifiable stopping condition. “All tests in tests/auth pass” is a goal. “Refactor the auth module” is not; nothing can check it.
  • Loop: the system that runs the goal on a heartbeat instead of you prompting turn by turn.
  • Task: a discrete unit the loop hands to a sub-agent, usually in an isolated git worktree so parallel agents do not collide.
  • Completion: the verified stop. Maker and checker are different agents; models grade their own homework too generously, so self-verification never counts as done.

  The fast path

  • Run until done: /goal all tests in tests/auth pass and lint exits clean
  • Cap the cost: /goal --tokens 250K ...
  • On a schedule: /loop 5m check error logs and open an issue for new stack traces
  • Both: /loop every morning at 9am: triage CI failures, then /goal each suite is green

  The build recipe (unattended loops)

  1. Pin the goal as something a script or evaluator checks from real command output.
  2. Pick the cadence: /goal once, /loop while the session lives, cron or scheduled tasks for anything that must survive a restart.
  3. Isolate parallel sub-agents in git worktrees.
  4. Create a maker agent that implements one task and never self-approves.
  5. Create a checker agent with different instructions and a cheaper model. It re-runs the real checks itself and returns PASS or FAIL with evidence.
  6. Keep a state file (LOOP_STATE.md) in the repo: open, in progress, done, blocked. The model forgets between runs; the repo does not.
  7. Set a token ceiling, a turn bound, and a fallback for unresolved items.
  8. Watch cycle one. Never walk away on the first run.

  Guardrails

  Verification stays your job. Read what the loop produced; an unattended loop is an unattended mistake-maker, and the gap between what exists and what you understand grows exactly as fast as the loop ships.

• 09 Loop craft 82 lines, MIT

  verifier-author

  Writes a checker that can actually fail, and proves it on a broken example.

  Copy install command Download SKILL.md
  Read the full skill Hide the skill

  The skill, exactly as it installs

  verifier-author

  Write the second agent: the one that grades the first and can fail it.

  Why this is separate

  A model that produced work is the worst judge of that work. It will report the claims are sourced and the job is done, because that is what it was trying to produce. The verifier exists to break that loop, and it only works if it can return FAIL.

  A checker that has never failed has not been tested, and an untested checker is worse than none: it manufactures confidence.

  Rules

  Run in a fresh session

  Never ask the session that did the work to check the work. It sees its own reasoning and grades the intent rather than the output. Give a new session the spec and the artifacts, and nothing about how they came to be.

  Check facts, counts, and boundaries

  • Facts. Does every number appear in the source it names? Does every link resolve? Did a value change that should not have?
  • Counts. Is every input item present in the output? Are there as many sections as required?
  • Boundaries. Did the work touch anything outside its brief? Did a drafts-only process acquire a send path?

  Never check taste

  If a check requires an opinion, it does not belong here. Clarity, persuasiveness and quality are for the human gate. A model asked to judge them will approve.

  Write failure conditions, not success criteria

  FAIL if any number in the diff does not appear in <source> with a citation.
  FAIL if any existing value changed.
  FAIL if any item in <input-list> is missing from the output.
  FAIL if the diff touches a file outside <scope>.
  Otherwise PASS. Print the verdict and, on FAIL, the condition and the evidence.
  

  Listing failures forces specificity, and makes the output actionable: the reader learns which check failed and why.

  Print evidence, not just a verdict

  Bad: FAIL

  Good: FAIL: claims check. The diff asserts "38 percent faster" and the claims file has no entry for it. Line 41.

  The test that makes it real

  Do this once, when you write the checker. It takes five minutes.

  1. Break the work deliberately. Take a good output and introduce exactly the failure this verifier should catch: change a value, delete a required section, add an unsourced claim.
  2. Run the verifier. It must FAIL and it must name what you broke.
  3. If it passes, the verifier is broken. Fix it and repeat.

  Keep the broken version. When the loop changes later, re-confirm the checker still catches it.

  What a verifier cannot do

  It cannot tell you the work was worth doing, and it cannot catch a well-sourced, plausible, entirely wrong argument. Those reach the human gate, which is the correct division of labour: mechanical errors are eliminated so judgment is spent where only judgment works.

  Reference

  Every loop here ships a verifier prompt you can read: https://vibemarketers.ai/loops

  A worked walkthrough, including a checker that failed its first test: https://vibemarketers.ai/guides/how-to-write-a-verifier

Want the agent to run a whole job on a schedule, not just know how? Loops and templates are full jobs with a checker built in. Writing your own? The guides work through one end to end.