Add Power Platform Requirements Architect skill

[Jan (Jndvr)]

Adds Power Platform Requirements Architect, a Copilot Studio skill that turns a Power Platform solution idea into a complete YAML requirements handoff for a coding agent.

The skill:

conducts structured stakeholder discovery;

defines requirements, architecture decisions, security, data, integrations, and acceptance criteria;

creates traceable work items, dependencies, deployment inputs, and build order;

separates requirements approval from implementation readiness.

This skill performs requirements engineering only. It contains no scripts, external dependencies, secrets, or organization-specific information.

[Copilot]

Pull request overview

Adds a new Copilot Studio skill submission under submissions/power-platform-requirements-architect/ that guides a structured Power Platform requirements/architecture interview and produces a single canonical YAML handoff (POWER_PLATFORM_SOLUTION_SPEC_V1) for a separate coding agent.

Changes:

• Introduces the skill definition (SKILL.md) with workflow phases, output/serialization rules, and completion gates.
• Adds a YAML handoff template (assets/solution-spec.template.yaml) defining the canonical schema and authority/stop conditions.
• Adds supporting reference materials covering interview strategy, discovery coverage, architecture decisions, surface-specific specification guidance, handoff contract, and a manual self-check.

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
submissions/power-platform-requirements-architect/SKILL.md	Skill runtime instructions, scope boundaries, workflow phases, and output rules.
submissions/power-platform-requirements-architect/README.md	Human-facing overview, usage guidance, and Copilot Studio adoption instructions.
submissions/power-platform-requirements-architect/metadata.json	Submission metadata (name/description/platform/tags/author/version/dates).
submissions/power-platform-requirements-architect/assets/solution-spec.template.yaml	Canonical YAML schema template for the single handoff artifact.
submissions/power-platform-requirements-architect/references/handoff-contract.md	Defines the final response shape and the coding-agent execution contract.
submissions/power-platform-requirements-architect/references/self-check.md	Manual checklist and pass/block outcomes before emitting the YAML.
submissions/power-platform-requirements-architect/references/interview-strategy.md	Core elicitation approach and sequencing guidance.
submissions/power-platform-requirements-architect/references/discovery-checklist.md	Domain coverage checklist to ensure requirements completeness.
submissions/power-platform-requirements-architect/references/architecture-decisions.md	Structured prompts for key architecture decisions (AD-*).
submissions/power-platform-requirements-architect/references/dataverse-spec.md	Guidance for specifying data layer details precisely (tables/columns/choices/etc.).
submissions/power-platform-requirements-architect/references/automation-spec.md	Guidance for specifying Power Automate flows (triggers, identity, error handling, idempotency).
submissions/power-platform-requirements-architect/references/app-and-agent-spec.md	Guidance for specifying app/agent surfaces (screens, states, delegation, accessibility).
submissions/power-platform-requirements-architect/references/coding-agent-handoff.md	Rules for decomposing into traceable work items and dependency-safe build order.

[Jan (Jndvr)]

@microsoft-github-policy-service agree

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated no new comments.

Suppressed comments (4)

submissions/power-platform-requirements-architect/references/handoff-contract.md:50

• The manual self-check outcomes in this header don’t match the canonical handoff.manual_self_check.status values defined in references/self-check.md and the YAML template, which can lead to emitting a header status that isn’t representable/traceable in the YAML.

Manual self-check: passed | passed with listed noncritical assumptions

submissions/power-platform-requirements-architect/assets/solution-spec.template.yaml:33

• meta.status in the YAML template includes superseded, but the status model in references/handoff-contract.md defines only draft, in_review, and approved. This inconsistency can lead to invalid/undefined status values in generated handoffs.

  meta:
    spec_version: "1.0"
    status: draft            # draft | in_review | approved | superseded
    tier: M                  # S | M | L
    revision: 1

submissions/power-platform-requirements-architect/assets/solution-spec.template.yaml:207

• The template uses SET_AT_DEPLOY for an unresolved environment-variable value, but the handoff contract’s placeholder rules only define SET_AT_BUILD (and require it map to a DEP- entry). Using an undocumented placeholder token makes the handoff rules ambiguous for the agent and any downstream tooling.

      values:
        dev: ""
        test: ""
        prod: "SET_AT_DEPLOY"
      used_by: []

submissions/power-platform-requirements-architect/references/automation-spec.md:68

• This reference instructs authors to use SET_AT_DEPLOY, but the canonical placeholder rules in references/handoff-contract.md only define SET_AT_BUILD. Aligning terminology avoids producing specs that violate the contract.

- Every connector use becomes a **connection reference** (`CR-`), with connector, tier, auth model, consenting identity, and whether consent is a human gate (it almost always is).
- Every environment-specific value becomes an **environment variable** (`EV-`): site URLs, list names, group ids, mailboxes, API base URLs, thresholds someone will want to change without editing the flow, feature toggles.
- Secrets go in an Azure Key Vault-backed environment variable, never in a flow, never in a spec file. If the spec would otherwise contain a credential, write `SET_AT_DEPLOY` and name the owner.

[adilei]

Where is the generated YAML supposed to go? We’re not aware of a Power Platform coding agent that consumes POWER_PLATFORM_SOLUTION_SPEC_V1 and can implement all of the described Dataverse, app, flow, security, integration, and deployment work. Could you clarify the intended downstream agent or workflow for this handoff?