Installing a skill pack is easy. Getting a good run out of one is the part nobody documents.
The ai-visibility-skills pack audits whether ChatGPT, Claude, Perplexity, and Google AI Overviews can discover, understand, and cite a website. Its SKILL.md files tell an agent what to do. Its README tells you what the pack is. Neither tells you what to type — so I wrote a prompt guide, and then wrote a skill that generates one for any pack.
The canonical guide lives in the repo: docs/PROMPT_GUIDE.md. That is the version that gets updated as bugs get fixed. What follows is the short version of why it looks the way it does.
Name the orchestrator, not the fourteen skills
The pack has fourteen skills, but you rarely pick one. ai-visibility-audit classifies the site, runs its own discovery pass, and delegates everything deeper to the specialist that owns it — crawler rules, sitemaps, schema, citation readiness, content gaps.
Use the ai-visibility-audit skill on https://example.com. Show the command output behind
each finding, and give me the prioritized action plan at the end.
That is a real run. Reach past the orchestrator only when you already know which dimension you care about.
Supply the context that changes the run
The test for whether something belongs in your prompt is not “is it true” but “does it change what the pack does.” Three that do:
- What the site actually is. The pack’s capability gating keys on ecommerce, multilingual, developer-platform, and paywalled signals. Say “docs site with an OpenAPI spec” and the docs specialist fires instead of being marked not-applicable.
- What private data you can hand over. The pack prefers public crawlable evidence unless you supply Search Console or analytics. Supplying it moves findings from derived to measured. Not supplying it is fine — just know which half of the report you are reading.
- Who reads the output. An executive dashboard, a developer ticket list, and a client PDF are three deliverables from the same findings.
Say what evidence you will accept, and why
The weak version:
audit example.com and tell me what's broken
The version that works:
Audit https://example.com with ai-visibility-audit. For every finding show the exact
command and its output — I need to hand this to a developer who will re-run it. Where
you're inferring rather than observing, label it [Derived] and say what would confirm it.
Attaching the reason to a constraint is doing real work there. “Cite the command” gets obeyed literally; “cite the command because someone else re-runs these” generalizes to the cases you did not anticipate.
The limitations section is the point
A prompt guide that documents only the happy path is worse than none, because it reads as authoritative. The repo guide names the gaps as they actually stand, with links, and says what to verify by hand:
- JavaScript-hydrated content can produce false negatives. Reading raw HTML only, the pack missed React-Helmet head tags and Next.js RSC-streamed JSON-LD — reporting “zero structured data” on a page with four valid blocks. A fix adding a hydrated-DOM second pass is open but not yet merged, and it covers title, meta description, canonical, and JSON-LD only; hreflang, heading extraction, and image checks keep the same blind spot.
- Sitemap discovery guesses filenames. A site publishing
/sitemap-index.xml(hyphenated, which is what one common static-site plugin writes) was reported as having no sitemap at all. The fix reorders discovery to follow what the site declares before guessing — also open, also not merged.
“Fixed in a pull request” and “fixed” are different claims, and a guide that blurs them sends people to trust a check that is still wrong on main.
The methodology is not mine
The structure — quick start, context, structured multi-phase requests, good versus less-effective pairs, limitations, where to go deeper — comes from the official prompting documentation of four providers: Anthropic, OpenAI, Google, and BytePlus.
What is striking is how much they independently agree on. All four document structural separation of instructions, context, examples, and input — Anthropic through XML tags, OpenAI and BytePlus through the identical Identity / Instructions / Examples / Context sections, Google through “XML tags or Markdown.” All four document few-shot examples. OpenAI and BytePlus separately arrive at the same rule that reasoning models want high-level goals while non-reasoning models want explicit steps. Four vendors converging on the same technique from different products is a much stronger basis than one vendor’s house style.
A couple of things in those guides deliberately did not make it in: temperature and top-K tuning, and prompt-cache placement. Both are API-level controls you do not have when typing at a skill in a chat window, and importing them silently would be padding.
Generating these for any pack
The process above is now a skill of its own — write-prompt-guide. Point it at a pack and it reads that pack’s SKILL.md files, README, and open issues, then produces the guide. The open-issues step is mandatory, and there is a structural validator behind it that fails a generated guide which names a capability the target pack does not ship, or which claims an unmerged fix as shipped.
Those are the two ways this kind of document goes bad. Everything else is editing.