Parts 2 and 3 prepared the template and the Power Platform-specific skills and tooling that GitHub Copilot can use. In Part 4, I created the project repository from that template, configured GitHub, and opened the project locally.

In Part 5, I bring the business context into the repository and use the Power Platform Architect skill to develop the requirements and a proposed architecture. I use a simulated grant-management solution throughout the remaining posts so the prompts, decisions, and screenshots come from one consistent project.

The first step is not asking Copilot to build an app. Before I let it change a Canvas app, model-driven app, flow, site, agent, or Dataverse table, I want it to understand the business problem well enough to help design the solution.

Start With the Business Problem, Not the Power Platform Component

One of the easiest mistakes to make with an AI coding assistant is to begin with the technology decision.

Build me an app that does X.

That prompt has already made an architecture decision before the requirements have been analyzed.

Instead, I want to give Copilot the same kind of context I would gather when I am acting as a solution architect. That can include:

  • The original business problem or use case
  • Known pain points with the current process
  • Business rules
  • Users and stakeholder groups
  • Existing systems and data sources
  • Security and compliance requirements
  • Integration requirements
  • Reporting requirements
  • Constraints such as licensing, environment, cloud, or supported connectors
  • Existing documentation
  • Notes from discovery sessions
  • Teams meeting transcripts
  • Teams chats
  • Email threads
  • Existing requirements documents
  • Process diagrams
  • Screenshots of any existing applications or process
  • User stories, backlog items, issues, or support tickets
  • Anything else that explains why the solution is being built

Real projects rarely arrive as one clean requirements document. The useful information is normally spread across multiple places and written by different people for different reasons.

The goal is to give Copilot enough of that material to reconstruct the business problem before asking it to recommend a technical solution.

Build a Project Context Area

I prefer to bring the relevant project information into the repository rather than relying on a long chat conversation that eventually disappears.

The exact structure can vary by project, but a simple approach might look like this:

/docs
  /discovery
  /requirements
  /architecture
  /decisions
  /process
README.md
AGENTS.md
PAC_COMMANDS.md

The repository does not need to become a dumping ground for every file the customer has ever produced. I only bring in information that can help explain the business process, requirements, constraints, or architecture.

For example, the discovery folder might contain a sanitized Teams transcript, notes from stakeholder interviews, exported requirements, or summaries of important email threads. The architecture folder will eventually contain the proposed architecture and diagrams. The decisions folder can hold architecture decision records or other decisions that should survive beyond a Copilot chat session.

This also gives Copilot a stable set of artifacts it can review again later.

Let the Template Evolve With the Work

One thing I have learned while actually using this template is that the template itself should keep changing.

Part 2 showed the initial repository structure, but that was never meant to be the final version. As I use GitHub Copilot on real Power Platform projects, I keep finding small things that make the next project easier, more consistent, or safer.

One of those additions is a new file called STARTER_PROMPTS.md.

The idea is simple: if I find myself writing the same useful prompt more than once, it may belong in the template.

I do not want STARTER_PROMPTS.md to become a giant prompt library. It should contain a small set of proven prompts that help start common phases of a Power Platform project, especially the points where I want Copilot to slow down, inspect context, and follow a repeatable process.

The first prompt I added is the project discovery and context-review prompt used in this post:

Review the repository instructions and all of the project context under /docs.

Do not create or modify any Power Platform components yet.

Summarize:
1. The business problem we are trying to solve.
2. The primary users and stakeholders.
3. The current process and pain points.
4. Functional requirements you can identify.
5. Data sources and integrations mentioned.
6. Security, compliance, licensing, or environment constraints.
7. Reporting or analytics requirements.
8. Assumptions you had to make.
9. Conflicting information you found.
10. Questions that still need to be answered.

Cite the project files that led you to each conclusion.

Now, instead of recreating that prompt for every new repository, it is available as part of the template and can improve over time as I learn what works and what does not.

That is an important part of this whole approach. The repository template is not just setup work from Part 2. It is becoming a reusable development system. Every project can teach me something that gets fed back into the template for the next one.

Over time, STARTER_PROMPTS.md may include prompts for things such as:

  • Initial project discovery
  • Architecture review
  • Implementation planning
  • Security review
  • Testing and validation
  • ALM readiness
  • Pre-deployment review

But I only want to add prompts after they have proven useful in actual work.

Ask Copilot to Understand the Project Before Solving It

My first prompt is intentionally a review prompt.

I want Copilot to inspect the repository instructions and the available business material, then explain the problem back to me.

I start with the project discovery prompt stored in STARTER_PROMPTS.md. It tells Copilot to review the repository instructions and /docs, summarize the business problem, identify assumptions and conflicts, and cite the project files supporting each conclusion.

This step is valuable because it gives me a way to test Copilot's understanding before it starts making architecture decisions.

If the summary is wrong, incomplete, or based on a bad assumption, I fix the context first.

Use the Power Platform Architect Skill

This is where one of the skills from Part 3 becomes especially useful.

Awesome GitHub Copilot currently includes a Power Platform Architect skill that is designed to take business requirements, use-case descriptions, and meeting transcripts and turn them into a proposed Power Platform architecture.

Power Platform Architect skill

The important part is not simply that the skill knows the names of Power Platform products. It gives Copilot a solution-architect workflow.

The skill guides the agent through activities such as:

  1. Analyzing the requirements and identifying stakeholders, data sources, security needs, and pain points.
  2. Asking follow-up questions when important information is missing.
  3. Recommending Power Platform components based on the actual requirements.
  4. Explaining the architecture as a business process instead of just listing products.
  5. Optionally producing a Mermaid architecture diagram.

That is exactly the type of thinking I want before implementation begins.

This is one of the reasons I spent Part 3 gathering skills instead of immediately writing code. A specialized skill can change Copilot from a generic coding assistant into an assistant that follows a repeatable Power Platform architecture process.

Give the Architect All of the Business Context

The architect skill becomes more useful when it has more than a one-paragraph use case.

For a real project, I want it to consider the combined picture.

That may mean asking Copilot to review:

  • A business issue or project request
  • Teams meeting transcripts from discovery sessions
  • Teams chats where requirements were clarified
  • Email threads containing decisions or exceptions
  • Word, PDF, Excel, or PowerPoint documents supplied by stakeholders
  • Existing application screenshots
  • Process maps
  • Data dictionaries
  • Security requirements
  • Backlog items or GitHub issues
  • Existing Power Platform components
  • Repository documentation

The important point is that these sources are evidence, not instructions that Copilot should blindly follow.

A meeting transcript may contain an idea that was later rejected. An email might contradict a requirements document. A Teams chat might include an exception that never made it into the formal specification.

I want Copilot to identify those conflicts and ask about them.

A useful architecture prompt might look like this:

Use the Power Platform Architect skill.

Review the repository instructions and the discovery material under /docs.

Develop a proposed Power Platform solution architecture for this business problem.

Before recommending an architecture:
- identify conflicting requirements,
- identify missing decisions,
- call out assumptions,
- ask follow-up questions where the answer could materially change the design.

Do not implement the solution yet.

For the architecture, document:
- user groups,
- the as-is process,
- the proposed to-be process,
- Dataverse tables and major relationships,
- application experiences,
- automations,
- integrations,
- reporting,
- security boundaries,
- environment or ALM considerations,
- licensing or cloud constraints,
- components intentionally excluded from the first release.

Also produce a Mermaid diagram of the proposed architecture.

I am deliberately separating architecture from implementation.

Let Copilot Find the Gaps

A good architecture session should create questions.

If Copilot accepts every requirement at face value and immediately produces a perfect-looking diagram, I do not consider that a success.

I want it to surface things such as:

  • Who actually owns the data?
  • Is the application internal or external?
  • Are users licensed for premium connectors?
  • Is Dataverse allowed for this workload?
  • Does the solution need to operate in Commercial, GCC, GCC High, or DoD?
  • Are there data residency or compliance requirements?
  • What happens when an approver is unavailable?
  • What is the exception process?
  • What data needs to be retained?
  • Which system is authoritative?
  • Is information being created, synchronized, or only displayed?
  • What volume should the solution support?
  • What does the business consider a successful outcome?

These questions matter because the answer can change the architecture.

For example, "users need to access the process" is not enough information to decide between a Canvas app, model-driven app, Power Pages site, Teams experience, or another interface.

Treat the Architecture as a Proposal

Copilot can accelerate architecture work, but it does not own the architecture.

I still review every recommendation.

I look for questions such as:

  • Does every selected Power Platform component have a reason to exist?
  • Is the proposed data model unnecessarily complicated?
  • Is Copilot recommending a Canvas app simply because the word "app" appeared in the requirements?
  • Would a model-driven app better match a process-heavy internal workload?
  • Is Power Automate being used for something that should be synchronous logic?
  • Is the architecture introducing premium licensing without acknowledging it?
  • Is the security model realistic?
  • Does the design fit the target cloud?
  • Does it support ALM from the beginning?
  • Are there requirements that belong in a later phase instead of the first release?

The architecture skill is a design assistant, not an architecture approval authority.

Save the Approved Requirements and Architecture

Once I am comfortable with the direction, the important information needs to leave the chat and become part of the project.

I ask Copilot to update or create the project documentation.

That normally includes:

  • The project README.md
  • A requirements document
  • The proposed architecture
  • The Mermaid architecture diagram
  • Initial Dataverse data model notes
  • Security and integration considerations
  • Known assumptions
  • Open questions
  • Architecture decisions
  • Out-of-scope items
  • A high-level delivery sequence

The result is that a future Copilot session does not have to rediscover the project from scratch.

The missing step here is turning the analysis into something the next session can use. A summary in chat is useful for review, but I want the agreed requirements, their sources, and the decisions recorded in files before I ask Copilot to plan the work.

For this example, I use these files. The names are a convention for this series, not a requirement of the skill:

  • /docs/requirements/requirements.md holds the reviewed requirements, each with a stable ID such as REQ-001, its business rule, source file and section, and release scope.
  • /docs/architecture/solution-architecture.md explains how the proposed components support those requirements.
  • /docs/decisions/decision-log.md records agreed decisions, assumptions, unresolved questions, and which requirements they affect.

I use a follow-up prompt to save the results of the discovery and architecture conversation:

Use the analysis and architecture proposal we have just reviewed.

Create or update:
- /docs/requirements/requirements.md
- /docs/architecture/solution-architecture.md
- /docs/decisions/decision-log.md

Give each requirement a stable ID. For each requirement, record:
- the required business behavior,
- the source file and section supporting it,
- whether it is confirmed or still needs clarification,
- whether it is in scope for the first release.

Link architecture recommendations and decisions to the requirement IDs.
Keep assumptions and unresolved questions separate from confirmed requirements.
Do not mark a requirement or architecture decision approved unless
I have explicitly agreed to it.

Show me the changes for review.
Do not create GitHub issues or implement components yet.

I review those files, correct anything the agent misunderstood, and record which requirements and architecture decisions I approve. Saving an AI-generated document does not make its contents approved. Where a question could change the design, I resolve it or leave the affected work blocked.

These are the inputs Part 6 will use. The requirements explain what the solution must do, the architecture explains the agreed approach, and the decision log explains the constraints and remaining questions. If I open a new Copilot session, I can point it to these files rather than depending on the previous chat.

The actionable backlog belongs in GitHub issues. I use parent issues as epics and attach bounded implementation issues as sub-issues. Those issues link back to the requirements and architecture in the repository. Part 6 covers creating and reviewing that hierarchy; the documentation does not become a competing task tracker.

Update the Repository Instructions for This Solution

The template from Part 2 contains general Power Platform guidance.

A real solution will have project-specific rules.

After the architecture is approved, I update the root and component-level AGENTS.md files with anything Copilot needs to consistently apply during implementation.

Examples include:

  • The target Power Platform environment
  • Cloud-specific constraints
  • Publisher and solution naming
  • Dataverse naming conventions
  • Which component folders are actually in scope
  • Required validation commands
  • Security requirements
  • Integration boundaries
  • ALM expectations
  • Whether Copilot is allowed to create new components without approval

Hand the Architecture Over to Backlog Planning

Before any component changes begin, I check that the reviewed requirements have stable IDs and source references, that the architecture links back to them, and that unresolved decisions are visible. That saved analysis is the handoff to backlog planning.

Part 6 will group related requirements into business outcomes for the epic parent issues, then use the architecture to break those outcomes into bounded implementation issues. The requirement IDs will travel with the work so I can trace an issue back to the business evidence that justified it.

In Part 6, I will use Copilot to draft that hierarchy, review it, and create the approved GitHub issues. In Part 7, I will select one ready issue and use the component-specific skills to implement and validate it.

The Important Shift

The biggest change in this workflow is that GitHub Copilot is not starting from:

Build me an app.

It is starting from:

Understand the business problem, examine the evidence, identify what we do not know, help me design the architecture, document the decisions, and then implement one approved piece at a time.

That is a much closer match to how I already approach Power Platform projects as a solution architect.

AI does not remove the architecture work.

It gives me another tool for processing a large amount of project context, finding gaps, challenging assumptions, documenting decisions, and carrying that context forward into implementation.

What Comes Next

At this point the repository contains more than generic Copilot instructions.

It contains the business context, requirements, architecture, project-specific instructions, known decisions, and the Power Platform skills needed to work on the solution.

Part 6 turns that approved design into GitHub epics and implementation issues. Part 7 starts development from one of those issues, with validation and a pull request tied to its acceptance criteria.

Resources