Shane O'Connor

Interview the user once and write a docs/gtm-cofounder/founder-brief.md that every other skill reads first, so the advice is about their real business, not a textbook. Use this before anything else, or whenever the agent lacks context on the user's product, ICP, market, or stage, or is giving generic GTM advice.

After the founder brief, turn it into an honest diagnosis and a prioritized, stage-aware GTM roadmap saved as docs/gtm-cofounder/gtm-roadmap.md. This is the hub the user returns to every session to see where they are and the single next move. Use right after start-here, whenever the user doesn't know what to work on next, wants a plan instead of a one-off task, or is drowning in disconnected tactics.

Define a real ICP and the developer personas in the sale. Use when the user says the product is "for developers," can't name who would say no, or is marketing to whoever holds the budget instead of who actually adopts.

Run developer customer discovery via a Technical Advisory Board (TAB). Use when the user has never interviewed a user who isn't a friend, is inventing messaging from a conference room, or is guessing at the roadmap instead of hearing the pain firsthand.

Build a positioning and narrative where the developer is the hero and a real trend is the villain. Use when the messaging describes the product instead of the problem, sounds like every competitor, or has no urgency because nothing is at stake.

Position an AI product when everyone claims AI and skeptics call it "just a wrapper." Find the real wedge (data, workflow, trust, domain), make reliability the differentiator, answer "won't the big labs just build this," and stop leading with "AI-powered." Use when your AI or dev tool blends into a sea of similar demos, buyers doubt the accuracy, or you can't say why you win when the model is a commodity.

Write a developer value proposition that is specific, provable, and free of puffery. Use when the messaging leans on "powerful," "better," "seamless," or "best-in-class," when claims have no proof, or when the same line is supposed to reach both the developer and the buyer.

Structure a dev-tool homepage that converts developers into champions. Use when the landing page is written for the buyer instead of the developer, reads as salesy, buries what the product does, or makes it hard to start. Pairs with the ShipReady homepage audit.

Turn a curious developer into an activated one: the docs, the quickstart, and the first-run experience that gets them to their first real win fast, and back again. Use when people sign up or star the repo but never get it working, come once and never return, or you're about to pour traffic into a first-run that leaks.

Get the first 50 real users through channels the user's ICP already uses. Use when the product shipped and nobody came, the user is "posting more" with no result, or is reaching for paid ads before product-market fit.

Plan a developer launch (Show HN, Reddit, Product Hunt) that earns goodwill instead of a flaming. Use when the user is sitting on a launch out of fear, wants to "go viral," or is about to post a press-release-style announcement to a developer community.

Turn developer love into revenue by enabling champions and choosing a GTM model. Use when developers adopt the free tier but nobody pays, when the user is cold-selling the VP instead of arming the developer, or when picking between open-source, PLG, inbound, and sales-led.

Help the user decide what to charge and how to package it: the value metric, the tiers, the free-to-paid line, and finding the actual number. Use when the user is guessing at a price, priced too cheap and can't change it, is stuck on free vs paid, or believes "developers won't pay" so never charges.

Coach the user through actually selling: finding the champion and the buyer, running the first sales conversations, demoing their use case, handling "let me think about it," and closing the first paying customers yourself. Use when developers love it but nobody pays, you've never sold anything and freeze on the conversation, or deals keep stalling on "we'll think about it."

Build authority by teaching the problem space, not announcing features. Use when the user finds "marketing" distasteful and does none, publishes only product updates, or wants a sustainable content and GitHub-README strategy that developers actually respect.

Measure GTM with the metrics that matter (net developer retention, DREAM funnel) instead of vanity numbers. Use when the user has dashboards full of stars and pageviews but can't tell if go-to-market is working, or is optimizing acquisition over a leaky bucket.

Refresh the user's competitive and market context. Re-scan named rivals and the category for what changed since the brief was written (rebrands, repositioning, new entrants, pricing shifts, renamed categories) and update docs/gtm-cofounder/founder-brief.md and the roadmap with anything that moves positioning. Use on a cadence, or whenever a competitor rebrands, a new tool appears, or the user senses the market has shifted under them.

Before showing the user any substantive GTM deliverable (positioning, value prop, homepage, launch post, pricing, sales script, the brief or roadmap), stress-test it against the standard as an independent critic, because the agent that wrote it is the worst judge of whether it is good. Use as a gate right before presenting work, or when the user asks whether something is actually strong.