Blog

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

Working on Power Platform projects with GitHub Copilot – Part 2

Introduction

In Part 1, I explained why GitHub Copilot matters for Power Platform professionals. Copilot can accelerate development, but we still need to provide context, define standards, and validate its work.

Before using Copilot to build anything, I prepare the repository where it will work. This post covers that foundation:

  • Creating a reusable GitHub template
  • Organizing it by Power Platform component
  • Adding root and component-level instructions
  • Adding compatibility files for Claude Code
  • Creating a living reference for PAC CLI commands
  • Creating a new project from the template

There is no application development in this post. The outcome is a reusable starting point for the rest of the series.

Creating the Repository Structure

Most Power Platform projects need a place for requirements, solution files, architecture decisions, tests, and deployment information. Creating that structure for every project is repetitive, so I use a GitHub template repository.

My starting structure reflects the components I commonly use:

power-platform-project/
├── AGENTS.md
├── CLAUDE.md
├── PAC_COMMANDS.md
├── README.md
├── plugins/
│   ├── AGENTS.md
│   ├── CLAUDE.md
│   └── README.md
├── copilot-studio-agents/
│   ├── AGENTS.md
│   ├── CLAUDE.md
│   └── README.md
├── reports/
│   ├── AGENTS.md
│   ├── CLAUDE.md
│   └── README.md
├── power-pages/
│   ├── AGENTS.md
│   ├── CLAUDE.md
│   └── README.md
├── azure/
│   ├── AGENTS.md
│   ├── CLAUDE.md
│   └── README.md
├── solutions/
├── docs/
│   ├── requirements/
│   ├── architecture/
│   ├── testing/
│   └── deployment/
└── .gitignore

The component folders provide starting locations for Dataverse plug-ins, Copilot Studio agents, Power BI reports, Power Pages, and Azure resources. I normally call the Power BI folder reports because a project may contain more than one report or semantic model.

A project may not use every folder. The goal is consistency, not forcing every project into the same architecture.

What Goes in the Template

The template contains reusable structure and guidance, not customer-specific information.

I include:

  • A root README.md explaining the repository and how to begin
  • Root and component-level agent instructions
  • A root PAC_COMMANDS.md for the PAC CLI commands used by the project
  • A README.md inside each component folder
  • Folders for requirements, architecture, testing, and deployment
  • A location for unpacked Power Platform solution files
  • A .gitignore for generated and local-only files

I do not include tenant IDs, environment URLs, connection information, credentials, or customer data. Every file in the template should have a clear purpose.

Layering the Agent Instructions

Putting every rule into one root AGENTS.md becomes difficult to maintain. A Power BI report does not use the same development process as a Dataverse plug-in, Copilot Studio agent, Power Pages site, or Azure Function.

GitHub supports multiple AGENTS.md files within a repository. When an agent works within the directory tree, the nearest file takes precedence.

I use the root file for rules that apply across the project:

  • Solution purpose and boundaries
  • Repository layout
  • Shared naming standards
  • Security and source-control rules
  • ALM expectations
  • Documentation requirements
  • Validation and approval gates

Each component folder has its own AGENTS.md:

  • plugins: .NET version, plug-in structure, testing, registration, and packaging
  • copilot-studio-agents: topics, tools, connections, testing, and solution packaging
  • reports: Power BI project format, semantic models, DAX, naming, and accessibility
  • power-pages: site model, Liquid or SPA conventions, Web API, web roles, table permissions, and deployment
  • azure: supported services, Infrastructure as Code, identity, runtime versions, testing, and deployment

The README.md explains the component to a developer. The AGENTS.md tells an AI agent how work in that folder must be performed and validated.

Supporting Claude Code

I also place a CLAUDE.md beside each AGENTS.md. Rather than duplicate the instructions, the file imports the authoritative instructions:

@AGENTS.md

Claude Code supports importing another file into CLAUDE.md with the @path/to/file syntax. This keeps AGENTS.md as the single source of truth for the directory while still giving Claude Code the file it expects.

I use this small forwarding file instead of a symbolic link. Power Platform teams frequently work on Windows, where creating symbolic links may require administrator privileges or Developer Mode.

Recording PAC CLI Commands

I also include a root PAC_COMMANDS.md file. This is a living reference for the Power Platform CLI commands actually used in the repository.

The goal is not to copy the entire PAC CLI reference. I only record commands that are relevant to the project. Each entry should explain:

  • What the command does
  • When it should be used
  • The folder from which it should be run
  • Required authentication or prerequisites
  • Which values must be replaced
  • Any result or validation that should follow

A starting entry can use this format:

## Command purpose

**Use when:** Describe when this command is needed.

**Run from:** `repository/path`


**Replace:**
- `<value>`: Explain the expected value.

**Verify:** Describe the expected result or follow-up check.

As the project grows, developers and agents add commands to this file when they introduce them. This makes successful command patterns reusable without turning the root AGENTS.md into a command reference.

The file must not contain passwords, client secrets, access tokens, or customer-specific values. Use placeholders for environment IDs, solution names, and other values that differ between projects. For the complete and current command syntax, link to the official Power Platform CLI documentation.

Making It a GitHub Template

After the structure and starter files are committed, I mark the repository as a template:

  1. Open the repository on GitHub.
  2. Select Settings.
  3. Under General, locate the repository settings.
  4. Enable Template repository.

The repository now displays a Use this template button. Selecting it creates a new repository with the template's files and folders but without its commit history.

Before using the template, I verify that:

  • The starter files do not contain customer information
  • Placeholder values are clearly marked
  • The component instructions do not conflict with the root instructions
  • The README explains how to remove unused folders
  • No secrets or local configuration files are committed

Ready for the Next Step

Part 2 ends with a reusable repository template containing:

  • Starting folders for common Power Platform components
  • Human-facing documentation in each folder
  • Root and component-specific AGENTS.md files
  • CLAUDE.md forwarding files
  • A growing PAC_COMMANDS.md reference for project-specific CLI commands
  • Locations for requirements, architecture, testing, and deployment documentation

In Part 3, I will equip the template with Microsoft Power Platform Skills and selected resources from Awesome GitHub Copilot. Development begins after the tooling and instructions are ready.

Resources