---
name: use-for-content-planning-and-video-topics
description: "Make a useful plan for your next set of clips."
category: Strategy & Measurement
stage: —
definitive_article: /topic-wheel
status: complete
---

# Use for content planning and video topics

Make a useful plan for your next set of clips. This guide turns your topic map and real questions into a short list of clips to make. Start with the offer, the stories you can prove and the time you have.

**The path:** Wheel + demand → Clear prompts → Recording plan → Editor

**Start when:** A checked Topic Wheel needs to become a bounded recording plan.

## Inputs

- [The WHAT offer](https://local-service-spotlight.github.io/task-library/?task=map-what-ring-specific-content#task-map-what-ring-specific-content), [HOW topics](https://local-service-spotlight.github.io/task-library/?task=map-how-ring-methods#task-map-how-ring-methods) and [WHY stories](https://local-service-spotlight.github.io/task-library/?task=map-why-ring-core-purpose#task-map-why-ring-core-purpose).
- Real customer questions, source proof, current content results and the [SEO Tree, the map of related pages](https://blitzmetrics.com/seo-tree/).
- The speaker’s availability, recording setup, existing library and receiving editor.

## Steps

1. Read the current wheel with WHAT in the center, HOW in the middle and WHY stories outside. Use its relevant stories and topic-linked questions to make a separate recording backlog; do not export an imaginary outer WHAT ring.
2. For each prompt, record the source, topic, intended viewer, purpose and owned destination page. Keep real questions in the customer’s language where appropriate and distinguish a proposed story from existing proof.
3. Prioritize by the current business goal, repeated customer need, usable proof and production effort. Search volume or last period’s winner is a signal, not a guaranteed future outcome.
4. Check for relevant existing assets that can be reused. Apply the source’s 90/10 greatest-hits principle to the declared effort unit, leaving a bounded portion for new tests.
5. Prepare one session’s prompts that fit the available time. Give the speaker a question and source reminders rather than invented first-person claims. Use the [one-minute guide](https://blitzmetrics.com/one-minute-video-guide/) for a clear short answer; split a topic that needs more.
6. Agree the actual recording owner, date and file handoff. A plan is not a scheduled calendar event until saved and verified, and a planned clip is not recorded.
7. After the authorized session, link the selected takes and actual remaining gaps in the library. Hand only real available sources to the editor and use later results to refine the next plan.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the result against its agreed requirements; see the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] Prompts use correct wheel relationships and trace to real questions or proof.
- [ ] The bounded session plan has a speaker, time, sources and editor handoff.
- [ ] Planned, recorded, usable and published states remain distinct in the backlog.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional bike shop has five source-backed questions but time for three clips. It picks the three that match its current service goal and saves the other two as pending. After recording, one take has no usable picture. The editor gets two selected files, and the plan records that the third still needs a take.

## Handoff and Content Factory context

[Record the planned clips](https://local-service-spotlight.github.io/task-library/?task=record-one-minute-videos#task-record-one-minute-videos) receives the prompts; [Process the saved source files](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) receives the actual usable takes.

This work supports Produce in the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). The selected sources pass to Process, approved outputs go to Post, and useful proven work can enter Promote. The real inputs and handoff above set this task’s scope.

## Start with an agent

Give the AI worker this recipe, the real Inputs, the desired result and the actions already authorized. Ask for the saved output, source evidence, passed and failed checks, and the next owner. A skill is a set of instructions. Loading it does not prove access, install a scheduled job or complete the work. Use the [current installation guide](https://localservicespotlight.com/install/) only if reusable setup is needed; a ZIP contains instructions and is not an access grant.

Use the actual supported app and verified source access. A model name is not a promise of browser control, memory or unattended work. For recurring work, inspect the real job’s trigger, owner, timezone and observed firing; this recipe creates no schedule. Before any media playback, mute the player and set volume to zero. A silent review does not prove sound was heard.

## Record the real execution

Open the run record when work begins. Keep one execution ID, the exact starting recipe revision, input sources and actual state. Write a [meta article, the record of one real execution](https://blitzmetrics.com/meta-article-prompt/) with results, checks, failures and next owner. Link it to this task in the [Task Library](https://local-service-spotlight.github.io/task-library/). Writing is required; public release follows existing authority.

Reuse the same execution ID for internal reviews, meta writing, revisions and retries. A blocked run stays open with its dependency and owner, without an invented finish time. Keep historical public examples as dated evidence; article counts alone are not verified execution frequency. Use supported findings to propose and verify a recipe improvement.


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

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

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, 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

- [Maintained source guide](https://blitzmetrics.com/topic-wheel/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=use-for-content-planning-and-video-topics#task-use-for-content-planning-and-video-topics)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records work together](https://localservicespotlight.com/meta-articles/)

## Review and evidence still needed

The inherited contributor status is `complete`. It is preserved, not promoted by this rewrite. That label alone does not verify document readiness, account access, an actual execution or a client outcome.

A relevant real execution, source evidence, independent reviewer and accepted handoff remain to be recorded. The fictional example teaches the method and does not fill a real-run evidence gap. The opening and full method need a named semantic reviewer; the task-specific path is source guidance, with visible desktop/mobile presentation still to check.