---
name: how-to-run-the-ai-business-audit
description: "Write clear steps to check a business online. Use this when the team needs a repeatable audit guide."
category: Gaps & Tasks to Create
stage: —
definitive_article: "GAP — to be written"
status: gap
---

# Write or Repair the AI Business Audit Guide

An online check should show a business owner what needs work and why. This task helps you write a guide for that check. Start with a real audit and its proof. Finish with clear steps and a useful list of next actions.

**The path:** Find the main guide → document the real method → check and link the result.

**Use this when:** the library needs a complete, current guide for this topic; this task writes or repairs that guide rather than silently running its client operation.

## Inputs

- The exact task, intended reader, useful result and existing pages that may already teach it.
- Current [definitive-article instructions](https://local-service-spotlight.github.io/task-library/?task=create-or-update-a-definitive-article#task-create-or-update-a-definitive-article) and [article guidelines](https://localservicespotlight.com/article-guidelines/).
- A real source run with dated evidence, or a clear list of the evidence still missing.
- A real business audit, allowed website/account scope, observed URLs and raw evidence.
- The current audit criteria, scoring version if used, missing-data rules and the owner of follow-up work.

## First-run prompt

> Find the current main guide for this topic. Use the real source run and current rules to repair it or prepare the missing recipe. Explain the value and first step simply, include proof and visuals, and show what can be completed now and what exact evidence remains.

## Steps

1. Search the owned site, Task Library and maintained source files for an existing main guide. Record the actual URL, title, role and current content. Repair a suitable canonical guide before creating a competing page; the old GAP field is a backlog claim, not proof that no guide exists.
2. Define the reader, starting condition, necessary inputs and measurable finish. Use a short grade-5 opening that explains business value and the first action. Expand unfamiliar terms and link to the owned teaching guide; use vendor documents to substantiate product behavior.
3. Read the real execution record and current source method. Separate observed steps, teaching examples and unresolved decisions. If a live run is needed, scope it explicitly through the operational task; writing this guide does not itself grant new account, publishing or spending authority.
4. Document how to confirm the business, audience, desired result and authorized read scope. A public page review does not require all client admin accounts; request only the source needed to resolve a specific missing check.
5. Describe the actual three-layer review: Digital Plumbing checks basic site and measurement function; content architecture checks useful pages, links and voice; authority checks sourced identity, claims and proof. Keep tests tied to the business’s real goal rather than forcing every tracking tool onto every site.
6. For each finding, preserve the exact URL or account source, time, observation, criterion and effect on the reader. Distinguish observed failures, inference and UNKNOWN. AI-generated prose is not a source and a hypothetical example cannot be reported as a real client defect.
7. Show how the report prioritizes useful fixes, identifies the next owner and sets a measurable recheck. If scoring is used, document its version and treatment of missing data. Hand scoped fixes into [Metrics, Analysis, Action](https://local-service-spotlight.github.io/task-library/?task=maa-cycle-metrics-analysis-action#task-maa-cycle-metrics-analysis-action); an audit does not itself authorize unrelated production changes or prove future revenue.
8. Write the complete recipe, including exceptions, measured QA and the next owner. Put a meaningful diagram, real image or suitable playable video in the first desktop and phone screen. Add a lower Content Factory context diagram with the actual upstream and downstream tasks; every link must point to a verified destination.
9. Review the exact source revision against the maintained article rules. Check the meaning and legibility of the real rendered visual at 1280×800 and 390×844, with scripts on and off where required. A grade number, empty colored box or keyword quota cannot substitute for useful instructions and proof.
10. Use the site’s actual supported editor or builder and preserve its existing metadata, content and media. Save and read back the source. Publish when already authorized; otherwise save the concrete draft and the precise pending decision. For a published result, check the normal public URL, expected text, links and both first screens rather than relying only on a preview or cache-busting URL.
11. Write the actual meta article with the same execution ID and evidence. Update the canonical mapping and related task links only after verifying the right live destination. Change a status only when its stated evidence requirements pass; a published page alone does not close runtime or certification gaps.

## Definition of done (QA checklist)

- [ ] An existing-guide search and canonical choice are recorded, with no accidental duplicate hub.
- [ ] The opening names reader value and the first action in grade-5 language.
- [ ] The audit scope, criteria and raw observations can be reproduced.
- [ ] Findings separate observation, inference and unknown data.
- [ ] The fix list has a useful priority, owner and measurable recheck without an invented client outcome.
- [ ] The recipe has actual inputs, steps, measured QA and next handoff; meaningful first-screen and lower context visuals were reviewed.
- [ ] Draft, saved, published, independently reviewed and actually executed states have separate evidence.
- [ ] The real meta record and any verified canonical mapping use stable task and execution IDs.

## Example(s)

**Fictional teaching example — no client result or completed run.** A teaching report identifies a broken contact link in a sample page. It explains how a real audit would record the URL and a recheck. It does not name a real business or call the sample a delivered client audit.

## Handoff and Content Factory context

Pass the checked guide, source revision, real meta record and open evidence list to [Audit a Local Service Website](https://local-service-spotlight.github.io/task-library/?task=audit-local-service-website#task-audit-local-service-website). Make the Task Library point to the verified canonical destination after its publication and review conditions pass.

This documentation job uses Process to turn real source work into a reusable recipe and Post to save and check its release. In the [Content Factory](https://blitzmetrics.com/content-factory/), later real runs supply new meta articles that improve this same recipe. Catalog neighbors are suggestions, not proven prerequisites.

## When this runs

Run when a verified gap or source change requires a guide update. Reuse the same execution ID for revisions of that update; another client run has its own evidence and is not created by this authoring task.

## First-run setup and continuity

Use the files and accounts this task actually needs. A skill is a written recipe; the [AI worker](https://blitzmetrics.com/build-agents/) needs suitable tools and access to follow it. This file does not install an app, connect an account or start a timer. Follow the [setup guide](https://localservicespotlight.com/install/) for the chosen app. Carry out work already covered by the user's instructions; ask only for an exact missing item or a new action outside that scope.

Save the source, current state, checked result and next owner in the project files. Check that record before retrying or handing work to another person. Configure a repeat only when requested, with its time zone, actual runtime and first successful firing. An app or model name does not prove persistence, memory or a schedule.

Keep every agent media check muted with volume zero before playback. If that cannot be verified, use captions, metadata or still frames and record the limit. Do not play sound through the user's speakers without their current request.

## Write up the real run

For each real attempt, [write the meta article](https://blitzmetrics.com/meta-article-prompt/): its task and source revision, starting point, work done, evidence, measured result, gaps and next handoff. Save one execution ID across retries and edits. Partial, blocked and failed work also gets a record. A saved draft satisfies writing while any public release is pending. Writing does not grant publication authority.

A teaching example is not a real execution. Do not count it, a repeated check or a revision as another run. The [recipe and meta-article guide](https://localservicespotlight.com/meta-articles/) explains the link between reusable instructions and actual work.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 2/5 `●●○○○` — frequency 2, revenue 2, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- Exact task: [Write or Repair the AI Business Audit Guide](https://local-service-spotlight.github.io/task-library/?task=how-to-run-the-ai-business-audit#task-how-to-run-the-ai-business-audit)
- [Definitive article guide](https://blitzmetrics.com/definitive-article-guide/) — reusable recipe standards.
- [Meta article prompt](https://blitzmetrics.com/meta-article-prompt/) — record the actual work.
- [Website QA audit](https://blitzmetrics.com/website-qa-audit/) — the three-layer review.
- [Digital Plumbing](https://blitzmetrics.com/digital-plumbing/) — functional setup.

## Review and evidence still needed

The original contributor state is preserved. Instruction review, article certification, account access and completed work are separate states.

- Needs a verified canonical audit guide and a real, reproducible audit with an evidence-based fix handoff.
- The contributor GAP state remains until the actual canonical guide, required review and evidence are verified. These improved writing instructions alone do not close the gap.