GitHub's gh skill command boosts AI agent productivity

As AI agents become core to our development workflows, a new governance problem is emerging: fragmented, unversioned prompts scattered across IDEs and local environments — what I'd call Instruction Drift. The new gh skill command in GitHub CLI is a meaningful step toward solving this. It treats Agent Skills as first-class citizens in the software delivery lifecycle: Centralized Discovery & Management — Standardize agent capabilities across the engineering org, installed via a single CLI command from any GitHub repository. Supply Chain Integrity for AI — Skills are pinned using git tree SHAs and immutable releases, ensuring the skill an agent uses today is byte-for-byte identical to what it uses tomorrow. No silent updates, no non-deterministic failures. Open Interoperability — Built on the open 'agentskills.io' spec, skills work across GitHub Copilot, Claude Code, Cursor, Codex, Gemini CLI, and more. No vendor lock-in. One important caveat worth noting: skills are not verified by GitHub — always inspect before installing (gh skill preview). This is exactly the kind of governance control your platform teams should be building policy around. Currently in public preview, but the architecture signals where this is heading: from experimental AI scripts to auditable, versioned, production-grade agent infrastructure. Read the full changelog #GitHubCopilot #GitHubCLI #AIAgents #AgentSkills #PlatformEngineering #AIGovernance #SupplyChainSecurity #EnterpriseAI #SolutionArchitect #DeveloperTools #DevOps #GenerativeAI #SoftwareEngineering #OpenSource #AI #developers #DeveloperCommunity #GitHub

At some point in early 2026, the majority of code committed to GitHub became AI-written. No announcement. No blog post. No confetti. We just crossed it. Here's why the number is wilder than it sounds: in 2023, GitHub Copilot was writing 46% of code — but only in Copilot-enabled projects, for users who had opted in. In 2026, 51% is across the entire platform. Two years. Enormous leap. The productivity story is real. Solo devs shipping full apps. Teams cutting cycles in half. I'm not arguing against any of that. But there are questions nobody wants to ask: What happens to open source when most of the code wasn't fully understood by the person who committed it? AI code has 1.7x more major issues and 2.74x higher security vulnerability rates than human-authored code (CodeRabbit, 2026). It looks fine. It often isn't. And the provenance loop is genuinely strange: AI models trained on GitHub code now write GitHub code that goes back into GitHub. Future models train on that. Nobody has a clean answer for what that does to software quality over time. The practical change I'd make: stop reviewing AI code the same way you review human code. The failure modes are different. You're not looking for "what did the author miss" — you're asking "what did the model assume about my system that it couldn't actually know?" Most teams haven't made that cognitive shift yet. We crossed a threshold. The least we can do is notice what it means. https://lnkd.in/eHjNQDXU

If you maintain an open source project, you already know: your code doesn’t get judged by your benchmarks. It gets judged by your Getting Started guide. If step 3 fails… Nobody opens an issue. Nobody asks for help. They just close the tab. We learned this the hard way on Drasi (one of the projects in our Open Source Incubations team) when an upstream Dev Container update bumped the minimum Docker version and silently broke *every* tutorial by disrupting the Docker daemon connection. No failing builds. No red CI. Just a broken onboarding experience for every new developer trying the project. So we stopped treating documentation like something you occasionally QA and started treating it like something you monitor. Using GitHub Copilot, the Drasi team built an AI agent that behaves like a brand‑new user and executes tutorials exactly as written, with no tribal knowledge, no assumptions, and no skipped “obvious” steps. Which turns out to be perfect for catching things like implicit steps we forgot to write down and silent drift when dependencies or configs change upstream. We can do this before our community ever hits them. This is the kind of AI‑augmented workflow I’m most excited about in OSS: Not just writing code faster but making projects easier to adopt and contribute to. If you’ve ever rage‑quit a tutorial, this one’s for you: How Drasi used GitHub Copilot to find documentation bugs: https://lnkd.in/gjURztdh Would love to hear how other maintainers are thinking about testing docs like code. #OpenSource #Maintainers #CNCF #GitHubCopilot #DevEx #Drasi

Manage agent skills with GitHub CLI Agent skills are the new way to give your agents super abilities !! GitHub is launching gh skill, a new command in the GitHub CLI that makes it easy to discover, install, manage, and publish agent skills from GitHub repositories. Skills are portable, reusable packages of instructions, scripts, and resources that extend the specialized capabilities of AI agents. Unlike generic instructions, skills allow an agent to become a "specialist" in a specific domain—such as legal workflows, data analysis, or debugging—by bundling complex procedural knowledge into a modular format. https://lnkd.in/g_wvBcrs

built something this week that's been bugging me for a while coding agents are getting good at reading code. but every new session they start completely blind — no memory of why anything was built the way it was. why did we switch from JWT to sessions? why is Redis here? why is the rate limit 10 req/min? that context lives in the head of your colleague who switched teams, a Teams chat you're not a part of, and these days by an agent whose context window is 90% full and can't triage why. so i built MemoryOS — a memory layer for coding agents that makes the "why" behind every commit queryable. not another RAG wrapper. the unit of memory is a commit, not a message. v1 is live and proves the hypothesis — if you give agents structured reasons behind commits, they can query them intelligently and retrieve the right context at the right time. → live demo: https://lnkd.in/eaMhNaaM → github: https://lnkd.in/e496kuJP v2 is where it gets interesting — auto-capture, neural embeddings, graph UI that gives you a full cognitive map of your codebase. parallel agents sharing one memory layer. early days. if you're building coding agents or agent infra and want to talk, drop a comment or DM me 🦾

I stopped caring about GitHub stars. Here's why you should too. GitHub stars used to mean something. A stamp of quality. Engineers vouching for good code. Not anymore. The AI wave broke that signal. Stars now measure virality, not usability. Here's what I found after testing 15+ viral AI repos over the last few weeks. 1. Most viral repos are barely functional Clone. Install. Run. Crash. Half of them break on step one. The README looks polished. The code doesn't. 2. Hardcoded configs everywhere API keys in source. Paths assuming Mac. Model names baked into strings. Zero thought given to anyone actually running this in production. 3. AI slop results The demo looks incredible. The actual output on your data? Borderline useless. Cherry picked examples in the README. Real world performance nowhere close. 4. One developer. No maintenance. Check the commit history. Big burst of 50 commits in week one. Then silence. Issues pile up. PRs rot. The author moved on to the next viral idea. 5. Stars are mass produced now Tweet goes viral. HN front page. 10K stars in 48 hours. 90% of those people never cloned the repo. They starred and scrolled. 6. README driven development Beautiful docs. Architecture diagrams. Fancy badges. Open the source? 200 lines of spaghetti wrapping an API call. 7. The real signal is in the Issues tab Stars tell you nothing. Issues tell you everything. Are bugs getting fixed? Are maintainers responding? Is anyone actually using this in prod? What I do instead I stopped sorting by stars. Now I look at three things. Commit frequency in the last 90 days. Ratio of closed issues to open ones. Whether anyone in the Issues tab is running it in production, not just "cool project!"

One of my favorite AI Automation personally! Documentation rarely fails loudly — it just quietly loses users. Learn how our Drasi team used GitHub Copilot as a “synthetic new user” to continuously test their documentation and surface bugs before real developers hit them. - Documentation breaks due to silent drift, not just bad instructions - Manual doc testing does not scale for fast‑moving open source projects - Treating documentation testing as a monitoring problem is a mindset shift - GitHub Copilot can follow instructions exactly as written, exposing gaps humans miss - “Getting started” guides deserve the same rigour as production code For many developers, documentation is the product. If the first experience fails, trust is gone — and users simply move on. If you’re shipping faster than you can manually test your docs, this is well worth reading. Read the full article here: How Drasi used GitHub Copilot to find documentation bugs https://msft.it/6042QfMT4 #OpenSource #GitHubCopilot #DeveloperExperience #Documentation #AIinDev #CloudNative #CNCF #MicrosoftAdvocate #MicrosoftEmployee #DevRel

You write a GitHub Issue. You set a label. You grab a coffee. The Guild takes it from there. Five agents. Each one knows its job. Guild.Scribe turns the issue into a spec. Architecture decisions, edge cases, acceptance criteria. Written before a single line of code is touched. Guild.Smith builds. Reads the spec, opens a branch, writes the code, opens the PR. Guild.Warden reviews. Not alone. Three independent perspectives on the same PR. AI systems are prone to groupthink. Three voices break that. After the merge, Warden looks again. Backend test coverage, Storybook coverage, deferred findings, AI code verbosity. Everything that slipped through goes into a backlog. The Guild picks it up. Guild.Seal merges. Watches CI, waits for green, closes the loop. Guild.Werkstatt orchestrates. Reads the label, picks the next agent, passes the baton. The state machine is GitHub labels. Not a custom dashboard. Not a proprietary format. Just labels. Visible in the UI, adjustable by humans. Because the system should work for you, not trap you. If something goes wrong, the system stops and escalates. No zombie jobs. No infinite loops. A clean handoff back to the human. The whole thing runs in Discord and on GitHub. Every agent logs its own work, in real time. Not because it had to. Because transparency was a design choice. You can watch it happen. Most days you want to. It makes you feel like a hacker. But you don't need to. Next post: 98 pull requests. The numbers tell their own story.

It's pure magic to observe this. What Björn is showing here isn't a side project. It's our production system. Five agents that turn a GitHub Issue into shipped code, it is specced, built, reviewed, tested, merged. No human in the loop unless something breaks. For us that means: we ship features in hours, not weeks. Two founders, no team, enterprise-grade output. And this exact setup is what we build for our clients. AI Enablement at Brumm Labs doesn't mean a slide deck with "transformation" on it. It means we show you how to get more done with fewer people. Because we do it ourselves. Every day. Burn token, burn!

It's pure magic to observe this. What he's showing here isn't a side project. It's our production system. Five agents that turn a GitHub Issue into shipped code — specced, built, reviewed, tested, merged. No human in the loop unless something breaks. For us that means: we ship features in hours, not weeks. Two founders, no team, enterprise-grade output. And this exact setup is what we build for our clients. AI Enablement at Brumm Labs doesn't mean a slide deck with "transformation" on it. It means we show you how to get more done with fewer people. Because we do it ourselves. Every day. Burn token, burn!