Blog

You are currently viewing Working on Power Platform projects with GitHub Copilot – Part 3

Working on Power Platform projects with GitHub Copilot – Part 3

In Part 2, I created a reusable GitHub template for Power Platform projects. It includes component folders, layered AGENTS.md files, CLAUDE.md forwarding files, and a growing PAC_COMMANDS.md reference.

The repository now tells an AI coding assistant how the project is organized. The next step is to give it the task-specific Power Platform knowledge and tools it will need. This post stays in setup mode. I am not creating an app, flow, site, report, or agent yet. Development begins in Part 4.

Instructions, Agents, Skills, and Plugins

These terms are related, but they solve different problems.

  • Instructions define rules that should apply broadly. The root and component-level AGENTS.md files from Part 2 contain repository structure, standards, boundaries, and validation expectations.
  • Agents provide a specialized role for a type of work. An agent may focus on planning, implementation, testing, security, or another responsibility.
  • Skills contain detailed instructions and supporting resources for a specific task. Copilot loads a skill when its description matches the work being requested.
  • Plugins package related capabilities. A plugin can include skills, agents, commands, and connections to tools such as MCP servers.

I do not want the same guidance copied into every layer. The AGENTS.md files describe how this repository should be handled. Skills describe how to complete specialized work. Plugins make a collection of those capabilities available to the coding assistant.

Start with Microsoft Power Platform Skills

Microsoft maintains the Power Platform Skills repository as a marketplace of official Power Platform development plugins for Claude Code and GitHub Copilot.

At the time of writing, the repository includes plugins for Power Pages, model-driven apps, Canvas apps, Power Automate, code apps, mobile apps, Power Apps mobile extensions, and MCP apps. Each plugin has its own purpose, dependencies, and implementation approach.

I do not add every plugin to every project. I start with the solution architecture.

For example:

  • A Canvas app project may need the Canvas Apps plugin and its Canvas Authoring MCP dependency.
  • A cloud-flow project may need the Power Automate plugin and its FlowAgent MCP dependency.
  • A Power Pages code site may need the Power Pages plugin.
  • A model-driven app project may need the Model Apps plugin.

The repository's convenience installer currently installs all listed plugins. That can be useful for a general development workstation, but it is not automatically the right choice for a focused project. The maintained documentation also describes how to install individual plugins.

I am linking to the current installation section instead of copying its commands here. The tools, prerequisites, plugin names, and installation process can change. The project documentation should point readers to the maintained source.

If you are in GCC/GCCH/DoD clouds the Power Automate skill requires an Azure app registration that may or not be setup by default. You will need to work with your admin team to get it working.

Review Before Installing

Official does not mean automatic. I still review a plugin before adding it to my workflow.

My review includes:

  • The problem the plugin is intended to solve
  • The skills, agents, commands, and scripts included in the plugin
  • Required runtimes, CLIs, authentication, and MCP servers
  • File, shell, network, and Power Platform permissions it may use
  • Telemetry behavior
  • How the plugin is updated
  • Whether its instructions conflict with the repository's AGENTS.md files

This matters because a Power Platform plugin may do more than provide prompt guidance. It may edit files, run commands, authenticate to a tenant, or call an MCP server. Microsoft’s repository also warns that broad auto-approval gives the agent the same access the user has on the machine. I prefer explicit permissions and a trusted development environment.

I also read the plugin-specific documentation instead of assuming that the repository-level prerequisites cover everything. The current Canvas Apps plugin, for example, uses PA YAML and the Canvas Authoring MCP server, while the Power Automate plugin uses FlowAgent and has a different set of prerequisites.

Use Awesome GitHub Copilot as a Catalog

The Power Platform plugins provide domain knowledge. Awesome GitHub Copilot provides a broader catalog of community-contributed agents, instructions, skills, and plugins.

I start with the Learning Hub. Its fundamentals explain the customization layers, including instructions, skills, agents, MCP servers, and plugins. This is useful before browsing the catalog because it helps prevent installing several resources that solve the same problem.

From there, I search for a specific gap in the project. Examples might include documenting architecture, reviewing security, planning tests, or troubleshooting GitHub Actions. I do not browse for resources simply to make the tool list longer.

My evaluation is similar to the Power Platform review:

  1. Does the resource solve a problem this project actually has?
  2. Does its description clearly explain when it should be used?
  3. What other files, scripts, tools, or permissions are included?
  4. Does it duplicate or contradict the repository instructions?
  5. Is the source and update history acceptable for the project?

GitHub’s agent skills documentation specifically warns that third-party skills are not verified and can contain hidden instructions or malicious scripts. I preview and inspect a skill before installing it.

Project Scope or Personal Scope

The next decision is where a selected resource belongs.

I use a project-level skill when the project depends on it for consistent delivery. Project skills travel with the repository and can be reviewed and versioned with the rest of the project. GitHub currently supports project skill directories under .github/skills, .claude/skills, and .agents/skills.

I use a personal skill when it supports the way I work across many repositories but is not required to understand or maintain this solution. GitHub documents personal skill locations under ~/.copilot/skills and ~/.agents/skills.

The reusable template should contain only broadly useful project resources. A skill required for every Power Platform repository may belong in the template. A skill for one customer, component, or delivery process belongs in the repository created from the template. Personal writing or research helpers stay outside the project.

Even when a plugin is installed outside the repository, I document the dependency in the project README when other contributors need it. I include the purpose, the authoritative documentation link, and any required version or authentication notes. I do not copy installation commands into the README unless the repository owns and tests those commands.

Connect the Tooling to the Template

The repository now has three complementary sources of guidance:

  • AGENTS.md defines repository and component rules.
  • Skills and plugins provide task-specific procedures and tooling.
  • PAC_COMMANDS.md records the PAC CLI commands that have actually been used and confirmed for this repository.

For example, the Canvas Apps AGENTS.md file can require source-controlled files, naming standards, accessible controls, and validation before a change is complete. The Canvas Apps skill can provide the procedure and tools for working with .pa.yaml files. PAC_COMMANDS.md can record the exact export, unpack, pack, and validation commands used by the project.

Each file has one job. This reduces duplication and makes it easier to update a tool without rewriting the repository standards.

Validate the Setup Without Developing

I finish with a short validation session before anyone starts building.

  1. Create a repository from the template and open it in the supported development environment.
  2. Ask Copilot to summarize the root instructions and the instructions for one component folder.
  3. Confirm that the selected skills and plugins are available.
  4. Give Copilot a hypothetical Power Platform task and ask which instructions and skill it would use.
  5. Review the tools and permissions it says it needs.
  6. Stop before it creates or modifies any Power Platform component.

This does not prove that every future task will be correct. It does confirm that Copilot can find the repository guidance, distinguish it from task-specific skills, and identify the expected tooling.

Ready for Development

The setup is complete when:

  • The repository instructions are recognized
  • Only relevant skills and plugins have been selected
  • Dependencies and authentication requirements are documented
  • Permissions and telemetry have been reviewed
  • Project and personal resources are separated
  • No conflicting instructions remain
  • No Power Platform component has been created yet

In Part 4, I will use this prepared repository and tooling to define the first real solution and begin development.

Resources