{"id":1678,"date":"2026-10-07T20:31:21","date_gmt":"2026-10-08T01:31:21","guid":{"rendered":"https:\/\/automatethemundane.com\/index.php\/2026\/10\/07\/working-on-power-platform-projects-with-github-copilot-part-4\/"},"modified":"2026-10-07T20:31:21","modified_gmt":"2026-10-08T01:31:21","slug":"working-on-power-platform-projects-with-github-copilot-part-4","status":"publish","type":"post","link":"https:\/\/automatethemundane.com\/index.php\/2026\/10\/07\/working-on-power-platform-projects-with-github-copilot-part-4\/","title":{"rendered":"Working on Power Platform projects with GitHub Copilot – Part 4"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

Create the Repository From the Template<\/h2>\n

Open the template repository in GitHub and select Use this template<\/strong>, then Create a new repository<\/strong>.<\/p>\n

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

    For this series, I am creating an independent project from the template. I am not forking it to contribute changes back to the template.<\/p>\n

    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<\/code> (more about that in the next post), existing projects need a deliberate update.<\/p>\n

    \"\"<\/figure>\n

    Configure Access and the Review Process<\/h2>\n

    Before inviting Copilot into the project, I check who can read the repository, create branches, and review changes.<\/p>\n

    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.<\/p>\n

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

    Clone the New Repository and Open It Locally<\/h2>\n

    I clone the new project repository, not the template repository, and open that folder in VS Code.<\/p>\n

    Using the repository's Code menu lets me copy the correct clone URL. From a terminal, the basic sequence is:<\/p>\n

    git clone <new-project-repository-url>\ncd <new-project-repository-folder>\ncode .\ngit remote -v\ngit status<\/code><\/pre>\n
    The remote check matters. I want to confirm that any future push goes to this project, rather than accidentally changing the template.<\/p>\n
    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.<\/p>\n
    \"\"<\/figure>\n
    Make the Template Specific to the Project<\/h2>\n
    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.<\/p>\n
    I check the ignore rules before committing local configuration. Credentials, tokens, and local authentication material do not belong in the project files.<\/p>\n
    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.<\/p>\n
    Ready for Discovery<\/h2>\n
    I now have a project repository, a local workspace, an agreed review process, and a place to manage the backlog.<\/p>\n
    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.<\/p>\n
    Resources<\/h2>\n