标签：#powerplatform

Looking for Contributors to Build Zentrail IDE — An AI-Native Open Source Desktop IDE Hello everyone! 👋 I'm building Zentrail IDE , an open-source, AI-native desktop IDE designed for the next generation of software development. The goal isn't to build another code editor. The goal is to create an IDE where multiple AI agents can collaborate with developers in a single workspace to plan, write, review, test, and manage code. We're still in the early architecture and planning phase, and I'm looking for developers, designers, and AI enthusiasts who want to help build it from the ground up. 🎯 Project Vision Create an AI-first development environment that combines: 🧠 Multi-Agent Collaboration 💻 Native Desktop Performance 🤖 AI CLI Integration 📦 Plugin & Skill Ecosystem 🌍 Open Source Community ⚡ Modern Developer Experience ✨ Planned Features Workspace System Multi-project workspaces Workspace memory Persistent sessions Task management AI Workspace Agents Multiple AI agents running simultaneously Shared workspace memory Parallel task execution Intelligent task orchestration AI CLI Support Claude Code Gemini CLI OpenAI-compatible providers Local AI models Custom AI CLIs Git Automation AI-assisted commits Pull requests Code reviews Branch management Repository insights Skill System Install reusable AI workflows with a single command. Examples: Security Review Code Refactoring API Generator Documentation Writer Test Generator Plugin SDK A modular extension system for adding custom functionality without modifying the core IDE. 🛠 Tech Stack Frontend TypeScript React Tauri v2 Monaco Editor Tailwind CSS Backend Go gRPC WebSocket AI Runtime Python MCP LangGraph Database SQLite 🤝 We're Looking For We're looking for contributors interested in: Frontend React TypeScript UI/UX Monaco Editor Backend Go gRPC WebSocket Performance optimization AI Python MCP Agent orchestration Prompt engineering Desktop Tauri Windows development Cross-platform architecture Design UI/UX Design Icons Develo

One thing Microsoft is not good at is naming things, and sadly it's happened again. But let's go back to the beginning: what are Skills? Skills are targeted prompts/context that are modular, so they are not always included in the LLM session. They are Markdown files with selected metadata in YAML, all in a file normally named skill.md (the parent folder and YAML metadata identify it). They were created by Anthropic (Claude) and were designed for both the user to add in a prompt ( /Skill ), or for the LLM to decide. Similar to Skills are Plug-ins. These can (and often do) include skill.md files, but can also have scripts, MCP servers, and other tools. So back to Microsoft naming things badly. Copilot Studio (Azure Bot Framework version) had skills, but they were not skills. The new Copilot Studio has Skills, but they are not Skills, they are actually Plug-ins. Plug-ins include Skills, so why does it matter? Well, it doesn't really, but I like to moan, and it means sometimes cool functionality can be left on the table because we presume Microsoft names things accurately. Anyway I digress (I like to do that), now we understand what Skills/Plug-ins are I wanted to dive into them within Copilot Studio and cover: Why Are They Cool Building Powerful Skills Adding Scripts/Templates Using Skills 1. Why Are They Cool I often go on about skills being cool, but why? There are a few reasons. Context Management Before skills, the standard approach was to give the LLM everything and let it figure out what it needed. The problem with this is twofold. First, more context equals more tokens, which equals more cost. Second—and more importantly—too much unrelated context can have a detrimental impact on the LLM response. LLMs work by using input tokens to predict the next token, so polluted input tokens can make the LLM predict the wrong next token (this is a huge simplification, but you get what I mean). Transferable As skills are simple Markdown files, they can easily be transferred

This continues from Part ① . In Part ②, we'll configure the common settings and the internal-processing Power Automate flows. Common Settings Setting Up Connections Open Power Automate ( https://make.powerautomate.com ) Go to "Data" → "Connections" → "New connection" and create a Microsoft Dataverse connection Do the same to create an Office 365 Outlook connection Basic Flow Creation Steps Click "Create" → select "Automated cloud flow" (event-triggered) or "Scheduled cloud flow" (recurring) Name flows in the format [Zone]-[Number] [Description] (e.g., "A-1 Opportunity Stage Stall Alert") Always run a test after creating a flow to verify it works 2. Internal-Processing PA Flows — 4 Flows (Write-back portions of A-4, C-5, C-6, D-3) Once the common settings are done, it's time to build. A-4: Write Back Stage Changed Date Without this flow, the stall-day calculations in A-1 and B-1 will not work. Implement this first. In Microsoft Dynamics 365 (D365), a "stage" refers to a major milestone in a process — such as a sales deal or customer engagement — that guides the responsible person through what needs to happen next. It's how a series of activities is visualized and managed. From here, all work is done in Power Automate. Step Task Details 1 Create the flow "Automated cloud flow" → select trigger "When a row is added, modified or deleted (Dataverse)" 2 Configure trigger Table: Opportunities / Change type: Modified 3 Add condition Add a "Condition" action: "When Status Reason (statuscode) has changed" 4 Write-back action "Update a row (Dataverse)" → set cr917_stage_changed_date to utcNow() C-5: Auto-Set Renewal Date + Auto-Create Renewal Opportunity (on Won) On Won close, two things happen: ① auto-set the renewal date to close date + 365 days, and ② auto-create a new Opportunity for the renewal cycle and add it to the pipeline. Step Task Details 1 Create the flow "Automated cloud flow" → trigger "When a row is added, modified or deleted (Dataverse)" 2 Configure trigger Ta

When you build a PowerApps Component Framework (PCF) component that will be used across multiple geographies, need to serve labels, button captions, validation messages, and tooltips in the user's preferred language. PCF has a built-in answer based on .resx resource files, the same format used by .NET applications. The mechanism is elegant in production — but surprisingly tricky during local development. This walkthrough takes you through the full setup, step by step, and then explains a problem that arises while locally debugging your PCF. Step 1 — Create the strings folder and your first .resx file PCF expects your localized strings to live in a folder (the conventional name is strings ) inside your component directory. Each language gets its own file, named with the pattern: <ComponentName>.<LCID>.resx The <LCID> part is the numeric Locale ID , not the textual code ( en-US , it-IT ). The framework relies on this naming convention to identify which file to load for a given user. Common LCIDs: Language LCID English (en-US) 1033 Italian (it-IT) 1040 German (de-DE) 1031 French (fr-FR) 1036 Spanish (es-ES) 3082 Japanese (ja-JP) 1041 Chinese Simplified (zh-CN) 2052 Portuguese (pt-BR) 1046 For a component called EquipmentGrid , the structure looks like this: EquipmentGrid/ ├── ControlManifest.Input.xml ├── index.ts └── strings/ ├── EquipmentGrid.1033.resx ├── EquipmentGrid.1040.resx └── EquipmentGrid.1031.resx Tip: Always include 1033.resx (English). The PCF runtime falls back to the first <resx> declared in the manifest when the user's preferred language isn't available, and English is the safest default. Step 2 — Author the resource file content A .resx file is just XML. Here's a minimal Italian version ( EquipmentGrid.1040.resx ): <?xml version="1.0" encoding="utf-8"?> <root> <resheader name= "resmimetype" > <value> text/microsoft-resx </value> </resheader> <resheader name= "version" > <value> 2.0 </value> </resheader> <resheader name= "reader" > <value> System.Resou