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

Working on Power Platform projects with GitHub Copilot – Part 4

Parts 2 and 3 prepared a reusable template and the skills that GitHub Copilot can use. Before I can apply that work to a real Power Platform project, I need to create the project's repository and set up how the work will be managed.

This post connects the template to a working project. By the end, I want a repository I can open locally, the right people able to contribute, and a GitHub Project ready to track the work. Discovery and architecture come in Part 5.

Create the Repository From the Template

Open the template repository in GitHub and select Use this template, then Create a new repository.

  1. Choose the owner: my account or the organization responsible for the solution.
  2. Give the repository a project-specific name and description.
  3. Choose the appropriate visibility for the project.
  4. Create the repository with the template's default branch unless there is a specific reason to include other branches.

For this series, I am creating an independent project from the template. I am not forking it to contribute changes back to the template.

The new repository contains the template's files and folder structure. It does not automatically stay synchronized with later template improvements. When I add something useful to the template, such as STARTER_PROMPTS.md (more about that in the next post), existing projects need a deliberate update.

Configure Access and the Review Process

Before inviting Copilot into the project, I check who can read the repository, create branches, and review changes.

For a team project, I add the appropriate collaborators or organization teams and agree on who reviews pull requests. I also review the default branch and configure the applicable branch protection or ruleset, so the team's review process is reflected in GitHub.

The exact rules depend on the account, repository visibility, and organization policies. The important decision is how a proposed change becomes an accepted change.

Clone the New Repository and Open It Locally

I clone the new project repository, not the template repository, and open that folder in VS Code.

Using the repository's Code menu lets me copy the correct clone URL. From a terminal, the basic sequence is:

git clone <new-project-repository-url>
cd <new-project-repository-folder>
code .
git remote -v
git status

The remote check matters. I want to confirm that any future push goes to this project, rather than accidentally changing the template.

Then I confirm that GitHub authentication and Copilot work in this workspace, and that the instructions, agents, and skills from the earlier posts are available through the setup I chose.

Make the Template Specific to the Project

I update the README with the project's purpose and links to its GitHub Project. I review the inherited instructions for template placeholders and replace values I already know.

I check the ignore rules before committing local configuration. Credentials, tokens, and local authentication material do not belong in the project files.

I retain component folders until discovery and architecture establish which ones are needed. Part 5 will provide the evidence for removing unused folders and adding solution-specific instructions.

Ready for Discovery

I now have a project repository, a local workspace, an agreed review process, and a place to manage the backlog.

Part 5 will use the business context and the Power Platform Architect skill to develop the requirements and architecture. Part 6 will turn that approved design into GitHub epics and implementation issues. Part 7 will begin implementation from one of those issues.

Resources