How the System Learns

The library

Keep one maintained recipe per repeatable task. Link an agent-readable skill and examples of actual executions to it. The recipe says when to begin, what to bring, what to do, how to test the result and where to hand it off.

The public lesson from an execution can teach others, while the private record preserves restricted operational detail. Neither becomes a competing recipe. A failed or partial run still deserves a truthful record.

Organize examples around the method they demonstrate. A useful library is navigable by the work someone needs to do, not just a long list of files. Count the current artifacts from the source rather than copying historical totals into an introduction.

Five documents with different jobs

Keep the method stable while recording what happened this time. Promote only supported improvements after review. A private mistake can yield a public lesson without publishing the recipient, relationship or incident record.

Read, do, check, save. The next session should have a starting point rather than repeat the discovery. A beginner can keep these functions in clearly labeled sections of one saved file, splitting them when different audiences or lifecycles make that necessary.

Inside a skill file

A skill describes how to perform a task; a plugin may distribute skills and tools; an agent combines a role, model, context, tools, authority and acceptance test; a schedule determines when it runs. A receipt records what happened.

A usable skill contains:

• Name and description with phrases that match the task people ask for
• Trigger, starting state, inputs, required access and prerequisites
• Ordered steps, decision points, stop rules and escalation conditions
• Expected artifact, measurable acceptance test and downstream handoff
• Examples, source revision and supported lessons
• Applicable shared rules, generated or linked through a verified distribution process

Fictional, platform-neutral recipe template:

Name: summarize-training-notes
When: authorized notes need a short summary
Inputs: notes, audience, length, definition of done
Allowed: read supplied notes and draft locally
Not allowed: send, publish or invent missing facts
Steps: read; summarize; check each claim; label unknowns
Output: summary, source references, uncertainties
Verify: every factual claim matches the supplied notes
Handoff: requester reviews the draft

Confirm the host's actual skill format before installation. A link pasted into a chat does not itself install a skill. Test activation in a fresh task and retain the result. Set a revision budget and stop when the acceptance criteria are met; endless polishing can consume the budget needed for verification.

How a rule reaches a worker

A rule needs one versioned source, an owner, provenance, scope and an observable violation. From it, generate or maintain the instruction, checklist and machine check without creating competing definitions.

The chain is source → generated copies → package → distribution → installation → activation → observed use. Verify each link. Merging the source does not update every old install, and a passing source check does not prove runtime obedience.

Test the check with a deliberately invalid sample and a valid one. If it cannot fail on a known violation, a green result has little value. Judgment-only rules should say so instead of claiming automatic enforcement.

When a run teaches a new rule, preserve the originating evidence and propose the smallest supported correction. Review it before adoption. A lesson, a draft standard and an adopted instruction are different states.

Tuning and improving

Run the recipe; save the result and failure evidence; propose a correction; review it; update the canonical skill; rebuild applicable packages; verify distribution and the next activation.

Tune against a stable business outcome and the acceptance test, not activity counts alone. Track accepted results, repeated defects, rework and total cost. The age of unreviewed lessons can reveal a stalled improvement loop, but use a cadence the team has actually adopted.

A lesson record needs an ID, date, source revision, observed defect, evidence, proposed correction and disposition. Apply it once so a repeated harvest cannot duplicate the same paragraph. Rebuild derived files from source rather than hand-edit every copy.

Keep unsuccessful and uncertain results visible. A partial runtime rollout remains partial even when the public package looks current. The run record should end the job, not start an endless chain of records about records.