Prompting and skills

Prompts and skills¶

You are here: Prompts and skills · Builder
Next: Creative toolkits

Put stable procedure in a skill, facts in a file, and secrets in a store the prompt cannot casually reprint.

Why it matters. A procedure that lives only in a long prompt is hard to review, and the model skims it. The Builder guide loads one SKILL.md into a working agent and leaves today's job in the message. This page is how to split the rest: system prompt, skill, task, and context.


Path	Builder
Time	About 15 minutes
You need	Memory, tools, and planning

What you will be able to do¶

Name the four layers of instruction an agent is actually following.
Decide what belongs in a skill instead of a longer system prompt.
Review a third-party skill before it runs.

Four layers¶

Layer	Changes	Holds	Example
System prompt	Rarely	Role, safety rules, definition of done	"You maintain a wiki. Cite sources. Mark per-post claims."
Skill	When the job type changes	Steps, checks, formats for one kind of work	"To cite a source, follow this checklist."
Task	Every run	The goal for this run	"Update the gateway page from a new source."
Context	Every step	Files, tool results, the plan	The raw post, the current page

A single prompt that tries to be all four becomes a novel. The model then attends to the novel's adjectives and misses the checklist. The layers also have different reviewers. A system prompt is a policy. A skill is a procedure. A task is a ticket. Context is evidence.

Tip

Established. Instructions that must be true on every run belong above the task. Facts that change belong in files the agent reads, because editing a file is easier to review than editing a prompt from memory.

What a skill contains¶

A useful skill is short enough to read in one sitting:

When to use it, and when not to.
Inputs it expects (paths, URLs, a brief).
Steps, in order, each ending in something you can see.
Checks it runs on its own output.
Tools it is allowed to call.

The motion-design post is a catalog of skills aimed at one job: an agent writes the code, a skill sets timing and camera, an engine renders a video (@N01ennn, per post). The catalog itself is the creative toolkits page. The pattern is the point, and it travels: code from the model, constraints from the skill, an artifact from a real renderer.

Installing a skill is running code¶

A skill file is instructions. Many skill packs also tell the agent to execute setup commands or to import a repository. That is a supply-chain decision, the same family as installing a dependency.

The motion post says to check each repository before you install (per post). Take that sentence, and leave the rest of the hype. The checks are in gateways and supply chain and in the craft playbook.

Secrets and standing orders¶

A prompt is a poor vault. Anything the model can see, a tool result or a later page can echo. Put API keys in the environment or a local secret store, and let a tool use them without returning the secret in the observation. The OmniRoute post claims local encryption of keys (@Bober_smart, per post). Whether a given gateway does that is something you verify, not something you paste into a system prompt as a wish.

Check yourself¶

Which layer should hold "cite the URL," and which should hold today's source?
What five headings do you want on a skill before you trust it?
Why is "check the repo before you install" a security step and not only a taste step?

Sources¶

Established practice for separating standing instructions, procedures, tasks, and evidence.
@N01ennn — 2026-10-08. Skills plus an engine, and the advice to check repos, per post.
@Bober_smart — local key encryption, per post, unverified.

Continue¶

Map | Paths | Glossary | References