Amazon's head of devices and services, Panos Panay, says that the company is "not necessarily" planning to release a smartphone, but has stopped short of denying it outright. It was previously reported that Amazon is developing an Alexa-enabled AI phone codenamed "Transformer," more than 10 years after it scrapped its ill-fated Fire Phone.

Speaking to the Financial Times, Panay was asked directly if the company was planning another smartphone. "It's just not the goal," he replied. "I know there's a lot of rumors out there."

"I think your black and white question is, are you going after a phone? A lot of people want me to say no, but a lot …

Read the full story at The Verge.

I spend a lot of time hopping around folders in Explorer, especially when I’m bouncing between demos, samples, blog code, and whatever random side quest has captured my attention that day. And since I’ve also been using Copilot CLI as my primary interface to Copilot, I had one of those wonderfully lazy thoughts: why am I manually opening Windows Terminal and navigating to the folder when right-click menus exist?

So naturally, instead of saving time immediately, I spent time automating the thing that would save me time later. As is tradition.

The goal

What I wanted was pretty simple:

1. Right-click a folder in Explorer
2. See a Copilot submenu
3. Choose between my normal GitHub Copilot terminal profile and my YOLO one
4. Have Windows Terminal open directly in that folder

The commands wired up to the context menu are:

1
2

wt.exe --profile "GitHub Copilot (yolo)" -d "<current directory>"
wt.exe --profile "GitHub Copilot" -d "<current directory>"

That -d argument is the important bit, because it tells Windows Terminal which folder to start in. So instead of opening a terminal somewhere generic and then /cd-ing around like it’s 2009, it just lands exactly where I clicked.

Explorer menus are just registry entries

The nice thing about classic Explorer context menu customisation is that it’s mostly just registry keys. You can create a menu for when a folder is selected, and another for when you right-click the background inside a folder.

That means I could create a Copilot submenu with two children:

• GitHub Copilot (yolo) (which runs copilot --allow-all in the terminal)
• GitHub Copilot

The commands behind those entries are just wt.exe invocations with the selected path passed in.

For a selected folder, Explorer passes %1. For the background of an open folder, it passes %V. That’s the little detail that makes the same idea work in both places.

The important bit: what those profiles actually launch

The context menu itself doesn’t launch copilot directly. It launches named Windows Terminal profiles, which is honestly the better setup because it means I can keep all the styling and command configuration in one place.

Here are the two profiles from my Windows Terminal settings.json:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "backgroundImage": "E:\\OneDrive\\Pictures\\copilot-background.png",
  "backgroundImageOpacity": 0.1,
  "colorScheme": "cyberpunk",
  "commandline": "\"C:\\Program Files\\PowerShell\\7-preview\\pwsh.exe\" -c copilot --allow-all",
  "guid": "{2cf1cb03-5c2b-4e3a-95c5-5959c1d6ecc4}",
  "hidden": false,
  "icon": "E:\\OneDrive\\Pictures\\copilot-icon.png",
  "name": "GitHub Copilot (yolo)",
  "opacity": 100,
  "startingDirectory": "D:\\",
  "tabTitle": "GitHub Copilot"
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "backgroundImage": "E:\\OneDrive\\Pictures\\copilot-background.png",
  "backgroundImageOpacity": 0.1,
  "colorScheme": "Solarized Light",
  "commandline": "\"C:\\Program Files\\PowerShell\\7-preview\\pwsh.exe\" -c copilot",
  "guid": "{4167d70b-3a61-4b17-82fa-8eb52103b1d2}",
  "hidden": false,
  "icon": "E:\\OneDrive\\Pictures\\copilot-icon.png",
  "name": "GitHub Copilot",
  "startingDirectory": "D:\\",
  "tabTitle": "GitHub Copilot"
}

So the difference between the two is exactly what you’d expect:

• the standard profile runs copilot
• the YOLO profile runs copilot --allow-all

Everything else is just terminal cosmetics (hey, I like my custom background and icon!).

Wiring it into Explorer

The registry file creates a Copilot submenu in two places:

• HKEY_CLASSES_ROOT\Directory\shell\Copilot
• HKEY_CLASSES_ROOT\Directory\Background\shell\Copilot

From there, each submenu item points to one of the Windows Terminal profiles:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\Copilot]
"MUIVerb"="Copilot"
"Icon"="E:\\OneDrive\\Pictures\\copilot-icon.ico"
"SubCommands"=""

[HKEY_CLASSES_ROOT\Directory\shell\Copilot\shell\Yolo]
"MUIVerb"="GitHub Copilot (yolo)"
"Icon"="E:\\OneDrive\\Pictures\\copilot-icon.ico"

[HKEY_CLASSES_ROOT\Directory\shell\Copilot\shell\Yolo\command]
@="wt.exe --profile \"GitHub Copilot (yolo)\" -d \"%1\""

[HKEY_CLASSES_ROOT\Directory\shell\Copilot\shell\Standard]
"MUIVerb"="GitHub Copilot"
"Icon"="E:\\OneDrive\\Pictures\\copilot-icon.ico"

[HKEY_CLASSES_ROOT\Directory\shell\Copilot\shell\Standard\command]
@="wt.exe --profile \"GitHub Copilot\" -d \"%1\""

There’s a matching set of keys under Directory\\Background\\shell\\Copilot that use %V instead of %1, but otherwise it’s the same idea.

A tiny icon gotcha

One slightly annoying detail: Explorer context menu icons really want an .ico file, not a .png. Windows Terminal is perfectly happy to use the PNG for the profile icon inside Terminal, but the registry-backed Explorer menu behaves much more reliably with an ICO.

So yes, I now have both:

• copilot-icon.png for Windows Terminal
• copilot-icon.ico for Explorer

Perfectly normal behaviour. No notes.

The result

Now I can right-click basically anywhere in Explorer, choose Copilot, pick the flavour of chaos I want, and drop straight into a terminal already pointed at the current folder. This is hidden behind the “Show more options” menu in Windows 11 because otherwise I have to futz with COM or something, and while I wanted this, I didn’t want it that badly.

You can adapt this to have more Terminal profiles if you like, setting up Copilot CLI in different ways, or even just flatten it to a root level without a submenu if you only have one profile. You could even have it launch some other profile that isn’t Copilot-related, but where’s the fun in that?

It’s a tiny bit of automation, but it’s exactly the kind I like: shaving off just enough friction that I stop noticing the setup step and get straight to the work. Or, more realistically, straight to asking Copilot to do the work while I pretend this was all about efficiency and not because I enjoy over-optimising my development environment.

Honestly, the only surprising part is that I didn’t do this sooner.

Read the full article at https://developer.chrome.com/blog/install-element-ot

These skills enable your agent to take your ideas to a native Windows app in minutes! They are built around the end-to-end loop: scaffold, build, run, test, iterate. They’ve been optimized to know how to drive each stage, recognize common failures that get normal agents stuck in loops, and steer towards successful patterns, while also minimizing the number of tokens used by your agent. We hope to continually improve this experience and outcomes as we gather more feedback and examples from our developer community!

Try it

# Add the WinUI plugin to GitHub Copilot CLI
/plugin install winui@awesome-copilot

# Run the winui-setup skill to install all prerequisites
/winui-setup

Then ask GitHub Copilot for the WinUI 3 app you’ve been meaning to build, and tell us how it goes.

Skills built for WinUI development

Modern Windows app development covers a lot of ground – XAML and Fluent Design, MVVM, MSIX packaging, code signing, Store submission, accessibility, theming, UI automation. Each piece is well-documented on its own but stitching them together into a smooth inner loop takes practice. AI agents working from generic web context tend to mix WinUI with older stacks, miss the packaged-execution model, or stop short of running and verifying what they built.

Copilot CLI agents and skills let us put that knowledge right next to the developer. You ask copilot -p "create a WinUI 3 photo viewer with thumbnails and EXIF metadata", and the agent:

1. Picks the right template and scaffolds the project
2. Builds it and runs it through the right packaged-execution pipeline
3. Interacts with the app to validate functionality, if requested

All the while it’s:

• Designing with XAML theming and accessibility in mind
• Using MVVM principles to separate concerns
• Fixing compilation errors automatically
• Considering the right usage of controls for your scenario

and when you think you have your ideal validated, the agent can polish your app at a higher level with:

• Accessibility audits
• Code reviews
• Packaging
• and UI testing

…all without you needing to guide it or teach it how to do any of those steps. And because each skill only loads what it needs and leans on the tools below for the rest, the agent does all of this in more than 70% fewer tokens than when we started – on the same model.

What’s inside the plugin

The plugin ships one agent, eight skills, and several supporting tools. The agent is the entry point – it loads by default the skills for building, debugging, and design, and you can add additional skills in the prompt or individually use just the skills you need.

The agent: winui-dev

A focused agent for WinUI / Windows App SDK / XAML / C# work. Use it for new apps, adding features, converting from WPF/Electron/web, or fixing bugs. It’s the orchestrator that pulls in the winui-dev-workflow and winui-design skills by default and kicks of the agent to accomplish the task.

The skills

Each skill is a focused, self-contained playbook. The agent loads winui-design and winui-dev-workflow by default – those cover most “build me a WinUI 3 app” requests end-to-end. You opt into the others when you want them. Mention UI testing and the agent will load the winui-ui-testing skill to drive your app through real UI automation, find functional issues, and iterate on fixes; ask forwinui-packaging when you’re ready to ship; include winui-wpf-migration when you’re porting from WPF. Skills compose cleanly, so adding one doesn’t disrupt the others.

The tools we lean on

Skills are prompts plus playbooks. They get their actual leverage from a small set of tools – some included as part of each skill.

External: tools expected on your machine

• WinApp CLI (winget install Microsoft.WinAppCLI) – the command-line driver for installing, running, signing, packaging, and automating WinUI 3 / WinAppSDK apps. Without winapp, these skills wouldn’t be possible. Packaged WinUI apps can’t just be launched as a .exe – they need to be installed and started through the right activation pipeline. winapp run does exactly that, and crucially streams the app’s debug output back to the agent so it can see crashes and exceptions instead of staring at silence. winapp ui powers the entire winui-ui-testing skill: enumerating elements, asserting state, driving controls, capturing accessibility audits – all from the command line, all scriptable, all readable by an AI agent. winapp manifest and winapp pack are what makes the winui-packaging skill able to take a build all the way to a signed MSIX.winapp CLI is built in parallel with these skills, in lockstep. Every time a skill needed a new automation surface, a missing JSON output mode, or a tighter feedback loop, that requirement landed in winapp first. The two repos co-evolve, and we expect that to continue. Read the latest WinApp CLI blog post for more details on winapp run and winapp ui.
• Microsoft.WindowsAppSDK.WinUI.CSharp.Templates — the new dotnet new templates for WinUI 3 + Windows App SDK. The dev-workflow skill uses these as the canonical scaffold so every new project starts from the same supported baseline. Read the blog post introducing the new dotnet new templates for WinUI to learn more.

In-skill: the three tools we built alongside the skills

These pre-build binaries ship with the plugin. Each one solves a problem that prevents the skills from being reliable. All three are early days – see the “What’s next” notes for where each is heading.

winui3-analyzer – a Roslyn analyzer for WinUI 3 pitfalls

A netstandard2.0 Roslyn analyzer that catches common WinUI 3 / WinAppSDK issues at build time: UWP namespace leaks, Window.Current and CoreDispatcher usage, WebView2 without EnsureCoreWebView2Async, TabView items containing raw content, attached-property initializer bugs, removed ONNX GenAI APIs, the old field-backed [ObservableProperty] pattern, and more. Distributed today as a prebuilt DLL the winui-dev-workflow skill auto-injects into your dotnet build.

• What’s next: the goal is to ship this as a standalone NuGet package with a categorized rule catalog, severity-ceiling policy (no Error rules by default), and per-rule helpLinkUris. Whenever that lands on NuGet, the skill will switch to a <PackageReference> and the in-repo distribution path goes away. Feedback on rule severity, false positives, and which categories matter most will shape the catalog.

winui-search – a fast, offline catalog of WinUI Gallery + Community Toolkit samples

A native-AOT CLI that indexes WinUI Gallery and CommunityToolkit/Windows scenarios so the agent has grounded knowledge of which control to pick, and how to use it well. WinUI 3 ships with a lot of controls – and Community Toolkit adds many more on top. Knowing whether the right answer is NavigationView or TabView, ListView or ItemsRepeater, a stock Expander or a Toolkit SettingsExpander, isn’t something a generic LLM gets right reliably. winui-search puts the actual shipping samples behind a fast lookup so the agent can see real usage before writing a single line of XAML. When a skill is drafting a settings page, it can ask winui-search for “toggle switch with description text” and get back the actual XAML pattern from WinUI Gallery – including the expected resource keys, spacing, and ancillary controls. Need a NavigationView example with a custom title bar? An ItemsRepeater with virtualized cards? A Community Toolkit SettingsCard with an icon and a hyperlink? It’s one query away. Backs the design skill’s “show me a real-world example” capability and grounds the agent’s XAML in patterns that already shipped to real users.

• What’s next: the data layer and the CLI surface are both in flux. We’re considering a few directions: shipping it as a standalone CLI tool, folding the search surface into winapp itself, or exposing the catalog over a small MCP server. We’re also working on expanding what’s searchable – multi-control composite patterns (a full settings page, not just a single ToggleSwitch), and going beyond UI into C# code patterns so agents can reliably search for snippets like “how do I implement a custom ICommand” or “Dispatcher-safe progress reporting from a background Task“. The right answer depends on where developers want to use it – your feedback will decide.

winmd-cli – offline WinRT + .NET API metadata lookup

A native-AOT CLI that indexes .winmd and managed .dll metadata from NuGet, the Windows SDK, and WinAppSDK and provides fast, offline API lookup with the same XML doc text Visual Studio IntelliSense uses. The agent can use it to verify that an API actually exists and has the signature it thinks it does – before writing code that won’t compile.

• What’s next: same set of options as winui-search – standalone CLI, integration into winapp, or MCP server. Likely shares whatever distribution decision we land on for winui-search.

One more in-repo tool you should know about

BuildAndRun.ps1 – a temporary build wrapper

The winui-dev-workflow skill currently invokes a small PowerShell helper, BuildAndRun.ps1, instead of calling dotnet build directly. Why? There’s a known XAML compiler issue (issue, issue) where, under dotnet build, a malformed XAML file produces no useful diagnostic – the build just fails with no indication of what’s wrong in which .xaml. Agents that hit this get completely stuck: they can see the build failed, but they have no signal to act on, and they thrash through unrelated guesses.

The script’s actual workaround is small but specific: if MSBuild is available on the machine (i.e. Visual Studio with the right workload is installed), the script builds with MSBuild instead of dotnet build, because the XAML diagnostics flow correctly through MSBuild. If MSBuild isn’t there, it falls back to dotnet build and surfaces what it can. Either way, after a successful build it hands off to winapp run so the app launches the right way.

• What’s next: this script is explicitly temporary. It’s slated to be removed entirely once the XAML compiler fix ships in the next Windows App SDK release. We’d rather not paper over platform bugs forever – the right fix lives in the platform.

We want your feedback!

This is the part we want to over-communicate: everything you see today is a starting point.

• Skill names, scopes, and structure can change. We’ve already collapsed and re-scoped a few skills based on early internal feedback.
• Distribution mechanics for the analyzer and CLI tools are open questions – see each tool’s “what’s next” above.
• The BuildAndRun.ps1 helper will go away when the platform fix ships.
• The winapp CLI is itself young and evolving in lockstep with these skills.

If a skill produces something wrong, surprising, or just not as good as it should be, we want to know. The fastest way to influence the direction is to file an issue on the microsoft/win-dev-skills repo (the bug template asks you to attach a session report – generated for you by the winui-session-report skill).

The post Introducing WinUI agent plugin for GitHub Copilot and Claude Code appeared first on #ifdef Windows.