What you will learn This is a chapter for doing, not reading. We build one.
Pick a request you keep repeating. Candidates look like this:
In this chapter we build "meeting-notes organiser" as the example.
Press Create at the top right of the agents screen and choose Sub-agent.
| Item | Example | Tip |
|---|---|---|
| Name | notes-organiser | invoked as @notes-organiser. Keep it short |
| Description | "Turns meeting notes into an action item table" | one line a teammate can judge from |
Do write the description. As "no description" entries pile up in the list, teammates stop knowing what to use.
Write the four parts of a good instruction directly.
| Part | Corresponding element |
|---|---|
| Role | goal |
| Rules | scope (what not to do) |
| Format specification | done condition |
| After the table | additional output |
All four lines under "Rules" are things not to do. Exactly as writing scope as what not to do is effective said.
Leave it private at first. Use it a few times, refine it, then publish.
Invoke it in a conversation like this:
When it does not come out as you want, edit the instructions. Correcting it each time in conversation does not carry forward; editing the instructions does.
| Symptom | Add to the instructions |
|---|---|
| The table is too long | "at most 10 rows per meeting" |
| The tone is stiff | "informal internal document tone" |
| It misses something important | "always include budget and headcount items" |
| The format varies | put an example in |
The last is especially effective. One example is more precise than ten lines of explanation.
When you are satisfied, switch it to public. Now the whole team can use
@notes-organiser.
| Trait | Why |
|---|---|
| It does one thing | doing several makes the instructions vague |
| It states what not to do | the scope is clear |
| The format is fixed | results are consistent |
| The description tells you when to use it | teammates actually use it |
A do-everything agent that "organises documents and writes emails and translates" does not work well. Build one per job.
Writing only "organise the meeting notes" is no different from an ordinary conversation. The rules and format are what make building an agent worthwhile.
Publish it without telling the team and nobody knows.
1. What should the "Rules" section contain to be effective?
What not to do. Listing everything to do is hard, the things that must not be done are few, and it clarifies the scope.
2. Where do you fix it when the results are not what you want?
The instructions themselves. Correcting it in conversation only fixes that instance; editing the instructions carries forward.
3. Why keep it private at first?
To use it a few times and refine it. Publish it under-refined and teammates try it, are disappointed, and never come back.
Now attach external tools → Connecting an MCP server
HyperTeams□ you produce the same kind of document every time□ you review material against the same criteria□ you often write emails in the same tone□ you organise data the same way[Role]You organise meeting notes into an action item table.[What you do]When the user gives you meeting notes, produce a table in this form:| Topic | Decision | Owner | Deadline |[Rules]- Include only decisions. Exclude anything still under discussion.- If no owner is named, leave "TBD" and do not assign one.- If no deadline is given, leave "TBD".- Do not guess at anything not present in the source.- Keep each cell to one short line.[After the table]Below the table, list "needs confirmation" items separately:- items where the owner or deadline is TBD- items where it is unclear whether it was a decision or a discussion@notes-organiser(paste the meeting notes)□ did items still under discussion stay out of the table□ did it avoid filling in TBD items□ did "needs confirmation" come out correctly□ recheck the description (is it a sentence a teammate can judge from)□ tell the team (built and unannounced means nobody knows)□ share one example of when to use it