Agent Skills

Reusable, markdown-packaged workflows and procedures injected into an agent's context when relevant, encoding expert practice as portable instructions.

Also known as: skills, skill, /skills, Agent Skills, SKILL.md, skill.md, Skill (Android Skill / SKILL.md), skill (file-based), skills (externalized), skills (in Genkit middleware), AI Agent Skill, Grok Skills, OpenClaw Skills, Skill (as deployable artifact), Modularity Skills (Khononov), write-kaggle-benchmarks skill, Lattice

Part of: Agent Harness

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (49)

• Agent Skills: Bridging AI and Senior Engineer Practices Addy Osmani · 2026-10-08 source ↗ Reader 🖥️
  AI coding agents are capable junior engineers with no instinct for the invisible, non-diff parts of senior engineering — specs, tests, reviews, scope discipline, verification — so Agent Skills exists to make those parts structurally non-negotiable, because they are no longer optional even when the 'engineer' is a model.
• Presentation: Decision Models in Agentic Architectures: From Production to Agent Skills Alex Porcelli · 2026-09-14 Reader 🖥️
  High-stakes decisions inside agentic AI systems need a deterministic, auditable decision-model layer (DMN, executed by a rule engine like Drools) sitting beneath the non-deterministic LLM and exposed to it as a skill or guardrail — generated from and owned by business domain experts rather than engineers — because what enterprise AI actually lacks is not mere consistency but full accountability: reproducibility, explainability, and governance together.
• Zero to Agent in 30 Minutes: Build a Supply Chain for Agent Context with Maxim Salnikov Michelle Smith · 2026-09-08 source ↗ Reader 🖥️
  Because agent skills, instructions, hooks, and other customizations now spread across machines, harnesses, and codebases with no record of their origin or whether they've changed, teams should manage agent context the way modern software already manages code dependencies — versioned, pinned, sourced from a vetted registry, and audited for drift in CI — using a purpose-built package-manager tool (APM) rather than ad hoc installation.
• TBM 437: AI and the Recontextualization Tax John Cutler · 2026-09-03 Reader 🖥️
  Organizations pay a real, often-hidden cost -- the 'recontextualization tax' -- every time people flatten a working reality into a simplified version to suit whoever has the most power, the least appetite for detail, or the least time, and AI is newly good at absorbing that translation labor because it can render one underlying, accurate context into many audience-tailored formats without forcing teams to first standardize how they actually work.
• Audit your Agent files AddyOsmani.com · 2026-08-27 source ↗ Reader 🖥️
  Coding-agent configuration (CLAUDE.md/AGENTS.md, skills, hooks, MCP servers, memory) has a half-life because models and harnesses keep improving past what the rules were written for, so instead of accumulating it indefinitely or purging it wholesale, developers should audit it on a recurring cadence — using tools like /doctor, questioning whether each item's original reason still holds, and testing removal before committing to it.
• When Guardrails Go Wrong Mike Loukides · 2026-08-19 source ↗ Reader 🖥️
  Because no classifier can eliminate both false positives and false negatives at once, AI guardrails that are overly broad, whole-conversation-scoped, and opaque about their own boundaries make models less useful without making them meaningfully safer, so labs should deliberately re-balance safety classifiers toward fewer false positives rather than defaulting to maximal caution.
• Paweł Huryn's Post Paweł Huryn · 2026-08-01 Reader 🖥️
  For most AI agents, the four functional types of memory — working, semantic, episodic, and procedural — map cleanly onto a context window plus a handful of git-versioned files (markdown for facts/rules, a CSV for history, more markdown for reusable skills), making vector databases and graph databases unnecessary defaults, appropriate only as 'escape hatches' when a corpus genuinely becomes too large to read.
• AI as an Enterprise Operating System Tim O'Reilly · 2026-07-31 source ↗ Reader 🖥️
  Enterprise AI adoption is stalled not because models are undercooked but because almost no organization has done the deliberate, CEO-led mechanism-design work — a capability ladder tied to status and pay, hardened defaults, a skills-as-code habit, and a forced permissions audit — that Guido's Trail of Bits case study shows is what actually turns AI from a tool into an operating system.
• Yonathan Cohen's Post Yonathan Cohen · 2026-07-31 Reader 🖥️
  A structured 'handoff' file — capturing every decision made, the verbatim work-in-progress, rejected alternatives, the user's style rules, and a single next instruction — lets work continue coherently across a session cutoff or even a different AI model, because it transfers state that a fresh conversation cannot otherwise recover.
• Kafka App? There's a Skill for That Isobel Scott · 2026-07-30 source ↗ Reader 🖥️
  Well-built Agent Skills that wrap error-prone Kafka streaming-pipeline work in deterministic, guardrailed automation are worthless until the coding agent reliably recognizes when to invoke them — so discoverability (matching the developer's actual vocabulary, workflow entry points, and file-touch context) must be engineered as deliberately as the automation itself.
• agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub Addy Osmani · 2026-07-28 Reader 🖥️
  agent-skills, Superpowers, and Matt Pocock's skills all encode good agentic-engineering discipline but optimize for different moments in the work — full product-lifecycle governance with human checkpoints (agent-skills), autonomous reasoning-heavy execution (Superpowers), or a sharp personal daily toolkit (Matt Pocock) — and while the piece insists 'none of them is best in the abstract,' its own structure (author's project profiled first-person, most elaborated column, sole cited empirical case study, broadest 'reach for X' pitch) quietly tilts the honest map toward agent-skills.
• Zero to Agent in 30 Minutes: Build a Hermes Social Media Agent with Craig Hewitt Michelle Smith · 2026-07-27 source ↗ Reader 🖥️
  A useful autonomous social-media agent is built by staging trust deliberately, not granting it upfront — engineering structured context (a documented voice profile and workspace) first, proving one narrow workflow under human review before packaging it as a reusable skill, and only then adding fresh-data connections, triggers, and access safeguards that let it run unsupervised.
• Zero to Agent in 30 Minutes: Build a Workflow Agent with John Berryman Michelle Smith · 2026-07-20 source ↗ Reader 🖥️
  An AI agent is, at bottom, simply an LLM wrapped in an outer conversation loop and an inner tool-use loop, and the right way to build one is 'outside in' — get the non-AI application working first, stub the AI, then incrementally swap in a minimal validated agent, a small fixed toolkit, and a natural-language 'skill' — because this staged sequencing both de-risks the build and produces instructions plain enough that domain experts, not just engineers, can read and correct them directly.
• GitHub Copilot CLI Gets Tabs and No-Config-File Tool Setup in Redesigned Terminal UI Mark Silvester · 2026-07-10 Reader 🖥️
  GitHub has made Copilot CLI's redesigned terminal interface generally available, adding tabbed in-terminal browsing of GitHub issues, pull requests and gists, guided in-session configuration of MCP servers, skills and plugins that removes the need to hand-edit config files, and accessibility-focused theming — consolidating the terminal into a self-contained, extensible surface for agentic development.
• mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? Matt Pocock (AI Hero) · 2026-07-08 source ↗ Reader 🖥️
  Pocock announces that v1.1 of his Claude Code skills repo now composes a complete agentic coding lifecycle (Grill -> Spec -> Tickets -> Implement -> Code Review), whose headline addition, /wayfinder, decomposes a plan too big for one session into agent-sized chunks mapped as GitHub issues with blocking edges so the work can be parallelized.
• New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets Matt Pocock · 2026-07-08 source ↗ Reader 🖥️
  Agent-assisted software work is best handled not as ad-hoc prompting but as an explicit, skill-mediated development lifecycle — interactively grill the human into a spec, split the spec into tickets each scoped to a single agent session, implement, then code-review for refactoring smells — fronted by a dedicated planning phase (Wayfinder) that externalizes large, foggy plans onto the shared issue tracker so they survive beyond any one context window, with research, prototyping and TDD as first-class supporting stages.
• Addy Osmani's Post (Agent Skills 0.6.3 release) Addy Osmani · 2026-07-07 source ↗ Reader 🖥️
  Addy Osmani's 0.6.3 release of Agent Skills deepens the code-review skill specifically, on the premise that review -- not planning or generation -- is now the bottleneck limiting how much autonomy a coding agent can safely be granted, so the release invests in structural code-review depth (a 'reduce, don't relocate' lens, a Structural Remedies catalog, a file-size gate, severity-ranked findings) and adds a project-wide Definition of Done and an observability checklist, rather than expanding what agents are allowed to do unsupervised.
• Software Teaming in the Age of AI with James Herr and Woody Zuill Mob Mentality Show · 2026-07-07 Reader 🖥️
  As AI takes over more of the actual typing, ensemble/mob programming becomes MORE important, not less — because code was never the real bottleneck (queueing on requirements and stakeholder availability always was, and AI's speed just exposes that more starkly), and because AI removes typing-speed as the reason non-coders couldn't stay in the room. The core discipline mob programming already trains — communicating high-level intent instead of dictating each low-level step — turns out to be the same skill effective AI-agent direction requires, so learning to team well and learning to direct agents well are converging into one discipline. But this potential is bounded by real, concretely observed LLM reliability limits (non-determinism, context forgetting, and test-hardcoding instead of genuine rule implementation) that demand deliberate engineering countermeasures — deterministic code generators, unit tests reframed as guardrails rather than TDD-as-design, and small on-demand skills files instead of one long instructions file — not blind trust in AI capability claims.
• Have your agent record video demos of its work with shot-scraper video Simon Willison (Simon Willison's Newsletter) · 2026-06-30 source ↗ Reader 🖥️
  Coding agents should record video demos of their own work, and the tooling that enables it — shot-scraper's new storyboard-driven `video` command — is itself best built by an agent and driven straight from its `--help` output, so the human's remaining job is reviewing the design rather than writing the code.
• Cybersecurity and the Gap Between Skill and Ability Bruce Schneier · 2026-06-29 source ↗ Reader 🖥️
  Computers, and now AI far faster, are decoupling ability (the capacity to accomplish something) from skill (mastery earned through practice) — and because the norm-instilling process of acquiring skill no longer gates dangerous capability, the only workable response to democratized offensive AI is to harness AI for the defense.
• Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) Cole Medin · 2026-06-24 Reader 🖥️
  A developer's or team's AI-coding results are determined far more by the harness they deliberately engineer around a model — specs, context, guardrails, verification, and the discipline of continuously improving that system — than by which model they use, so investing upfront in 'agentic engineering' over ad-hoc 'vibe coding' is the highest-leverage move available right now, even though it costs more to start.
• Agent Skills Tanvi Singhal, Gabriela Hernandez Larios, Debanshu Dus, Lavi Nigam, and Smitha Kolan · 2026-06-10 Reader 🖥️
  Agent Skills are the engineering primitive that gives AI agents testable procedural memory — how to do things, not just what is true — and because the format is deliberately thin (a folder, a markdown file, optional scripts), the real and still-unsettled work is everything built around it: evaluating skills under realistic co-loaded conditions, governing who may author and promote them, and composing them into production systems — work that is organizational and engineering discipline, not a model capability.
• Loop Engineering Addy Osmani · 2026-06-07 Reader 🖥️
  Loop engineering means replacing yourself as the person who prompts the coding agent turn-by-turn with a designed system — automations, worktrees, skills, plugins/connectors, and sub-agents, plus externally-persisted state — that prompts the agent for you; but because that system can't distinguish between someone using it to move faster on work they understand and someone using it to avoid understanding the work at all, the engineer's judgement doesn't disappear, it relocates one level up, from prompting to system design, which Osmani argues is harder, not easier.
• Kaggle is making AI benchmark creation effortless Andrew Wang (Google) · 2026-06-04 Reader 🖥️
  By moving Kaggle Benchmarks into developers' local environments and letting AI coding agents author tasks in natural language, Google can scale community-built evaluations to the point where any measurable capability becomes a target that frontier labs will race to improve.
• Lessons from building Claude Code: How we use skills Claude · 2026-06-03 Reader 🖥️
  Skills work best when treated as folders (not markdown snippets) that use progressive disclosure and hard-won gotchas rather than restating known behavior, are described for machine-triggered discovery rather than human summary, and are distributed and curated organically as they scale — with verification skills specifically deserving outsized investment because they have had the most measurable impact on Claude's output quality internally.
• Google Introduces Middleware Architecture for Genkit Applications Robert Krzaczyński · 2026-05-25 source ↗ Reader 🖥️
  Google's new Genkit middleware turns agentic application reliability, safety, and orchestration from prompt-time concerns into a programmable, stackable interception layer wrapped around generation, model calls, and tool execution.
• This Week in AI: Rethinking the Agent Harness Michelle Smith · 2026-05-22 source ↗ Reader 🖥️
  In mid-2026 the strategic locus of AI value has shifted from model selection to harness design, so practitioners — including non-developers — should build their own skill-driven agent harnesses rather than depend on bespoke applications or wrapped commercial products.
• With Android CLI, Google is Making the Android Toolchain Agent-Friendly Sergio De Simone · 2026-05-21 source ↗ Reader 🖥️
  Google is reshaping the Android toolchain around the AI coding agent as the primary user — exposing a scriptable CLI, modular SKILL.md instruction packs, and a live-updated knowledge base — and is positioning this agent-first surface, not the IDE, as the entry point for new Android work.
• Three more static code analysis sensors Birgitta Böckeler (published on martinfowler.com) · 2026-05-20 source ↗ Reader 🖥️
  For maintainability concerns that cross file and module boundaries, computational static-analysis sensors (dependency rules, coupling metrics) can usefully enforce a few structural invariants but cannot judge what coupling is appropriate; the most productive sensor is an inferential, prompt-driven AI modularity review that reads the code itself, with the deterministic tools relegated to enforcement of known rules and to triage of review attention.
• Doug Shannon's Post Doug Shannon, Anastasios (Tassos) Fountis, Victoria Dior Wang, Dr Scott Davies, Carrie Eckersley, Antony Evans, and others · 2026-05-19 source ↗ Reader 🖥️
  As AI absorbs more of the work of producing answers, the decisive human skill shifts from using AI well to thinking well about one's own thinking while using it — a disposition ('co-thinking', the 'Cyborg' stance) distinct from both AI dependency and from mere prompt skill, with early evidence (self-reported and cited brain-connectivity and creativity studies) suggesting this metacognitive posture determines whether AI sharpens or erodes a person's independent judgment.
• JobRunr Introduces ClawRunr, an Open-Source Java AI Agent Diogo Carleto · 2026-05-18 Reader 🖥️
  ClawRunr is JobRunr's open-source Java AI agent that wraps Spring AI's ChatClient with JobRunr's durable, retryable, scheduled job execution, packaging conversational LLM interaction with first-class persistence, recurrence, and monitoring so that long-running agent work behaves like production background jobs rather than ephemeral chat completions.
• Meta Deploys Unified AI Agents to Automate Performance Optimization at Hyperscale Craig Risi · 2026-05-18 Reader 🖥️
  Meta has built a unified, LLM-agent-based capacity-efficiency platform that encodes senior engineering expertise as reusable 'skills' and standardized 'tools' to autonomously detect and fix performance and resource inefficiencies across its hyperscale infrastructure, exemplifying an industry-wide shift from reactive, manual performance tuning to continuous, real-time, self-optimizing systems.
• How Claude Code works in large codebases: Best practices and where to start Claude · 2026-05-14 source ↗ Reader 🖥️
  At scale — multi-million-line monorepos, decades-old legacy systems, and organizations with thousands of developers — Claude Code's effectiveness is determined less by the underlying model than by a deliberately built harness (CLAUDE.md, hooks, skills, plugins, MCP servers, plus LSP integrations and subagents) and, just as importantly, by a durable organizational ownership structure (a dedicated owner or team, cross-functional governance, scheduled re-review as models evolve) that keeps good setups from staying tribal and adoption from plateauing.
• Agent Skills Addy Osmani · 2026-05-09 source ↗ Reader 🖥️
  AI coding agents default to the shortest path to 'done' and systematically skip the invisible senior-engineer work (specs, tests, reviews, scope discipline) that separates reliable software from code that breaks — skills are portable, workflow-shaped markdown files that bolt that scaffolding back on by making it impossible for the agent to rationalize skipping it.
• Teaching an AI Agent to Debug Flaky Tests Igor Kulakov · 2026-05-09 source ↗ Reader 🖥️
  Flaky tests can be debugged deterministically by diffing code-coverage reports from passing and failing runs to locate where execution paths diverge, and this entire procedure can be packaged as a reusable AI Agent Skill so that an agent follows it without human guidance.
• The Founder's Playbook: Building An AI-Native Startup Claude (Anthropic) · 2026-05-05 source ↗ Reader 🖥️
  Because AI now collapses the cost of building, researching, and operating a company, the AI-native founder's job is no longer execution but orchestration of AI across four stages (Idea, MVP, Launch, Scale), and a small (often single-founder) team that systematically routes work through Claude, Claude Cowork, and Claude Code can reach outcomes that previously required a fully-staffed organisation.
• Fragments: May 5 Martin Fowler · 2026-05-05 source ↗ Reader 🖥️
  The current moment in AI-assisted software development is defined by a tension between the power of cloud-hosted AI genies and the risks they carry — to code quality, to truth, to budgets, and to autonomy — and the pieces Fowler curates collectively ask whether the escape route runs through disciplined engineering practice, local-first computing, or some combination of both.
• xAI Releases Grok Skills and Updates Tool Calling Responses API Daniel Dominguez · 2026-05 Reader 🖥️
  xAI's Grok Skills + enhanced Responses API position Grok as a platform-native, account-level workflow runtime — catching up to industry-standard 'Skills' vocabulary while differentiating through X integration — rather than as a fully deployable autonomous agent system like Anthropic's and OpenAI's offerings.
• Alex Wang's Post Alex Wang · 2026-04-16 Reader 🖥️
  Claude Code becomes more reliable when you move recurring, deterministic, and structural concerns out of ad-hoc prompts and into the environment (CLAUDE.md, skills, hooks, plan mode).
• Charlie Hills 🦩's Post Charlie Hills 🦩 · 2026-04-16 source ↗ Reader 🖥️
  Effective use of Claude Code requires deliberate setup, disciplined workflow habits, context management, precise prompting, and exploitation of power features — and learning these on day one would save weeks of friction.
• Agent Skills: Google-Backed AI Coding Agent Workflow Addy Osmani · 2026-04-10 source ↗ Reader 🖥️
  AI coding agents produce poor-quality output when unconstrained, so encoding senior-engineer workflows as structured skills — covering the full define-plan-build-verify-review-ship lifecycle — forces agents to follow the disciplined practices that distinguish professional engineering from mere code generation.
• Agentic Engine Optimization (AEO) Addy Osmani · 2026-04-10 source ↗ Reader 🖥️
  Developer documentation must be restructured for AI coding agents as a new primary consumer — optimizing for discoverability, parsability, and token efficiency via a layered stack of standards (robots.txt, llms.txt, skill.md, Markdown formatting, token surfacing) — because agents read fundamentally differently from humans and current analytics cannot detect their failures.
• Anatomy of a perfect Openclaw setup Corey Ganim · 2026-04-10 Reader 🖥️
  A well-configured OpenClaw workspace — organized around a set of markdown files (AGENTS.md, SOUL.md, IDENTITY.md, USER.md, HEARTBEAT.md, TOOLS.md) plus skills, memory, and secrets folders — is the key to making an AI assistant behave reliably and proactively, with AGENTS.md as the single highest-leverage file.
• Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering Chenyu Zhou, Huacan Chai, Wenteng Chen, Zihan Guo, Rong Shan, Yuanyi Song, Tianyi Xu, Congming Zheng, Jiachen Zhu, Zeyu Zheng, Zhuosheng Zhang, Xingyu Lou, Zhihui Fu, Jianghao Lin, Weinan Zhang · 2026-04-09 Reader 🖥️
  Practical progress in LLM agents increasingly depends not on improving model weights but on externalizing cognitive burdens into external infrastructure — memory, skills, protocols, and harness engineering — which together form a systems-level framework of cognitive artifacts.
• Encoding Team Standards Rahul Garg · 2026-03-31 source ↗ Reader 🖥️
  A team's standards for how AI should generate, refactor, secure, and review code must stop living as tacit judgment in senior engineers' heads or as unread documentation, and instead be encoded as small, versioned, repository-resident AI instructions — because an instruction's execution is its application, which turns consistent team judgment into a side effect of the normal workflow rather than a separate step that depends on someone remembering and applying it under pressure.
• Stop Using /init for AGENTS.md Addy Osmani · 2026-02-23 source ↗ Reader 🖥️
  AGENTS.md should hold only project-specific facts an agent cannot discover by reading the code itself — because auto-generated, comprehensiveness-optimized context files duplicate what agents already find on their own and measurably slow and bias them — and the file should function as a living log of unfixed codebase friction to be resolved in the code, not as a permanent, ever-growing configuration.
• Incident 1368: Malicious OpenClaw Skills Reportedly Delivered AMOS Stealer and Exfiltrated Credentials via ClawHub incidentdatabase.ai · 2026-02-01 Reader 🖥️
  Malicious actors are exploiting the OpenClaw Skills ecosystem on ClawHub to distribute credential-stealing malware (notably AMOS Stealer), and organizations must treat community-contributed Skills as untrusted software requiring validation and code review.
• 10 Things Developers Want from their Agentic IDEs in 2025 Kate Holterhoff (RedMonk) · 2025-12-22 source ↗ Reader 🖥️
  Developer demand on AI coding tools shifted decisively in 2025 from reactive assistance (autocomplete, suggestions) to autonomous delegation across entire codebases, and this shift produces a more sophisticated, partly self-tensioned set of ten concrete demands — simultaneously wanting more autonomy (background agents, parallel orchestration) and tighter control (predictable costs, human-in-the-loop gates, rollbacks) — that agentic-IDE vendors must satisfy without losing sight of the premise that these tools exist to serve developers, not replace them.
• Building AI Agents For The Enterprise Anthropic (vendor-published; Reader recorded the byline as 'Claude') · 2025 source ↗ Reader 🖥️
  Enterprises that treat AI as a point solution (chatbot, summariser, isolated pilot) get incremental, plateauing gains; those that cross the 'agentic thinking divide' by simultaneously transforming three pillars — employees, processes, products — atop a governed, plugin-based platform (positioned as Claude Cowork) capture compounding advantages, and the practical path to doing so is a four-phase rollout (specificity-not-scale pilot, champion pilot, scale, compound) anchored by admin-controlled governance from day one.

Propositions touching this concept (149)

By publication month, oldest first (extraction month when no publication date is known).

2024-08

• explicitPromotion requires fluency -- not just proficiency -- in every skill associated with a title and all prior titles, making fluency the operative gate for advancement, though individual skills can be waived at managers' discretion.
  Update on Software Engineering Career Ladder · p4
• implicitSeveral specific skills were deliberately added or reclassified between the April and August versions of the ladder (e.g. 'Assume positive intent' and 'Build quality in' added; 'Grit' renamed 'Persistence'; 'Evaluate complex dependencies' moved up from Senior Software Engineer to Technical Lead; 'Reflective codebase architecture' moved up from Senior Software Engineer to the new Staff Engineer level), indicating the skill list is actively recalibrated based on where each skill is actually exercised, not fixed at first design.
  Update on Software Engineering Career Ladder · p10

2025

• explicitcontestedEncoded organisational knowledge (plugins, skills) is the binding scarce input: two companies using the same model get dramatically different results based on context provided.
  Building AI Agents For The Enterprise · p4

2025-12

• explicitDevelopers want to package reusable workflows into shareable, version-controlled 'skills' (e.g., a code-review or security-audit procedure defined once and invoked consistently across projects and teams) instead of re-engineering the same prompts repeatedly, encoding institutional knowledge that new team members can adopt immediately.
  10 Things Developers Want from their Agentic IDEs in 2025 · p11
• explicitCombining prompts/skills/rules with feedback loops -- strong lint rules, minimum test coverage, and automated review of AI-generated code -- is where results start to materially improve.
  Nick Tune's Post · p3

2026-02

• explicitRoughly 17% of reviewed OpenClaw Skills exhibited malicious intent
  Incident 1368: Malicious OpenClaw Skills Reportedly Delivered AMOS Stealer and Exfiltrated Credentials via ClawHub · p1
• explicitMalicious Skills focus on stealing crypto-wallet data and user credentials
  Incident 1368: Malicious OpenClaw Skills Reportedly Delivered AMOS Stealer and Exfiltrated Credentials via ClawHub · p2
• implicitestablishedThe OpenClaw Skills ecosystem lacks sufficient vetting to prevent malicious submissions at scale
  Incident 1368: Malicious OpenClaw Skills Reportedly Delivered AMOS Stealer and Exfiltrated Credentials via ClawHub · p5
• explicitThe correct architecture is layered and selectively loaded: a thin routing/protocol file (minimum undiscoverable facts, available personas/skills/MCP connections), focused persona or skill files loaded only for the relevant task type, and a maintenance subagent whose sole job is keeping the protocol file accurate as the codebase evolves.
  Stop Using /init for AGENTS.md · p8

2026-03

• explicitWhen AI-assisted development quality depends on who is prompting, senior engineers become bottlenecks — not because they write the code, but because they alone know what to ask the AI for — and this is a systems problem requiring a systems solution, not a skills problem that training, documentation, or more pairing can fix, because those approaches are slow and do not scale.
  Encoding Team Standards · p1
• explicitA harness is defined by exclusion: every piece of code, configuration, and execution logic that is not the model itself — including system prompts, tools/skills/MCPs, bundled infrastructure (filesystem, sandbox, browser), orchestration logic, and hooks/middleware for deterministic execution.
  The Anatomy of an Agent Harness · p1

2026-04

• explicitdevelopedThe workflows senior engineers follow can be encoded as structured, reusable skill packages that AI agents can execute consistently.
  Agent Skills: Google-Backed AI Coding Agent Workflow · p2
• explicitA six-layer stack (robots.txt, llms.txt, skill.md, content formatting, token surfacing, Copy-for-AI) constitutes the necessary infrastructure for agent-optimized documentation.
  Agentic Engine Optimization (AEO) · p3
• explicitestablishedRepeatable procedures, checklists, and playbooks belong in a separate mechanism (skills), not in CLAUDE.md.
  Alex Wang's Post · p2
• explicitdevelopedIf you repeatedly type the same instructions, the workflow should become a reusable skill.
  Alex Wang's Post · p4
• explicitA 6-step progressive setup (onboard, AGENTS.md, identity files, first skill, memory, TOOLS.md) covers 95% of use cases.
  Anatomy of a perfect Openclaw setup · p6
• explicitcorroboratedMemory, skills, and protocols are three distinct but coupled forms of externalization.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering · p4

2026-05

• explicitcorroboratedAgency — the belief that the world is malleable and you can change it — is more important than skill acquisition in the AI era, because AI can supply skills on demand but cannot supply agency.
  Why cultivating agency matters more than cultivating skills in the AI era | Max Schoening (Head of Product, Notion) · p1
• explicitA frontier model has read 'Hyrum's Law' in training data but does not apply it when designing your API at 3am — skills make it do so.
  Agent Skills · p10
• explicitdevelopedModular SKILL.md files, auto-triggered by prompt metadata, are a better way to encode domain workflows than attaching documentation to each prompt.
  With Android CLI, Google is Making the Android Toolchain Agent-Friendly · p3
• explicitThe harness has an intentional build order across five extension points — CLAUDE.md, hooks, skills, plugins, MCP servers — each layer building on what came before, plus two further capabilities (LSP integrations, subagents) that round out the setup.
  How Claude Code works in large codebases: Best practices and where to start · p3
• explicitdevelopedSkills exist to solve a scaling problem specific to large codebases: with dozens of distinct task types, loading all specialized expertise into every session would bloat context, so skills load on demand (progressive disclosure) and can be scoped to specific paths so they activate only for the team that owns that part of the codebase.
  How Claude Code works in large codebases: Best practices and where to start · p5
• explicitPlugins exist to solve an organizational, not technical, problem — that 'good setups can stay tribal' — by bundling skills, hooks, and MCP configurations into a single installable package so a new engineer gets the same context and capabilities on day one that existing users built up incrementally.
  How Claude Code works in large codebases: Best practices and where to start · p6
• explicitAs models evolve, CLAUDE.md instructions and compensatory skills/hooks written for a weaker model's limitations can become unnecessary or actively counterproductive for a newer model — e.g. a rule forcing single-file refactors that blocks a newer model's legitimate coordinated cross-file edits — so teams should expect a meaningful configuration review every three to six months, and especially after major model releases.
  How Claude Code works in large codebases: Best practices and where to start · p8
• explicitIn large or regulated organizations, governance questions (who controls which skills/plugins are available, how to prevent thousands of engineers independently rebuilding the same thing, how AI-generated code goes through the same review process as human-generated code) come up early, and the smoothest deployments establish cross-functional working groups (engineering, information security, governance) before rollout rather than retrofitting governance afterward.
  How Claude Code works in large codebases: Best practices and where to start · p12
• implicitOff-the-shelf 'skills' from named experts (Khononov's Modularity Skills) raise the floor of LLM code review enough that organisations need not author their own modularity prompts.
  Three more static code analysis sensors · p19
• explicitAI coding assistants silently make design decisions, forget constraints, and skip review — but composable skill frameworks like Lattice can embed engineering discipline that accumulates with use.
  Fragments: May 5 · p1
• implicitSkill retention cannot be incentivized purely by organizational policy when the same organization is signaling that those skills are obsolete; the friction comes from senior practitioners who carry the cost of incidents.
  Presentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) · p23
• extensibility claimFile-based skills loaded from a workspace directory enable runtime extensibility without redeployment.
  JobRunr Introduces ClawRunr, an Open-Source Java AI Agent · p7
• explicitcorroboratedEncoding expert reasoning as reusable agent 'skills' operationalizes and democratizes institutional knowledge.
  Meta Deploys Unified AI Agents to Automate Performance Optimization at Hyperscale · p6
• explicitcorroboratedReplacing a bespoke application with a skills-driven agent harness lets domain experts read and modify agent behavior in plain English, without developer intermediation.
  This Week in AI: Rethinking the Agent Harness · p5
• explicitSkills-driven harnesses give domain experts a kind of control that wrapped commercial agent products do not.
  This Week in AI: Rethinking the Agent Harness · p6
• explicitA future 'open agent protocol' will let agents move between environments and receive environment-specific skills from each environment.
  This Week in AI: Rethinking the Agent Harness · p12
• implicitcorroboratedA skill written in plain English is a kind of executable code.
  This Week in AI: Rethinking the Agent Harness · p14
• explicitDecades of prior research in self-regulated learning and goal-setting (Simon's Intelligence-Design-Choice model, Hollenbeck & Klein's goal-commitment research, Zimmerman's cyclical self-regulation, Flavell's metacognition model) already describe the planning, monitoring, evaluation, and adaptation skills that now determine the quality of human-AI collaboration — this is an old psychological phenomenon applied to a new domain, not a newly discovered one.
  Doug Shannon's Post · p8
• explicitAI Agent Skills make hard debugging procedures accessible to agents that have no prior context about the problem.
  Teaching an AI Agent to Debug Flaky Tests · p5
• explicitGrok Skills persist across all Grok conversations on web/iOS/Android without re-instruction
  xAI Releases Grok Skills and Updates Tool Calling Responses API · p1
• explicitSkills are created via natural-language descriptions or file uploads
  xAI Releases Grok Skills and Updates Tool Calling Responses API · p2
• explicitSkills operate at the account level, take priority over default behaviors when invoked via slash commands, and support sharing between users
  xAI Releases Grok Skills and Updates Tool Calling Responses API · p4
• explicitdevelopedGrok Skills is more like a reusable workflow/capability layer than a fully deployable autonomous agent system
  xAI Releases Grok Skills and Updates Tool Calling Responses API · p7
• implicit'Skills' is now the converging industry vocabulary across vendors (Anthropic, OpenAI, xAI, Vercel)
  xAI Releases Grok Skills and Updates Tool Calling Responses API · p8
• implicitDifferent vendors mean meaningfully different things by 'Skill' (workflow vs. autonomous agent vs. developer extension)
  xAI Releases Grok Skills and Updates Tool Calling Responses API · p9
• implicitSkills are persistent at the user-account level — implying a per-account storage of instructions injected at conversation time
  xAI Releases Grok Skills and Updates Tool Calling Responses API · p11
• implicitSkills are not fine-tunes — they are reusable instructions/context, complementing system prompts
  xAI Releases Grok Skills and Updates Tool Calling Responses API · p12

2026-06

• explicitA command's --help output can carry enough detail for a coding agent to use the tool correctly, functioning like a SKILL.md bundled directly inside the tool and removing the need for a separate agent-instruction file.
  Have your agent record video demos of its work with shot-scraper video · p4
• explicitSkills are folders of instructions, scripts, and resources that agents discover and use, not merely markdown files — treating them as folders (with progressive disclosure across their contents) is central to what makes them effective.
  Lessons from building Claude Code: How we use skills · p1
• explicitAnthropic's internal skills cluster into nine categories (library/API reference, product verification, data fetching/analysis, business process automation, code scaffolding/templates, code quality/review, CI/CD and deployment, runbooks, infrastructure operations); skills that straddle several categories instead of fitting cleanly into one confuse the agent.
  Lessons from building Claude Code: How we use skills · p2
• explicitVerification skills (testing/checking that code actually works) have had the most measurable impact on Claude's output quality of any skill category internally, to the point that it can be worth dedicating an engineer-week to making them excellent.
  Lessons from building Claude Code: How we use skills · p3
• explicitA skill should not restate what Claude would already do by default (it already knows how to code and can read the codebase); a skill's value comes from pushing the agent out of its normal default way of thinking.
  Lessons from building Claude Code: How we use skills · p4
• explicitThe highest-signal content in any skill is its 'Gotchas' section, built up incrementally from Claude's actual observed failure points rather than designed upfront.
  Lessons from building Claude Code: How we use skills · p5
• explicitThe entire skill filesystem — SKILL.md plus references/, assets/, and scripts/ — should be treated as a deliberate form of context engineering and progressive disclosure: point Claude to files, and it will read them at the appropriate time rather than needing everything loaded up front.
  Lessons from building Claude Code: How we use skills · p6
• explicitSkill instructions should avoid being overly specific or prescriptive ('railroading'), because skills are reused across many situations and over-constraining Claude removes its ability to adapt to the actual case in front of it.
  Lessons from building Claude Code: How we use skills · p7
• explicitdevelopedA skill's frontmatter description field functions as a trigger condition scanned across every installed skill at session start to decide whether a request should invoke it — it is not a human-facing summary, and should be written accordingly (including explicit trigger words).
  Lessons from building Claude Code: How we use skills · p8
• explicitSkills can carry persistent memory (append-only logs, JSON, or SQLite) stored via a stable directory (${CLAUDE_PLUGIN_DATA}), letting Claude read its own history from past invocations of the same skill and detect what changed since last time.
  Lessons from building Claude Code: How we use skills · p9
• explicitGiving Claude pre-written scripts and helper functions inside a skill lets it spend its reasoning turns on composing and deciding what to do next, rather than reconstructing boilerplate code from scratch each time.
  Lessons from building Claude Code: How we use skills · p10
• explicitHooks scoped to activate only while a specific skill is invoked ('on-demand hooks') let a team apply strict, opinionated guardrails (blocking rm -rf, force-push, DROP TABLE) only in the contexts where they're actually needed, since having such constraints always-on would be too restrictive for general use.
  Lessons from building Claude Code: How we use skills · p11
• explicitFor small teams working across few repos, checking skills into the repo (./.claude/skills) is sufficient; but every checked-in skill adds a small, permanent tax to the model's context, so at scale an internal plugin marketplace with opt-in installation becomes the better distribution model.
  Lessons from building Claude Code: How we use skills · p12
• explicitcontestedAnthropic curates its internal skills marketplace organically and bottom-up rather than through a centralized gatekeeping team: a skill starts in a sandbox folder, gains traction by word of mouth, and only then gets promoted into the marketplace via a PR from the skill's own owner.
  Lessons from building Claude Code: How we use skills · p13
• explicitSkill-to-skill dependency and composition currently works only informally — by referencing another skill by name in an instruction and relying on the model to invoke it if that skill happens to be installed — because no formal dependency-management mechanism is built into skills or marketplaces yet.
  Lessons from building Claude Code: How we use skills · p14
• explicitdevelopedSkill usage across a company can be measured with a PreToolUse hook that logs invocations, giving visibility into which skills are popular versus under-triggering relative to expectations.
  Lessons from building Claude Code: How we use skills · p15
• implicitcontestedSkill quality is driven more by iterative refinement from real failures encountered over time than by upfront design — most of Anthropic's best skills 'began as a few lines and a single gotcha' and improved as people kept adding to them.
  Lessons from building Claude Code: How we use skills · p16
• explicitFor most of human history skill and ability were synonymous, but computers decoupled them — and AI is widening the gap far faster; as it widens, people can do more (more writing, research, analysis) and also more damage than ever before.
  Cybersecurity and the Gap Between Skill and Ability · p1
• explicitInternet risk and cyberattacks long predate generative AI; what AI changes is not the existence of the threat but the speed at which the skill/ability gap widens.
  Cybersecurity and the Gap Between Skill and Ability · p2
• explicitcorroboratedThe historical shift from skilled hackers (L0pht) to 'script kiddies' using others' tools shows that as prewritten attack capability spreads, the pool of potential attackers grows even as the required skill falls; AI is the extreme continuation of this trend.
  Cybersecurity and the Gap Between Skill and Ability · p4
• explicitdevelopedThe lengthy process of acquiring a skill also instills a moral and ethical code and binds the practitioner to a professional community's norms; people with ability but no skill are typically norm-free outsiders, which is precisely why democratized dangerous capability is dangerous.
  Cybersecurity and the Gap Between Skill and Ability · p5
• explicitThe decoupling generalizes far beyond cybersecurity: any doctor can describe an untraceable poison, virus researchers know how to build a bioweapon, bridge engineers know how to blow up a bridge — the rarity of murderous professionals is due to the norms that skill acquisition instilled, not to the knowledge being scarce.
  Cybersecurity and the Gap Between Skill and Ability · p6
• explicitBecause the two paths demand opposite preparation — deepen technical judgment and AI-code-review skill for the TLM path, versus practice domain-transferable people skills (running 1:1s with someone whose work you don't understand, getting visible to skip-levels) for the multi-team path — engineers should stop treating 'becoming an EM' as a single career destination and instead diagnose which future their company is building and develop accordingly.
  The engineering manager role is splitting in two · p5
• explicitAgent Skills are a procedural-memory primitive: a folder (minimally just a SKILL.md) that teaches a general-purpose agent how-to-do-it knowledge, loaded only when its description matches the task, keeping active context small while total available capability stays effectively unbounded.
  Agent Skills · p1
• explicitConverting a 50-workflow system prompt into a skills library can cut active context from roughly 150,000 tokens to about 2,000 (a 98%+ reduction), because only the matching skill's body loads per turn instead of every workflow's instructions loading every turn.
  Agent Skills · p2
• explicitSkills fail in four distinct, independently-testable ways — wrong/missed trigger, incorrect execution once triggered, token-budget degradation under co-loading, and regression when a new skill overlaps an existing one — and a skill is not 'evaluated' unless all four are checked.
  Agent Skills · p3
• explicitIn a 2025 benchmark of 84 real-world agent tasks (SkillsBench), 19% of tested skills made the agent perform worse than having no skill at all — a poorly designed skill is not neutral, it actively subtracts capability.
  Agent Skills · p4
• explicitVercel's production analysis found a 56% non-invocation rate for skills expected to activate consistently, and — more strikingly — a skill stripped of its instructions scored 58% on a task while the agent with no skill at all scored 63%, meaning the bare presence of an unused skill can itself subtract five points of capability.
  Agent Skills · p5
• explicitSingle-run evaluation success is a poor predictor of production reliability: on tau-bench, GPT-4o scored 61% on pass^1 but dropped below 25% on pass^8 (succeeding on every one of eight repeated runs), so action-allowed skills should be gated on sustained, not occasional, success.
  Agent Skills · p6
• explicitSkill authorship should be distributed to the domain team that already owns the underlying expertise — compliance officers, HR managers, merchandisers — rather than centralized in an AI/platform team, because adding a new skill takes hours to days and is owned by any domain team, whereas a model swap takes an ML/platform team days to weeks.
  Agent Skills · p7
• explicitSkills should be governed as code dependencies — versioned, pinned, reviewed in PRs, security-scanned before adoption — with explicit trust tiers (trust-by-default for first-party vendor skills, org-review for internally-curated skills, audit-before-adopting for community skills from marketplaces now exceeding a million listings).
  Agent Skills · p8
• explicitAgent-drafted skills (meta-skills authoring, trace-harvesting, metric-driven optimization) must always enter the library at the draft tier regardless of how confident the drafting agent is, with a human scanning the diff for the first several edits, because an agent permitted to edit its own skills will optimize for whatever metric it is given, including metrics that are easy to game.
  Agent Skills · p10
• explicitA retailer's durable competitive asset is its skills library, not its custom agent or its runtime, because the runtime is commoditized (any competitor on the same generic agent runtime starts from the same baseline) while the skills library encodes the retailer's own accumulated merchandising, trades, and compliance expertise.
  Agent Skills · p12
• explicitA skill's description field is effectively the entire routing algorithm — the only thing the model sees to decide whether to load it — so it must state what it does and when (and when not) to use it, front-load trigger keywords, and be validated against a 90% trigger-accuracy target using explicit positive and negative test cases.
  Agent Skills · p13
• explicitSkills and multi-agent architectures are not competitors — multi-agent remains correct when there is genuine parallelism, real capability/security boundaries, or heterogeneous models — but many systems built multi-agent by default (one sub-agent per process variant) can be elegantly collapsed to a single agent with many skills, cutting the operational surface from N deployments to N folders.
  Agent Skills · p14
• implicitThe whitepaper's own trust-tier and governance framework is itself a skill-adoption artifact of a specific moment (early 2026, 40,000+ marketplace listings and climbing) rather than a timeless design, which the authors implicitly acknowledge by distinguishing what is 'settled' (the file format, the open standard) from what is 'still emerging' (evaluation practice, governance patterns, agent-driven authoring).
  Agent Skills · p15
• explicitRather than building many specialized sub-agents, the industry is converging on using one generalist agent that becomes specialized on demand by loading Agent Skills (dynamic context) — this is simpler to maintain than complex multi-agent architectures of dedicated specialist agents.
  Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) · p5
• explicitStatic context (rules and guardrails loaded into every agent session) buys reliability because the agent doesn't have to seek the information out, but costs context-window space upfront, so it should be kept lean; dynamic context (skills, conventions loaded on demand) is more scalable but risks the agent failing to retrieve it exactly when needed.
  Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) · p7
• explicitdevelopedAgent Skills let an agent remain a lightweight generalist at session start and flex into specialist roles on demand, so a system can carry many capabilities while only paying the token cost for the one actively in use.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p5
• explicitTwo well-placed practitioners — Peter Steinberger and Boris Cherny (head of Claude Code at Anthropic) — independently report they no longer prompt coding agents directly; they design loops that prompt the agents for them, and this convergent testimony is offered as the article's central evidence that prompting skill is being superseded as a differentiator.
  Loop Engineering · p3
• explicitdevelopedA loop requires five building blocks — Automations (scheduled discovery/triage), Worktrees (parallel isolation), Skills (externalized project knowledge), Plugins/connectors (tool access via MCP), and Sub-agents (idea/verify split) — plus a sixth non-negotiable: state/memory persisted outside the conversation, because the model forgets everything between runs but the repo doesn't.
  Loop Engineering · p4
• explicitSkills are where a loop stops re-deriving project context from zero every cycle: a skill externalizes intent (conventions, the "why," past incidents) once, so every iteration of the loop reads it instead of guessing at intent each session.
  Loop Engineering · p8

2026-07

• explicitThree 'skills for coding agents' collections — agent-skills, Superpowers, and Matt Pocock's skills — optimize for different moments in the work rather than one being objectively superior; none is 'best in the abstract.'
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p1
• explicitagent-skills organizes the entire product lifecycle (Define→Plan→Build→Verify→Review→Ship) as skills routed through a meta-skill, whereas Superpowers concentrates on the core build loop (brainstorm→plan→execute) and Matt Pocock's skills are one expert's personal, curated daily toolkit rather than an exhaustive framework.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p2
• explicitEvery agent-skills skill carries a 'Common Rationalizations' table and 'Red Flags' section as its most distinctive mechanism, framed as the project's answer to the excuse-generation problem in LLM agents.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p3
• explicitagent-skills' /ship command fans out multiple named review personas (code-reviewer, security-auditor, test-engineer, web-performance-auditor) in parallel and merges their verdicts into a single go/no-go decision.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p4
• explicitBecause these are markdown skills, not runtimes, individual skills can be cherry-picked across frameworks even though a framework's meta-skill router cannot safely coexist with another framework's router in the same session.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p6
• explicitRunning two frameworks' meta-skills as simultaneous active routers causes command-name collisions and competing TDD philosophies, producing unpredictable behavior rather than combined benefit — so exactly one framework should be the primary router, with skills from the others borrowed à la carte.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p7
• explicitA single controlled experiment (Om Mishra: same model, same repo, same prompt, only the skill framework changed) found agent-skills reached working code faster (~8 vs ~12 minutes) and ran more validation passes (7 vs 5, including the full test suite), catching an out-of-scope compatibility issue the feature-specific tests missed; Superpowers still invested more upfront architectural reasoning, which the experimenter prefers as his daily driver for exploratory or evolving production work.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p8
• implicitThe document frames itself as fair and neutral ('we'd rather be fair than flattering,' an open invitation to file corrections) while structurally favoring agent-skills: it is the only project introduced in first person ('this project'), it receives the most elaborated profile, it is the only project anchored to an external empirical case study, and its 'reach for X' recommendation is strictly broader (lifecycle + parallel review/security/perf + multi-tool reach) than the corresponding pitches for the other two.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p9
• implicitMulti-tool reach (how many agent harnesses a skill set runs across — Claude Code, Cursor, Gemini CLI, Antigravity, OpenCode, Windsurf, Copilot, Codex, Factory Droid) is presented as a comparison axis in its own right, implying portability across harnesses is a distinguishing, non-default property of a skill framework rather than something skills automatically have.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p10
• implicitcontestedBy making 'reach for agent-skills' the recommendation with the broadest lifecycle-phase and mechanism coverage, the comparison implicitly treats more upfront structure (more phases, more named mechanisms, more review personas) as the more sophisticated shape — a framing in tension with Anthropic's own internal finding that skill quality comes from iterative, failure-driven refinement of a few lines (the 'Gotchas' section), not from broader upfront design.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p11
• explicitAgent Skills, invoked via natural language or a slash command, let developers and an LLM collaborate conversationally to generate code, validate configs, run applications locally, and create pull requests for streaming pipelines.
  Kafka App? There's a Skill for That · p2
• explicitA well-built, well-demoed, well-tested set of Agent Skills can still see near-zero real-world adoption — the failure mode was that the coding agent never offered the Skills to developers during ordinary sessions, not that the Skills themselves were bad.
  Kafka App? There's a Skill for That · p4
• explicitDevelopers' pre-existing habit — find the closest existing feature, copy its code, modify the fields, engaging the agent mid-task ("copy this class and change it to count cart moves") rather than starting from "I'd like to create a new streaming feature" — doesn't match a Skill's natural-language trigger phrasing, so the Skill never activates even where it is the better path.
  Kafka App? There's a Skill for That · p5
• explicitRequests for a new feature arrive in whatever internal vocabulary the developer's own team uses (a specific feature-store entry, an internal event name, a parent Java class, an output data type) rather than in the vocabulary encoded into the Skill's description.
  Kafka App? There's a Skill for That · p6
• explicitSkill discoverability can be improved by enumerating multiple entry points across vocabularies, lifecycle stages, and copy-paste-shaped requests, and by adding repository-level routing so that touching related files is itself a trigger, independent of how the request is phrased in natural language.
  Kafka App? There's a Skill for That · p7
• explicitLightweight telemetry — a hook that fires a 'started' event when a Skill is invoked, and a wrapper that fires a completion event when the agent opens a pull request, both flowing through an existing company event pipeline into a BigQuery table — lets a platform team measure which Skills are used, how often they reach a PR, and where developers still need support.
  Kafka App? There's a Skill for That · p8
• implicitAutomation quality and discoverability are separable engineering problems: solving the first (building a Skill that works well when invoked) does not solve the second (getting the coding agent to actually invoke it), and a team should budget dedicated design effort for entry points and routing after the Skill itself already works, not assume it follows automatically from quality.
  Kafka App? There's a Skill for That · p11
• explicitA subagent does not automatically inherit skills that are active in the parent/orchestrator session; the orchestrator must explicitly pass the relevant skill along (e.g. by pointing the subagent at the skill file) for it to apply.
  The Orchestrator's Tax · p10
• explicitSkills, plugins, and settings are each managed in-session through dedicated commands: /skills toggles individual skills, /plugin installs plugins from a marketplace/repo/local path, and /settings opens an inline configuration dialogue.
  GitHub Copilot CLI Gets Tabs and No-Config-File Tool Setup in Redesigned Terminal UI · p6
• implicitSkills, MCP servers, and plugins are the assumed standard extension mechanisms for an agentic CLI — the tool now treats them as first-class, built-in configuration surfaces rather than optional add-ons.
  GitHub Copilot CLI Gets Tabs and No-Config-File Tool Setup in Redesigned Terminal UI · p10
• explicitdevelopedThe specification's two core constructs are catalogs (a machine-readable ai-catalog.json manifest an organization publishes describing its tools/APIs/skills/endpoints) and registries (aggregators letting agents search across organizations by task intent instead of hardcoded integrations or static endpoint lists).
  Google and Industry Partners Announce Agentic Resource Discovery Specification for AI Agents · p2
• explicitThe skills now compose a complete lifecycle: Grill -> Spec -> Tickets -> Implement -> Code Review.
  mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? · p5
• implicitSkill terminology should be tool-agnostic and should name the artifact actually produced (spec, ticket) rather than borrow product-management or GitHub-specific labels (PRD, issue).
  mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? · p8
• explicitA three-tier skills-repository model (internal, public, curated) lets individual engineers' tacit expertise compound into shared organizational capital, converting one-off lessons ('scar tissue') into reusable defaults.
  AI as an Enterprise Operating System · p6
• implicitPublishing an internal playbook and skills repository externally functions as a governance mechanism, not merely marketing, because public accountability forces tacit, tribal knowledge into an explicit, checkable form.
  AI as an Enterprise Operating System · p9
• explicitRigorously evaluating whether AI skills/agents are actually worth deploying requires purpose-built benchmarks with positive and negative test cases compared against existing algorithmic tools — something Trail of Bits has not yet built despite having already scaled its adoption program company-wide.
  AI as an Enterprise Operating System · p10
• explicitHackathons work as skill-diffusion mechanisms when they are recurring, purpose-designed training programs measured by movement on the capability ladder, not one-off production sprints measured by artifacts shipped.
  AI as an Enterprise Operating System · p11
• explicitEncoding an agent's context, decision criteria, and workflow as a natural-language 'skill' — rather than as a coded state machine — is preferable, and skills should include self-checking checklists so the agent confirms each step was completed or fails fast.
  Zero to Agent in 30 Minutes: Build a Workflow Agent with John Berryman · p8
• implicitcorroboratedComplexity should be added to an agent build only incrementally, and only once each simpler layer is proven — the five-step order (traditional software → stub → minimal agent → small toolkit → natural-language skill) encodes a staged de-risking principle that the piece never names as such.
  Zero to Agent in 30 Minutes: Build a Workflow Agent with John Berryman · p10
• implicitNatural-language legibility — skills that subject-matter experts can read and edit — is treated as inherently a quality/governance improvement, not merely a productivity one: the piece assumes direct SME editing produces better outcomes than the product-manager/engineer relay it replaces, without demonstrating this or acknowledging what that relay used to catch.
  Zero to Agent in 30 Minutes: Build a Workflow Agent with John Berryman · p12
• explicitIf code review is the bottleneck limiting how much autonomy an agent can safely be given, the correct response is to invest in sharpening the review skill itself, not in expanding the agent's unsupervised scope.
  Addy Osmani's Post (Agent Skills 0.6.3 release) · p1
• implicitA reusable 'agent skill pack' encoding senior-engineer workflow judgment is becoming a recognized, competitive category rather than a single project's idiosyncratic tool -- evidenced by the author publishing a comparison doc against two named peer efforts (Superpowers, Matt Pocock's skills) including a controlled head-to-head.
  Addy Osmani's Post (Agent Skills 0.6.3 release) · p5
• explicitBecause skills are plain Markdown files, the same skill pack can function as harness-agnostic infrastructure across essentially every major coding-agent surface, rather than being tied to one vendor's tool.
  Addy Osmani's Post (Agent Skills 0.6.3 release) · p6
• implicitSkill atrophy from AI use should be accepted selectively — for skills one doesn't personally need to keep sharp — rather than adopted as a blanket policy across all activities.
  The Pragmatic Engineer AMA · p9
• explicitAgent-assisted development should be run as an explicit, staged lifecycle in which each stage is a discrete, named skill — grill/plan, then /to-spec, then /to-tickets, then /implement (one ticket per session), then /code-review, then commit — rather than ad-hoc prompting or a single 'plan mode'; this answers the recurring user question 'what is the main flow?'.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets · p1
• explicitWorkflow artifacts should be named for what they actually are, and in vendor-neutral terms: the skills were renamed from /to-PRD to /to-spec (what they produced was a specification, not a PRD) and from /to-issues to /to-tickets ('issues' felt biased toward GitHub/Linear) — 'good friction because it names it properly'.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets · p2
• explicitAn implementation skill should be deliberately thin, leaning on the agent's priors and the harness rather than encoding detailed instructions: /implement is 'very, very simple' ('implement the work described... use TDD where possible at pre-agreed seams, run type-checking and single test files regularly and the full suite once at the end, then code review, then commit') and earns its place mainly by naming and anchoring a stage in the flow, not by adding instruction volume.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets · p4
• explicitA skill can invoke a model's latent knowledge by naming canonical concepts rather than teaching them: because Fowler's Refactoring is old and heavily cited, its code smells are 'deep in the agent's priors', so describing each smell in one sentence (~10 lines total) is enough to make the agent identify it, repeat the name back, and fix it — 'outrageously useful' and cheap.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets · p5
• explicitFidelity of a planning discussion is raised most cheaply by building a rough, concrete artifact to react to, before committing to a spec: prototyping (an outline, a rough tech stub, or UI logic via the /prototype skill) should happen in the pre-spec phase — especially for anything touching front-end code — because 'how should it look / how should it behave' is answered better by a concrete artifact than by abstract discussion.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets · p8
• explicitSkills should be designed to work AFK (usable by an away-from-keyboard agent without step-by-step human confirmation): the TDD skill was converted to reference-material-only, dropping its prescribed interactive steps and keeping just the ordering discipline (red before green, one slice at a time), and refactoring was moved out of the red-green loop into the code-review stage so implementation isn't overloaded.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets · p10
• implicitdevelopedCodifying agent workflows into reusable, installable, versioned skills is a better unit for distributing engineering practice than ad-hoc prompting — the load-bearing premise behind shipping a versioned skills library at all.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets · p11
• explicitFrom a lean perspective, each prompt is a depletion of a scarce human-attention resource, so the goal is not smaller prompts but the largest prompt that produces zero rework — developed through deliberate 'agentic katas' that practice expanding prompt scope while refactoring a bloated instructions file into small, individually-retrievable skills files.
  Software Teaming in the Age of AI with James Herr and Woody Zuill · p6
• explicitcorroboratedKeeping an agent's active context window around half-full — achieved by moving detail out of one long instructions file into small on-demand skills files — produces the most consistent agent output.
  Software Teaming in the Age of AI with James Herr and Woody Zuill · p7
• explicitcorroboratedMob programming's founding discipline of communicating 'high-level intent' rather than 'coding out loud' (dictating each low-level step) is the same skill required to direct an AI agent well — exemplified by telling a taxi driver 'get me to the airport' rather than instructing the accelerator pedal.
  Software Teaming in the Age of AI with James Herr and Woody Zuill · p15
• explicitcorroboratedAI shifts the security attack surface from human-written code to the spec, prompts, agent skills, knowledge layer, agent tool access, and supply chain — surfaces that legacy, human-review-based security models were not built to defend, requiring continuous self-directed red-teaming baked into the loop.
  We've Stopped Arguing About Whether AI Changes Software · p12
• explicitEngineers who are actually compounding skill run a self-assessment every few weeks rather than annually, asking what they can do now that they couldn't do a month ago, because specific skills decay faster than the default annual-review cadence assumes.
  SWLW #711: The laws of this world (game theory), Should you still become a Software Engineer in 2026, and more. · p7
• explicitAgent Skills (as a format) follow an open standard, such that the same Skill/handoff file works identically across different AI products (Claude, ChatGPT, Gemini).
  Yonathan Cohen's Post · p4
• explicitReusable skills — packaged instructions for recurring tasks — function like standard operating procedures, making recurring work more consistent.
  Zero to Agent in 30 Minutes: Build a Hermes Social Media Agent with Craig Hewitt · p3

2026-08

• explicitA June 2026 study of 100 popular repositories found configuration smells were near-universal and often co-occurring: lint-related leakage in 62%, context bloat in 42%, and skill leakage in 35%.
  Audit your Agent files · p3
• explicitPersonalized skills built from a single developer's interaction history performed no better than a skill borrowed from someone else; a generic skill pooled from many developers was more useful overall, with personalization looking more promising only when the same preference recurred across several similar tasks.
  Audit your Agent files · p5
• explicitThe real cost of an unused, still-installed skill is not primarily token burn per prompt (only names/descriptions load for discovery, inside a budget defaulting to 1% of the context window; the body loads only on invocation) — it is degraded discoverability among a long list, accidental triggering/conflict between similar skills, unowned maintenance surface, and the owner's own loss of ability to reason about the setup.
  Audit your Agent files · p7
• explicitA test-removal run is a smoke test, not proof of safety to delete: agent outcomes vary even at low temperature, so a single run isn't decisive, and the run failing in exactly the way the skill was written to prevent counts as the skill re-earning its place.
  Audit your Agent files · p12
• explicitProcedural memory (reusable steps loaded on a trigger) is implemented as 'skills,' which are themselves files.
  Paweł Huryn's Post · p5
• explicitAnthropic's real-time 'cyber safeguards' can be triggered by an AI-generated skill description containing security-adjacent vocabulary (e.g., 'vulnerabilities, exploits, threat reporting'), even when the underlying skill and its target content are benign.
  When Guardrails Go Wrong · p1

2026-09

• explicitDevelopers now install agent skills, instructions, and other customizations from public repositories by the dozens, and the resulting files are scattered across user profiles, application folders, and codebases with no record of where they came from or whether they've changed since installation.
  Zero to Agent in 30 Minutes: Build a Supply Chain for Agent Context with Maxim Salnikov · p1
• explicitCustomizations should be vetted for security before being added to a codebase, ideally sourced from an organization's own repository of skills already identified as safe to use.
  Zero to Agent in 30 Minutes: Build a Supply Chain for Agent Context with Maxim Salnikov · p4
• explicitAn installed skill should be pinned to a specific version or commit hash, because a legitimate skill can later be compromised and have malicious content slipped into a new version published under the same name.
  Zero to Agent in 30 Minutes: Build a Supply Chain for Agent Context with Maxim Salnikov · p5
• implicitThe discipline the software industry already built for code dependencies (versioning, pinning, provenance tracking) transfers cleanly onto agent-context artifacts — skills, instructions, and hooks — without needing to be substantially reinvented.
  Zero to Agent in 30 Minutes: Build a Supply Chain for Agent Context with Maxim Salnikov · p10
• explicitPublishing a DMN model automatically yields a usable Agent Skill, because the model's own specification is expressive enough for an LLM to derive correct tool-invocation metadata (inputs, outputs, execution) from it without bespoke integration work.
  Presentation: Decision Models in Agentic Architectures: From Production to Agent Skills · p5
• implicitDMN's status as an open, published specification — rather than a proprietary internal rules format — is what makes it legible enough for an LLM to reliably translate into a working Agent Skill or NeMo guardrail without custom integration engineering.
  Presentation: Decision Models in Agentic Architectures: From Production to Agent Skills · p9
• explicitAI makes it newly practical to let a team work however is genuinely effective for them while still producing an artfully tailored, audience-specific translation of that work for each stakeholder segment, via a dedicated translation 'skill' per audience.
  TBM 437: AI and the Recontextualization Tax · p7
• implicitIt is preferable for an organization to build audience-specific translation skills than to force every client or stakeholder to adopt one shared working format, and preferable to that than over-customizing an internal tool to accommodate every external workflow.
  TBM 437: AI and the Recontextualization Tax · p8

2026-10

• explicitAgent Skills is a system for bolting senior-engineer scaffolding back onto an AI agent by making the invisible, critical steps non-negotiable rather than optional best practice.
  Agent Skills: Bridging AI and Senior Engineer Practices · p3

Tensions

Open gaps (125)

• incompleteThe document leans on the 'using-agent-skills' meta-skill router as agent-skills' defining organizing mechanism but, exactly as in the author's earlier standalone piece on the project, never explains how the router actually decides which lifecycle-phase skill to invoke, nor what happens when it misclassifies a task — a gap already flagged in extract-agent-skills-osmani#g2 and left unresolved here despite this document building its entire comparative case on that mechanism's existence.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub — read next: extract-agent-skills-osmani#g2 for the original statement of this gap; would need the agent-skills repo's actual router implementation/prompt to close.
• misinformedThe document frames itself as an 'honest map' written to be 'fair rather than flattering,' but the structural asymmetry undercuts the disclaimer: agent-skills is the only project profiled in first person ('this project'), receives the most elaborated column and prose section, is the sole project anchored to an external case study, and is the only one whose 'reach for X' recommendation spans governance, parallel review, security, performance, and the widest tool reach simultaneously. The fairness gesture (linking to both other repos, inviting corrections) is real but doesn't offset the coverage and evidence asymmetry in the document's own structure.
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub — read next: Compare directly against the Superpowers and Matt Pocock's skills repos' own documentation to see whether their self-descriptions would produce an equally broad 'reach for X' case if written by their own maintainers.
• illogicalThe comparison's recommendation logic implicitly treats more upfront structure — more lifecycle phases, more named mechanisms, more review personas, more supported tools — as the more sophisticated or capable shape, since agent-skills' 'reach for X' pitch is the broadest of the three. That framing is in tension with Anthropic's own internal account of what actually makes skills effective: their best skills 'began as a few lines and a single gotcha' and improved through iterative, failure-driven refinement rather than broad upfront design, and a skill that straddles multiple categories confuses the agent rather than serving it better. This comparison never engages that alternative axis of quality (depth of iterative hardening vs. breadth of upfront lifecycle coverage).
  agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub — read next: extract-claude-code-how-we-use-skills#p2 (skills that straddle categories confuse the agent) and #p16 (skill quality driven by iterative refinement from failures, not upfront design) — directly in tension with this document's breadth-favoring recommendation logic.
• scopeAll referenced engineering principles come from Google. No acknowledgment that different organizational contexts (startups, regulated industries, open-source projects) may need different trade-offs.
  Agent Skills: Google-Backed AI Coding Agent Workflow — read next: Literature on context-dependent software engineering practices; critique of one-size-fits-all process frameworks.
• argumentativeAnti-rationalization tables assume static excuses. The article treats rationalization as a finite, enumerable set. But LLMs can generate novel justifications not covered by any pre-written table. No discussion of what happens when the agent rationalizes in a way not anticipated by the table.
  Agent Skills
• practicalNo discussion of the cost of false enforcement. Skills add friction. What happens when the skill system forces an agent to write a spec for a one-line typo fix? The article mentions that 'a small bug fix might use three' skills but doesn't address the overhead/accuracy tradeoff.
  Agent Skills
• evidentiaryPortability is claimed but not demonstrated. The article asserts the same SKILL.md works across Claude Code, Cursor, Gemini CLI, Codex, etc. but provides no evidence that different harnesses interpret the same markdown workflow identically.
  Agent Skills
• incompleteThe piece advocates video demos as the way to show an agent's work, but never addresses that a scripted storyboard exercises a predetermined happy path — it even stubs navigator.clipboard via injected JavaScript — so it demonstrates 'the flow runs as scripted', not 'the feature is correct'. The adjacent sqlite-utils story is the counter-example the piece doesn't connect: its release-blocking data-loss bug was invisible to any demo and caught only by code review. Demos verify liveness and UX, not correctness.
  Have your agent record video demos of its work with shot-scraper video — read next: Read on evals and property-based testing as complements to demos, and Geoffrey Litt's 'understand to participate' (quoted later in this same newsletter) on why watching output cannot substitute for conceptual understanding of the change.
• incompleteThe '--help as embedded SKILL.md' pattern assumes the --help text stays accurate, complete and token-cheap as the tool grows. The piece does not consider --help drift (help falling out of sync with behavior), how a large tool's full --help fits an agent's context budget, or when the embedded-skill approach should give way to a real SKILL.md or progressive disclosure.
  Have your agent record video demos of its work with shot-scraper video — read next: Agent-native design and progressive-disclosure/token-efficiency literature; compare with SKILL.md ecosystem write-ups on versioning and staleness.
• incompleteThe whole reliability argument rests on the human catching design flaws by reviewing agent-written documentation, yet the piece does not examine the case where the agent's prose is as confidently wrong as its code — doc rot, plausible-but-inaccurate documentation that reads clean. Release notes are declared 'safe to outsource because boring, predictable and accurate', but boring text is also the text least likely to be scrutinized.
  Have your agent record video demos of its work with shot-scraper video — read next: Cognitive-debt and comprehension-debt writing; work on documentation as a review surface and on LLM-generated-text 'tells' and silent inaccuracy.
• incompleteCross-family review is recommended from repeated anecdote ('it really does work'), with no false-positive rate, no cost/benefit accounting, and no discussion of when it fails to catch things or produces noise that costs more review time than it saves.
  Have your agent record video demos of its work with shot-scraper video — read next: See the GitHub Copilot 'Rubber Duck' analysis of cross-family review as cost-effective only when invoked sparingly at high-signal moments, and eval methodology for measuring reviewer models.
• evidentialNo quantitative data on what percentage of documentation traffic comes from AI agents, or how that share is trending. The claim of 'significant and growing' is unsupported numerically.
  Agentic Engine Optimization (AEO) — read next: Look for server log analyses or industry surveys quantifying AI agent traffic share on developer documentation sites.
• evidentialNo before/after case study showing that implementing the AEO stack actually improved agent task success rates. The argument is structurally sound but empirically unvalidated.
  Agentic Engine Optimization (AEO) — read next: Seek controlled studies or A/B tests measuring agent task completion on AEO-optimized vs. non-optimized documentation.
• conceptualThe relationship between AEO and API design itself is unexplored. If an API is poorly designed, no amount of documentation optimization will help agents use it well. AEO treats documentation as the optimization surface but the API is the upstream variable.
  Agentic Engine Optimization (AEO) — read next: Explore 'agentic API design' — how API surface design (not just documentation) should change for agent consumers.
• adversarialNo discussion of the tension between making content agent-accessible and protecting intellectual property, competitive intelligence, or premium content. Opening documentation fully to agents may conflict with business models.
  Agentic Engine Optimization (AEO) — read next: Explore access control, rate limiting, and content licensing frameworks for AI agent consumers.
• incompleteNo evidence or examples are provided for any of the four habits. The claims are presented as practitioner wisdom without empirical support, before-after comparisons, or concrete scenarios showing failure modes.
  Alex Wang's Post
• incompleteThe distinction between what belongs in CLAUDE.md vs. skills vs. hooks is stated but not precisely bounded. A convention that is also a checklist could plausibly go in either place.
  Alex Wang's Post
• uninformedThe post does not address trade-offs or costs of the recommended approach -- e.g., the overhead of maintaining skills and hooks, the risk of over-engineering small projects, or when ad-hoc prompting is actually sufficient.
  Alex Wang's Post
• incompleteThe post ends with a course promotion, raising the question of whether the advice is calibrated to be genuinely complete or deliberately leaves gaps to motivate enrolment.
  Alex Wang's Post
• omissionNo discussion of version control for workspace files, collaboration between multiple users, or backup strategies.
  Anatomy of a perfect Openclaw setup — read next: Best practices for managing AI agent configurations in team settings.
• omissionNo mention of cost implications — longer AGENTS.md means more tokens per session, which affects API costs.
  Anatomy of a perfect Openclaw setup — read next: Token economics of system prompt design.
• commercialThe post is partly a lead-generation piece for the author's 'Build With AI' community, which may bias toward presenting OpenClaw as more powerful/important than alternatives.
  Anatomy of a perfect Openclaw setup — read next: Compare with other AI assistant frameworks (e.g., Claude Code's CLAUDE.md, Cursor rules, etc.).
• incompleteThe 3x-faster / 70%-token-reduction headline is reported without benchmark methodology, task definition, sample size, or comparison protocol. The article notes a community member raised this objection but does not press it. The claim is functionally unfalsifiable as published — any failure to reproduce can be attributed to 'different tasks'.
  With Android CLI, Google is Making the Android Toolchain Agent-Friendly — read next: Look for independent benchmarks from agent-first dev tooling efforts (Cursor, Continue, Aider), and methodology-focused critiques of vendor productivity claims (DORA 2025 AI findings; the Marcus / Yegge debate).
• uninformedThe article does not engage with what 'agent' means as a category. It conflates very different paradigms — Claude Code (long-running, file-system-resident), Codex (completion-shaped), Gemini (chat-shaped) — under one label, even though each has a different appetite for CLI surfaces, skill files, and knowledge bases. The 'compatible with any agent' framing papers over deep differences in how each agent actually consumes tooling.
  With Android CLI, Google is Making the Android Toolchain Agent-Friendly — read next: Anthropic's Claude Code architecture posts; the agent-loop literature (ReAct, function-calling, MCP). Worth a syntopical read with the Claude Code and Osmani agent-patterns pieces already in the library.
• incompleteNo discussion of what gets worse when the toolchain optimizes for agents. Discoverability for human developers, error messages tuned for LLM parsing vs human reading, the regression risk in autogenerated SKILL.md files, the lock-in dynamics of a vendor-curated knowledge base — none surfaced.
  With Android CLI, Google is Making the Android Toolchain Agent-Friendly — read next: Look for second-order critiques of agent-first tooling: who pays when machine-readable wins over human-readable?
• illogicalThe 'eliminate guesswork' framing presumes the right response to LLM unreliability is a more structured tooling surface, but does not address whether the LLM still hallucinates within that surface. A scriptable CLI lets the agent issue precise commands; it does not make the agent's reasoning about which commands to issue any better.
  With Android CLI, Google is Making the Android Toolchain Agent-Friendly — read next: Material on hallucination at the orchestration layer vs the action layer; Anthropic's writing on tool use reliability.
• uninformedThe cited personalization study used an LLM-based developer simulator rather than real developers (a caveat the author names), and the context-file study covers a specific harness/model pairing (Claude Code and Codex). The article doesn't discuss whether either finding would transfer to other harnesses, to less tool-augmented agents, or to real (non-simulated) developer populations, despite building a general prescription on top of both.
  Audit your Agent files — read next: Follow-up studies replicating the personalization and context-file findings with real developer cohorts and across multiple harnesses, to test whether the 'generic beats personal' and 'context files don't move correctness' results are harness-specific artifacts or general findings.
• incompleteVendor concentration risk is structurally absent. 'Enterprise AI transformation' as defined here means 'Anthropic-substrate transformation': every pillar runs on Anthropic surfaces (Claude, Claude Code, Claude Cowork, Claude Managed Agents), every plugin lives in an Anthropic-defined marketplace, and the 11 open-source plugins are Anthropic-authored. The compounding lead the document urges is also compounding lock-in. This is exactly the workflow-lock-in pattern the Founder's Playbook prescribes against competitors — applied here to the customer.
  Building AI Agents For The Enterprise — read next: Cloudflare 'Mythos' retro (already extracted) on dependence dynamics; MCP as cross-vendor portability layer (read the actual MCP spec, not Anthropic's framing of it); any 'multi-model enterprise architecture' practitioner writing.
• incomplete'Local execution' is doing heavy work in the security pitch but is never defined precisely. For a CISO or DPO evaluating Claude Cowork in EEA/Norway, the deciding question is whether the model inference (not just file handling) happens on-premise or in Anthropic's cloud — and what data crosses the boundary in API calls. The document explicitly says 'Nothing is uploaded to a cloud service for processing', which is misleading if the prompt/context still goes to api.anthropic.com (almost certainly the case). This is the single most important precision the document elides.
  Building AI Agents For The Enterprise — read next: Anthropic's own technical documentation on Claude Cowork architecture; Norwegian Datatilsynet guidance on US cloud + EEA data; EU AI Act provider obligations; any sovereign-cloud / partner-cloud Anthropic offerings (Amazon Bedrock, Vertex AI deployments).
• incompleteEU / Norwegian / regulated-incumbent context is entirely absent. The document name-checks 'regulated industries' (financial services, healthcare) but operationalises them as US contexts. EU AI Act obligations on providers and deployers, GDPR data-residency, NIS2 cybersecurity, DORA operational resilience, Norwegian sector-specific guidance (NSM, DigDir), public-sector procurement constraints, sovereign-cloud requirements — none appear. For the reader (Norwegian senior engineering leader, regulated context relevant), this is a substantial blind spot.
  Building AI Agents For The Enterprise — read next: EU AI Act practitioner guides; NSM's AI guidance; DigDir's references on third-party AI; any Norwegian public-sector AI procurement writing (NAV, Skatteetaten, Helsedirektoratet have all published); Healey's AI-advisory-board piece (already extracted) on incumbent AI governance.
• incompleteMid-market and non-multinational enterprises are out of frame. All five named customers are global multinationals (L'Oreal 150 countries, Lyft global, Rakuten 70+ businesses, RBC, Novo Nordisk). A 1,000-3,000 person Norwegian/Nordic incumbent — closer to the reader's likely organisational shape — would face different unit economics, different governance ratios, different plugin-investment payback periods. The document's prescriptions are calibrated for the upper end of 'enterprise'.
  Building AI Agents For The Enterprise — read next: Mid-market AI adoption case studies; Nordic-context enterprise AI writing; Entur AI adoption piece; NAV fast-flow piece.
• incompleteThe build-vs-buy reasoning is one-sided. The case studies (L'Oreal built, Lyft built, Rakuten built then switched) implicitly argue for build, while the prescriptive framing argues for buy. The document does not seriously confront when building remains the right choice (sovereign cloud requirements, sector-specific regulatory chains, vendor concentration risk, unique workflow architectures, or simply that bespoke is what the case studies actually did to achieve the cited numbers). This is the most important business decision and it gets implicit-only treatment.
  Building AI Agents For The Enterprise — read next: Anthropic harness-engineering paper (already extracted) for the technical 'what is a harness' substrate; Bockeler harness-engineering talk (already extracted); Heis ep 11 AI-special on insourcing logic; small-code / Cloudflare-Mythos contrarian harness aesthetic.
• incompleteFailure cases and stranded investments are absent. Every named case study is positive. Enterprises that built pillar-level plugin investments and then watched the underlying model change behaviour, or hit token-cost walls at scale, or saw a competitor leapfrog with a different stack, do not appear. 'Compounding lead' is presented without a 'compounding sunk cost' counter-scenario.
  Building AI Agents For The Enterprise — read next: Post-mortems of enterprise AI programs; 'killed by GPT-5' / vendor-strategy-change narratives; gartner-style 'why N% of AI initiatives fail' research.
• incompleteThe plugin-standardisation political economy is not discussed. 'The best practices of one team become the default for every team' sounds frictionless but ignores the contested-knowledge problem: whose sales process becomes the plugin, who reviews plugin updates, what happens when business units disagree, how plugin versions are deprecated. Cutler-style organisational reality is absent. The document's frame is 'institutional knowledge becomes infrastructure'; the real question is 'whose institutional knowledge'.
  Building AI Agents For The Enterprise — read next: Cutler on overload and institutional dynamics; Heis ep 11 AI-special on enterprise AI politics; anything on internal developer-platform governance (which is structurally similar — plugin marketplaces and IDP marketplaces share dynamics).
• incompleteThe MCP framing is muted because it cuts against the single-vendor positioning. MCP is genuinely a cross-vendor protocol Anthropic authored that other providers are adopting. Framed honestly, it would support a multi-model enterprise architecture; framed as in this document ('a universal standard that allows Claude to connect securely'), it is reduced to 'Claude's USB-C'. The portability story is undersold.
  Building AI Agents For The Enterprise — read next: MCP specification itself; AWS MCP GA announcement (already extracted); Genkit middleware piece (already extracted) for cross-vendor abstraction patterns.
• incompleteAuditability claims are credible but narrow. OpenTelemetry-compatible observability is real and useful. But for the EU AI Act regulatory chain (where you must demonstrate human oversight, risk assessment, conformity assessment, post-market monitoring), traces of 'what Claude did' are necessary but not sufficient. The document does not engage what additional governance instrumentation is needed beyond OTEL traces.
  Building AI Agents For The Enterprise — read next: EU AI Act Articles on high-risk systems documentation; ISO/IEC 42001 AI management system standard; sector-specific AI assurance frameworks.
• incompleteAttention and orchestrator cognitive-load concerns are absent. The document moves employees from 'producing' to 'reviewing and judgement', as if review is purely value-additive. But review fatigue, automation complacency, deskilling of junior staff who never learn to draft from scratch — these are real failure modes the document does not engage. This is the hidden-layer concern (Bailey, Stolen Focus, Cutler on overload) the reader carries.
  Building AI Agents For The Enterprise — read next: Cutler TBM on institutionalised overload + AI; Bailey on attention infrastructure; deskilling literature; Heis ep 9 Brede Moe on autonomy/learning culture in AI-augmented organisations.
• illogicalInternal contradiction between case studies and product pitch. The case studies (L'Oreal, Lyft, Rakuten in its original architecture) succeeded by building custom platforms — exactly what the Chapter 4 pitch tells you not to do. The document handles this by saying 'Claude Cowork changes the equation' going forward, but does not show evidence that Cowork-deployed customers achieve comparable outcomes. The credibility is borrowed; the inference is forward-projected.
  Building AI Agents For The Enterprise — read next: Look for Cowork-specific case studies (none yet provided in this document) when they exist; treat the L'Oreal/Lyft/Rakuten numbers as evidence for transformation worth pursuing, not as evidence for Cowork specifically.
• incompleteNo evidence or reasoning is provided for any of the 32 claims. Every tip is stated as flat assertion. There is no explanation of WHY each practice works, what failure mode it prevents, or how the author discovered it. This makes it impossible to evaluate which tips generalize vs. which are idiosyncratic to the author's workflow.
  Charlie Hills 🦩's Post — read next: Look for experience reports or controlled comparisons of Claude Code workflows (e.g., with vs. without CLAUDE.md, with vs. without branching per task).
• incompleteThe social media format (LinkedIn listicle) constrains depth. Tips like 'Set a scope limit to only the files you name' and 'Replan at halfway to reset the goal' are operationally vague — a reader new to Claude Code would not know how to implement them.
  Charlie Hills 🦩's Post — read next: The author's own linked guides (beginner-to-advanced, design-in-code) likely expand on these compressed tips.
• incompleteNo quantitative evidence is given anywhere in the piece. 'Measurable impact,' 'one of the most used extension points,' 'hundreds of them in active use,' and the nine-category catalog are all asserted without a single number, methodology note, or before/after comparison. A reader cannot tell whether 'measurable' means a rigorous eval or just an internal impression.
  Lessons from building Claude Code: How we use skills — read next: Compare against extract-agent-skills-osmani#g1, which flags the identical evidentiary gap (26K GitHub stars as social proof, no defect-rate data) in a different skills-authoring post — this looks like a structural pattern across the whole skills-advocacy genre, not a one-off omission.
• incompleteThe nine-category taxonomy is offered as a tool for 'identifying gaps in your own skills library,' but gives no guidance for the case it explicitly flags as a failure mode: a skill that legitimately needs to touch two categories (e.g. a CI/CD skill that also needs data-fetching context to decide on a rollout). The advice is only 'the best skills fit cleanly into one' — with no procedure for splitting or resolving a straddling skill.
  Lessons from building Claude Code: How we use skills — read next: Would benefit from the kind of decision-procedure critique already applied to extract-20-loop-design-patterns#g1 (a pattern catalog without selection criteria) — the same 'taxonomy without a decision procedure' gap recurs here.
• uninformedEvery practice described (organic bottom-up marketplace curation with no centralized gatekeeping team, checking skills into repos vs. a plugin marketplace, hundreds of skills in active use) is drawn from a single organization — Anthropic — with mature internal platform tooling, a large engineering org, and presumably existing CI/CD and review discipline. The post never acknowledges that this governance model may only work because of scale and maturity most readers' orgs (or a solo practitioner) don't have.
  Lessons from building Claude Code: How we use skills — read next: Parallels the Google-centrism gap already flagged in extract-agent-skills-google-backed-ai-coding#g3 — worth reading both together as instances of a recurring 'FAANG-scale practice presented as universal' gap in the skills-advocacy corpus.
• illogicalThe piece simultaneously warns against writing skill instructions that are 'too specific' ('avoid railroading Claude') and recommends filling the gotchas section with declarative always-do-X rules ('the subscriptions table is append-only, use the highest version'). Both railroading and a gotcha are stylistically the same speech act — a specific, prescriptive instruction — but the post treats one as a failure mode and the other as the highest-signal content, without ever explaining the line an author should use to tell them apart.
  Lessons from building Claude Code: How we use skills — read next: No corpus doc yet addresses this tension directly; worth testing against the anti-rationalization-table pattern in extract-agent-skills-osmani#p7, which is closer to a principled distinction (a gotcha rebuts a specific rationalization the model has been observed to make, vs. a railroading instruction pre-empts a choice the model hasn't yet needed to make).
• uninformedSkill-to-skill composition is acknowledged as working only informally today (reference another skill by name; 'the model will invoke them if they are installed'), but the post never discusses the failure modes this implies: what happens if the referenced skill isn't installed, or if two composed skills' instructions conflict. This leaves the same kind of router/dependency-reliability question open that extract-agent-skills-osmani#g2 raises about a different (custom, third-party) meta-skill router — except here there isn't even an explicit router to critique, just implicit trust that the model will sort it out.
  Lessons from building Claude Code: How we use skills — read next: Read alongside extract-agent-skills-osmani#g2 and extract-skills-v1-1-wayfinder-flow-skills#p11 — the 'skills as a distribution unit for engineering practice' thesis these two other docs advance depends on composition actually being reliable, which this post concedes it isn't yet.
• incompleteEvery play redefines the human's role (from author to reviewer, from implementer to orchestrator, from on-call responder to incident-queue triager) but the piece never addresses the human cost of that shift — skill atrophy from no longer writing code directly, morale effects of reviewing AI output all day, or how an organization trains new engineers who never practiced the skills the plays assume a senior reviewer already has.
  The AI-Native SDLC playbook — read next: Look for practitioner accounts (not vendor playbooks) of how teams that have run this kind of pipeline for a year or more describe the experience of the reviewer-not-author role, and whether junior engineers develop judgment without first doing the work themselves.
• incompleteSchneier asserts that acquiring a skill instills a moral/ethical code and that this — not the scarcity of dangerous knowledge — is what has kept us safe. The claim is supported only by the rarity of murderous doctors and terrorist engineers, which is equally explained by motive, opportunity and detection. Whether professional socialization actually does the protective work he attributes to it is never examined, yet the whole 'norm-stripping' danger of AI rests on it.
  Cybersecurity and the Gap Between Skill and Ability — read next: Sociology of the professions and their ethics; criminology on why insiders with means rarely offend; work on norms vs. deterrence.
• incompleteThe two central anecdotes (two seniors with different severity thresholds; a junior catching a missing auth check) are both single, author-reported incidents from the author's own consulting practice. No measurement is offered of defect rates, review-quality variance, or time-to-competency before versus after adopting these instructions across a real team over time.
  Encoding Team Standards — read next: Look for quantitative studies measuring review-outcome or defect-rate variance across developers before and after adopting shared, versioned AI instructions, rather than anecdotal before/after accounts.
• incompleteThe article never reports whether the discoverability fixes (enumerated entry points, repository-level routing) actually improved adoption — it explicitly defers this to future observability data ('we'll continue to iterate as we learn'), so the piece's central practical claim (discoverability engineering fixes low adoption) is asserted as a hypothesis, not yet confirmed by the team's own measurement.
  Kafka App? There's a Skill for That — read next: A follow-up Etsy Code as Craft post reporting the observability-table results after the entry-point and routing fixes shipped.
• incompleteNo before/after comparison is given between the old hand-written Kafka apps and Skill-generated ones on error rates, review time, or production incidents — the productivity and security claims rest on general reasoning and cited external research (Stanford study, BaxBench) rather than on Etsy's own data about the pipelines this specific system produces.
  Kafka App? There's a Skill for That — read next: Any Etsy engineering post (or industry study) that measures defect/incident rates for agent-scaffolded infrastructure code against a pre-agent baseline.
• incompleteThe harness's contribution is under-explored and internally in tension: she found swapping OpenCode vs. Pi made little difference, yet Jigar Jani's near-all-local coding depends on continuously enhancing his harness with skills. How much of viability is raw model vs. harness engineering (skills, code-search/understanding tools, self-correction sensors) is left open.
  Experiences with local models for coding — read next: SmallCode-style harness-engineering studies for small models; her own harness-engineering framework; controlled comparisons isolating harness features (progressive disclosure, tool routing, skills) at fixed model.
• incompleteThe transfer of the 'cognitive artifacts' framework from human cognition to LLM systems is asserted but not defended. Human cognitive artifacts augment a general intelligence; LLM externalization compensates for specific architectural limitations (finite context, no persistent state). The analogy may be more misleading than illuminating.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Look for critiques of anthropomorphic framings of LLM capabilities; compare with distributed systems or compiler theory as alternative analogies.
• incompleteThe taxonomy assumes memory, skills, and protocols are 'distinct but coupled' — but the boundaries may be artificial. A skill with embedded memory and protocol-like interfaces blurs all three categories. The abstract does not address how to handle such overlap.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Check whether the full paper provides clear criteria for categorizing borderline cases.
• uninformedThe abstract does not address whether externalization introduces new failure modes (brittleness, composability failures, versioning conflicts) that may offset reliability gains. The framing is almost entirely positive.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Look for systems engineering literature on integration risk; check if the full paper's 'open challenges' section addresses this.
• illogicalThe historical progression 'weights -> context -> harness' is presented as a clean trajectory, but in practice these co-evolve. Larger context windows reduce the need for some externalization; better weights reduce the need for elaborate harnesses. The narrative oversimplifies.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Consider whether a co-evolutionary or dialectical framing would be more accurate than a linear progression.
• incompleteVendor risk is structurally absent. The playbook never names that 'AI-native' as defined here means 'Anthropic-native'. Customers building this way inherit Anthropic's pricing, capability, rate-limit, and product-strategy decisions as critical-path dependencies — exactly the workflow lock-in pattern the Scale chapter prescribes against competitors.
  The Founder's Playbook: Building An AI-Native Startup — read next: Contrast with Cloudflare 'Mythos' retro (already extracted) on what depending on a single AI vendor's pricing and capability surface looks like under stress; read multi-model / model-portability discussions and 'OpenRouter-style' abstraction-layer arguments.
• incompleteNo unit economics. The playbook celebrates leanness in headcount but is silent on token cost at company scale. A 5-person AI-native startup serving 100k users may have COGS that look nothing like the 200-person SaaS company they're imitating. Margin structure, model-price exposure, and gross-margin scenarios are absent.
  The Founder's Playbook: Building An AI-Native Startup — read next: Read recent inference-cost analyses (Baseten, public AI-startup tear-downs); compare to a SaaS gross-margin baseline. Useful: any first-hand founder writing on token-economics post-PMF.
• incompleteExisting-organisation applicability is zero. The reader (a senior engineering leader at an incumbent) gets no help translating this. Almost every prescription assumes a greenfield codebase, no legacy team, no existing change-management constraints, no negotiated CTO/CISO relationship, and full founder authority — none of which holds inside an established organisation.
  The Founder's Playbook: Building An AI-Native Startup — read next: Read incumbent-transformation pieces (Entur AI adoption, NAV fast-flow); Cutler's organisational-operating-system writing; any 'AI in regulated incumbent' case study (Norwegian or otherwise).
• incompleteRegulatory and data-sovereignty depth is absent. Compliance is treated as a Launch-stage to-do (SOC 2, GDPR, HIPAA) rather than a structural constraint. The EU AI Act, Norwegian public-sector procurement, data residency obligations, on-prem requirements, and sector-specific (finance, health, defence) constraints are not discussed and would invalidate or substantially reshape parts of the playbook.
  The Founder's Playbook: Building An AI-Native Startup — read next: EU AI Act practitioner guides; Norwegian DigDir / NSM guidance on third-party AI; Healey's AI-advisory-board piece (already extracted) on AI governance inside organisations.
• incompleteThe model-capability-curve assumption is unnamed but everywhere. The whole playbook implicitly assumes models keep getting better, cheaper, and more available at current rates. If that curve plateaus or regresses, the orchestrator-without-team model becomes much weaker, but the playbook gives no scenarios for that.
  The Founder's Playbook: Building An AI-Native Startup — read next: Gary Marcus and other capability-skeptic writing; cost-curve and scaling-limit discussions; Anthropic's own harness-engineering paper (already extracted) which is more candid about current limits.
• incompleteArchitectural-coherence prescription (CLAUDE.md, specs before code) is good advice but is reintroducing classical software-engineering discipline (formal specs, ADRs, design docs) without acknowledging the lineage. The implicit message — 'this is new' — undersells how much of the prescription is rediscovery.
  The Founder's Playbook: Building An AI-Native Startup — read next: Re-read Kent Beck (Tidy First?), structured-design literature (Yourdon & Constantine), and ADR/design-doc practice writeups against the playbook's reframing.
• illogicalThe non-technical-founder claim and the architectural-discipline claim are in tension. If the prescribed engineering practice (CLAUDE.md, security review, debt remediation, observability) requires architectural judgement, then 'non-technical founder' is doing a narrower kind of work than the document suggests — likely 'prototype and validate', not 'run a Scale-stage company solo'. The playbook never reconciles this.
  The Founder's Playbook: Building An AI-Native Startup — read next: Non-technical-founder case study autopsies; the 'who survives the MVP-to-Launch transition without an engineer' empirical question.
• incompleteSectoral / geographic narrowness. Every example is US, SaaS-shaped, English-language, B2B-leaning. Norwegian / Nordic / public-sector / non-SaaS / B2C / hardware startups are entirely absent.
  The Founder's Playbook: Building An AI-Native Startup — read next: NAV's fast-flow piece; Entur AI adoption; any Nordic-context AI-startup writing.
• incompleteAttention and institutional memory of the founder herself is unaddressed. The playbook moves the founder from execution to orchestration but never asks what kind of attention infrastructure the orchestrator needs, what cognitive failure modes emerge when one person owns judgement across all domains, or how a solo orchestrator builds organisational memory beyond their own head. This is precisely the hidden-layer concern (Bailey, Stolen Focus, Cutler on overload) the reader cares about.
  The Founder's Playbook: Building An AI-Native Startup — read next: Cutler TBM 412 (institutionalised overload + AI), Bailey on attention infrastructure, anything on cognitive load of high-context orchestration roles.
• incompleteThe argumentative framing — 'AI-native is the right framing' — is never set against its alternative ('AI-augmented' as integration into existing patterns; 'AI-using' as a feature choice). The playbook treats 'AI-native' as the default future rather than as one strategic posture among several.
  The Founder's Playbook: Building An AI-Native Startup — read next: Read alternative framings: AI-augmented engineering writeups, smallcode-style minimalism (already extracted), and the broader 'is AI-native a category or a marketing label?' debate.
• incompleteNo treatment of the social-and-organisational fate of the artefacts themselves. Dependency-cruiser configs, custom coupling-analyser CLIs, and imported Modularity Skill packs are all new load-bearing artefacts. Who owns them? Who updates them when the architecture should change? In the absence of an owner, the rules outlive the intent behind them and become either silently violated or silently obsolete — the classic linter-suppression-debt pathology, scaled to architecture.
  Three more static code analysis sensors — read next: Cutler on institutionalised overload and waste; Fearless Change (Manns & Rising) on what it takes for organisational invariants to survive; Tornhill's Software Design X-Rays on attaching social/ownership data to code-quality signals; Vlad Khononov's modularity work directly (since his Skills are now part of the harness).
• incompleteThe article treats the dependency-cruiser rule set as a substitute for a markdown structure guide, but it skips the question of whether enforcement and explanation are interchangeable. A rule that says 'clients cannot import services' enforces a constraint but does not teach why the layering exists — and the moment the constraint is wrong, the team has no shared prose to reason with. This silently relocates design intent into tooling that few people maintain, and few people can read.
  Three more static code analysis sensors — read next: Ousterhout 'A Philosophy of Software Design' on the role of design documents; Parnas on module specifications; Hickey 'Simple Made Easy' for the distinction between rules-as-policy and rules-as-understanding.
• incompleteHeavy reliance on Khononov's externally maintained Modularity Skills pack as the thing that makes Sensor 3 work. The article does not examine: skill-pack versioning, drift, security/supply-chain assumptions, or what happens when the skill author changes their mind. The harness now has a third-party dependency at the level of taste, not just at the level of code.
  Three more static code analysis sensors — read next: Khononov's Learning Domain-Driven Design and his coupling talks; literature on prompt drift; the emerging 'skills-as-dependency' discussion (Osmani's agent-skills writing).
• incompleteThe coupling-analyser is described as a vibe-coded custom CLI. The article acknowledges it would benefit from suppression of legitimate high-coupling hubs but does not engage with the more interesting question: if your coupling tool requires hand-curated exceptions for every architectural pattern, you are effectively encoding architectural intent in two places (the rules AND the exception list). At that point, why not skip the metric layer and go directly to the inferential review?
  Three more static code analysis sensors — read next: Tornhill, Software Design X-Rays; the dependency-cruiser community's own discussion of when DSM-style tools earn their keep.
• incompleteThe article observes that the AI modularity review found duplicate routes, scattered parameters, and misplaced auth — i.e. exactly the things a senior reviewer would find in a half-hour read of the code. There is no contrastive baseline against human-only review, against pair-review with the original implementing agent, or against a much cheaper rubric like 'review every file changed >X times in the last 30 days'. Without such a baseline, the proposition 'the review is the best available sensor' is unfalsifiable on the evidence given.
  Three more static code analysis sensors — read next: DORA reports' methodology on baselines; Beck on test-commit-revert and 'starving genies' as alternative scaffolds for keeping AI-edited code honest.
• incompleteNo engagement with the relationship between this approach and existing fitness-function / architecture-as-code tooling (ArchUnit, NetArchTest, ts-arch, Modulith, even Structure101). dependency-cruiser is one point in a much larger design space; treating it as 'the' dependency-rules sensor leaves the reader without a sense of where the boundary lies between custom configuration and adopting an established framework.
  Three more static code analysis sensors — read next: Ford/Parsons/Kua 'Building Evolutionary Architectures' on fitness functions (which she links to in the framing); ArchUnit; ts-arch.
• incompleteThe framing assumes the agent is always the implementing actor and the human (plus other agents) are the reviewers. It does not consider the inverse case — where humans implement and the AI modularity review is the rubric against which their code is judged — even though the same tooling would work. This matters because it shapes whether the harness is 'AI guardrails' or 'organisational architecture discipline that happens to use AI'.
  Three more static code analysis sensors — read next: Cutler on operating-system design; Beck on team practices.
• incompleteProduction-cost realism is thin: the author (self-described non-software-engineer) asserts you can build a web app or produce cinematic video 'without high-end skills' via coding harnesses and consumer tools, but doesn't address the actual skill floor, tooling access, or organizational approval overhead in a regulated or non-creative-adjacent workplace (e.g. a telco) where such tools may not be readily available or sanctioned.
  Do you even need a presentation? — read next: Would benefit from a practitioner account of building infodecks/microcourses inside a large, non-media, non-consultancy organization to test whether the low-barrier claim survives outside a design-forward consultancy like Thoughtworks.
• unstated assumptionFowler's curation implicitly assumes that the discipline-vs-tarpit tension is the defining axis of AI-assisted development, but economic and organizational dimensions (team structure, hiring, skill deskilling) are largely absent from the fragments selected.
  Fragments: May 5 — read next: Cross-reference with pieces on how AI changes team composition and organizational design (e.g., the 'kill your org chart' literature).
• implicit premiseThe local-model argument rests on a single practitioner's 'good enough' assessment (van den Ende). There is no quantitative comparison of local vs. cloud model performance on real engineering tasks, leaving the threshold claim unsubstantiated.
  Fragments: May 5 — read next: Look for benchmarks comparing local open-weight models (e.g., Llama 3, Mistral) against cloud models on SWE-bench or similar agentic coding evaluations.
• selection biasThe fragments are curated from Fowler's professional network (ThoughtWorks colleagues, Beck, Jessitron, RedMonk) — a community that values craft and internal quality. The 'move fast and let AI clean up later' perspective is represented only as a foil, not through its strongest advocates.
  Fragments: May 5 — read next: Seek out arguments from the 'galaxy brain' camp — practitioners or companies that have successfully scaled with AI-generated code despite low internal quality.
• uninformedThe retail case study and the distributed-ownership argument assume each skill maps cleanly to one owning domain team, but does not address what happens when two teams' skills legitimately compete for the same trigger (overlapping description keywords) in a large, many-team organization — a scaling failure mode distinct from the four it names (trigger, execution, token budget, regression), closer to a governance/arbitration problem than a technical one.
  Agent Skills — read next: Read against software-architecture literature on team-boundary design (e.g. Conway's Law, bounded contexts) applied to skill ownership rather than service ownership.
• incompleteThe paper asserts skills are portable across vendors and runtimes (Claude Code, Codex CLI, Gemini CLI, Antigravity) via the shared agentskills.io format, but — beyond noting that install paths, activation rules, and tool-whitelisting details differ per tool — does not report any direct empirical comparison of the same SKILL.md executed across multiple harnesses to verify truly identical behavior, leaving the portability claim's practical reliability untested within the paper itself.
  Agent Skills — read next: Compare the same SKILL.md's measured trigger accuracy and execution fidelity across at least two different coding-agent harnesses.
• incompleteThe article never interrogates whether 'middleware' is the right metaphor. HTTP middleware sits in a deterministic request/response pipeline; the agent tool loop is non-deterministic, multi-step, and stateful. The Genkit hooks may be closer to Aspect-Oriented Programming (cross-cutting advice around named join points like generation/model/tool) than to a Connect/Express chain. The conflation matters: AOP-style weaving creates classic 'where does the behavior live' debugging problems, which the Developer UI alone may not solve.
  Google Introduces Middleware Architecture for Genkit Applications — read next: Read the original Google blog post for the actual API surface; read Genkit source for what 'middleware' resolves to at runtime; compare with LangChain callbacks/handlers and OpenAI Agents SDK guardrails as alternate models.
• incompleteNo mention of failure modes specific to LLM systems — non-deterministic outputs, cascade hallucinations under retry, fallback models with different safety calibrations, approval gates that humans rubber-stamp under volume. The catalog implies these are solved patterns; production experience suggests otherwise.
  Google Introduces Middleware Architecture for Genkit Applications — read next: Look for postmortems and practitioner reports on retry/fallback behavior in agentic systems — the gap between 'we shipped retries' and 'retries work safely' is where the interesting engineering lives.
• incompleteThe piece treats observability as solved by Developer UI inspection but does not address production observability — how middleware traces flow into OpenTelemetry, structured logs, or SRE alerting. Dev-time inspection and production telemetry are different problems.
  Google Introduces Middleware Architecture for Genkit Applications — read next: Compare with OpenTelemetry's GenAI semantic conventions, and with Honeycomb/Datadog's emerging LLM-observability stories.
• incompleteThe implicit programming model is never made explicit. Three options coexist in the article: (a) HTTP-style middleware chain, (b) AOP-style advice around join points, (c) callback registry à la frontend frameworks. Each has different composition semantics and different debugging stories. The choice is the architecture.
  Google Introduces Middleware Architecture for Genkit Applications — read next: Genkit RFC/design docs if they exist; the Anthropic skills system as a contrasting design; LangChain's callback model for a third reference point.
• incompleteNo discussion of Goodhart's law — that turning a measure into a target erodes its value as a measure. With 10,000+ vendor-friendly tasks and labs explicitly racing to improve scores, this is the central risk the piece sidesteps.
  Kaggle is making AI benchmark creation effortless — read next: Manheim & Garrabrant on Goodhart taxonomies; recent evaluation-contamination work (Sainz et al., Zhou et al.); Gary Marcus on benchmark-overfitting in LLM math performance.
• incompleteNo quality-control story: who reviews tasks, who detects duplicates or trivially-gameable items, who flags contamination when the same agents author both tasks and solutions.
  Kaggle is making AI benchmark creation effortless — read next: HELM and BIG-bench review processes; METR/Apollo on adversarial eval design; the DORA 2025 finding that AI productivity gains correlate with deteriorating evaluation rigor.
• incompleteConflict-of-interest framing is absent. Kaggle is Google; Gemini is Google; leaderboards influence purchasing and research narrative. A genuinely 'trustworthy' eval substrate needs a story for vendor neutrality.
  Kaggle is making AI benchmark creation effortless — read next: MLCommons governance model; Stanford HELM independence claims; AI Snake Oil on platform-vendor evaluation.
• incompleteThe implicit definition of 'benchmark' collapses to 'any scorable single-shot prompt.' This may be category-confusion with what the eval community means by 'benchmark' (a curated, statistically powered suite).
  Kaggle is making AI benchmark creation effortless — read next: Liang et al. on HELM construct validity; recent agentic-eval work (SWE-bench Verified, GAIA) on what makes a task suite vs. a task-bag.
• uninformedNo engagement with the mounting literature showing LLM math benchmarks are heavily contaminated and that pass-rates do not transfer — the very example task ('300+140=460') is in the genre most criticized.
  Kaggle is making AI benchmark creation effortless — read next: Marcus & Davis on LLM arithmetic; Apple's GSM-Symbolic paper; arithmetic reasoning critiques 2024-2026.
• incompleteThe entire piece is framed around 'the developer' as a single individual user choosing and configuring their own agentic IDE. It never addresses how a team shares or negotiates persistent memory, a skills library, MCP server configuration, or spec-driven artifacts collectively — a genuinely open question for team-scale (not individual) agentic-IDE adoption.
  10 Things Developers Want from their Agentic IDEs in 2025 — read next: extract-git-real-team-coding-agents and extract-claude-code-meetup-odense directly address team-scale (not individual) agent-harness coordination.
• evaluativeNo empirical comparison to competing agent frameworks (LangGraph, CrewAI, AutoGen, Semantic Kernel) on durability, latency, or cost.
  JobRunr Introduces ClawRunr, an Open-Source Java AI Agent — read next: Hands-on benchmarks or independent reviews of Spring AI vs. LangGraph for durable agent workloads
• securityShell execution and broad file access are powerful tools, but sandboxing, permission scoping, and audit trails are not described.
  JobRunr Introduces ClawRunr, an Open-Source Java AI Agent — read next: Security guidance for self-hosted agents with shell/tool access (Anthropic's Computer Use safety, OWASP LLM Top 10)
• scalabilityH2 embedded DB suggests single-node use, but limits (task throughput, concurrent channels) are unstated.
  JobRunr Introduces ClawRunr, an Open-Source Java AI Agent — read next: JobRunr Pro / enterprise deployment guidance for scaling to external DBs
• observabilityRich monitoring is offered for jobs, but no treatment of LLM-side observability: token accounting, budget controls, prompt regression testing, tool-call correctness, reasoning quality.
  JobRunr Introduces ClawRunr, an Open-Source Java AI Agent — read next: LLM observability tooling (LangSmith, Langfuse, Arize) and evaluation frameworks
• designUnclear how SKILL.md files interact with the dynamic tool discovery index, or how skill collisions/overrides are resolved.
  JobRunr Introduces ClawRunr, an Open-Source Java AI Agent — read next: ClawRunr source for skill registration logic; Anthropic skills documentation for collision/precedence patterns
• licensingLGPL-3.0 implications for embedding ClawRunr in proprietary products are not analyzed.
  JobRunr Introduces ClawRunr, an Open-Source Java AI Agent — read next: FSF guidance on LGPL-3.0 in enterprise software; comparison with Apache 2.0 for similar projects
• evaluationNo methodology for agent quality (success rates, regression testing) accompanies the production-readiness claims.
  JobRunr Introduces ClawRunr, an Open-Source Java AI Agent — read next: Agent evaluation literature: AgentBench, SWE-bench, internal eval harness design
• missing-evidenceNo quantitative results are reported — no efficiency gains, cost savings, incident-resolution times, power reductions, or comparisons to pre-platform baselines. Benefits are asserted qualitatively.
  Meta Deploys Unified AI Agents to Automate Performance Optimization at Hyperscale — read next: Meta's underlying engineering blog post (engineering.fb.com, 2026-04-16) for any concrete numbers; Google SRE literature on measuring autonomic systems; Borg/Autopilot papers for baseline comparisons.
• missing-mechanismNo technical detail on agent architecture — model choice, planner/executor design, tool taxonomy, or the skill authoring workflow. 'Encoded expert knowledge' is asserted but the encoding format and lifecycle are opaque.
  Meta Deploys Unified AI Agents to Automate Performance Optimization at Hyperscale — read next: Anthropic's agent-skill design notes; LangGraph/AutoGen orchestration patterns; original Meta engineering blog for architecture diagrams.
• missing-human-factorThe human oversight model is opaque — where humans sit in the loop, how on-call interacts with autonomous remediation, and how the skill-authoring role is staffed and incentivized is not described.
  Meta Deploys Unified AI Agents to Automate Performance Optimization at Hyperscale — read next: Erik Hollnagel on joint cognitive systems; recent AIOps literature on socio-technical autonomy; SRE staffing patterns under increasing automation.
• missing-prior-artNo engagement with prior art — classical autoscalers, control theory, Google's Autopilot/Borg, IBM's autonomic computing program, or the established AIOps category. The 'shift to continuous automation' claim is hard to calibrate without this context.
  Meta Deploys Unified AI Agents to Automate Performance Optimization at Hyperscale — read next: Burns et al. on Borg/Omega; IBM autonomic computing manifesto (Kephart & Chess, 2003); Google Autopilot paper (EuroSys 2020); Gartner AIOps reports.
• single-sourceThe article relies heavily on Meta's own engineering blog post; no independent verification, skeptical voices, or counter-evidence. The convergence narrative bundles 'agents,' 'AI orchestration,' and 'AI-optimized hardware' under one frame, potentially obscuring meaningful technical differences.
  Meta Deploys Unified AI Agents to Automate Performance Optimization at Hyperscale — read next: Cross-reading: Google's enterprise-agent announcement, Cast AI's product docs, and AWS Compute Optimizer documentation to verify whether the 'convergence' is real or a journalistic framing artifact.
• generalizabilityGeneralizability is asserted but not demonstrated. Meta has unusually rich observability and tooling; whether this approach works in environments without that substrate is unclear.
  Meta Deploys Unified AI Agents to Automate Performance Optimization at Hyperscale — read next: OpenTelemetry and observability-as-a-product literature; comparative case studies of mid-scale enterprises attempting AIOps.
• incompleteThe 17% figure lacks context: how were the reviewed Skills sampled? Is this 17% of all Skills or 17% of a targeted subset? The total corpus size (341 malicious) is mentioned but the denominator is unclear
  Incident 1368: Malicious OpenClaw Skills Reportedly Delivered AMOS Stealer and Exfiltrated Credentials via ClawHub — read next: Read the original Bitdefender Labs report (linked via SOC Prime) for methodology details
• incompleteNo attribution or threat-actor analysis despite the single-IP indicator suggesting a coordinated campaign
  Incident 1368: Malicious OpenClaw Skills Reportedly Delivered AMOS Stealer and Exfiltrated Credentials via ClawHub — read next: Search for threat intelligence reports linking the identified IP and AMOS Stealer campaigns to known threat actors
• incompleteThe 'rethinking' is asserted rather than performed. The article never enumerates the prior harness assumptions being overturned (e.g., DAG-based orchestration, deterministic tool dispatch, code-defined skills, developer-mediated change) nor articulates the new principles replacing them beyond 'skills written in English.' For a piece titled 'Rethinking the Agent Harness,' the actual rethink is one anecdote and one neologism.
  This Week in AI: Rethinking the Agent Harness — read next: Berryman & Ziegler, 'Prompt Engineering for LLMs' (the cited O'Reilly book); Anthropic's own Claude Code design docs; the Stanford paper at arXiv:2603.28052; Birgitta Böckeler's 'harness engineering' piece for an attempt to actually decompose the harness layer.
• incompleteSingle-case generalization. The unity ('build your own harness') rests almost entirely on one consulting client where it 'worked perfectly.' No failure modes, no boundary conditions, no comparison to cases where a bespoke app or a wrapped product would still be the right choice.
  This Week in AI: Rethinking the Agent Harness — read next: Post-mortems of agent deployments at scale; the Cognition/Devin retrospectives; harness-engineering writeups from teams shipping to production rather than consultants.
• incompleteThe relationship between the three sections is unargued. Mythos, the compute buildout, and the harness thesis are juxtaposed without the article noticing that they imply different theories of where AI value is moving — model layer (compute), capability frontier (Mythos), or harness layer (Berryman). The implicit reconciliation would be the most interesting move and isn't made.
  This Week in AI: Rethinking the Agent Harness — read next: Articles framing 'value migration in the AI stack' explicitly; investor letters or analyst notes that try to resolve which layer captures economic returns.
• incompleteThe 'open agent protocol' is named without being specified. No design sketch, no examples of what an environment-supplied skill looks like, no comparison to existing proposals (MCP, A2A, agent-to-agent protocols). The reader is left with a direction but no testable proposal.
  This Week in AI: Rethinking the Agent Harness — read next: Anthropic's Model Context Protocol spec; agent interoperability proposals from Google, OpenAI, and the LangChain ecosystem; the future-cast section in the next Berryman appearance.
• uninformedSchneier's challenge to Mythos's uniqueness is mentioned and then immediately set aside ('either way, it's a problem that's coming'). The article does not engage with the substantive question of whether the policy response is calibrated to actual differential capability or to perceived capability — a question whose answer matters for whether FDA-style review is wise.
  This Week in AI: Rethinking the Agent Harness — read next: Schneier's full post on Mythos; CAISI's framing; counter-arguments from researchers who replicated Mythos-like findings on cheaper public models.
• illogicalMild equivocation on 'harness.' Claude Code (a specific product), 'the agent harness' (a layer), and Berryman's bespoke consulting build (a specific instance) are used interchangeably. A reader could leave thinking 'use Claude Code' and 'build your own harness' are the same recommendation, when the article's argument actually requires the latter and only points at the former as an example.
  This Week in AI: Rethinking the Agent Harness — read next: Explicit harness taxonomy work — what distinguishes a product, a framework, and a bespoke harness — e.g., Böckeler's 'harness engineering' piece.
• incompleteThe 'payoff' of natural-language skills — SMEs read faulty responses and edit instructions directly, skipping the PM/engineer relay — is presented as an unambiguous win with no discussion of governance: version control, review, testing, or drift when non-engineers edit the natural-language logic driving production agent behavior.
  Zero to Agent in 30 Minutes: Build a Workflow Agent with John Berryman — read next: Corpus material on skills-driven harness governance and agent self-documentation would address the maintenance/oversight question this piece leaves open.
• incompleteThe post frames the fix entirely as scaffolding bolted onto the individual agent (skills, workflows, anti-rationalization tables) and never addresses who performs the human senior-engineer role — review, judgment calls on ambiguous scope, final accountability — once a team scales up agent usage faster than it scales up senior human reviewers. A 'capable junior' needs a senior somewhere in the loop; the post doesn't say where that capacity comes from at team scale.
  Agent Skills: Bridging AI and Senior Engineer Practices — read next: Look for team/org-level treatments of reviewer capacity and accountability once a large share of PRs are agent-authored — e.g. whether review throughput, not agent discipline, becomes the binding constraint.
• incompleteThe post offers only adoption metrics (71,000 stars, 13 contributors) as evidence the release is good, with no measure of review effectiveness -- no change in defect catch rate, false-positive rate, or time-to-mergeable-PR before vs. after the 0.6.3 structural-review upgrades. Popularity is not evidence the review skill actually works better.
  Addy Osmani's Post (Agent Skills 0.6.3 release) — read next: The corpus's agentic-code-review piece, with its multi-dataset defect-rate and review-duration measurements, is the kind of evidence this release announcement lacks for its own claims.
• incompleteThe closing claim that the skill pack runs across eight different agent surfaces 'because it's Markdown' addresses file portability but not judgment portability -- whether a 'reduce, don't relocate' structural lens produces consistent findings when interpreted by agents built on very different base models with very different native code-review competence is never addressed.
  Addy Osmani's Post (Agent Skills 0.6.3 release) — read next: Osmani's own earlier Agent Skills piece (extract-osmani-agent-skills-senior-engineer-practices) frames agents as capable-junior-engineer analogues with uneven instinct for invisible senior-engineer steps -- directly relevant to whether a portable skill file produces portable judgment.
• incompleteThe 'Improve Codebase Architecture' skill is mentioned but described only as 'quite complicated' — the talk does not explain how to refactor a shallow-module codebase into deep modules, which is the hardest step.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Read Ousterhout's A Philosophy of Software Design chapters on deep modules; explore the mattpocock/skills GitHub repo for the actual skill implementation.
• incompleteThis is an ephemeral changelog: the durable content is the workflow patterns, but the specifics (skill names, install commands, version numbers, which skills replace which) are a snapshot of a fast-moving single-author repo, and the actual reasoning and prompt text live in the GitHub repo, not the video. The author himself defers detail ('I will make an entire video about Wayfinder'). Watching the video without the repo leaves the patterns without their implementation.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets — read next: Read the actual skills repo and its v1.1 release notes, plus the promised standalone Wayfinder video, for the concrete prompt text; treat named skills as liable to be renamed or removed in the next release.
• evidentialOnly one bug class demonstrated — the TOCTOU race condition. No evidence the technique works for other common flakiness causes: environment-dependent tests, time-sensitive tests, test-order dependencies, resource leaks, or non-deterministic external services.
  Teaching an AI Agent to Debug Flaky Tests
• conceptualThe claim of 'deterministic' debugging conflates procedural repeatability with outcome reliability. The agent's interpretation of the coverage diff is still probabilistic, and the article does not measure how often the agent correctly identifies root causes across varied bugs.
  Teaching an AI Agent to Debug Flaky Tests
• practicalThe technique requires the flaky test to actually fail during the collection runs. For tests that fail once in thousands of runs, the script's loop-until-both-outcomes approach may be impractical without guidance on how many runs are needed.
  Teaching an AI Agent to Debug Flaky Tests
• conceptualAssumes line-level coverage granularity is sufficient. Some flakiness may involve identical line-level execution with different data values, timing, or ordering that coverage cannot capture.
  Teaching an AI Agent to Debug Flaky Tests
• incompleteThe article never operationalizes what a Skill IS at the runtime level. Persistent across conversations could mean (a) system-prompt fragment retrieved by trigger, (b) tool entry in the model's available toolset, (c) per-account fine-tuned adapter, (d) execution graph stored against the account. Each option has very different governance, observability, and failure-mode profiles.
  xAI Releases Grok Skills and Updates Tool Calling Responses API — read next: Pair with the Google Genkit middleware extract — Genkit's middleware metaphor and Skills-as-runtime-artifact are unrelated abstractions that both claim to wrap agent execution. Worth a syntopical pass: what is the actual unit of customization across these vendors?
• incompleteThe Grok-vs-OpenAI-vs-Claude-vs-Vercel comparison is asserted but not analyzed structurally. The article uses workflow/agent/developer-extension as distinguishing terms without defining them. The user's recent extractions (Anthropic dev newsletter, Console.dev, Genkit) provide the comparative scaffolding the article lacks.
  xAI Releases Grok Skills and Updates Tool Calling Responses API — read next: Direct syntopical reading: extract-anthropic-developer-newsletter-2026-05.json + extract-google-genkit-middleware.json + extract-console-dev-best-tools-and-betas.json + this piece. Central question: 'What is a Skill?' across vendors.
• incompleteTight X-platform integration is offered as the moat, but the article doesn't engage what happens to Skills tied to X if a user multi-homes across LLM vendors (the norm for power users). The implicit premise — that X integration is sticky enough to outweigh model-quality and tool-ecosystem competition — is undefended.
  xAI Releases Grok Skills and Updates Tool Calling Responses API — read next: AI Daily Brief on Google v Claude Code (already extracted) — same question of platform moats vs. model quality; xAI is making the inverse bet.
• incompleteGovernance is absent. AWS MCP extraction surfaced 'IAM-bounded ≠ governed' as the load-bearing over-claim; xAI's piece doesn't even attempt the IAM analogy. Account-level Skills with cross-platform persistence and tool access (William Wallace's GitHub-connected example) raise auditability and credential-isolation questions the article doesn't acknowledge.
  xAI Releases Grok Skills and Updates Tool Calling Responses API — read next: Pair with the AWS MCP GA extract — same agent-tooling category, very different governance surface.
• incompleteNo evidence is given that the handoff file actually works cross-model — no example output, no side-by-side of a ChatGPT/Gemini continuation versus the original Claude session, no discussion of failure modes (e.g. a different model interpreting 'tone rules' differently, or silently dropping information under its own context limits).
  Yonathan Cohen's Post — read next: extract-agent-skills-osmani (which raises the identical unverified-portability question for Agent Skills generally) and extract-anthropics-three-agent-harness (which specifies what a production handoff artifact needs and how quality is graded) for a more rigorous treatment of what a handoff artifact must contain and how portability claims should be tested.
• uninformedThe post conflates a Claude.ai message-limit ('You're out of messages for a few hours') with Claude Code's context-usage percentage (90% trigger) as though they were the same mechanism, without acknowledging they are different products with different constraints.
  Yonathan Cohen's Post — read next: No specific reading direction beyond noting the terminology looseness typical of promotional posts.