talk-moss-skills-team-workflow

name

talk-moss-skills-team-workflow

description

Use when the user asks about James Moss's talk "Using skills to pay the bills: graduating from solo hacks to a team workflow" (Tessl, DevCon 2026) — including questions about skills sprawl, the failure modes of team skill adoption (overlap, drift, activation, rot, overloading), the agentic equation (model + harness + context), treating skills as software, the Context Development Life Cycle (CDLC), skill registries, evals for skills, or applying his recommendations (decompose, extend don't edit, version control, automated reviews, registry, agent-agnostic skills) to current work.

Using skills to pay the bills: graduating from solo hacks to a team workflow — James Moss (Tessl, DevCon)

James Moss argues that AI coding skills work fine for solo developers but break down at team scale, producing "skills sprawl" with five characteristic failure modes (overlap, drift, lack of activation, rot, overloading). His thesis: treat skills as software — decompose them, version control them in the repo (never globally), automate reviews, publish to a registry, keep them agent-agnostic, and measure with evals. The industry already learned these lessons painfully for code over the last ~20 years (the SDLC); the Context Development Life Cycle (CDLC) shouldn't have to repeat them.

Grounding rules — MUST follow when answering

1. Before answering any specific question, read outline.md to locate the relevant section, then read that section of transcript.md.
2. When attributing words, quote verbatim from transcript.md. Never put quotation marks around paraphrased content.
3. If a claim isn't in transcript.md, say "the talk doesn't address this" — do not infer positions from outside knowledge.
4. Cite by transcript line range or section heading whenever possible.
5. Speaker attribution is unreliable for this transcript — the source has no per-speaker labels. The talk is overwhelmingly James Moss speaking, but there are also: an MC who introduces him, and several audience Q&A questioners at the end. Prefer phrasing like "Moss said..." for the main body. For the Q&A, distinguish "an audience member asked..." from "Moss replied...". Do not invent attributions.
6. The transcript is from speech-to-text and contains many garbled words and homophones (e.g. "Wilming" likely = "Grill me", "Sneak" = "Snyk", "fabric" likely = "package", "AKM" likely an unclear package manager name, "mini sha loot tack" = likely "Shai-Hulud attack"). Preserve the artifacts verbatim when quoting; you may note the likely intended term parenthetically.

How to help with this talk

Factual Q&A about the talk

For any question about what the speaker said, did, or argued:

1. Read outline.md first to find the relevant section(s).
2. Read the matching range of transcript.md.
3. Answer using verbatim quotes from transcript.md. Do not paraphrase the speaker's words while presenting them as a quote.
4. Cite line numbers or section headings so the user can verify.
5. If the answer genuinely isn't in the transcript, say so explicitly — do not reach for outside knowledge to fill the gap unless the user explicitly asks for it (and then mark that part clearly as "not from the talk").

Apply the speaker's approach to current work

When the user asks "how would Moss tackle X?" or wants the talk's framework applied to their own situation:

1. Use outline.md → "Named frameworks / concepts" to find the relevant framework (the five failure modes, the agentic equation, the skills-as-software checklist, or the CDLC analogy).
2. Read the corresponding range of transcript.md for the speaker's exact wording.
3. Anchor your suggestion in a verbatim quote of how Moss articulates the framework. Then walk through applying it step-by-step to the user's case.
4. If the framework genuinely doesn't fit the user's situation, say so. Do not stretch the speaker's words to cover cases they don't actually address.

Audit the user's situation against the speaker's framework

When the user asks to "audit", "score", "review", "grade", "check", or "gap-analyse" their current skill setup against Moss's recommendations:

1. Use outline.md → "Named frameworks / concepts" to locate the dimensions. The two main checklists are:
   • Five failure modes of skills sprawl: overlap, drift, (lack of) activation, rot, overloading.
   • Skills-as-software practices: decompose; avoid global skills; extend (don't edit) third-party skills; single responsibility; automated skill reviews (lint + LLM-as-judge); publish to a registry (governance, security scans, minimum release age, discoverability); don't lock to one agent; make context a team asset; measure with evals.
2. For each dimension, read Moss's definition in transcript.md and quote it verbatim when stating what "good" looks like.
3. Walk the user through every dimension in order — don't skip ones that seem weak; the value is in completeness. If the user hasn't described their state for a dimension, ask before scoring.
4. For each dimension, give a clear verdict (covered / partial / missing) grounded in Moss's criteria, not your own intuition.
5. If a dimension genuinely doesn't apply, say so explicitly and explain why.
6. Summarise at the end: which dimensions are gaps, and what Moss said about closing them (verbatim quotes again).

Teach / explain concepts from the talk

When the user wants to understand a concept Moss covered:

1. Look up the term in outline.md → "Terminology glossary".
2. Read the speaker's explanation in transcript.md.
3. Re-explain using Moss's own framing and examples first, with verbatim quotes for the key claims and definitions (the agentic equation, sprawl, drift, rot, overloading, CDLC, etc.).
4. You may add modern context, comparisons, or extensions afterwards — but mark them clearly as "not from the talk" so the user can tell which parts are Moss's and which are yours.

Surface this talk proactively when relevant

When the user's current work touches on themes Moss addressed (even if they haven't asked about the talk):

1. Briefly note: "James Moss made a related point in his DevCon talk on skills sprawl..."
2. Quote verbatim from transcript.md — one quote is usually enough.
3. Add one sentence connecting the quote to the user's situation.
4. Do not over-cite. Likely triggers: someone editing a vendored third-party skill, installing skills to ~/.claude/, talking about CLAUDE.md or AGENTS.md drift across a team, debugging "works on my machine" agent behaviour, or evaluating package managers / registries for AI artifacts. If the connection feels strained, stay quiet.

Key quotes

quotes.md contains pre-extracted verbatim highlights from this talk, organised by theme. When formulating answers, check quotes.md first for strong citable evidence before searching the full transcript.md.