---
name: document-a-task
description: Your team should be able to repeat good work without guessing.
category: Knowledge System Maintenance
stage: Process
definitive_article: https://blitzmetrics.com/how-to-document-a-task/
status: needs-work
---

# Document a task

Your team should be able to repeat good work without guessing. This guide turns one real job into clear steps and checks. Start while you do the work, so you can save the details that matter.

**The path:** Real task → Steps and proof → Fresh-reader check → Published guide

**Start when:** Real work reveals a task recipe that is missing or too unclear for someone else to follow.

## Inputs

- The actual task, starting state, required sources and authorized actions.
- Permission to retain screenshots or recordings, with private details excluded.
- A maintained guide if one exists, [current article guide](https://blitzmetrics.com/definitive-article-guide/), and [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

## Steps

1. Name the trigger, reader, useful result and boundary of the task in plain words. Search the Task Library and site for an existing recipe before creating a second guide.
2. As the real work proceeds, capture inputs, decisions, actions, expected results and failures. Keep exact source references and timestamps; a reconstructed success is not evidence.
3. Write ordered steps that another operator can follow. For each, state the input, action and observable result. Add current tool instructions beneath the method, with version/date where relevant.
4. Add real annotated screenshots or a truthful task diagram beside the grade 5 opening. Explain jargon on first use and link owned prerequisite guides. Preserve existing media and body content when editing.
5. Create completion checks for the saved result, not just the presence of headings. Include downstream task, receiving owner and how to handle a missing input or failed check.
6. Ask a fresh reviewer to follow the recipe with appropriate test inputs. Record ambiguous steps and actual proof; a desk review alone is not a completed client execution.
7. Prepare the readable page and matching skill through [the skill-publishing task](https://local-service-spotlight.github.io/task-library/?task=publish-skill-and-task-page#task-publish-skill-and-task-page). Preserve the owning format; a builder page must use its supported builder save, not an overwrite of generated HTML.

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

[Quality assurance (QA)](https://localservicespotlight.com/article-guidelines/) means checking the work against the agreed result.

- [ ] Trigger, inputs, exact steps, measurable output and downstream handoff are explicit.
- [ ] Real proof is relevant and private material stays protected; teaching examples are labeled.
- [ ] Source/page/skill agree after any authorized release and the fresh-reader review is recorded.

## Example(s)

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

A fictional editor documents a broken booking-link repair. The recipe begins with the old page URL, names the correct target source, shows the link edit and checks the anonymous page afterward. The example’s “saved” state is separate from its “public page works” check. This is a teaching outline, not evidence of a repaired site.

## Handoff and Content Factory context

The [Content Factory, our four stages of using real content](https://blitzmetrics.com/content-factory/) goes Produce → Process → Post → Promote. Capture the real work in Produce, turn it into a usable recipe in Process, then release and connect the approved guide in Post. The same recipe can support later work in any of the four stages.

[Publish the skill and task page](https://local-service-spotlight.github.io/task-library/?task=publish-skill-and-task-page#task-publish-skill-and-task-page) receives the guide, example, review findings and exact source revision.

## Run with an agent

Give the AI worker this recipe, the real Inputs above, the intended result and the actions already authorized. Ask it to return the saved output, checks, evidence and remaining owner. Check its work against this guide; loading a skill does not prove access, installation of a job, or successful execution. Keep media muted with volume at zero if playback is needed.

For recurring work, keep the actual trigger, owner and runtime in the job record. Scheduling and observed firings are separate. Do not create a schedule merely because this guide mentions a review interval.

## Record the real execution

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

Reuse the same execution ID for revisions, QA, meta writing and retries within that run. A blocked run stays open with its dependency and next owner; do not invent a finish time. Use supported findings to propose and verify a better recipe. A historical public-example count without distinct run IDs remains dated article volume, not verified execution frequency.


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

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

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

- [Maintained source guide](https://blitzmetrics.com/how-to-document-a-task/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=document-a-task#task-document-a-task)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [current article guide](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 `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not verify document readiness, a client outcome, access or an executed task.

A real execution still needs its own source, reviewer, saved result and handoff evidence. The fictional example teaches the method; a real example with relevant proof is still needed where required. The task-specific flow above is source guidance; its visible presentation and the full document need a named reviewer and desktop/mobile checks.