Build the standing brief for an assistant you reuse.
The durable instructions for a Claude Project, custom GPT, or agent: who it is, what it knows, how it behaves, what it must never do.
Inside: The identity / knowledge / behavior / guardrails brief for a reusable assistant.
Install it in one line, or paste it in.
~/.claude/skills/ and runs automatically when it is relevant.Connect your context. Set it to your motion.
| Set this | What it is | Example |
|---|---|---|
| The assistant's job | The one thing it exists to do | "Draft first-pass support replies" |
| Reference material | Docs or facts it should always have | Your product docsyour tone guide |
| Hard rules | The lines it must never cross | "Never promise a refund. Escalate instead." |
Everything the skill does, in full.
Builds the standing instructions for an AI assistant you will reuse: a Claude Project, a custom GPT, or an agent. Not a one-off prompt. The durable brief that defines who the assistant is, what it knows, how it behaves, and what it must never do, so every conversation starts aligned.
- 11. Define the role in one paragraph: who the assistant is and the single job it owns.
- Set the knowledge: what it should treat as ground truth, and what to do when it does not know.
- Set the behavior: tone, format, how long answers run, when to ask versus when to act.
- Set the boundaries: the hard rules, the things it must never do, what to escalate.
- Give a worked example: one ideal exchange, input and output, so the model has a target.
- Add the refusal line: how it declines gracefully when a request is out of scope.
You are a first-pass support assistant for a B2B software product. You draft replies for a human to review and send. You do not send anything yourself. Knowledge: treat the linked product docs as ground truth. If an answer is not in the docs, say "I am not certain, a human should confirm" and draft your best guess clearly labeled as unconfirmed. Behavior: warm, plain, under 120 words. Lead with the answer, then the steps. Never open with "Great question." Ask a clarifying question only if the issue is genuinely ambiguous. Boundaries: never promise a refund, a timeline, or a feature. For anything involving money or a complaint, draft an escalation note to the human instead. Example: User: "The export button is greyed out." You: "That usually means the report is still generating. Give it about a minute, then refresh. If it is still greyed out, tell me your plan tier and I will check the export limits."
Where an operator takes this next.
The prompt is written. Here is where an operator takes it once the manual version proves out.
The prompt sets who it is once; the connections keep it accurate after that.
Point the knowledge section at a live doc (Notion) instead of pasted text, so ground truth updates without touching the prompt.
Run the finished prompt through a small eval, a dozen realistic requests, and check it holds the boundaries before the team starts relying on it.
Wire the refusal line to open a Slack thread with a human instead of just declining, so an out-of-scope request does not dead-end.
One skill is the on-ramp.
A single skill does one job. Chained into a playbook, or run as a full build, it becomes a system. Here is where this one plugs in.