In Part 6, I used the requirements and architecture to create the GitHub epics and child issues. I now have a backlog that explains what needs to be built and how the work connects to the requirements.

Now I can start building. In this post, I will take one ready issue and use Copilot to work through the implementation, validation, and pull request.

Start From the Issue

I start by giving Copilot the issue URL. I ask it to read the issue, its parent epic, and the linked requirements before proposing any changes. I also want it to check whether anything needs to be completed or decided first.

I use a branch for the issue and keep the pull request focused on that change.

I will continue with the example from Part 6: “Enforce required information before submission,” under the “Grant application intake” epic. It links to REQ-001, which requires the requested amount and project summary before an application can be submitted for review.

For this example to be ready, the application fields and the way users submit an application need to exist. If they do not, I need to complete those issues first.

I give Copilot the parent epic so it understands the bigger picture. The child issue is the work I am asking it to complete.

The requirement ID takes it back to /docs/requirements/requirements.md. It can then read the agreed design in /docs/architecture/solution-architecture.md and the relevant decisions in /docs/decisions/decision-log.md.

If the issue and the documents disagree, I fix that before letting Copilot make changes. This is why I saved the information in the repository. A new session can read it without needing the chat where we originally worked it out.

Start PAC_COMMANDS.md With Commands We Actually Use

The same rule from Part 2 still applies to PAC_COMMANDS.md.

I do not want a giant list of every PAC CLI command that might theoretically be useful.

I add commands when the project actually uses them.

At this point that might include commands used to:

  • Authenticate to the target environment
  • List or select environments
  • Create or work with the solution
  • Export solution metadata
  • Unpack or validate components

I include enough context with each command that another developer, or Copilot, can understand when and why to use it.

These examples show the level of detail I want to keep. Each entry explains what the command does, when I used it, and any project-specific details needed to run it again.

Plan the Selected Issue Before Creating Components

We already worked out the backlog in Part 6. At this point, I want a plan for the issue I selected.

For the submission example, I want Copilot to look at the existing fields and how an application is submitted. Then it can explain what needs to change and how it will check the result. Any security requirements for the issue need to be included in that plan as well.

I use a prompt like this, replacing the placeholder with the actual child issue URL:

Read the implementation issue at <child-issue-url>, its parent epic,
and the linked requirements and architecture decisions.

Review the repository instructions, including the applicable AGENTS.md files.
Use the issue's requirement IDs to locate the supporting requirements in:
- /docs/requirements/requirements.md
- /docs/architecture/solution-architecture.md
- /docs/decisions/decision-log.md

Confirm the issue's scope, exclusions, acceptance criteria, and dependencies.
Inspect the existing solution before proposing changes.
Flag conflicts or unresolved decisions that block implementation.

Propose a plan for this issue only. Include:
- the components and repository paths you expect to change,
- the appropriate installed Power Platform skills and available tooling,
- how each step supports the issue's acceptance criteria,
- how you will validate the behavior and capture the results.

Do not implement changes yet. Present the plan for review.

I review the plan before implementation. Does it fit the issue? Does it follow the architecture? Is it changing anything outside the work we agreed to?

If we discover another decision or additional work is needed, I update the documents and affected issues first.

This is where the skills from Part 3 start doing the implementation work. The Power Platform Architect skill helped with the design in Part 5. Now I want Copilot to use the appropriate component skills for the work described in the issue.

Implement the Selected Issue

Only now do I let Copilot start changing the solution.

Once I am happy with the plan, I tell Copilot to implement it. An issue may need changes in more than one component. I still expect each change to have a reason tied to the issue and its acceptance criteria.

For this example, I am asking it to add the submission validation we agreed to. The review routing, award management, and reporting have their own issues.

Implement the reviewed plan for the selected child issue.
Follow the repository instructions and use the relevant installed skills.
Keep changes within the issue's scope and approved architecture.

Run the planned validation and report results against each acceptance criterion.
Update PAC_COMMANDS.md with any new reusable PAC commands actually used.
Report blockers or required scope changes before proceeding beyond the plan.
Stop when the issue's implementation and validation are complete.

For every change I still expect Copilot to:

  • Follow the repository instructions
  • Use the appropriate Power Platform skill
  • Explain the change it intends to make
  • Add any new PAC CLI commands to PAC_COMMANDS.md
  • Validate the result
  • Report warnings or failures instead of hiding them
  • Stop when the bounded task is complete

Validate Against the Issue

I want to see that the change does what the issue asked for. Passing a build or solution check is useful, but I also need to test the business behavior. I compare the results with each acceptance criterion and include the evidence in the pull request.

For REQ-001, I check what happens when the project summary is missing, when the requested amount is missing, and when both are missing. In each case, the application should stay out of review and the user should know what information is needed.

I also check that an application with both values can pass this validation, assuming the other submission rules are met.

I ask Copilot to show what it tested and mark each criterion as passed, failed, or not tested. If it cannot access the environment, I want a clear list of the checks I still need to run. I do not want an untested change reported as working.

If something blocks the work, I record it in the issue and resolve it before continuing.

Review the Pull Request

I use the pull request to explain what changed and show how I checked it. I link the implementation issue, include the requirement IDs, and call out anything that still needs attention. The review follows the repository rules set up in Part 4.

For this example, another developer should be able to follow REQ-001 from the requirements document to the issue and then to the changes in the pull request. They should also be able to see how I tested the submission rule. The other issues under the intake epic still need to be completed.

After the pull request is reviewed and merged, I update the issue and GitHub Project to reflect the work completed. Deployment and checks in the target environment follow the project's ALM process.

Then I move to the next ready issue. The requirements, architecture, issues, and pull requests give me a way to keep that work connected as the solution grows.

Resources