Outline — Using skills to pay the bills

Speaker

James Moss, Member of Technical Staff at Tessl. Software engineer working on Tessl's registry product. 20+ years across the stack, last decade mostly frontend. "A developer since uploading his first GeoCities site in 1999."

Introduced by an unnamed MC (a Tessl colleague) who jokes: "a software engineer with a priority complex. Just kidding."

Abstract (as provided by the user)

We started where most developers start: one person, one agent, tinkering at the desk and getting things done faster than before. Skills are everywhere right now and the clever ones do genuinely impressive things. For solo work, that's usually enough.

It's a different story when you try to work as a team with the same approach, and it's not something people talk about much yet. Your codebase now has a new layer: skills, context files, agent instructions. The stuff that tells your AI coding agent how to behave. It lives alongside your code but gets none of the same treatment. No versioning, no review, no shared source of truth. Everyone's agent is doing something slightly different and nobody knows why.

We'll share what we learned the hard way: what broke, what we borrowed from how we already manage code, and what it actually takes to make your agent context something your whole team can build on top of.

Thesis (synthesis)

Solo AI-skill workflows don't survive contact with a team. Skills authored carelessly produce "sprawl" with five recognisable failure modes. The fix is to treat skills as software using the same disciplines the industry painfully developed for code over 10+ years (registries, semver, CI, security scanning, package managers, no global state) — and not re-learn those lessons. Context is the most controllable lever in the "agent = model + harness + context" equation, so investing in context hygiene has outsized impact.

Section TOC

• Intro & framing (transcript lines ~1–25) — MC introduction, Moss's bio, joke about "get rich quick scheme."
• The three-part plan (~25–35) — skills sprawl; skills as software; context development life cycle.
• Skills sprawl: definition (~35–60) — low barrier to entry, Cambrian explosion, 2M+ skills across 44k GitHub repos, customer quotes ("wild west", "free form").
• The five failure modes (~60–95) — overlap, drift (Matt Pocock's "Grill me" → "Grill with Docs" example), activation/lack of activation, rot, overloading (description-truncation problem).
• Tessl's sprawl-detection product (~95–110) — private beta; scans GitHub orgs; surfaces token usage, third-party reviews, security scans from Tessl's registry.
• The agentic equation (~115–125) — agent = f(model, harness, context); context is the best lever.
• Skills-as-software practices (~125–210):
  • Decompose; don't write monolithic skills; use plugins; example of Tessl's Figma → UI skill chain.
  • Extend, don't edit vendored third-party skills.
  • Single responsibility principle (CS 101 callback).
  • Avoid global skills — "works on my machine"; Boris Cherny / Claude Code quote about banning local setup.
  • Automated skill reviews — lint-like + LLM-as-judge; example showing a skill scored 20%.
  • Publish to a registry — single source of truth, governance, security (Snyk integration), minimum release age (the "mini sha loot tack" / Shai-Hulud-style attack with persistent Claude Code hook), non-tech-user GitHub-seat cost problem.
  • Don't lock skills to one agent — screenshot of many .agent-* folders; agents change every six months, skills are the durable asset.
  • Make context a team asset — DRY, shared ownership, safe to contribute.
  • Measure with evals — Adam Savage "the difference between screwing around and science is writing it down" quote; mockery of inflated Reddit/LinkedIn claims (60–80% token reduction, 65→94% coding accuracy, "kills 90% of production bugs").
• The Context Development Life Cycle (CDLC) (~210–230) — every code-hygiene practice has a context equivalent.
• 2005 PHP story (~230–260) — pre-Composer, pre-semver, SourceForge zips, FTP-to-production. Took the industry ~10 years to invent package managers, CI, registries. Skills are repeating these mistakes; we don't have to spend another 10 years.
• Q&A (~260–end) — four questions: (1) bundle skills into plugins or keep separate? (2) sharing skills with non-technical colleagues (e.g. Jira/backstage users); (3) opinion on a package manager ("AKM"?); (4) expressing dependencies between skills across packages.
• Wrap-up — MC closes, points to Tessl booth.

Terminology glossary (definitions Moss actually gave)

• Skills sprawl — skills "spread across lots of different locations… GitHub… marketplaces and also on developers local machines." Hard to track, measure, or improve.
• Overlap — "multiple teams all building the same thing in isolation without realizing… multiple kind of wasted effort."
• Drift — "newer skills are shipping and teams aren't keeping up with those newer versions" (Matt Pocock's "Grill me" → "Grill with Docs" example).
• Activation (failure of) — no visibility into whether skills are actually being used by agents or humans.
• Rot — a skill that describes code/process/workflow whose subject has changed, while the skill hasn't. "Having an outdated skill can often be just as bad as having no skill at all."
• Overloading — "too many skills in a single repository"; descriptions get truncated by agents at the percentage-of-context-window limit, so activation breaks silently.
• Agentic equation — "an agent is a function of the model, the harness and the context."
• Plugin — "just a group of contexts related together that can be installed into your [agentic] coding tools."
• CDLC (Context Development Life Cycle) — the context-side analogue of SDLC: "Everything you do to keep code healthy already has a direct equivalent for context."
• Minimum release age — a registry policy where "any [packages] that are newer than that can[not] be installed." Defence against supply-chain attacks.

Named frameworks / concepts introduced

1. The five failure modes of skills sprawl: overlap, drift, activation, rot, overloading.
2. The agentic equation: agent = f(model, harness, context) — context is the most practical lever.
3. Skills-as-software checklist (nine practices): decompose; extend don't edit; single responsibility; avoid global skills; automated skill reviews; publish to a registry; don't lock to one agent; make context a team asset; measure with evals.
4. CDLC ↔ SDLC analogy: skill reviews ↔ linting + unit tests; evals ↔ end-to-end tests; context registries ↔ code registries; same authoring reflexes (composition, no global state); same human factors (no silos, no bus factor).
5. Registry governance levers: approved-skills-only, first-party vs. limited third-party allowlist, security scans, minimum release age.

Open questions / not covered

• A precise definition of what counts as "a skill" vs. a plugin vs. a sub-agent (assumed familiar).
• Concrete eval tooling or syntax — Moss endorses evals but doesn't demo one.
• How to share skills with non-technical colleagues — explicitly raised in Q&A, Moss says "I don't think [there] is a good answer" and floats "some sort of gooey [GUI]" as speculation.
• How to express dependencies between skills across packages — Moss says "there isn't a standard way to understand it [at] the moment" and speculates the agent itself might resolve dependencies by reading skills.
• Specific recommendation on AKM (unclear package-manager name) — Moss says he's "played around with it a bit" and it's "definitely [worth a] use" but doesn't commit.
• Quantitative ROI of adopting the full checklist.
• Comparison of specific registries beyond Tessl's.