Publish a Skill and Its Task Page

Publish one clear task guide that your team can find and use. Keep its web page, skill file, and library entry in sync so no one follows old steps. Start with a checked task recipe, then use this guide to publish and check its copies.

The file and page stay connected through the same published entry.

This guide is part of the definitive article guide. Next, explore Canonical Skill Rule, or LSS Everything: AI Skills for Busy Business Owners.

Where this task fits in the Content Factory

This task belongs in Post. Its inputs come from the linked work below; its checked result becomes the next worker’s starting point.

1. ProduceCapture real work

2. ProcessTurn sources into useful assets

THIS TASK3. PostPublish and connect approved assets

4. PromoteShare proven work and measure results

Follow the numbered stages from Produce to Promote. Each stage links to its part of the Content Factory guide.

Start, finish, and next step

Start when

A reviewed task method needs a maintained skill and matching readable page.

Have ready

Canonical skill source and permanent name
Real example and task requirements
Correct publishing site and authorized editor
The existing task registration and canonical source

How to Document a Task

Follow the steps

Search for the existing canonical page
Prepare the runnable file and human-readable task page
Include setup, rules, example and QA
Update the matching registry entry
Create the reviewable draft and publish through the authorized rail

Use the detailed instructions in this article for each step.

Finish with

A matched runnable skill, canonical human-readable page and registry record.

Measure the result

The file, page and registry refer to the same skill
The complete runnable instructions are available
The real run links back to the task
Draft and published state are reported separately

Hand off next

Return the saved draft or authorized public URL and connect the execution meta article (a record of one task run) to this task.

Before closing the run, name the actual next task, receiving owner, and trigger in the execution record. The assignment and findings determine that handoff.

Reference material for the inputs

Open this article’s tasks in the Task Library (our directory of tasks and recipes; see current Task Library). The library connects the current recipe, its smaller tasks, and the records of work performed.

Close the learning loop. Write a meta article: the record of this execution with the starting state, recipe version, result, checks, failures, and next owner. Link it back to this recipe and register the run under the same Task Library task. Reuse one execution ID for revisions and retries. A partial or failed run stays labeled that way. Public release follows the recorded publication authority; writing the run record is part of doing the task. Writing and revising that record belong to the original execution; they do not start another meta-article task. Use the findings to propose and verify a recipe improvement. See how recipes and execution records work together.

Task Library › Create a checked task recipe › Publish its skill and page

Publish one source in three places

A skill file can be shared, but your team also needs a clear page that explains when and how to use it. Publish and check both as part of the same release.

Why it exists

A 2026 audit found skill pack pages that linked to nothing — pages that existed but pointed nowhere, and skills that ran fine but had no public home. The audit describes the same defect: the artifact and its documentation drifted apart.

Use the checks below for each release: a skill is not done until it has a page.

The three artifacts

A completed public release has all three. Keep draft or pending items labeled until they are published and checked:

The canonical skill source — the exact maintained instruction file and its matching download. Repositories may use skills/<skill-name>/SKILL.md or the Task Library’s category-and-file layout. A downloaded file is a delivery; installed and tested require separate receipts.
The task article — the main human-readable recipe, with the complete skill file between START and END markers. A published page earns the definitive label only after its checks pass.
The task registration and state receipt — map the canonical recipe to its durable task slug in the Task Library. Record the canonical skill source and the state actually verified: available, installed, enabled, tested, scheduled, or observed. Add an agent or job record only when that worker or job really exists and is authorized.

If any of the three is missing, the public release is incomplete. You may still save a draft and record the next required step.

The definitive-article pattern

Every task recipe states who it serves, why and when to run it, required inputs, ordered steps, observable results, and the next task. Include a real source-backed execution and the canonical skill reference. A task is the work and a skill is its method; a separately configured agent or job gets its own record only when it actually exists.

Search the site before writing. The earlier RACI guide to clear roles explains who does the work and who owns the result. The project lead onboarding guide applies that ownership to a project. Build on the maintained guide instead of publishing a competing explanation.

Where it goes

Skill scope	Site
Company-wide method, project management, Content Factory (our four-stage process for using real content)	blitzmetrics.com
Local service business delivery	localservicespotlight.com
Trade-specific vertical	the matching Spotlight site

How to publish through the site’s maintained route

Use the publishing connection already maintained for the site. For LSS pages hosted at blitzmetrics.com, a configured WordPress REST connection can read and save the editable source. An authorized browser editor is another supported path. One tool’s blocked request does not mean the page is broken or that every agent needs a new browser login.

Read the current editable page and record its revision. Keep its URL, page type, title, media, useful styles and other people’s changes.
Prepare the full change and review the opening, steps, links, visual and matching skill file.
Apply the publication authority already given for this work. If public release is not authorized, save a draft and name the exact approval needed. Existing approval does not need to be requested again.
Save through the supported route, then read back the exact saved source. Confirm that the intended fields changed and the others stayed intact.
Open the ordinary public URL on phone and desktop. Check the page, download and links. A saved draft, merge or successful build alone does not prove the public copy is current.

Check the Task Library connection

The Task Library helps people find the recipe and its work records. Its contributor guide explains how the source sheet and repository connect. A row in the sheet reaches the dashboard only when that build imports the intended tracker data.

Keep the permanent task name and map it to the reviewed skill and article. Use the existing task row; do not create another registry.
Before relying on a sheet update, check the dashboard’s team-update notice and the build’s tracker-import receipt. If the feed is missing, the page may still use saved library records. Mark the sheet change as saved and the public sync as pending.
Have the library maintainer verify the existing approved tracker connection and intended tab. Do not publish a private sheet, add account access or create a new credential just to make a check pass.
After import and deployment, open this task’s public entry. Compare its owner, status, source, article and download with the intended values. A loaded feed is not proof that every field or task passed.

Record the checked result and remaining owner in a work record. Installing a skill or scheduling an agent is a separate task with its own checks.

A real publishing repair

On September 25, 2026, the publishing instructions were corrected to explain that a saved tracker row may not reach the public library. The dated review and its checks records the repaired instructions and public readback. The merged library change shows the exact source edit. The linked work record and remaining gaps keeps the attempt labeled partial: the tracker feed, upkeep owner and first-user proof were still missing.

Use that example to separate a published repair from a completed setup. It is evidence of what was checked, not a claim that someone installed the pack or completed every task.

The full skill file

This task’s maintained file is Publish a skill and its task page in the Local Service Spotlight Task Library repository. The permanent task name is publish-skill-and-task-page. The copy below matches that file; update and check both in the same release.

START

---
name: publish-skill-and-task-page
description: A useful guide should be easy for people and AI to find.
category: Knowledge System Maintenance
stage: Post
definitive_article: https://blitzmetrics.com/skill-publishing-standard/
status: complete
---

# Publish a skill and its task page

Publish one clear task guide that your team can find and use. Keep its web page, skill file, and library entry in sync so no one follows old steps. Start with a [checked task recipe](https://blitzmetrics.com/definitive-article-guide/), then use this guide to publish and check its copies.

**The path:** Checked recipe → Matched files → Authorized release → Live readback

**Start when:** A reviewed task method needs a maintained skill and matching readable page.

## Inputs

- [The documented task](https://local-service-spotlight.github.io/task-library/?task=document-a-task#task-document-a-task) with its trigger, inputs, ordered steps, checks and handoff.
- The canonical source repository, permanent task name, existing page and correct registry.
- A real relevant example or an explicit example gap, plus publishing authority and supported editor access.

## Steps

1. Search the site and Task Library for the existing task. Preserve its URL, name and page type; a rename needs a migration plan for links and installed references.
2. Prepare a complete skill file and human-readable page from the same reviewed method. Include plain grade 5 context, meaningful lead visual, owned prerequisite links, example and lower task context.
3. Keep task registration separate from AI-worker and job registration. Update the actual task/skill entry; do not create an Agent Roster row merely because a new skill exists. Follow the [contributor guide](https://github.com/Local-Service-Spotlight/task-library/blob/main/CONTRIBUTING-SKILLS.md). A sheet row reaches the dashboard only when the intended tracker feed is imported. Check the team-update notice and build receipt; when missing, report the row saved and public sync pending. The maintainer checks the existing approved connection without silently changing sharing or access.
4. Link the exact maintained source file and permanent task name on the page. If the page includes a copy of the skill, compare its full decoded text with the source file before release. Check exact source-file, page and registry links in both directions. The downloadable instructions must match the reviewed revision; a short summary wrapper is not the full recipe.
5. Use the repository’s branch/review/check workflow and the page’s supported editor or generator. Preserve existing media, builder state, categories and concurrent edits. Keep the full reviewable draft before publication.
6. After the authorized release, read back the saved source and open the ordinary anonymous URL on desktop/mobile. Inspect the lead visual, links, task context and download; clear or fix stale public copies through their owning publisher. Compare the deployed task’s owner, status, source, article and download with the intended values. A successful build or loaded feed alone does not prove these fields match.
7. Record source available, page public, file downloadable and installed activation separately. Leave certification gaps visible; writing the run’s meta record is required even when public release is pending.

## Definition of done (QA checklist)

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

- [ ] Page, full skill and registry refer to the same canonical task/revision.
- [ ] All released destinations are read back and the rendered guide is usable.
- [ ] Tracker import state and the deployed task fields are checked; missing sync remains pending.
- [ ] Missing real examples, private access or installed activation remain explicit.

## Example(s)

**Recorded partial publishing run, September 25, 2026.** The [tracker setup review](https://github.com/Local-Service-Spotlight/task-library/blob/main/reviews/tracker-setup-2026-09-25.md) documents the saved guide changes, public readback and missing tracker feed. The [merged repair](https://github.com/Local-Service-Spotlight/task-library/pull/39) and [work record](https://blitzmetrics.com/making-task-guides-easier-to-use/#tracker-setup-20260925-000216) show what shipped and what stayed open. This proves a publishing repair and its limits; it does not prove a new user installed a skill or that the tracker feed was connected.

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

A fictional guide is merged and its page saved, but the public URL still serves yesterday’s download. Report source released and public copy stale. Fix the owning cache/publisher, then verify the same revision before calling the page current. No agent or recurring job is created by registering the skill.

## 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. The source method is prepared and checked in Process. Its authorized page release and links belong to Post. Promotion is a separate decision after the published result is checked.

The task owner receives the public/draft state and remaining gaps. Consumers use the exact guide; any installed-package update needs its own activation check.

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

## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/skill-publishing-standard/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=publish-skill-and-task-page#task-publish-skill-and-task-page)
- [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/)

## Evidence limits

Contributor status `complete` records that these written instructions have been completed and reviewed. It does not certify account access, novice setup, a successful client outcome, or every article standard. Keep the task's current verification gates visible in the library.

The September 25 example ended partial. Each new execution still needs its own starting recipe revision, saved output, independent result review and next handoff. Name any missing upkeep owner or tracker connection; do not infer either from a byline or a successful build.

END

For AI agents reading this page

Use the exact source file linked above and the permanent task name publish-skill-and-task-page. The legacy download name 061-skill-publishing-standard.skill.md refers to an older delivery; it is not the source for this library task. An available guide does not prove that a plugin is installed, an agent exists, or a job has run. Check the current task evidence before making those claims.

Originally published August 3, 2026.