Memory and skills

Ask Buffaly to remember a fact when it is stable, reusable, safe to store, and likely to improve future routing or validation. Good examples are a preferred repo path, a customer contact, a project-specific review rule, a recurring environment detail, or a personal communication preference.

The expected storage path is ontology memory: Buffaly should search for an existing matching object, choose the correct personal or project placement, store or update a typed prototype, add semantic names so it is discoverable, and report what changed. It should not bury the fact in Scratch or append a broad instruction to the master prompt.

Use a prompt skill when the repeated work is mostly judgment, sequencing, review, writing, triage, or coordination. A prompt skill should describe the goal, evidence to inspect, decision rules, safety boundaries, validation, and output contract. It is better than copy-pasting the same checklist into every future prompt because Buffaly can discover it by intent.

A prompt skill is also a good staging step. If the workflow becomes stable and has clear inputs and outputs, ask Buffaly whether parts of it should be promoted into a ProtoScript action or a DLL-backed tool.

Create a ProtoScript action when Buffaly needs a typed, discoverable operation instead of general instructions. This is the right boundary when the user should be able to ask for one operation, Buffaly should bind parameters, and validation should prove the action can be found and called.

• Use an action phrase such as "to summarize a session handoff" or "to validate a docs route" so semantic action search can find it.
• Keep the action body thin: validate inputs, call the right service/tool, and return a clear result.
• Use prompt guidance for judgment and ProtoScript for stable callable operations. Many useful capabilities use both.

For authoring details, continue to Add a ProtoScript skill.

Use a C# DLL-backed tool when the capability needs compiled code: SDKs, authenticated clients, deterministic parsing, long-running logic, network calls, file-system operations, or strongly typed request/response contracts. Do not force these through prompt text or ad hoc shell commands when a native tool can express the operation safely.

Use a service when the domain has identity, lifecycle, configuration, state, or several related methods. A service may project selected methods as callable tools, but the service remains the owner of account boundaries, endpoints, settings, and shared behavior.

Memory should be stored at the narrowest scope that will be useful later.

• Personal memory is for your preferences, your local paths, your contacts, and your personal workflows.
• Project memory is for facts and workflows that belong to a repository, customer, website, deployment, or solution.
• System memory is for shared Buffaly concepts and capability definitions that should apply broadly across users or installations.

If you are unsure, ask Buffaly to explain the proposed scope before storing the memory. A local path that only works on your machine should not become global guidance for every user.

Appending every lesson to a global instruction makes the agent harder to audit and easier to confuse. Ontology memory keeps facts and objects queryable. Prompt skills keep procedures discoverable. ProtoScript actions keep operations callable. Secrets stay in secret storage. Current task evidence stays in Plan, Scratch, tasks, artifacts, and commits.

A useful request is: "Decide whether this belongs as ontology memory, a prompt skill, a ProtoScript action, a task artifact, or a secret. Explain the choice before storing anything."

Do not accept "I remembered it" or "I added a skill" without evidence. Ask Buffaly to prove the memory or capability can be found again.

1. For a fact, ask which ontology object or prototype was created or updated, what semantic names make it findable, and what scope it belongs to.
2. For a prompt skill, ask for the action phrase, prompt location, owning skill, and one representative discovery/execution test.
3. For a ProtoScript action, ask Buffaly to search candidate actions by meaning, load the action if needed, run a small example, and report the action prototype used.
4. For a service or DLL tool, ask for the service/tool owner, typed request and response shape, configured account or endpoint boundary, and one success/failure validation.

The normal discovery path uses candidate action search, candidate entity search, skill listing, skill-action listing, action loading, and loaded-tool inspection. See Tools and action loading.

Correct memory by finding the existing object first. Do not create a second conflicting memory unless the new fact truly represents a different scope or object.

For workflows, ask Buffaly to update the prompt skill or action that owns the procedure. For secrets, rotate or update the secret in the secret store; do not write the new value into memory. For obsolete memories, ask Buffaly to show where the object lives, explain the risk, and either update, supersede, or remove only the intended item.

Most users should not hand-edit ontology, prompt, or skill files. Ask Buffaly to choose the storage boundary, inspect existing memory and skills, use the correct authoring tools, validate discovery, and report exactly what changed.

• "Remember this as a project-scoped fact if it is stable; otherwise keep it in the task artifact."
• "Turn this repeated checklist into a prompt skill and verify that action discovery finds it."
• "Decide whether this should be a ProtoScript action, DLL tool, or service, then explain the validation plan before editing."
• "Update the outdated memory instead of creating a duplicate, and show how you verified the new one is discoverable."