Six skills, one meeting: how a real team runs on shared skills
The team behind shareskills runs its client work on the product. Here is the actual library — the meeting pipeline, the guardrails skill, and the patterns worth stealing.
The shareskills team
The team that builds shareskills also ships workforce-compliance software, with real customers, real implementation projects, and a real support queue. Our own skill library is where shareskills gets stress-tested. This post walks through what is actually in it — client details removed — because the patterns transfer to almost any team working with AI agents.
The meeting that runs itself
The heaviest cluster in our library is six small skills wrapped around one recurring event: the weekly implementation meeting with a large retail client rolling out our software. None of them is clever on its own. Together they absorb what used to be a day of project-management admin every week:
- Pre-meeting trawl — combs the client’s inbound email, their project tickets, and their service-desk reports since the last meeting, de-duplicates the same issue appearing in all three, and walks the PM through the findings interview-style.
- Agenda builder — turns the previous meeting’s minutes into a blocker-focused agenda for the next one, published as a restricted draft in the client’s docs space with reviewers tagged.
- Minutes generator — takes the raw transcript and produces customer-facing minutes with an actions table, updates the decisions register, and drafts internal feedback separately.
- Ticket reconciler — matches each action item to an existing ticket or proposes a new one, and writes nothing until the human approves the plan.
- Release-gated email — checks reviewer sign-off, strips the draft banner, exports the PDF, and prepares the cover email as a draft. It never sends; a human does.
- Stale-action chaser — the weekly check-in that sorts open tickets into needs-action, parked, and moving, and only ever chases our own team’s items, never the client’s.
Two things make this work. Each skill has exactly one job, so each one stays small enough to trust and to fix. And the client specifics live in a config file, so the same six skills point at the next implementation project by changing a handful of values — the pipeline is the asset, not the project.
The most-installed skill is a rulebook
The single most-installed skill in our org contains no automation at all. It is the guardrails skill: how to operate safely across our email, ticketing, chat and support tools — what agents must never delete, how to avoid duplicate records, when to stop and ask. Every person on the team installs it, so every agent session starts already knowing the house rules.
This is the pattern we would push hardest on a new team: write the rulebook skill first. Norms you encode once and distribute beat norms you repeat in every prompt.
Agents type, humans pull the trigger
Read back through the pipeline and notice how many times it stops: the reconciler proposes ticket changes and waits; the email skill produces a draft and never sends; the release gate checks that a named reviewer actually signed off before anything faces the customer. That is not timidity — it is what makes the automation adoptable. People let agents into their client work when the irreversible step is visibly still theirs.
We built the same philosophy into shareskills itself this month — directory skill updates that add risky behaviour now wait for explicit human approval. The pattern scales from one team’s meeting minutes to the supply chain.
Routines on a schedule
A second cluster runs on timers rather than triggers: daily content research that drafts social posts in the company voice, a weekly SEO and site-health report that files one prioritised task, and a weekly marketing roll-up across analytics sources. The human stays in the loop through the documents themselves — one skill only generates artwork for posts a named person has approved in comments. The agent reads the approval state; it does not assume it.
The unglamorous wins
The rest of the library is deeply unsexy and used constantly: a QA brief that summarises a ticket’s year of back-and-forth before an engineer touches it, a feedback-page formatter, a branded-documents kit whose entire job is making generated documents look designed rather than generated, and an onboarding scaffolder that sets up the project plan for a new customer. Nobody demos these. Everybody uses them.
If your team is starting from zero
- Start from a recurring ritual, not a moonshot — a weekly meeting, a report, a review. Recurrence is where skill-shaped work lives.
- One job per skill. Chain small skills into pipelines instead of growing one skill into a monolith.
- Write the guardrails skill first, and make installing it part of joining the team.
- Put the irreversible step behind a human: drafts over sends, plans over writes.
- Let teammates propose changes — members suggest, maintainers approve, versions keep the history honest.
- When a skill stops being about your company, strip the specifics and publish it to the directory. Our git-hygiene report started as an internal tool; it is public now.
None of this required a platform team or a prompt-engineering guild. It required noticing which work repeats, writing the playbook down once, and putting it somewhere the whole team — and the whole team’s agents — stay in sync with.