Skills and Library

Recipes and execution records

A definitive article is the maintained method. A skill expresses the same operational sequence for an agent. A meta article documents one real execution in a public-safe form. The private run note and live packet carry restricted evidence and state.

A complete recipe contains the trigger and starting state, required inputs and access, prerequisite tasks, ordered steps and decision points, measurable output and pass/fail criteria, and the downstream owner and artifact. An example must be real and verified or explicitly fictional.

The source method labels example depth: no verified examples, Emerging for 1–2, Supported for 3–5, Strong for 6–10, and Deep for 11 or more. These are library evidence bands, not guarantees of quality. Count the actual qualifying examples and preserve their evidence.

A run record links the task and recipe revision, execution ID, trigger, date, inputs, steps and deviations, output, results, lessons and next owner. Failed and partial runs remain useful evidence. Review improvements before merging them into the recipe; the run story never becomes another master.

Skill anatomy and maintenance

Use the host's supported format. Typical front matter identifies the skill name, a description matching real request language, and applicable scope. The body supplies inputs, steps, decision points, failure modes, outputs, verification and related methods.

Keep source rules versioned and distinguish generated blocks from hand-authored recipe text. A stable skill name can be an identifier used by installs, bundles and scheduled jobs. Renaming it requires a migration plan, not only an editorial change.

Test a fresh task with a realistic request to confirm activation and behavior. A skill listed in an index is only available; it may not be installed, enabled or tested in this account. If learned-in-the-field notes are harvested automatically, use unique IDs and verify the operation is idempotent.

Set a useful finish line: acceptance criteria and a revision allowance. Spend the remaining effort on checking the result rather than indefinite stylistic changes after the task already passes.

One source and its derived copies

A controlled publication path is source branch, reviewable change, validation, authorized merge, package generation, distribution, installation, activation and observed run. Preserve the exact source revision across the chain.

Generate shared-rule copies and counts from the master when possible. Test drift detection and do not hand-edit generated outputs. A package filename or modification date is weaker release identity than a pinned source revision and a file hash.

Changing a rule requires more than editing an article. Identify the affected skills, bundles, instructions and schedules, then verify what actually updated. Prior installs can remain stale. A declaration that everything is distributed cannot replace a consumer-level activation check.

Five systems seven steps seven states

The source registry distinguishes five places to audit: the canonical skill source, installed plugins and account skills, cloud scheduled tasks, local scheduled jobs, and fleet copies with run receipts. A source check proves availability there; it does not prove an account installed it.

The seven-step intake is: valid skill metadata; placement in the canonical source; inclusion in the appropriate bundles; repository and marketplace validation; fresh-task activation; first scheduled activation if scheduling is part of the task; accurate state recording. Skip no relevant acceptance evidence by calling a saved file shipped.

Capability states: Available → Delivered → Installed → Enabled → Tested → Scheduled → Observed. Preserve these terms separately from packet states and use only states supported by evidence.

Scheduled-run observations: Scheduled, Attempted, Observed success, Observed failure, Missing run. When now is later than the next expected run plus its grace period and no receipt exists, report a missing run.

The publisher proposes, the executor installs the approved revision, the auditor checks source and receipts independently, and the human owner supplies decisions reserved for a person. Keep one deployment owner; do not start another deployment because a lock or unanswered thread is inconvenient.