Use when an integration or product partnership needs pre-engineering scoping: the brief, the ranked roadmap input, readiness, and the handoff.
Instructions your experts follow when using this skill.
Use this when an integration or product partnership needs scoping before engineering picks it up. Start from the partner's product and API documentation, the integration ask, our product contacts, and the roadmap window.
This hands off to engineering. It never implements.
Platform and program selection first — pricing, program features, case studies — then the application programming interfaces (APIs) and the extensibility surface, data flows, authentication, and rate limits, then the open questions for partner engineering.
Each unknown names who can answer it and by when. An unknown with no owner is not scoped.
Ranked partner asks with their evidence: who asked, what deal or adoption is attached, how often it comes up. Then what we will not build, with the reason for each.
Product decides. This brief informs.
Documentation, a sandbox, the support path, joint messaging, and the early-access or beta coordination plan — who is in it, what success looks like, and when it ends.
Pass the certification and technical-validation gate on performance, security, and interoperability before launch. A launch with no support path stays in beta.
The brief, one named owner on each side, and a date. Then track the handoff and the integration success metrics — adoption, attach, retention lift — not the build.
The scoping brief, the ranked roadmap input, the readiness checklist, and the dated handoff.
No API documentation means scoping from public material marked INFERENCE, with the documentation request as step one. No product contact means the introduction ask comes before any roadmap input.
Phrases that help your experts find this skill.
When the user wants to create or update their product marketing context document. Also use when the user mentions 'product context,' 'marketing context,' 'set up context,' 'positioning,' 'who is my target audience,' 'describe my product,' 'ICP,' 'ideal customer profile,' or wants to avoid repeating foundational information across marketing tasks. Use this at the start of any new project before using other marketing skills — it creates `.agents/product-marketing.md` that all other skills reference for product, audience, and positioning context.
When the user wants to research, profile, or analyze competitors from their URLs. Also use when the user mentions 'competitor profile,' 'competitor research,' 'competitor analysis,' 'profile this competitor,' 'analyze competitor,' 'competitive intelligence,' 'competitor deep dive,' 'who are my competitors,' 'competitor landscape,' 'competitor dossier,' 'competitive audit,' or 'research these competitors.' Input is a list of competitor URLs. Output is structured competitor profile markdown files. For creating comparison/alternative pages from profiles, see competitors. For sales-specific battle cards, see sales-enablement.
When the user wants to conduct, analyze, or synthesize customer research. Use when the user mentions "customer research," "ICP research," "talk to customers," "analyze transcripts," "customer interviews," "survey analysis," "support ticket analysis," "voice of customer," "VOC," "build personas," "customer personas," "jobs to be done," "JTBD," "what do customers say," "what are customers struggling with," "Reddit mining," "G2 reviews," "review mining," "digital watering holes," "community research," "forum research," "competitor reviews," "customer sentiment," "PMF survey," "product/market fit survey," "customer interview questions," "interview outreach," "Sales Safari," or "find out why customers churn/convert/buy." Use for analyzing existing research assets, mining online sources, AND running primary research (interviews and surveys). For writing copy informed by research, see copywriting. For acting on research to improve pages, see cro.