For creators
Package an operator’s real decision rules
Replace expert-sounding prose with a workflow that can explain why it chose an answer.
Quick answer
Structure the instructions around inputs, decision rules, output fields, and stopping conditions. Write down the judgments you normally make silently. Then test whether someone else’s AI can apply those judgments to an ordinary case and a difficult case without inventing missing facts or taking actions you never authorized.
Begin with an inspectable handoff
Imagine a fictional support lead who reviews replies before they are sent. Their expertise includes spotting an unsupported refund promise, noticing missing order facts, and preserving a helpful tone. “Act like an experienced support lead” does not capture those decisions. A better scope is a reply draft plus a short list of unresolved policy questions.
Write the output fields first: customer request, relevant supplied policy, proposed reply, and questions that prevent sending. This makes omissions visible. It also prevents a polished paragraph from concealing that the AI never received the policy needed to support its answer.
Turn each judgment into a conditional rule
Give every rule a trigger and a consequence. If the order date is missing, ask for it before assessing a time-limited policy. If two supplied policies disagree, quote the conflict and ask which applies. If the requested remedy is absent from the policy, present it as an unresolved request rather than an approved entitlement.
Decide which missing inputs block progress. Tone preferences may allow a clearly stated default; eligibility facts usually do not. Keep the difference explicit so the AI does not treat all omissions as permission to guess.
If a proposed reply promises a remedy:
1. Identify the supplied policy supporting it.
2. If no policy supports it, remove the promise.
3. Ask the user to resolve the missing authorization.
Return a draft only; do not send it.Use frontmatter to identify the job
The Agent Skills specification separates YAML frontmatter from the Markdown body and requires name and description metadata. Use the description to identify when the workflow is relevant; put the actual decision procedure in the body. A good label helps discovery, but it cannot replace the method.
Test the contract with contrasting cases
Paste the complete instruction text into Skillset’s creator editor. Do not refer to a local attachment that this delivery does not include. Name any external tool dependency and give a supplied-text alternative when the job permits one.
Try three fictional tickets: a normal request with complete evidence, a missing order date, and conflicting policy excerpts. Keep the expected decision next to each input. Check the reply and the unresolved questions, not just whether the prose sounds professional. If the missing-date case still produces a confident eligibility answer, revise the rule before submission.
Common questions
Should examples contain real customer tickets?
Use fictional or properly sanitized examples. Preserve the difficult decision while removing personal details and secrets that are not necessary to teach it.
Can headings alone make a workflow reliable?
No. Headings organize the text. The useful content is the rule that changes a decision and the evidence needed to apply it.
What belongs in the public description?
State the job, inputs, output, and dependencies clearly. Keep the description aligned with the reviewed workflow rather than promising an imagined future version.
Put a workflow to work.
Connect your library to your AI, or turn your method into a skill.