Sitebulb Cloud

View saved version →

---
name: sitebulb-dev-handoff
description: "Turn Sitebulb audit findings into dev-ready tickets in the connected PM tool (Jira, Linear, Asana, Monday, or ClickUp): one ticket per selected issue — what's wrong, why it matters, the true affected-URL count with labelled sample URLs and a pointer to the full export in the Sitebulb app, a suggested fix with its knowledge-base link, acceptance criteria, severity-mapped priority, and an effort estimate (size and duration) — every draft previewed in chat before anything is created, falling back to markdown ticket bodies when no PM tool is connected. Use when the user wants to raise, create, push, or log tickets/tasks/issues from crawl or audit findings — \"send these to Jira\", \"ticket the quick wins\", \"hand the 404s to the devs\", \"make Linear issues for these\" — not for triggering crawls, since it reads Sitebulb read-only."
---

# Dev Handoff

Turns Sitebulb crawl findings into tickets a developer can act on without asking follow-up questions — each carrying the problem, why it matters, sample and full affected URLs, a suggested fix, acceptance criteria, priority and an effort estimate. Reads Sitebulb data through the Sitebulb MCP and writes through whatever PM-tool MCP is connected.

Before doing anything else, read `references/shared-core.md` — the data-handling rules (noise filtering, sample semantics, score semantics) and its § Tool binding (resolve Sitebulb capabilities to the live tools, plus the preflight) without which the output is wrong, not just worse.

## Preconditions

1. **A Sitebulb MCP is connected.** If not, say so and stop — there is no fallback data source.
2. **The MCP is read-only — it cannot trigger crawls.** If the user asks for "fresh data" or "crawl it first", tell them the latest finished audit is from <date> and that a new crawl must be started in Sitebulb itself; offer to proceed on the existing audit.
3. **A finished audit exists for the target project.** In-progress audits are not usable; name the most recent finished one and its date so the user knows what evidence the tickets rest on.
4. **A PM-tool MCP is connected.** It writes the tickets. If none is, don't dead-end: offer the ticket bodies as formatted markdown the user can paste manually, and note that connecting Jira/Linear/Asana/Monday/ClickUp enables direct creation.

## Framing interview

Ask once, up front, per the rules in `references/shared-core.md` § Invocation framing interview (skip what's already known; challenge vague answers; one round only, then proceed on stated assumptions). Tailored for this skill:

- **Output:** "I'll create tickets in <detected PM tool> — which project/board? Any conventions I should follow: labels, components, assignee, epic? And how many sample URLs in each ticket body (default 10, max 50 — the MCP returns an up-to-50-URL sample per issue)?"
- **Context:** "Is there a sprint deadline, limited dev capacity, or an upcoming release these should align to? That changes how many tickets to raise and how they're prioritised."
- **Role:** "Are these going to your own dev team, or a client's?" Tickets to a client's developers need a more diplomatic, evidence-heavy voice — lead with the data, attribute problems to the issue not the implementation, and avoid anything that reads as blame for past work. Tickets to your own team can be terser.

## Building the tickets

0. **Preflight capabilities** (shared-core § Tool binding), before any data pull and before drafting. *Sitebulb read — core, stop if any can't be matched to a connected tool:* list a project's audits, list the audit's hint categories, list triggered hints per category (the category is a required input, so the category list is load-bearing), and list a hint's affected-URL sample. A missing one almost always means a tool was renamed or removed in a newer Sitebulb release; name the capability you expected, say what you can see instead, and don't build tickets from a source you can't verify — there is no fa

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: sitebulb-release-check
description: "Run the user's configured post-release watch-list check on a Sitebulb project: compare the latest finished audit against the previous one, evaluate each watched item against the thresholds in this file's settings block (project, watch-list, thresholds and alert channel live there — the first run asks setup once and hands the filled block back to paste in), treat changes the user names as deliberate as confirmations rather than breaches, then post a breach alert via a connected messaging or project tool — in chat when none is connected — or give a two-to-four-sentence all-clear. Strictly user-invoked; it cannot schedule itself or trigger crawls. Use for \"run my Tuesday check\", \"release check\", \"run my watch-list\", \"run my release check on [project name]\", or the user's own named check ritual. Not for open-ended \"what changed\" or \"did the release break anything\" change-story conversations — that is the sitebulb-what-changed skill; this is the configured ritual with thresholds and alerts."
---

# Release Check

The Tuesday ritual: release goes out Monday, the scheduled crawl finishes Tuesday, the user says "run my Tuesday check". The job is narrow by design — compare the latest finished audit against the previous one, evaluate the user's own watch-list and thresholds, and either raise a breach alert or confirm all-clear briefly. Everything is configured once in the settings block below; the only question a routine run asks is "what went out in the release?". This skill is not a change-story explorer (that is the sitebulb-what-changed skill) and never sizes fixes (sitebulb-what-to-fix-first) or raises tickets (sitebulb-dev-handoff) — it detects, alerts, and hands off.

It is strictly user-invoked. The assistant cannot schedule this check or trigger crawls — the Sitebulb connection is read-only. Never claim otherwise; the ritual works because the user's crawl is already scheduled in Sitebulb.

Before doing anything else, read `references/shared-core.md` — the data-handling rules (noise filtering, delta and split semantics, sample semantics) and its § Tool binding (resolve Sitebulb capabilities to the live tools, plus the preflight) without which the check is wrong, not just quiet.

## Your settings — edit this block

<!-- ═════════════ RELEASE CHECK SETTINGS — YOURS TO EDIT ═════════════
This block is the skill's memory. Fill it in once — or let the first run
ask the setup questions and hand you this block back filled in, ready to
paste over this section — and every future check runs with no setup, just
"what went out?". Write watch items in your own words; the assistant maps
them to the audit data at run time. Thresholds compare the latest finished
audit against the one before it.
-->

**Project:** *not set — the first run asks which Sitebulb project this check watches, then hands this line back filled in.*

**Watch-list and thresholds** — alert when any of these moves past its limit since the previous audit:

- Pages newly blocked from search (noindex, robots.txt, canonical mistakes): any increase of 10+ URLs or 25%
- Broken internal links and new 404s: 10+ more than the previous audit
- Internal links pointing at redirects: 25+ more
- Any Critical issue that is new, or grows by 10+ URLs or 10%
- Overall audit score: a drop of 5+ points — a score that disappears to zero means that area wasn't measured this audit, never a collapse

**Alert channel:** *not set — if a messaging or project tool is connected, the first breach asks where to post and this line records it; with none connected, alerts appear in chat.*

<!-- ═════════════ END SETTINGS ═════════════ -->

## Preconditions

1. **A Sitebulb MCP is connected** (Desktop and Cloud are tool-for-tool identical). If not, say so and stop — there is no fallback data source.
2. **Two finished audits exist to compare.** Take the previous-audit flag from the change-list or per-category hint tools. If the flag is genuinely false, 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: sitebulb-technical-seo-audit
description: "Produce the client-facing technical SEO audit document from a Sitebulb project's latest finished audit: a focused Word working draft of 5–10 issues — never encyclopaedic — selected and ordered by why the audit was commissioned (traffic decline, redesign/migration, onboarding, due diligence), written for the stated reader, each issue carrying its true affected count, labelled sample URLs, a Sitebulb-app export pointer, a knowledge-base link, and a recommendation with owner and indicative effort. Ships seeded with consultant-facing review comments marking where human judgment is needed. Use whenever the user asks for a 'technical SEO audit', 'client audit', 'audit document', or 'audit deliverable', says 'write up the audit for [client]' or 'run the audit on [project]', or hands off from a prioritised read ('need this as a client document'). Not for conversational what-to-fix triage (sitebulb-what-to-fix-first), change-over-time stories (sitebulb-what-changed), or dev tickets (sitebulb-dev-handoff)."
---

# Technical SEO Audit

Produces the deliverable an agency consultant or freelancer sells as a one-off engagement: the client-facing technical audit document. Focused, not encyclopaedic — **five to ten items maximum**, the most important issues for *this* client in *their* specific situation. The temptation to be exhaustive is the failure mode this skill exists to refuse: a 40-issue laundry list is what the client could have got from any crawler export; the 5–10 items that matter, explained in their terms and ordered by why they bought the audit, is what they paid a consultant for.

The output is a **working document, not a finished ta-da deliverable**. If a consultant ships it without checking or improving anything themselves, they are not doing their job — the document says so where it matters, via review comments anchored to the passages that need human judgment (see § The review layer). The consultant's name goes on this document, not the assistant's.

Before doing anything else, read `references/shared-core.md` — the data-handling rules and its § Tool binding (resolve Sitebulb capabilities to the live tools, plus the preflight) without which the output is wrong, not just worse. Then read `references/context-emphasis.md` — the reframe rules that decide what goes in the document. `references/document-template.md` is the deliverable spec; read it before drafting.

## Preconditions

1. **A Sitebulb MCP is connected** (Desktop and Cloud are tool-for-tool identical). If not, say so and stop — there is no fallback data source.
2. **The MCP is read-only — it cannot trigger crawls.** If the user wants the audit run on fresh data, tell them the latest finished audit is from <date> and a new crawl must be started in Sitebulb itself; offer to proceed on the existing audit.
3. **A finished audit exists for the target project.** Name the most recent finished one and its date — the document's evidence rests on it, and the document itself states the crawl date.

## The commissioning interview

The context layer is load-bearing here: the same crawl produces a *different document* for a different commissioning context. Ask once, up front, before any data pull — one round only, per the shared-core interview rules (skip what's already known or evident; challenge non-answers; then proceed on stated assumptions). Four things, conversationally, not as a form:

- **Why was the audit commissioned?** Traffic decline, redesign/migration (done or planned), new-client onboarding, due diligence, deadline-driven, international expansion, or a routine engagement. This maps to the situation layer in `references/context-emphasis.md` (up to two; a causally-linked pair becomes the lead hypothesis) and becomes the document's narrative spine — the exec summary answers *this question*, and item selection and ordering serve it.
- **What kind of business is the client?** Ecommerce, publisher/news/content, SaaS, l

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 10 — file references are metadata, not package contents.

View saved version →

---
name: sitebulb-what-changed
description: "Tell the change story between a Sitebulb project's two most recent audits — wins first, then regressions, then a watch-list, each with what it means and whether it needs action — reframed for the business's situation, with a Google Analytics/Search Console overlay where connected, evidence cards showing per-hint deltas, and an optional self-contained HTML dashboard. Use for \"what changed since last crawl\", \"monthly check\", \"progress since last month\", \"did we get better or worse\", \"did the release/deploy break anything\", \"did the migration cause this\", or prepping a client update — including a \"client meeting in 20 minutes\" short version. Not for full-site triage (sitebulb-what-to-fix-first), raising dev tickets (sitebulb-dev-handoff), client audit documents (sitebulb-technical-seo-audit), or configured watch-list/threshold alerting (sitebulb-release-check)."
---

# What Changed

The job is to help the user understand what changed since the last crawl, and what to do about it. Consultation-first: establish context, deliver a conversational read of the deltas, stay in the conversation. The read compares the latest finished audit against the previous one only — multi-audit trending is out of scope by design.

Before doing anything else, read `references/shared-core.md` — the data-handling rules (noise filtering, sample semantics, delta and split semantics) and its § Tool binding (resolve Sitebulb capabilities to the live tools, plus the preflight) without which the change story is wrong, not just worse. Then read `references/context-emphasis.md` — the reframe rules that decide what leads.

## Preconditions

1. **A Sitebulb MCP is connected** (Desktop and Cloud are tool-for-tool identical). If not, say so and stop — there is no fallback data source.
2. **The MCP is read-only — it cannot trigger crawls.** If the user asks for fresh data, tell them the latest finished audit is from <date> and a new crawl must be started in Sitebulb itself; offer to proceed on the existing pair.
3. **A finished audit exists for the target project.** Name it and its date. If `hasPreviousAudit` is false there is no change story: say so plainly, offer a current-state read of the latest audit instead (framed as the baseline the next comparison will run against), and recommend scheduled crawls so next month has a story. Never fake a delta.

## The context interview

Ask once, up front, before any data pull — one round only, per the shared-core interview rules (skip what's already known or evident; challenge non-answers; then proceed on stated assumptions). Light-touch, conversationally:

- **What happened this period:** "anything happen this month — releases, content pushes, seasonality?" This is the load-bearing question: it separates intended change from regression. A user who arrived via a release/deploy phrasing ("did Tuesday's release break anything?") has already answered it — don't re-ask; treat the release as the stated event and the comparison window's lead hypothesis.
- **Business type and situation** — only if not already known from the conversation or a prior run: the type list and situation list in `references/context-emphasis.md`. The two situations that most reshape this skill's read are **routine check** (deltas first, brief, don't manufacture drama) and **traffic decline** (every delta framed as "could this explain the drop?"; opportunity-class changes demoted).

**Refusal default:** if the user skips or doesn't know, proceed with no reframe and say that's what's happening. Never stall on an unanswered interview.

## Building the read

0. **Preflight capabilities** (shared-core § Tool binding). *Core — stop if unmatched:* list a project's audits; list changed hints vs the previous audit (`audit_lostfound_hint_list`); list an audit's hint categories and triggered hints per category (the per-row previous-audit counts corroborate the deltas). *Peripheral — note the gap and carry on

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: sitebulb-what-to-fix-first
description: "Produce a prioritised read of a Sitebulb audit — the 3–5 issue clusters most worth fixing for this business in this situation — by interviewing for business context, sweeping triggered hints, and scoring impact (severity × section tier × effective coverage × traffic linkage) against effort (fix archetype, S–XL, owner, indicative duration), with context reframing what leads but never the scores. Use for \"what should I fix first\", \"what's wrong with this site\", \"where do I start\", \"prioritise this crawl/audit\", \"quick wins\", \"what's worth my attention\", or any effort-vs-impact triage of Sitebulb findings. Not for raising dev tickets (sitebulb-dev-handoff), change-over-time stories (sitebulb-what-changed), or client documents (sitebulb-technical-seo-audit)."
---

# What To Fix First

Opens as a diagnosis, not a data pull. The job is to help the user understand what's wrong with their site and what's worth their attention — for *this* business, in *this* situation. Data pulls, scoring and the ranked output are in service of that: the skill establishes context first, delivers a conversational prioritised read, then stays in the conversation guiding next explorations. It is the front door of the Sitebulb skill ecosystem.

Before doing anything else, read `references/shared-core.md` — the data-handling rules (noise filtering, sample semantics, score semantics) and its § Tool binding (resolve Sitebulb capabilities to the live tools, plus the preflight) without which the output is wrong, not just worse. Then read `references/context-emphasis.md` — the reframe rules this skill's identity rests on.

## Preconditions

1. **A Sitebulb MCP is connected** (Desktop and Cloud are tool-for-tool identical). If not, say so and stop — there is no fallback data source.
2. **The MCP is read-only — it cannot trigger crawls.** If the user asks for fresh data, tell them the latest finished audit is from <date> and a new crawl must be started in Sitebulb itself; offer to proceed on the existing audit.
3. **A finished audit exists for the target project.** Name the most recent finished one and its date so the user knows what evidence the read rests on.

## The context interview

Ask once, up front, before any data pull — one round only, per the shared-core interview rules (skip what's already known or evident; challenge non-answers; then proceed on stated assumptions). Four things, conversationally, not as a form:

- **Business type:** ecommerce, publisher/news/content, SaaS, lead-gen, marketplace, education, business/services, or affiliate — plus an *enterprise* modifier flag that can sit on any type.
- **Situation** (up to two; a causally-linked pair becomes the lead hypothesis): traffic decline, migration/redesign just happened, pre-migration, new client onboarding, routine check, deadline-driven, international expansion.
- **Constraints:** CMS, dev availability, team shape — these feed the effort engine's modifiers (`cms_self_serve_metadata`, `low_dev_availability`, `ample_dev_capacity`, `solo_no_content_team`, `host_managed_infra`). Only pass a modifier the conversation has actually surfaced; never invent one to complete the picture.
- **Role:** agency, independent, or in-house — sets voice and who the read is written for.

**Refusal default:** if the user skips, passes, or doesn't know, proceed on the pure tier ordering with no reframe — and say that's what's happening ("no context given, so this is the raw SEO-relevance ranking"). Never stall on an unanswered interview.

**Conversational mode:** "what should I fix first?" with context already established (or declined) goes straight to the ranked read — no ceremony, no re-interviewing.

## Building the read

0. **Preflight capabilities** (shared-core § Tool binding). *Core — stop if unmatched:* list a project's audits; list an audit's hint categories; list triggered hints per category (category is a required input, so the category list 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.