---
name: record-screen-shares-of-real-audits
description: "Record a real review of approved work. Show what you checked, what you found, and what needs to happen next."
category: Content Factory — Produce
stage: Produce
definitive_article: GAP — to be written
status: needs-work
---

# Record screen shares of real audits

A screen full of charts can be hard to understand. This guide helps an owner or reviewer explain a real check in plain words. Start with the goal, then show what you found and what should happen next.

**The path:** Approved audit → Clear screen and narration → Findings and edit notes → Editor.

**Use this when:** An approved real audit is about to happen and it may be recorded for teaching or review.

## Inputs
- The actual audit task and checklist, the property to review, and authorization for that read or work. This recording guide does not grant permission to test or change systems.
- Permission to record and the agreed later uses. List private names, emails, account data, and other details to keep out.
- An approved screen recorder with microphone and screen-capture access; enough local storage. For the Zoom method below, use the desktop app and a host role or host-granted recording privilege.
- The approved raw folder, tracker, reviewer, and editor. Keep credentials out of the recording and all public evidence.

## First-run prompt

> Use the approved audit scope and checklist I provide to plan a clear screen recording. Give me a short goal statement, section prompts, and a privacy check. After capture, organize actual findings and time ranges. Do not run changes, assume a passed check, or expose private account details.

## Steps
1. Name the goal, what this recording will show, and who needs it. These are [Goals, Content, and Targeting](https://blitzmetrics.com/gct-business-strategy/). Link the exact audit checklist instead of improvising a new audit from this filming guide.
2. Close private tabs, notifications, password tools, and unrelated windows. Share only the needed window when possible. Choose examples and views the client has allowed. Keep a private list of any remaining redaction risks.
3. For an approved Zoom recording, start the meeting as host or get host permission to record. Select the intended screen or window and check that the needed text is readable. Check microphone input without playing sound through speakers.
4. Use Record, then Record on this Computer if offered. Confirm the recording indicator before beginning. If the approved recorder is Descript instead, use its current recording controls and verify the same screen, microphone, and file checks; do not assume Zoom’s controls apply.
5. For each real checklist item, say what you are checking, why it matters, what the screen shows, and the next action. Keep observations separate from guesses. An inaccessible view is “not checked,” not a pass.
6. Pause between sections and when private content may appear. Note time ranges for useful findings and sections that must be removed. A recording is not permission to click a live change or run an intrusive test.
7. For Zoom, stop recording, then end the meeting to begin local conversion. Wait for conversion to finish before moving or renaming the file; keep it on a local drive during conversion. For Descript or another approved recorder, verify its processing has finished before copying the saved file to the approved raw folder.
8. Name it YYYY-MM-DD-clientname-audit-topic. Save checklist results, evidence references, time ranges, and privacy notes with the tracker row. Review a redacted copy before public use; keep the original in its approved restricted location.
9. Hand the source and findings to [Upload the source to Drive and Descript](https://local-service-spotlight.github.io/task-library/?task=step-1-upload-video-to-google-drive-and-descript#task-step-1-upload-video-to-google-drive-and-descript). The actual audit’s own acceptance checks determine whether the audit passed. This task checks the recording package.

## Definition of done (QA checklist)

- [ ] The audit property, checklist, scope, and permitted recording use are stated.
- [ ] The saved recording shows readable evidence and explains observation, meaning, and next action.
- [ ] Missing checks are visible; the narration does not claim a result from a screen it could not inspect.
- [ ] The file has finished processing, is saved, and has time-based privacy and highlight notes.
- [ ] The named editor can access the allowed package; public-use clearance and sound review are explicit.

## Example(s)

**Fictional teaching example — not an audit of a real site.** In a sample page review for Maple Cycle, a reviewer checks whether the “Book a visit” link reaches the intended booking page.

The narration is: “The goal is to help a rider book a visit. At 02:10, this button opens an old page. I checked the new page separately and it loads. The site editor should update the button and test it again.”

The sample result is one failed link check and one proposed fix. It is not “the site passed” or “bookings increased.” The cut list marks 04:15–04:25 for removal because a private email appears. A real handoff needs the actual page references, recording, permission, and retest evidence.

## Handoff and Content Factory context

The editor takes the recording through [Upload the source to Drive and Descript](https://local-service-spotlight.github.io/task-library/?task=step-1-upload-video-to-google-drive-and-descript#task-step-1-upload-video-to-google-drive-and-descript). The audit owner keeps the findings and any repair tasks; they are not complete merely because a teaching clip was made.

This task serves **Produce** in the [Content Factory](https://blitzmetrics.com/content-factory/). Produce makes or prepares source material. Process edits it, Post puts approved work on a channel, and Promote helps it reach people. Only the steps and handoff above are part of this task.

## When this runs

Run when an authorized audit needs a recording. A recurring audit may use this task for each actual session, but this guide does not schedule audits or start automatic recording.

## Run with an agent

The agent can prepare the plan, organize allowed files, and check the evidence it can actually access. A person records real stories, supplies permission, or resolves an account step when needed. Save the current state in the project files and tracker. A model name does not create memory, access, a scheduler, or permission to act.

For all agent media checks, keep the player muted and its volume at zero before playback. If that cannot be checked, use captions, metadata, or still frames. Do not claim sound quality was heard when it was not.

## Write up the real run

For every actual attempt, [write the run’s meta article](https://blitzmetrics.com/meta-article-prompt/). Link this exact task and its source revision. State the start, work done, evidence, result, gaps, and next owner. Keep failed, partial, and blocked work visible. Writing the record does not authorize publishing it.

Use one stable execution ID for this task’s actual run. Internal retries, checks, and new versions do not add runs. A separately scoped child task may have its own ID linked to the parent. A teaching example has no real execution ID and must not enter the run count. Follow the [recipe and meta-article guide](https://localservicespotlight.com/meta-articles/) for that distinction.


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

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

- **Phase:** Produce
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 2 (supporting)
- **Suggested previous station:** `film-conference-presentations`
- **Suggested next station:** `film-casual-team-conversations`
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Raw files in Content Library `01-Raw/` plus a tracker row (question, date, speaker). Next skill never needs the chat — it needs the files.

## 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

- Dedicated canonical article: not mapped in the current task source. Use the owned teaching references below while that article gap is reviewed.
- Exact task: [Record screen shares of real audits](https://local-service-spotlight.github.io/task-library/?task=record-screen-shares-of-real-audits#task-record-screen-shares-of-real-audits)
- Publishing standard: [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Zoom’s current local-recording controls](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0076922)

## Review and evidence still needed

The contributor status in the source header is preserved. It is not a claim that this draft has been independently accepted or that a real run has passed. The worked example above is for teaching only.
- No dedicated recording guide is mapped in the source.
- Descript UI details are not specified or claimed verified here; the full concrete provider route uses current official Zoom documentation.
- Real audit scope, sound check and redacted-copy review are still required.