---
name: create-or-update-a-definitive-article
description: "Build one clear guide for a real task. Show how to do it, check it, and pass the result on."
category: Content Factory — Process
stage: Process
definitive_article: https://blitzmetrics.com/definitive-article-guide/
status: needs-work
---

# Create or update a definitive task article

Your team needs one clear place to learn a task. This guide helps you create that page or fix the one you have. Start by finding its current owner and the real work it should teach.

**The path:** Current owner and source → Usable recipe → Independent checks → Published or staged guide.

**Use this when:** A task guide is missing/incomplete, or evidence from a real run shows the existing method needs a change.

## Inputs
- The task, existing canonical owner URL/source revision and declared page role.
- Actual source material, examples and permissions, plus the [Goals, Content, and Targeting](https://blitzmetrics.com/gct-business-strategy/) brief.
- Maintained [Article Guidelines](https://localservicespotlight.com/article-guidelines/), the Task Library and actual prerequisite outputs/access.
- The supported CMS/builder or repository source, edit/publication scope, independent reviewer and next owner.

## First-run prompt

> Create or repair the full canonical task guide from this source and real run evidence. Verify its owner/role, correct stale steps, write grade-5 setup context, and provide a useful labeled example. Preserve status, URL and supported source. Complete authorized publication with exact source/public QA, and document the actual run without inventing certification.

## Steps
1. Search the live site, canonical directory and Task Library. Improve the current owner when it exists. Keep a topic hub, story, reference and task recipe distinct; do not create a new definitive page simply because an old article lacks a wrapper.
2. Read the full current procedure and available execution proof. Identify what is missing or false. Verify changing technical claims against current primary product docs while linking owned training for explanations.
3. Write a specific GCT opening in two or three plain sentences at grade 5. Say who the page helps, why the task matters, and what useful result the reader will get. Explain first-use jargon and include a topic-specific meaningful lead visual.
4. Write the full task contract: trigger/start, inputs/access, true prerequisite outputs, ordered decisions, measurable deliverable, acceptance checks and the actual next task/owner. Fix bad old steps rather than preserving them inside a new template.
5. Include a useful worked example. Prefer relevant verified run evidence; when none exists, label a concrete teaching example as fictional and keep the real-run evidence gap explicit. Neither a fictional result nor a contributor label certifies execution.
6. Connect the page to its actual SEO Tree parent, useful proof stories and next guides. Verify every new target and named anchor. Keep a needed primary proof/download/sign-in link where its purpose is clear, without routing every tool explanation to the provider.
7. Preserve the canonical URL, existing Page/builder and original proof media. Change source type, redirects or identity only where the job authorizes it. Stage exact before/after files and protect newer concurrent changes.
8. Place the lower Content Factory map after the main task explanation, showing true inputs/handoff and stage. Keep the topic lead visual distinct. Check the applicable article standards and have an independent reviewer inspect meaning and source fidelity.
9. Publish/update through the supported route when already authorized and checks pass, or finish the reviewable draft when staging is the scope. Read back the saved source and normal public canonical URL separately. Check meaningful lead visibility/no overflow at 1440×860 and 390×844, with silent media and evidence tied to the final revision.
10. Write this actual execution’s meta, register its real state through the existing ledger rail, and give the next owner the artifact, acceptance evidence and gaps. Certification requires actual semantic review and evidence; authoring or registration alone does not promote the source status.

## Opening meaning review

Keep the opening to two or three short sentences at grade 5 or below. It must show the actual reader’s situation, why the subject matters, the useful result, and how this page helps. A source-backed moment or useful finding can lead. Keep its relevant visual in the first screen; check that the body delivers the opening’s promise.

Save the exact opening and artifact revision in the existing run receipt. Have the reviewer quote the words that establish the situation, reason to care, result and method. Record PASS, FAIL or UNKNOWN with reasons and a readability diagnostic. A grade score, keyword, generic audience label or unsupported conversion promise cannot approve meaning. Follow [Step 7: write and review the opening](https://local-service-spotlight.github.io/task-library/?task=step-7-write-hook-and-establish-context#task-step-7-write-hook-and-establish-context) and the [maintained opening standard](https://github.com/dennisyu/local-service-spotlight-skills/blob/main/standards/every-article-and-project-starts-with-specific-gct.md).

## Definition of done (QA checklist)

- [ ] One canonical owner and correct page role are preserved.
- [ ] The full useful recipe, grade-5 opening and worked example are source-grounded; real-run gaps remain explicit.
- [ ] Owned links, lead visual, lower context and supported publishing source are checked.
- [ ] Independent review and actual save/public evidence match the final revision, with truthful execution/meta state.

## Example(s)

**Fictional teaching example — no new guide was published.** Maple Cycle has a short photo-request note that says only “send us pictures.” The revised task guide specifies a whole-bike view, a close-up and a note on when the issue occurs, then explains how the shop checks that package and arranges an inspection when needed.

The example is labeled teaching material because no customer run has been supplied. Its status stays WIP even after a reviewer finds the draft clear. Separately, the real source record points to `recipe-audit-20260905-080140`; use that ledger entry for its actual evidence and state rather than treating this draft revision as a new completed run.

## Handoff and Content Factory context

The publishing or task owner receives the checked guide and evidence. [Article checklist review](https://local-service-spotlight.github.io/task-library/?task=verify-all-items-on-blog-posting-checklist#task-verify-all-items-on-blog-posting-checklist) and [Final rendered QA](https://local-service-spotlight.github.io/task-library/?task=step-17-final-formatting-and-qa-checks#task-step-17-final-formatting-and-qa-checks) can be components of this parent run; their links do not create separate completions.

Produce supplies the real source. **Process**, this stage of the [Content Factory](https://blitzmetrics.com/content-factory/), turns it into useful finished assets. Post saves or publishes them on the agreed channels. Promote tests and distributes suitable work within its own scope. The handoff above names this task’s actual next step; catalog neighbors alone are not prerequisites.

## When this runs

When a guide is missing, a scoped audit finds defects, or an actual run supports a correction. No automatic per-run source edit is required if the recipe already worked.

## First-run setup and continuity

Open the supplied task file and its linked source. Verify the project’s real inputs, account, access and output folder before work. This Markdown file is a guide; it does not install an app, connect an account, supply a subscription or create a schedule. Carry out work already authorized; do not ask for the same approval again. Keep any unsupplied destination or new action outside that scope clearly pending.

Save source IDs, versions, decisions, checked outputs and next owner in the project tracker. Before a retry, check the saved state and other workers’ changes. A model name does not guarantee memory or a running timer. Repeated work needs an actual configured trigger and durable state; one-off work can be started by the prompt above.

Keep agent media muted with volume zero before playback. If mute cannot be verified, use captions, metadata or still frames. State the limit: silent visual checks do not prove spoken-word accuracy or audio quality. Do not start sound through the user’s speakers unless explicitly asked.

## Write up the real run

For every actual attempt, [write its meta article](https://blitzmetrics.com/meta-article-prompt/) with this recipe and revision, trigger, steps performed, output evidence, measured result, gaps and next owner. Failed, blocked and partial attempts also get a written record. A draft can satisfy writing; publishing it follows the existing job scope.

Keep one stable execution ID across retries and edits. A separately scoped child task may have its own ID linked to its parent. Writing the parent’s meta record is part of that run, not an endless new chain. The [recipe and meta-article guide](https://localservicespotlight.com/meta-articles/) explains this distinction. Teaching examples are not real executions and must not enter the run count.


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

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

- **Phase:** Process
- **Importance:** 4/5 `●●●●○` — frequency 4, revenue 3, gating 2 (runs every factory cycle or weekly)
- **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:** Process-stage artifact examples include `transcript.md`, `gct.md`, `article.html` (or a staged draft), `clips/`, or `04-Promote-Creatives/`. These are examples, not requirements for every task. Follow this task's actual Inputs and Handoff sections for the required output, evidence, and next owner. Pass the files or records, not one vendor's memory.

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

- Canonical article: https://blitzmetrics.com/definitive-article-guide/
- Exact task: [Create or update a definitive task article](https://local-service-spotlight.github.io/task-library/?task=create-or-update-a-definitive-article#task-create-or-update-a-definitive-article)
- Writing standard: [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Entity linking: choose the right person, company or guide](https://blitzmetrics.com/entity-linking/)
- [SEO Tree: give a page its right topic home](https://blitzmetrics.com/seo-tree/)
- [Task Library execution schema and CLI](https://github.com/Local-Service-Spotlight/task-library/blob/main/EXECUTION-LEDGER.md)

## Review and evidence still needed

The source contributor status is preserved. It is not certification of this draft or proof of account access, completed work or a live outcome. The worked example teaches the method and is explicitly fictional.
- Real examples, independent semantic acceptance, access and live revision evidence remain required where absent.