Prompts to Run on Your Website Markdown

Using only the attached Markdown of [Competitor A], [Competitor B] and [Competitor C], build a positioning matrix with one row per competitor and these columns: target segment and ICP, core value proposition, key differentiators, proof points (named customers, case studies, certifications), and primary call to action. Cite the page URL for every cell and write 'not stated' where the pages are silent. Close with three messaging angles we could use against each.

Extract each competitor's pricing model from the attached pages: plans and tiers, price points and billing periods, the pricing metric (seat, usage, or feature), included limits, add-ons, free trial or freemium terms, and which features are gated behind contact sales. Present a side-by-side table, cite the source URL for each figure, and list the pricing questions the pages leave unanswered.

Below is our feature list. For each feature, check the attached competitor documentation and mark it Present, Partial, or Not found for each competitor, quoting the supporting passage and URL. Then summarize where we lead, where we trail, and which gaps appear most often in competitor messaging. Treat 'Not found' as 'not documented', not as 'does not exist'. [paste our feature list]

Analyze the changelog and release-notes pages in the attached Markdown. Group releases by theme, estimate the release cadence per month, and summarize where each competitor has invested over the last six months. Flag deprecations, new integrations, enterprise features, and pricing changes, and say what the pattern suggests about their direction. Label every inference as an inference.

Using only the attached API documentation, write a [language] client for [task, for example creating and listing orders]. Cover authentication, the exact endpoints and request and response shapes, pagination, rate limits with retry and backoff, and error handling. Add a comment with the documentation URL above each call. If the docs do not specify something, list it under 'Unverified assumptions' instead of guessing.

Compare the changelog and migration guide pages in the attached Markdown between v[X] and v[Y]. List the breaking changes and deprecations, the endpoints, parameters, or SDK methods affected, the code change required for each, and a migration checklist ordered by risk. Include the source URL for each item and mark anything the docs leave ambiguous.

From the attached library documentation, write a concise instructions section for our coding agent: canonical installation and initialization, the authentication pattern, preferred idioms with short examples, common pitfalls, and deprecated APIs to avoid with their replacements. Keep it under 60 lines, link each rule to its documentation page, and omit anything the docs do not support.

For every endpoint used in [feature], derive an integration test plan from the attached docs: the happy path, documented error codes, authentication failures, pagination boundaries, rate limiting (429) and idempotency behavior, and webhook signature verification if described. For each case give the request, the expected response, and the assertion, and flag any behavior that needs to be verified in a sandbox.

For each paper or article in the attached Markdown, build a table with: citation (authors, year, venue), research question, methodology, data or sample, key findings, stated limitations, and the source URL and DOI exactly as shown on the page. Write 'not stated' rather than inferring. Do not add any source that is not in the file.

Synthesize the attached sources into three to five themes. For each theme, state where the sources agree, where they disagree, and which methods they use, citing the source URL for every claim. Then list underexplored questions and methodological gaps that a new study could address, marking which are stated by the authors and which are your inference.

From this proceedings site, list the accepted papers grouped by track or topic, identify the five most represented topics, and note recurring methods and datasets. Use only information stated on the pages, and include the paper title and URL for each entry. Finish with a short list of the papers most relevant to [my research question].

Draft a 400-word related-work section on [topic] using only the attached sources. Every sentence that makes a claim must end with the source URL or DOI it came from. After the draft, list the claims I should verify against the original papers before citing, and flag any sentence where the sources only partly support the claim.

Using only the attached Markdown of [competitor], build a one-page battlecard: positioning and target ICP, key capabilities, pricing tiers and packaging, three strengths, three weaknesses, likely objections with a recommended response to each, and five landmine questions we can ask in discovery to expose their gaps. Cite the page URL for every point and write 'not stated' where the pages are silent.

Using the attached Markdown of [prospect]'s website, write a pre-call account brief for a conversation with a [role, for example VP of Operations]: what they sell and to whom, their customers and segments, recent trigger events (launches, hiring, funding, partnerships), likely priorities and pain points, and three tailored talking points for our [product]. Give the source URL for each point and separate what the site states from what you infer.

Draft discovery questions for [prospect] mapped to MEDDICC: metrics, economic buyer, decision criteria, decision process, identified pain, and champion. For each element, note what the attached pages already tell us (with the URL) and what they do not, so we only ask what we cannot learn from the site.

Using only the attached Markdown of our public documentation and trust-center pages, draft answers to the RFP questions below. For each answer, quote the supporting passage and its URL, and mark any question the documentation does not answer as 'not found' so a subject-matter expert can complete it. [paste RFP questions]

Using the two attached Markdown files (competitor blog and our blog), cluster each site's posts by topic and search intent (informational, commercial, transactional, navigational). List the topic clusters the competitor covers that we do not, note which clusters have a pillar page, and rank the gaps by how much supporting content the competitor has published. Give the post titles and URLs behind each cluster.

Write an SEO content brief for the keyword [target keyword], aimed at [audience]: primary and secondary search intent, suggested H1 and H2 outline, questions to answer, entities and terms to cover, and the posts from our site (with URLs) that should be linked internally. Base the outline on what the attached competitor posts cover, note where we can add original experience, data, or expert quotes for E-E-A-T, and do not reuse competitor wording.

Audit the attached Markdown of our blog. Flag thin posts, posts that target overlapping topics (cannibalization risk), and content that looks outdated. For each flagged page give the URL, the issue, and a recommendation: refresh, consolidate, or redirect. Then suggest ten internal links with source page, target page, and anchor text, favoring links from our strongest pages to pillar pages.

Read these posts and write a one-page voice and style guide: tone, point of view, sentence length, formatting habits, preferred and avoided terminology, and three do and don't examples quoted from the text. Write it as instructions to a writer, because I will use it as context when editing drafts.

Using only the attached help center Markdown, answer this customer question in a friendly, concise reply an agent can send: "[customer question]". Quote the relevant steps, cite the article URL, and if the documentation does not fully answer it, say what is missing and what to escalate to Tier 2.

Turn the article on [topic] into a reusable macro (canned response) with a greeting that has a [customer name] placeholder, numbered steps, a link to the article, and a closing line. Then write a shorter version for chat. Keep product terminology exactly as it appears in the docs.

Create a two-week onboarding plan for a new Tier 1 support agent from these docs: a glossary of product terms, the ten most important features to master, five practice tickets with expected resolutions, and a 20-question quiz with answers and source URLs.

Review the attached help center content. List articles that contradict each other, steps that reference outdated UI or features named in the release notes, and common topics that have no article. For each, give the URL and a suggested fix.

From the attached Markdown of regulator guidance, extract every obligation into a table with these columns: obligation, applicable entity, deadline or trigger, exceptions, and source URL. Quote the operative wording for each row and mark anything ambiguous for legal review. Do not infer requirements the text does not state.

Compare our internal [policy name] (pasted below) with the attached public guidance. List each requirement in the guidance, whether our policy addresses it (yes, partially, no), the passage from each document that supports your assessment, and the source URL of the guidance. Flag items that need counsel's judgment. [paste our policy text]

Review this vendor's privacy policy, DPA, sub-processor page, and terms of service. Summarize data retention, sub-processing, breach notification timelines, international transfers, and limitation of liability, and note anything unusual or missing. Cite the page for each point.

Compare these two exports of the same policy (earlier and later). Summarize material changes by section, quote the old and new wording, and classify each change as clarification, new obligation, or removal. List anything you are unsure about.