One of the things that comes with maintaining the Awesome Copilot repo is that people want to contribute to it. And that’s great! We’ve had community contributions since the repo was first created. But recently we’ve been getting a growing number of requests from people wanting to list their external plugins in the marketplace — plugins that live in repos we don’t own, maintained by people we might not know.

That’s… a different proposition to someone submitting a PR with a resource that we can review directly.

The supply chain problem

Here’s the thing that kept me up at night: external plugins are essentially us telling Copilot “hey, go clone this repo and pull stuff out of it.” We become the front door. The marketplace passthrough. And if you’ve been paying any attention to the NPM ecosystem lately (or PyPI, or… look, pick your package manager, they’ve all had incidents), you know that being the trusted entry point to untrusted code is a really bad position to be in. Combine that with the rise of using AI in writing code, and Awesome Copilot being a directory of AI-powered plugins, and you have a recipe for… well, a lot of things that could go wrong.

I don’t need to be the reason someone’s machine gets owned because they trusted a plugin that we listed. That’s the kind of thing that keeps open source maintainers awake at 2am, staring at the ceiling, questioning their life choices.

So before we could open this up, we needed a process. Not just “yeah sure, send us a link and we’ll add it”. An actual, structured, auditable process with real security guardrails.

Designing the intake workflow

The goals were pretty straightforward:

1. Transparency — submitters should be able to see exactly where they are in the process, and consumers should be able to see that a review happened.
2. Automation — reduce the manual burden as much as possible, because I do not have time to manually validate every field in a submission.
3. Security — pin submissions to immutable refs (SHAs or tags), not branches. Branches move with HEAD. SHAs cannot. And tags, well that can move, but they require a force push to change, which is at least a more deliberate action.
4. Human oversight — automation is great, but someone with context still needs to make the final call.

What we landed on is a GitHub Issues-based workflow, which honestly felt like the most natural fit. Issues are already where people interact with repos, they have structured forms, they support automation via Actions, and they’re public by default. So it’s approachable, transparent, and auditable.

How it actually works

The process flows like this:

1. Submission via Issue form

We created a form-based issue template that captures everything we need: plugin name, description, repo URL, the ref or SHA to review against, and so on.

The form-based approach is important here. It’s not a freeform text area where people can write whatever they want, it’s structured fields that we can programmatically parse. This means we can validate the submission before a human ever looks at it.

2. Automated validation

When an issue is opened using the template, a GitHub Action fires and runs a validation script. This script checks:

• All required fields are populated
• The referenced repository actually exists and is public
• The ref or SHA provided actually resolves to something real on the remote repo
• The license is something we’re comfortable with
• The structure looks correct

If any of these checks fail, the automation comments on the issue explaining what’s wrong, and the submitter can fix their issue and trigger a re-run with /rerun-intake.

3. JSON generation

If validation passes, the action generates a comment containing the exact JSON blob that would need to be added to our repository’s plugin definitions. This serves two purposes: it shows the submitter exactly what will be added, and it gives us (the maintainers) a copy-paste-ready block for the actual PR. Think of it as getting a preview of the PR diff before we even create the PR.

4. Manual review

This is where the human comes in. A maintainer looks at the actual plugin and performs the same kind of review that we would of anything that comes in via a PR. Does it do what it claims? Is it useful? Is the quality reasonable? Does it follow our responsible AI policies? Does it pass the “vibe check”? (C’mon, it’s AI, there’s gotta be some vibes in there!) This is the part you can’t automate, because it requires judgement and context.

After the review, we either /approve or /reject via a comment, which triggers the next automation step.

5. Automated PR (or rejection notice)

If approved, an Action automatically creates the PR to add the plugin to the repo. If rejected, the submitter gets a comment explaining why, and the issue is closed.

The iterative part

One of the things I’m most pleased about is how well the iterative feedback loop works. Take issue #1813 as an example. Someone submitted a plugin for review, the automated review flagged some issues, they edited their submission, ran /rerun-intake, the automation validated again, found more issues, they fixed those too, and then it was ready for a manual review.

That whole back-and-forth happened without any human maintainer involvement. The submitter got immediate feedback, knew exactly what to fix, and could iterate on their own timeline. That’s the kind of developer experience I was aiming for.

(Ultimately, the plugin was rejected after I did a manual review, but I wanted to highlight the process, not the outcome.)

Re-review after six months

Something we built into the process is a staleness check. After six months, approved external plugins get flagged for re-review. This mirrors what we already do for resources directly in the repo (via our staleness report), and it ensures that the external plugins stay maintained, useful, and not quietly hijacked by someone buying an expired domain or taking over an abandoned repo.

Individuals welcome

One decision I’m happy about is that this isn’t limited to organisations or official “partners”. If you’re an individual with a plugin that’s genuinely useful to the Copilot community, you can submit it through the same process. We might be a bit more thorough on the review (the rise of purely AI-generated submissions means quality varies… a lot), but the door is open.

Testing Actions is hard

I’ll be honest: I’m pretty amazed at just how smoothly the Actions and scripts are working, because they are super hard to test. You can’t really unit test “a GitHub Issue was opened with this specific form data and an Action should parse it, validate it, comment on it, and then wait for a slash command.” You kind of just… ship it and hope.

Ok, that’s not entirely true — we did test the validation logic in isolation, and we did dry-run the workflow a bunch of times against test issues. But the integration between all the moving parts (issue forms, action triggers, comment parsing, slash command detection, PR creation) is the kind of thing where you cross your fingers and watch the first real submission come through.

And it worked. First time. Well, mostly first time. Look, there were a few tweaks needed, but nothing that was visible to submitters, so it counts.

What’s next

Now that the process is live, the next challenge is scale. As more submissions come in, the manual review step becomes the bottleneck. I’m exploring ways to leverage the other automation workflows that we have in Awesome Copilot and apply them to this process, but baby steps.

But for now, I’m just enjoying the fact that we have a transparent, auditable, secure-ish process for external plugins, and that it all runs on GitHub’s native primitives — Issues, Actions, and PRs. No external services, no special tooling, just the platform doing what it does best.

If you’ve got a Copilot plugin you’d like listed in the marketplace, open a submission and let the robots take it from there. Well, the robots and me. Eventually me. I’ll get to it. One day. Promise.

Large language models (LLMs) are efficient general-purpose tools, but they work much better when you give them the right context. Whether you're using a coding assistant (yes, you can run your own private coding assistant), building an agentic application, or trying to get more accurate answers from your favorite model, there are two main ways to extend what an LLM can do: Model Context Protocol (MCP) servers and skills.

Both expand the context window of your model, but they solve fundamentally different problems. This article explains what each option does, how they work technically, and how to choose between them—or use both.

Why LLMs need context

An LLM is a prediction engine trained on massive datasets, and it can identify the history of Red Hat, determine which SQL command inspects a database schema, or write a Dockerfile. Most models are great at answering these types of general questions. However, getting the right answer for your specific use case requires providing the right context.

Let's say, for example, you're asking a model for help working with your team's database. In addition to your question, the model will need relevant context. This might include the configuration your team uses for development or production environments, the formatting of queries to send, or a tool executed to check which tables are available. Providing this information used to be entirely manual: copy-pasting documentation, writing long and detailed prompts, and hoping the model understands your question and puts it all together correctly. The workflow shift from manual parsing to an automated context pipeline is illustrated in Figure 1.

This is where context engineering comes in. It goes beyond prompt engineering, which only provides instructions, personas, and basic guidelines. Context engineering is about curating the right data, tools, and instructions, so that the model has everything it needs to give you a correct, useful answer. So the question is, how do we provide that context?

Connecting external data with the Model Context Protocol

Let's say the context your agent needs lives in an external service: a customer relationship management (CRM) solution, a database, or a cloud provider's API. Previously, with AI agents, you had to manually convert the service's API documentation into a custom tool with an authentication token, instruct the LLM to update the customer's contact info, and hope for the best.

Model Context Protocol (MCP) standardizes how your AI agent talks to external data sources. Instead of custom integrations for every tool, MCP provides a universal interface that:

• Abstracts service APIs into a simple, LLM-ready format.
• Manages authentication by issuing your AI model a scoped access token with specific permissions (for example, read or write).
• Instructs the LLM to provide specific JSON to interact with the MCP server (for example, using GET to fetch a record or POST to submit an update).
• Defines the structured JSON inputs the LLM must produce to call tools on the MCP server.

This systemic separation of concerns between the agent, protocol, and external APIs is visualized in Figure 2.

Behind the scenes, when you add an MCP server to your IDE or AI application, the agent client discovers available tools and appends descriptions to the model's context, signaling that it can view active Kubernetes resources. When the user makes a request, the model sees those tool descriptions alongside the conversation and decides which tools to call and with what arguments (Figure 3).

MCP was introduced by Anthropic in November 2024 as an open standard and has since been widely adopted, with support from major AI tools and providers. In December 2025, Anthropic donated the protocol to the Linux Foundation through the Agentic AI Foundation, which includes Red Hat as a member.

Structure of an MCP server interaction

Here's a simplified example of what an MCP interaction looks like. Let's say your AI agent has a CRM MCP server configured to look up customer information, and the user requests the contact information for customer_123. The LLM then generates the following JSON:

{
  "tool": "crm_get_contact",
  "parameters": {
    "customer_id": "cust_12345"
  }
}

This abstracts the LLM from the MCP server, which handles the actual API call, authentication, and response formatting. The LLM gets back structured data it can reason about. For a deeper look at how agentic AI uses MCP servers, check out the MCP servers for Red Hat OpenShift AI and a guide on Building effective AI agents with Model Context Protocol.

Adding domain expertise with skills

While MCP solved the problem of “how do we give external data to an LLM,” there's another challenge: how do we give the LLM domain expertise it might not already have?

Sure, with MCP, you can pull those customer records from a CRM, but your sales team wants the output formatted exactly the same way every time: customer name, contact info, and their favorite cookie flavor (Figure 4). Without explicit instructions, the model will format things differently each time.

Skills are reusable, structured instructions that teach your LLM how to do something. Think about the tasks you might use an LLM for repeatedly:

• Cleaning up Excel documents in a specific format
• Debugging code (for example, always running maven verify before suggesting fixes)
• Running compliance checks against a standard template
• Formatting reports according to your team's style guide

Each of these can be packaged into a skill, which contains the following three parts:

• Title: How you and the model identify the capability
• Description: When the skill should be added to the model's context
• The prompt: Instructions, examples, templates, and scripts

The key feature of skills is auto-loading. The underlying agent loads the relevant skill into its context window only when needed. A code debugger skill only activates when you ask about code errors. A document formatting skill only loads when you're working with documents. This keeps the context window efficient while providing specialized expertise on demand. With the rising cost of LLMs, this capability helps manage resource spending efficiently.

Skills have become a widely adopted pattern across AI tools. The skill.md format, popularized through coding assistants like Claude Code, has become a de facto standard across multiple platforms. You can find community-maintained skill libraries with thousands of entries covering everything from front-end design to Kubernetes deployment and data analysis.

Anatomy of a skill definition

Here's a basic skill.md definition, pulled from Claude Code's documentation:

---
name: explain-code
description: Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?"
---
When explaining code, always include:
1. **Start with an analogy**: Compare the code to something from everyday life
2. **Draw a diagram**: Use ASCII art to show the flow, structure, or relationships
3. **Walk through the code**: Explain step-by-step what happens
4. **Highlight a gotcha**: What's a common mistake or misconception?
Keep explanations conversational. For complex concepts, use multiple analogies.

Once added to your AI coding assistant or AI agent, if a user asks, “How are we handling database queries in our development environment?” the skill auto-loads. The model then follows these standardized conventions automatically. In addition to the markdown file, you can include optional folders like references, assets, or scripts to provide context. The standard directory layout of a packaged skill is shown in Figure 5.

When to use MCP servers

Use MCP when your AI application needs access to real-time, external data in a controlled, tightly permissioned way. MCP is an integration layer between agents and tools. It lets you query what virtual machiness are currently running, determine the cluster state in your cloud provider, or request contact information for a customer.

MCP is the right choice when the value comes from the data itself, not from how the model processes it. The model needs to read from or write to an external system, and MCP provides a security-focused, standardized pipeline to do that.

When to use skills

Setting up and configuring an MCP server can be overkill if you only need to add a reusable, custom capability to your AI. That's where skills shine.

Skills are lightweight and tell your model how to do something: for example, how to fetch investment data and analyze it using scripts or examples included in the skill. Use skills when you're repeating the same prompts across conversations, or need consistent output formatting across your team, or want to give domain-specific best practices to your model.

Combining MCP and skills for comprehensive workflows

MCP and skills aren't competing approaches; they're complementary, and the most effective AI agents use both. Let's think about a scenario where you're building an AI agent for your DevOps team:

• MCP connects the agent to your Kubernetes cluster, your monitoring stack, and your incident management system. The agent can query pod status, pull metrics, and create incident tickets.
• A skill teaches the agent your team's incident response runbook: how to triage alerts, what thresholds matter, how to format a post-incident report, and which Slack channels to notify.

Without MCP, the agent cannot access your systems. Without the skill, the agent has access, but doesn't know your processes. Together, your agent can monitor active statuses and respond according to your team's processes.

Next steps for your automation architecture

Both MCP and skills are open source capabilities widely adopted across AI environments. Most providers offer an official MCP server, specific skills, or both. You can import these directly to your AI coding assistant or agent. Review the underlying code and execute these elements in sandboxed environments to verify behaviors safely.

The post MCP servers vs. skills: Choosing the right context for your AI appeared first on Red Hat Developer.

Learn why EF Core without migrations is a disaster. Learn how to setup, configure, and deploy using migrations to keep databases consistent across environments.

The page EF Core without migrations - it's only a matter of time appeared on Round The Code.

Creative writing teachers say writers should keep a diary. So, why don’t we? Maybe because we don’t see the point? Or because we don’t know how? This blog is here to help, because keeping a diary does matter.

We all know what a diary is, don’t we? It involves taking one of those cute notebooks we hoard for dire times, and we just haven’t been able to start. Sound familiar? This was me – until I thought hard about what a diary truly was, and what it could be for me. Let me convince you.

What Exactly Is A Diary?

The question sounds superfluous, I know. Please hear me out. According to Wikipedia, a diary is first and foremost a record of events arranged by date. Traditionally, it is written by hand, but nowadays, it exists in digital form, either on a cell phone or a computer.

Diaries can also be an audiovisual recording, either as a voice message or as a video. Since we’re all writers, I’ll concentrate on the written diaries.

There are different approaches, and they all have an impact on what the diary (or journal) can do for you. But first, let’s look at what keeping a diary can do for you as a writer.

7 Benefits Of Keeping A Diary – For Writers

Ever wondered what journaling can do for you as a writer?

1. Encourage you to write.

A diary is the perfect training ground for writers. There’s no formal restriction, no hierarchy of topics, no censorship, no editing. Just you and your pen (or computer, but we’ll get to that later). Let the words flow!

2. Promote a writing habit.

This is key to being a writer. You need to create a habit, or writing will just be a ‘once in a blue moon’ hobby. Of course, that habit needs to suit you. If it doesn’t fit into your lifestyle, you’ll quit (as many people do). Here are two key points to consider:

1. You don’t need to write every day.
2. You don’t need to write a set number of lines or for a set amount of time.

You get to decide. You can write one line per day. Or you’ll write five pages at the end of the week. But you need to form a habit. Why? Because if you’re used to forming thoughts into sentences, then words will flow easily when you sit down to write a story. The habit of keeping a diary will make you a better writer.

3. Sharpen your focus.

As you engage with your diary, you are alone with your brain. You shouldn’t let anyone or anything disturb you. Not even your inner critic!
This is your Me-Time. That will show the writer inside you that whatever you pour onto a page – it’s ok! Your words deserve the space.
This will build the self-confidence you need for writing poems and stories. You need to write that first draft without the fear of the inner critic.

4. Help you get unstuck.

Very often, our thoughts are so noisy that we keep going over the same things again and again. It’s like a vicious circle. It’s also one of the reasons for procrastination.
Diaries are a possible remedy. Try a brain dump. By unloading all the noisy thoughts onto the page, you clear your mind. That clarity really helps you get unstuck. It can certainly help overthinkers!

5. Let you sort your thoughts.

Many people list the pros and cons to decide. A diary does the same thing. It works even when the categories of ‘pro and con’ don’t really apply. Writing in your diary, you will argue with yourself, going through possibilities, back and forth, until you get to the point when you know what to do.
This also works for problems in your writing. Go through possible scene ideas, work them out, and just see what works best.

6. Let you explore your personality.

A diary isn’t edited. No need to mince your words! Where else can you explore different sides of your personality? Or different writing styles?  You could try out different versions of yourself, and no one will ever know.
For your literary self, it’s important that you do. This is a great way to find your own style.

7. Record your life.

Now this really depends on how you do this. If you just write ‘this happened, and then this happened, and then this’ – well, that’s just an itinerary, right? About as boring as a train schedule.
It’ll get much more interesting if you record events and the feelings they provoke. What about your experiences and the lessons you draw from them? Places you visit, people you meet, and how they impressed you?
Do this, and your diary becomes a treasure chest where you keep all the gems of your life. This can come in handy for you as a writer – your diary will be a literary notebook! You’ll never run out of ideas.

Now that these benefits have convinced you to keep a diary, you need to decide on two more things. They’re technical but important.

The Medium Is Part Of The Message

First and foremost, your diary is exactly that – your diary. So be brave and make it into whatever you want. If you are a writer who also illustrates, or simply likes to include visuals in your writing, do just that. Include little doodles, bits from a newspaper, pictures, sketches, or drawings. Make it a scrapbook.

Other than that, writers have two options: either write by hand or keep a digital version on a computer or a cell phone.

The benefits of writing by hand have been discussed widely (you can read up on them here), and they all apply to keeping a diary. Writing by hand is good for your body, and it tends to result in better writing. What you practice with your diary will prepare you for writing creatively.
Yet some people choose to write with a computer. This can be due to a physical condition. It can also be a deliberate choice. Writing with a keyboard does give a certain free rein to your inner critic. However, it’s also a very fast way of writing for many people. Fast writing, especially if it’s close to automatic writing, silences the inner critic and gives your brain free access to the page.

The Best Time To Write

Night journaling is the traditional way of keeping a diary. At the end of the day, you look back and assess your wins and your struggles. This will produce some sort of reckoning. At some point, you’ll say if it’s been a good or a bad day for you. That sounds a lot like the ugly twin of the inner critic, doesn’t it? This is the danger of night journaling. Please be aware of that. Try to write without judging. No editing, remember?
Yet the evening gives you plenty to write about. If you can include gratitude in your diary writing practice, then this will also help you get out of the reckoning mode. Gratitude lets you assess a situation, and then it takes you into the future by thinking about what you have (rather than what you lack).

Morning diaries tend to be future-oriented by nature. This is why Julia Cameron chose the ‘morning pages’ as her technique to enhance creativity. There is a slight difference between the two.
A morning diary simply means that you sit down to write, not reflecting on the day past, but the day ahead. This kind of diary tends to be more optimistic. It’s all about plans and hopes and dreams. Morning diaries are about what could be. This can put you into a more creative mood. However, the blank page can also leave you without anything to write about. In this case, try doing this with a prompt (Writers Write has lots, here’s the link).
The ‘morning pages’ try to channel the morning diary into something more literary. Julia Cameron wants you to write for either 20 minutes or to write 3 pages, uninterrupted, unedited, just free writing. Chances are, you’ll discover an idea worth exploring further in your creative writing.
Some people find this hard – sometimes we need a good brain dump in our diary to quiet those noisy thoughts. Only then will creativity rise. Why not try Julia Cameron’s technique in the evening? Who says ‘night pages’ can’t work for you?

The Last Word

Writing is good for you – any kind of writing. The more you do it, the more you build your writing muscle. A diary is the easiest way to do it.

This little book will also serve you as a record of settings. Whenever you sit in a café, whenever you travel to another city or even country, when you’re at someone else’s home – whatever you see, and whatever impresses you, write about it. It’s this kind of information that fuels our stories with lots of ‘showing.’

The biggest benefit of a diary is a psychological one. It clears your mind, and that gets you unstuck. It helps you to create the comfort zone you need to write.

Start a diary today. Happy writing!

By Susanne Bennett. Susanne  is a German-American writer who is a journalist by trade and a writer by heart. After years of working at German public radio and an online news portal, she has decided to accept challenges by Deadlines for Writers. Currently she is writing her first novel with them. She is known for overweight purses and carrying a novel everywhere. Follow her on Facebook.

More Posts From Susanne:

1. 7 Gripping Dystopian Plot Ideas For Writers
2. Poets On Writing Poetry: Insights & Inspiration
3. Poetry Made Easy: How To Read & Interpret Poems
4. What Writers Can Learn From Trashy Novels
5. 10 Weird Things Writers Do
6. Weird Habits Of Famous Writers
7. What Is Blackout Poetry & How Do I Write It?
8. 6 Lessons From Lord Byron – How To Make Others Swoon With Words
9. How To Write A Cozy Mystery
10. The Writers Write Book Reading Challenge – 3

Top Tip: Sign up for our free daily writing links.

The post Why Keeping A Diary Matters appeared first on Writers Write.

IAsyncEnumerable: Streaming data without loading everything into memory
7 minutes by Adrian Bailador

Streaming data with IAsyncEnumerable lets you process large datasets one item at a time instead of loading everything into memory at once. This works well with Entity Framework queries and HTTP responses. Memory usage drops significantly compared to fetching all records upfront, and your app stays responsive under load. Start with simple yield return patterns, then apply them to database reads and API calls.

C# finally gets union types
12 minutes by Andrew Lock

Unions are one of those features that have been requested for years, and in .NET 11 (or rather, C# 15) they're finally here. In this post Andrew describes what that support looks like, how you can use them, how they're implemented, and how you can implement your own custom types.

Zstandard compression in .NET 11
2 minutes by Steven Giesel

Steven introduces Zstandard compression support in .NET 11 through the new ZstandardStream API. He explains how Zstd provides fast and efficient compression, similar to existing formats like GZip and Brotli. He also covers new APIs, quality settings, ASP.NET Core integration, and dictionary compression for improving performance when compressing many small and similar files.

Understanding IHostedService & BackgroundService in .NET 10
17 minutes by Mukesh Murugan

Mukesh explains the differences between IHostedService and BackgroundService in .NET 10 using simple examples and real production issues. He compares their lifecycle, usage patterns, and common mistakes developers face in background processing. His guide also shows when to use tools like Hangfire or Quartz.NET instead of hosted services, helping developers choose the right solution for reliable, scalable background tasks in ASP.NET Core applications.

Implementing the Inbox pattern for reliable message consumption
6 minutes by Milan Jovanović

Milan describes how the Inbox pattern improves reliable message consumption by preventing duplicate processing in event-driven systems. Messages are first stored in a database, where duplicates are ignored, and then processed asynchronously. This approach supports retries, scalability, and fault tolerance while ensuring each message is handled safely and consistently.

And the most popular article from the last issue was:

• Pattern matching in C#: Advanced scenarios you didn't know

Apple just registered a new subdomain record: genai.apple.com. The domain was spotted by a MacRumors contributing researcher, and though it doesn't yet lead to a live web page, they believe it's tied to Apple's annual developers conference WWDC which starts June 8, "where the company has promised to announce 'AI advancements' across its software platforms." The blog 9to5Mac speculates that "All signs point to WWDC 2026 being Apple's major AI renaissance, where the company will live up to the promises it made back at WWDC 2024, as well as a few additional new announcements." [I]it goes without saying that this is probably related to Apple's upcoming generative AI announcements at WWDC... Siri should finally be able to understand more personal context, have on screen awareness, and be able to take action in apps for you. This'll finally be made possible thanks to Apple's new partnership with Google, where Apple will be using Gemini-diffused models hosted on Private Cloud Compute to power Siri... Apple will also reportedly be introducing a new Siri app. This'll allow you to access your previous Siri conversations, as well as have text-based conversations with Siri. Other Apple Intelligence upgrades coming at WWDC 2026 include the ability to generate wallet passes from physical tickets, new editing features in the Photos app, and additional functionality for Visual Intelligence...

Read more of this story at Slashdot.