Skip to main content
Real operator prompts pulled from Synscribe production chat sessions with Pi, cleaned and anonymized (client names, URLs, and PII replaced with [placeholders] — structure and intent preserved so they stay copy-paste-ready). Grouped by task category. Placeholder key: [client] = the account/company · [domain] = client site · [partner] = a partner brand to co-rank · [competitor] = a rival · [keyword] · [product] · [region] · [month] = cycle month tag (e.g. jul'26).
Provenance is the source org slug + approximate month. It is metadata for us, not part of the prompt — drop it when you copy a prompt.

1. Keyword research & planning

1.1 — Pick the most winnable keywords from a tagged pool

Does: narrows a month’s candidate keywords down to a small, winnable test set.
In [month] keywords, pick the top 5 to test — the most winnable.
org: straitsx, ~Jun 2026 · Pattern: short, but leans on an already-tagged monthly pool and a clear selection criterion (“most winnable”).

1.2 — Full monthly keyword selection run (the canonical workflow)

Does: runs the end-to-end monthly keyword pipeline — explore, evaluate, SERP-cliff, cannibalization check, tag.
We only need 20 keywords. Can you use the keyword explorer, then the 2D framework
(intent × winnability), check for cannibalization within the selected set AND against
existing landing pages, then run a SERP-cliff analysis. Tag the final set [month].
org: rently-uae, ~Jun 2026 · Pattern: the operator names each step explicitly and caps the count — the loop that recurs across every account.

1.3 — Keyword discovery scoped to gaps, with cannibalization guard

Does: finds keywords with no existing LP, audits them, dedupes for cannibalization, iterates.
Use /goals, then find me keywords that (1) do NOT have an existing landing page and
(2) are relevant to what [client] actually sells. Then do a keyword audit on all of them
and select the best 37. Make sure the selected keywords aren't so similar to one another
that they cannibalize — if they do, replace the offenders from the earlier search pool and
repeat the process.
org: wonderchat, ~Jun 2026 · Pattern: bakes the acceptance test (“no existing LP”, “no cannibalization”) into the request and tells Pi to loop until it passes.

1.4 — “Keyword vs content-idea” correction (the most-repeated coaching)

Does: rejects head-term/content-idea entries and forces true keywords usable for both LP and blog.
Many of the selected entries are content-idea queries, not keywords usable for both landing
pages and blogs. A keyword derived from "what is the best [competitor] alternative" is
"[competitor] alternative" (which we already have an LP for). "how to measure X" →
"[X]". Please revise: keep only keywords that work for both LP and blog, add modifiers to
turn queries into keywords, and drop anything we already rank for.
org: wonderchat / rently-uae, ~Jun 2026 · Pattern: teaches the model the distinction WITH worked examples — the single highest-frequency operator correction in the corpus.

1.5 — Turn queries into keywords, then tie content ideas back

Does: converts blog-idea queries into taggable keywords and attaches the query as a content idea.
I want keywords that can do both LP and blogs. Come up with keywords derived from these
queries and tag those instead. Then, since we can't yet tag blog ideas to keywords directly,
once you've tagged a keyword, suggest the actual query that would make a good blog for it.
Example: "best [product] for [use-case] [region]" is a blog idea → derive the keyword, tag it,
and note that query as the blog content for it.
org: rently-uae, ~Jun 2026 · Pattern: works around a product limitation by having Pi record the mapping in notes.

1.6 — SERP-cliff + “are we already ranking?” verdict pass

Does: decides keep/drop/optimize per keyword based on cliff position and whether client already ranks.
Before we commit these, check the SERP for each and whether [client] already ranks:
- already #1/#2 → drop (don't build a competing page)
- not ranked yet → keep
- striking distance (pos 8–20, high impressions) → keep to optimize the existing page
org: rently-uae, ~Jun/Jul 2026 · Pattern: an explicit decision rubric — the operator does this manually keyword-by-keyword, pasting positions back in.

1.7 — Crawl a competitor/product page for keyword candidates

Does: harvests product names off a live page as net-new keyword candidates.
Check the page [product-listing-URL] and crawl it for all product names that can be used as
keywords. Then see which ones are net new vs our existing list, and run a keyword eval on those.
org: frameshft, ~May 2026 · Pattern: grounds discovery in the client’s real catalogue, not generic ideation.

1.8 — Tag and file, with research attached to notes

Does: commits the accepted keywords with correct tags and the supporting research in notes.
Okay, let's add the net-new ones. Make sure to tag them properly (as [tag]) and add the
research to the notes. Tag the accepted set [month] and remove the rest — we'll revisit them
another month as we build the month-to-month strategy.
org: frameshft / wonderchat, ~May–Jun 2026 · Pattern: research is always filed to notes alongside the tag; leftover candidates are parked, not deleted.

1.9 — Build the keyword ladder / dendrogram

Does: maps head terms to their long-tail supporters so the cluster structure is visible.
For these keywords, build a dendrogram so I can see which are the head terms and how the
ladder works — which long-tail keyword targets which head term eventually.
org: wonderchat, ~Jun 2026 · Pattern: asks for a structural view of the cluster, not just a flat list.

1.10 — Challenge the strategy before executing

Does: pressure-tests whether the keyword direction matches the client’s actual ICP and stated goals.
Are we really going after verticals? Is this what the client wants based on the ICP doc?
I feel like they want to establish themselves in the [category] space and the pain points the
ICP faces — you've seen the ICP research and the language they use. Be honest: does this
selection align with the focus and direction we discussed?
org: wonderchat, ~Jun 2026 · Pattern: demands honesty and re-grounds in the ICP doc before letting Pi proceed.

2. Landing pages (pillar, generation, alignment, refiners)

2.1 — Align the LP generator to a compliance guideline

Does: updates the LP prompt and supporting files so future pages are generated compliant.
Update the LP prompt and all the relevant files so that generated LPs are compliant with
[the compliance guideline]. Then check the unpublished LPs and tell me if they're compliant.
org: straitsx, ~Jun 2026 · Pattern: fix the generator first, then audit the backlog — root-cause before cleanup.

2.2 — Drive LP content from a CSV source of truth

Does: treats an uploaded CSV as authoritative and reconciles the pages to it.
[attach CSV]  The CSV is the source of truth. Build/adjust the LPs from it, then run the
compliance scan.
org: straitsx, ~Jun 2026 · Pattern: pins a single source of truth so Pi doesn’t drift or invent copy.

2.3 — Align all LPs to an ICP/positioning brief

Does: rewrites LP files, prompt, and refiners against a pasted ICP + positioning brief.
With these requirements, update all relevant files, the prompt, and the refiners: [paste ICP /
positioning brief — who to target, what we already rank for, the gaps that are priorities, and
what NOT to duplicate]. Then look through the latest [N] unpublished LPs in /uses and make
sure they're compliant with the above.
org: wonderchat, ~Jun 2026 · Pattern: the brief explicitly says “write into a gap, not a page we already rank for” — the ICP doc doubles as guardrails.

2.4 — Position hero copy for a fake-door / lead-gen page

Does: works the on-page text for a validation page that intentionally has no real deliverable.
How should we position / work on the text here? Note there's no actual report that gets sent —
it's a fake door so we can gauge lead interest.
org: scheduling-wizard, ~May 2026 · Pattern: states the page’s real intent so the copy matches the experiment.

2.5 — Write a build prompt for an external page builder

Does: produces a ready-to-paste prompt for a no-code builder to adjust a page.
Write a [builder] prompt to adjust the page accordingly. Note: I can't give verified pricing
because clinics may not want that shared — keep it as ranges / "from" framing.
org: bookaclinic, ~Jul 2026 · Pattern: hands Pi the constraint (no hard pricing) so the generated prompt respects it.

3. Blog content (writing, editing, refiners)

Does: verifies facts as-of-today and checks every internal link on the unpublished backlog.
Look through all the unpublished blogs and make sure all information is the most up to date
and all the internal links are valid — no errors, no 404s. Search the web to verify accuracy
as of today, [date].
org: chalkie / scheduling-wizard / wonderchat, ~May–Jul 2026 · Pattern: recurs almost verbatim across every account — the standard pre-publish sweep. Often paired with /goals to run one blog at a time.

3.2 — Fully specified blog audit with domain guardrails

Does: audits a named set of articles against explicit factual rules and forbidden fabrications.
You are auditing all [N] unpublished blog articles for [client] ([domain]). For each article:
(1) read the full content, (2) check factual accuracy as of [date], (3) verify all hyperlinks
work. Critical accuracy context you MUST keep in mind: [list the non-negotiable facts —
regulations, what the product IS and IS NOT, competitor relationships, real ARR/customer
numbers]. Do NOT fabricate or assume competitor pricing/features you can't verify.
Article IDs: [list].
org: scheduling-wizard, ~Jun 2026 · Pattern: front-loads the ground truth and an explicit “don’t fabricate” so the audit can’t invent facts. The gold-standard audit prompt.

3.3 — Enforce brand ordering in metadescriptions

Does: guarantees the client is named first (ahead of competitors) in every meta description.
For all the unpublished blogs, make sure the meta descriptions place [client] at the front —
before all competitors, if any competitors are mentioned.
org: chalkie / wonderchat, ~Jun 2026 · Pattern: a single consistent rule applied across the whole backlog.

3.4 — Enforce ranked ordering across title, content, slug, and meta

Does: locks a consistent competitive ordering everywhere the list appears, and syncs the count.
Run through all unpublished blogs, verify all information is accurate as of today (search the
web to confirm), then ensure [client] is always #1 and [partner] is always #2. If the numbers
differ, check the title, content, slug, and meta description and sync everything. The number of
options in any listicle must match the title, content, AND meta description.
org: scheduling-wizard, ~Jul 2026 · Pattern: one ordering rule enforced across all four surfaces + count consistency — catches the classic “title says 10, body lists 8” defect.

3.5 — Fix titles / metadescriptions to lead with the brand

Does: targeted follow-up to correct titles once the audit surfaces mismatches.
For all the unpublished blogs, help me fix the titles. And make sure the meta descriptions
place [client] at the front before any competitors.
org: straitsx / chalkie, ~Jun–Jul 2026 · Pattern: operators split a big audit into narrow follow-up fixes.

3.6 — Compliance-check blogs one by one with /goals

Does: runs each blog individually through the compliance guideline and retries failures.
Check if all the blogs are written to the compliance guideline — do it one by one, use /goals.
[on failure] Retry what failed. [after] Were all the blogs fixed? Yes, please help me fix.
org: straitsx, ~Jun 2026 · Pattern: one-by-one via /goals for reliability; the operator explicitly re-runs failed subagents and confirms completion before moving on.

4. Publishing & distribution

Does: checks which host variant is canonical before rewriting internal links across content.
Can you confirm — I think their site is [domain] with www as the canonical? Once confirmed,
make sure all links to the [client] homepage use the correct canonical form.
org: chalkie / frameshft, ~May–Jun 2026 · Pattern: verify canonical first, then bulk-fix — avoids rewriting every link twice. Does: rewrites outdated/broken internal links to the correct current paths across all blogs.
This is [client]'s site: [domain]. Make sure all links to the [client] homepage are correct.
Check the product bible, the prompts, and the refiners. Fix all broken/old links across the
blogs to the correct current URLs.
org: frameshft, ~May 2026 · Pattern: fixes the content AND the upstream sources (product bible, prompts, refiners) so the errors don’t regenerate. Does: inserts subtle anchor-text links to partner pages using their top GSC performers.
This is from [partner] — let's incorporate some of these links into our blogs as subtle
anchor texts: [paste partner's top GSC pages]. Prioritize their best commercial and how-to
pages as natural anchor targets.
org: scheduling-wizard, ~Jul 2026 · Pattern: link-building grounded in the partner’s actual ranking data, placed as natural anchors.

4.4 — Decide next move after losing share of voice

Does: asks for a strategic recommendation (e.g. link building) after a competitive-loss audit.
[after an SOV/ranking audit] So what should we do — go into link building? Suggest next steps.
org: bluente, ~May 2026 · Pattern: uses Pi as a strategist once the diagnostic is done.
Coverage note: press-release and formal indexing-submission prompts are thin in the sampled chats. Distribution activity concentrated on internal linking, canonical/link hygiene, and partner-anchor link building rather than PR or index-ping workflows.

5. Analytics & review

5.1 — Read-only analytics onboarding exploration

Does: gets acquainted with a newly connected analytics account without changing anything.
We just got onboarded on [client] and got access to [analytics tool]. Help me do an initial
exploration of their insights and dashboards — do NOT add or write anything yet. The goal is
to understand what's already set up and what else we need to do.
org: straitsx, ~Jun 2026 · Pattern: the “explore, don’t touch” opener — read-only reconnaissance before any changes.

5.2 — Scope which events to own, and protect the rest

Does: picks the events to instrument for organic/AI visibility and records ownership boundaries.
Help me think through which events we should set up to get visibility into organic and AI
traffic — don't set anything up yet. Then let's do P1–P4 only. Do NOT override or change
existing ones. Save to memory what WE own and what not to touch.
org: straitsx, ~Jun 2026 · Pattern: explicit ownership boundary written to memory so future sessions don’t clobber the client’s own setup.

5.3 — Profile who converts, exploratory

Does: breaks lead-form submitters down by attributes to characterize the buyer.
I want more analytics on who submits these forms — break them down by country and any other
insights you find. No need to create new insights or dashboards; just run the queries so I
understand the type of people who submit leads and how we might find more of them.
org: straitsx, ~Jun 2026 · Pattern: exploratory, query-only (“don’t create dashboards”) — understand the buyer before building anything.

5.4 — Attribution / impact validation

Does: tests whether specific content (blogs, /uses pages) drove measurable growth.
Find out from [client]'s [analytics tool] what growth looks like over the last couple of
months, and whether it can be attributed to the blogs and /uses pages. Do a full exploration
of events and flows first to build a picture of the funnel. Then illustrate how much conversion
is attributed to /uses or blog per month vs other channels (split it) — show funnel input,
output (converts), and contribution. I'm validating whether these two things had significant
impact on the org.
org: rently-uae, ~Jun 2026 · Pattern: states the hypothesis being tested up front (“I’m validating…”), and asks for the funnel picture before the attribution split.

5.5 — Pull a GSC keyword report into the strategy

Does: feeds a GSC export in as context for keyword and content decisions.
[attach GSC keyword CSV]  Based on this and the product bible (which should be the most
up-to-date), come up with keywords and select. Also check the SERP and whether [client] is
already on the page for each.
org: rently-uae, ~Jun 2026 · Pattern: real GSC data + product bible as the two grounding inputs; SERP + already-ranking check reapplied.

5.6 — Prep a client review, aligned to the last review

Does: summarizes findings so they line up with what was agreed in the prior review call.
Based on everything we've discussed in this chat, summarize your findings and make sure
they're aligned to what was discussed in the [month] review — in terms of the plans and
concerns raised, especially the ones [stakeholder] brought up.
org: rently-uae, ~Jun 2026 · Pattern: explicitly ties the deliverable back to a named stakeholder’s concerns from the review call.

6. Account setup & memory

6.1 — Feed a review/call transcript to set direction

Does: hands Pi the meeting transcript so the next cycle’s strategy inherits what was agreed.
[paste review meeting transcript]  This is the [month] review with [client]. Based on this
and the product bible (which should be the most updated), come up with keywords and select.
[Client] also flagged: [paste any client-suggested keywords / news angles].
org: rently-uae, ~Jun 2026 · Pattern: the call transcript is the primary strategy input; client asks are pulled straight from it.

6.2 — Correct the product/org info, precisely

Does: makes targeted factual corrections to the org’s product info fields.
Let's update these:
- Detailed description — remove "[inaccurate claim]"; for this [region] account, focus on
  [correct scope].
- Product [N] — references to "[wrong locations]" → update to [correct locations].
- ICPs — several mention only "[subset]" → update to include [full set].
I'm not sure we have a product bible yet — if we don't, let's NOT create one yet.
org: rently-uae, ~Mar 2026 · Pattern: field-by-field corrections with reasons; explicitly defers creating new artifacts until asked.

6.3 — Build ICP hypotheses from the ground up

Does: derives who searches and why, grounded in transcripts and research rather than keywords.
Look into the ICP of [client]. Come up with hypotheses for the [region] ICP — why do people
find [client], and who are they? Dig into the transcripts and research to understand what
brings people to [client]: who we're selling to, who's interested, and what circumstances
would cause them to search for the solutions [client] provides. Start from the ICP, not the
keywords.
org: rently-uae, ~Jun 2026 · Pattern: “start from the ICP, not the keywords” — the operator repeatedly redirects from keyword-first to persona-first.

6.4 — Set up the image generator and default refiners

Does: configures per-account image generation and the default refiner set.
Help me set up my image generator. Set up my default refiners: set up the image refiner first,
grabbing the logo from [domain], then add the CTA refiner to the default set.
org: bookaclinic, ~Jun 2026 · Pattern: sequences setup (image refiner → CTA refiner) and points Pi at the source of the brand asset.

6.5 — Image-generation prompt spec grounded in ICP + real product

Does: produces per-keyword image prompts that reflect the actual product and buyer perception.
For each of these, give me a short image-generation prompt. Consider our ICP and our ACTUAL
products — the images must reflect what we offer and make buyers see us as credible and
authoritative. They should look genuinely installed and in perfect use: professional, clean,
but still realistic. No humans in the background.
org: frameshft, ~May 2026 · Pattern: precise visual constraints tied back to ICP and credibility, reused verbatim per keyword. Does: corrects stale URLs in the account’s persistent context files, not just the content.
Fix all the links in the product bible and memory for [client].
org: frameshft, ~May 2026 · Pattern: treats the account’s memory/product bible as maintainable source data that also drifts and needs correcting.

6.7 — Diagnose before acting (audit-first)

Does: demands a root-cause audit before any fix when performance drops.
Have you run an audit? Debug to understand and diagnose why this is happening [before we
decide what to do].
org: bluente, ~May 2026 · Pattern: audit-and-diagnose gate — no fixes until the cause is understood.

Recurring operator patterns (for Part 3 SOPs)

  1. Audit / explore before acting. Operators routinely open with “don’t add or write anything yet”, “have you run an audit — diagnose why”, “do a full exploration first”. Read-only reconnaissance precedes any change, especially on a newly onboarded account.
  2. Cannibalization is checked twice — within the set AND against existing LPs. Almost every keyword run asks Pi to dedupe the selected keywords against each other and against pages the client already ranks for. This is the single most-repeated guardrail, and operators re-flag it when Pi forgets (“you casually forget about cannibalization… file a ticket about this”).
  3. “Keyword vs content-idea” is the top coaching correction. Operators repeatedly reject head-terms / “best X” / “how to Y” as keywords, insisting keywords must serve BOTH a landing page and a blog, and teach the fix by example (add a modifier to turn a query into a keyword; attach the query as the blog idea for that keyword).
  4. SERP-cliff + “are we already ranking?” verdict rubric. Keep/drop/optimize decisions are driven by (a) the SERP cliff position and (b) whether the client already ranks: drop if already #1–#2, keep if not ranked, optimize the existing page if in striking distance (pos ~8–20).
  5. Monthly cycle tagging. Selected keywords are tagged by cycle month (jun'26, jul'26); the rest are parked (“we’ll come back another month”) rather than deleted. The month tag is the backbone of the month-to-month strategy.
  6. Brand ordering enforced across ALL surfaces. Client must appear #1 (partner #2) ahead of competitors in title, body, slug, AND meta description — and the listicle count must match across all of them. Operators sweep the whole unpublished backlog for this.
  7. Grounding trio: ICP doc + product bible + review transcript. Strategy is anchored to these three, and operators paste call/review transcripts directly into chat to set direction. “Start from the ICP, not the keywords” is a recurring redirect.
  8. Pre-publish sweep is a standing ritual. “Check all unpublished blogs — accurate as of today (verify on the web), all internal links valid, no 404s” recurs almost verbatim across every account, usually run one-by-one via /goals with explicit retry of failed subagents.
  9. Fix the generator, then the backlog. For compliance/link/positioning issues, operators fix the upstream prompt / refiners / product bible first so errors stop regenerating, then audit and fix the existing pages.
  10. Research is filed to notes; ownership is written to memory. Accepted keywords carry their supporting research in notes; on shared tools (analytics) operators tell Pi to “save to memory what we own and not to touch” so later sessions don’t clobber the client’s own setup.
  11. Confirm completion and demand honesty. Operators close loops explicitly (“all blogs fixed?”, “were all fixed?”) and repeatedly ask for candor (“be honest: do these align with the direction we discussed?”) rather than accepting the first answer.
  12. File a ticket on repeat mistakes. When Pi makes the same error twice (e.g. cannibalization), operators ask it to file a ticket in-line — feeding the product-improvement / feedback loop.