The Ambassador
The AI Skilling Ambassador program runs on people who volunteer for it - 72 of them across nine regions, doing office hours, mentoring, and writing the quickstarts everyone leans on, all on top of their real jobs. Nobody's paid, so the program keeps them with what it can offer back: an invitation in, a facilitation slot, a nomination. Last round five withdrew and seven were passed over, and the person who ran it left halfway through.
The Ambassador skill they left behind picks the next cohort. It reads DEFINITION.md, applies it to the candidates, and comes back with eight names, a reason for each, and what to offer them. It's fast and confident - and it can't show its work. Nine data files ship with it; the skill reads one, checks no claim against a record, gives no one a way to overrule it, and can't run again without someone kicking it off.
Objectives
Ship something that makes the pick trustworthy and gives it somewhere to run: it surfaces someone the shipped skill misses, backs every claim with evidence, keeps a person in the loop, and can run again on its own. How you meet that is yours - a table that ships one of these well beats a table that half-ships four.
By the end, you should have at least one of:
- Someone the skill misses - surfaced from the evidence it currently ignores.
- Every claim backed by a record - no assertion without a row behind it.
- A person who can overrule it - and a next run that remembers the correction.
- It runs again without you - on a schedule, on your machine.
Nothing gets sent
Invitations and nominations are drafted and held for a person to read. Keep that in whatever you build.
Setup
Check Scout is signed in. Ask it anything and confirm you get an answer back. Everything stays local - nothing is hosted and nothing leaves your machine.
The data is fictional. Invented people, invented scores, invented feedback. Nothing here describes a real person and no real program is being modeled.
1 · Download the skill and the data
What's in the skill:
ambassador/
SKILL.md the instructions Scout loads and follows
references/
DEFINITION.md what the program looks for. This is the file you edit
PLAYBOOK.md how the program describes itself
definitions/ three worked alternatives - reach, depth, risingTwo places to get unstuck
Ask Scout: it's building with you, so paste the error or describe what came back wrong. For mechanics like scheduling or running things locally, the Guides are short how-tos. Coaches are in the room and every table has an SME.
2 · Run it, and swap the definition
Done when: two definitions have given you two different shortlists.
- Unzip both downloads. Put the
program-datafolder somewhere you can point Scout at. - In Scout, open Extensions → Import and drag in the
ambassadorfolder. Import the folder, notSKILL.md:references/holds the definition and the playbook. - Start a new session. Skills load when a session begins.
Then ask it the question the program exists to answer - name the skill so Scout calls it:
Using the ambassador skill, who should be in the next cohort? The data is in [path to program-data].Eight names, a reason each, and what to offer them. Start each request with "using the ambassador skill" - that's the skill's name, and Scout may not call it otherwise. Now change what it's looking for:
Using the ambassador skill, use definitions/depth.md as the definition instead. Re-run and tell me which names changed.Then try definitions/rising.md. Same 72 people, and the shortlists barely overlap: depth.md and rising.md share two names out of eight, and each surfaces four people no other definition finds.
The definition is plain prose in a file. Open references/DEFINITION.md from the folder where your Scout skills are imported to (%USERPROFILE%/.scout/m-skills/ambassador), write what your program would look for, and re-run.
Build
Done when: one condition is met, on real output, with a name on screen.
🎈 This is the fun part - keep it low-stress
Pick whatever direction sounds good and build it with your table. It doesn't have to be perfect, and it doesn't have to solve everything - the whole point is to explore your tool, trade ideas, and vibe-code something together. Use whatever you came here to learn, see how far you get, and have fun with it. You're here to learn by doing.
The program already ships everything you need to judge these people: nine files, 72 candidates, ~2,000 evidence records - what they ran, the feedback they got, what they've shipped. You don't build the data; it's here. What the skill doesn't do is use most of it - it reads one file and ignores eight. Scout can reach a lot to change that: it reads and writes files, runs on a schedule, and drives the CLI and git on your machine. So the builds below come in two shapes: leverage the skill as it is to make something new from its picks - a local board, a scheduled scan - or build onto the skill so it reads more, remembers what it decided, or holds a call for a human every run. Work one change at a time; throw everything at it at once and you won't know what moved the shortlist.
Pick a direction
Pick one or two and spend the session building. Take one as-is, combine two, or bring your own. Click a bubble for where to start and a prompt to open with.
Pick by what your table would actually use, not by what sounds most impressive - then spend the time making it real.
Build in layers
Get one real name on screen end to end before you add anything:
- The smallest version - "Build the smallest version that runs end to end. Start simple."
- The evidence - "Now make every line carry the record behind it, and say which files you read."
- One addition - "That works. Now add [one thing]."
- A bound - "Cap this at [N] people per run and say what was left out."
After today
This is a starting point, not the finish line. In one session, alongside a table doing the same thing, you took a fast, opaque pick and made a piece of it trustworthy - and gave it somewhere to run. You practiced the real skill: describing what you want, watching Scout build it, and correcting from there.