requirements-author

Requirements Author Skill

Overview

This skill defines how to produce and evolve requirements documents across the project lifecycle for two document types: the Business Requirements Document (BRD) and the Product Requirements Document (PRD). Shared requirements-engineering knowledge lives in references/_shared/, while BRD-specific and PRD-specific knowledge live in references/brd/ and references/prd/ so each consuming agent loads only what its document needs.

The canonical BRD template is brd-full.md with its brd-frontmatter-overlay.md, and the canonical PRD template is prd-full.md. The BRD Builder dispatches into the BRD phase anchors (#discover, #define, #govern); the PRD Builder dispatches into the PRD phase anchors (#prd-assess through #prd-finalize).

Use this skill with the references for the active document scope:

Shared (references/_shared/):

• Requirements Definition
• Traceability Naming
• Traceability Matrix

BRD scope (references/brd/):

• BRD-to-PRD Handoff
• Outcome Hypothesis-to-BRD Handoff
• BRD Quality Formats

PRD scope (references/prd/):

• Product Discovery
• EARS Acceptance
• PRD Quality Formats

Handoff Transport Convention

The producing workflow owns each handoff's canonical transport, and the consumer validates the complete payload regardless of transport. An outcome hypothesis returns OUTCOME_HYPOTHESIS_TO_BRD_HANDOFF_V1 inline by default because it is a one-time seed derived from an already persisted source artifact; the user may instead supply a separately persisted payload path. BRD Govern persists BRD_TO_PRD_HANDOFF_V1 and returns its path because that payload is a durable governance record consumed across agent sessions. This asymmetry is intentional and does not change payload authority or validation.

BRD Lifecycle

Discover {#discover}

Activities

• Capture business context, drivers, imposed constraints, and expected outcomes.
• Identify stakeholders, decision owners, and review participants.
• Define scope boundaries, assumptions, and dependency surfaces.
• Draft initial requirement candidates and map early traceability placeholders.
• Validate and disposition an OUTCOME_HYPOTHESIS_TO_BRD_HANDOFF_V1 payload when one is supplied.

Outcome hypothesis intake

Use Outcome Hypothesis-to-BRD Handoff as the canonical contract.

1. Accept the YAML inline or from a user-supplied artifact path.
2. Validate the complete payload before copying any value into the BRD.
3. Reject unsupported versions, incomplete seeds, placeholder values, and invalid provenance. Do not reinterpret a rejected payload as unstructured evidence.
4. Assign the next stable BG-### identifier.
5. Record distinct statement, KPI, baseline, target, timeframe, measurement source, and owner values.
6. Mark each seed field accepted or revised. For a revision, preserve the source value, current BRD value, and rationale.
7. Map assumptions and open questions into their canonical BRD sections. Initialize each imported question to Open unless Discover explicitly confirms another BRD-owned status. Every deferred question requires a rationale for deferral and one target phase: PRD, Implementation, Operations, or Future-Release.
8. Record the handoff ID, source path, source SHA-256, and KPI measurement source in the BRD provenance receipt.

Before Discover accepts the handoff, the validated payload is authoritative for imported seed values. Discover may explicitly accept or revise those values. After Discover exits, the BRD is authoritative. A later hypothesis change requires a new validated payload and explicit Discover re-entry.

Hard exit gate

Discover exits only when:

• Scope is bounded and stakeholder ownership is explicit.
• Core assumptions and constraints are documented and reviewable.
• Seed artifacts needed for Define are present and internally consistent.
• Any outcome-hypothesis handoff has passed validation, every imported seed field has an explicit disposition, and its provenance receipt is complete.

Output artifacts

• Discover summary and scope statement.
• Stakeholder inventory with role and ownership mapping.
• Initial assumption and constraint register.
• Seed requirement and traceability scaffold for Define.
• Outcome-hypothesis receipt and field dispositions when a handoff was supplied.

Define {#define}

Activities

• Author full BRD content using brd-full.md and the canonical naming rules.
• Refine business goals and requirement sets with clear acceptance intent.
• Build and verify author-maintained traceability links across FR, AC, BG, and BR records.
• Perform quality assessment using the BRD quality reporting contract.

Hard exit gate

Define exits only when:

• Requirement content is complete, unambiguous, and testable.
• Traceability links satisfy the active ID schema and naming policy.
• FR-to-AC coverage meets the active fr_to_ac_coverage_threshold_pct or has a recorded blocker.
• Quality findings are generated and reviewed against the defined rubric.

Output artifacts

• Full BRD draft package with structured sections.
• Author-maintained traceability matrix aligned to naming and ID conventions.
• BRD quality findings and consolidated quality report payloads.
• Define gate decision record with reviewer notes.

Govern {#govern}

Activities

• Prepare final BRD for approval with version metadata and lineage fields.
• Bump approved BRDs from draft 0.x.y versions to 1.0.0 or higher.
• Resolve or disposition remaining quality findings.
• Publish approved BRD outputs and downstream handoff payloads.
• Maintain supersession chain when issuing replacement BRD versions.

Govern handoff production

Before emitting BRD_TO_PRD_HANDOFF_V1, the BRD Builder applies the coverage and waiver validation rules in BRD-to-PRD Handoff, including zero-FR coverage handling. It records the following values from the signed-off BRD and final quality review:

• A lowercase SHA-256 hash of the exact BRD artifact bytes at signoff.
• Counts for FR, NFR, BR, CON, AC, and BG identifiers using id-schema.md.
• FR-to-AC and FR-to-BG coverage metrics from the author-maintained traceability matrix.
• The final BRD_QUALITY_REPORT_V1 reference, overall status, and Govern decision.
• Signoff approvers, roles, decisions, approval timestamps, comments, and active waivers.
• Waiver records for any accepted FR-to-AC threshold gap or FR-to-BG target gap.

After validation succeeds, write the complete YAML payload to .copilot-tracking/brd-sessions/<brd-name>.handoff.yml, record that path in BRD session state, and return the path with a compact Govern summary. Do not rely on an inline chat payload as the downstream transport.

Hard exit gate

Govern exits only when:

• Approval status and required reviewers are recorded.
• Version and lineage metadata are valid and complete.
• The final quality report authorizes Govern exit.
• Handoff artifacts are published for downstream consumers.

Output artifacts

• Approved BRD release artifact.
• BRD-to-PRD handoff payload.
• Governance decision log with approval evidence.
• Supersession linkage record for replaced BRD versions.

Status taxonomy

Use the following status values for BRD lifecycle tracking:

• draft: Actively authored or revised.
• in-review: Under formal review and gate validation.
• approved: Accepted for governed use.
• superseded: Replaced by a newer approved BRD.

Quality rubric pointer

Apply the BRD quality rubric and payload contracts from BRD Quality Formats together with guidance in Requirements Definition. Treat rubric results as gate evidence for Define and Govern decisions. The BRD Quality Reviewer emits both standard findings and the consolidated quality report.

Supersession lineage rules

• A BRD can supersede one or more earlier BRDs when scope is merged.
• A BRD can be superseded by only one approved successor version.
• Every supersession event records supersedes and superseded_by links.
• Supersession preserves historical artifacts for auditability.

PRD Lifecycle

The PRD Builder agent runs a seven-phase lifecycle. Each phase has its own section anchor below so the agent loads only the guidance for the active phase.

PRD Assess {#prd-assess}

Activities

• Determine whether enough product context exists to create PRD artifacts.
• Identify the initiative, problem statement, and primary target users.
• Check for an upstream BRD_TO_PRD_HANDOFF_V1 artifact path and ingest its coverage and waiver context when present.
• Check for an upstream feasibility-to-PRD handoff. Follow Feasibility-to-PRD Handoff to recognize it by kind, verify required metadata, verdict field presence, and a readable workspace-relative study path. Treat feasibility as supplementary evidence and preserve approved BRD scope.
• For a new session, carry the handoff kind, path, ingest timestamp, verdict, and study revision identifier in the Assess output until Create writes the state file. When state already exists, update its feasibility-specific metadata object directly. Keep raw candidate content in the handoff artifact.
• Decide whether to gather more context or proceed to file creation.

Hard exit gate

Assess exits only when:

• A meaningful kebab-case PRD name can be derived.
• Problem framing and primary users are identified.
• Any available BRD handoff artifact has been read, its payload validated, and its coverage metrics recorded.
• Any available feasibility handoff is recognized by kind, has readable workspace-relative paths, a valid verdict shape, and normalized metadata ready for Create or persisted in existing state.

Output artifacts

• Assess summary noting context sufficiency.
• Derived working title for the PRD.
• Ingested handoff context when a BRD handoff payload exists.
• Feasibility verdict, evidence summary, constraints, gaps, and normalized handoff metadata when a feasibility handoff exists. Negative verdicts create no candidate dispositions.

PRD Discover {#prd-discover}

Activities

• Ask focused questions to establish the PRD title, scope, and product goals.
• Explore the problem space using Product Discovery and MVP Framing.
• Capture target users, candidate success metrics, and explicit non-goals using Metrics Frameworks.

Hard exit gate

Discover exits only when:

• Title and scope are explicit.
• Primary users and candidate success metrics are named.
• In-scope and out-of-scope boundaries are recorded.

Output artifacts

• Discovery summary.
• Scope and non-goals statement.
• Candidate success metrics.

PRD Create {#prd-create}

Activities

• Generate the PRD file from prd-full.md and create the session state file once title and context are clear.
• Populate the skeleton with the established scope, users, and goals.
• Seed the iterative requirement and metric structure for Build.
• When Assess produced normalized feasibility metadata, write its fields atomically to the new state file as feasibilityHandoff, carrying kind, path, ingestedAt, verdict, and studyRevisionId. State written before this contract may carry schemaVersion instead of kind; read it without error and rewrite the object to the current shape on the next feasibility metadata update. Do not persist raw candidate content.

Hard exit gate

Create exits only when:

• The PRD file and state file exist.
• The skeleton matches the canonical PRD structure.
• Initial scope and goals are seeded.
• Any normalized feasibility metadata from Assess is present in the newly created state before Build begins.

Output artifacts

• PRD draft skeleton.
• PRD session state file.
• Seeded scope and goals sections.
• Feasibility handoff metadata persisted when supplied.

PRD Build {#prd-build}

Activities

• Gather detailed functional and non-functional requirements iteratively.
• When feasibilityHandoff is present, read candidate content from its workspace-relative path. Stop if ingestion was reported but metadata is absent or the path is unreadable.
• Give every forward-verdict feasibility candidate exactly one PRD-owned disposition: accepted-fr, accepted-nfr, accepted-constraint, retained-gap, rejected, or deferred. Treat concern hints as advisory evidence only.
• Allocate final FR-###, NFR-###, or CON-### identifiers only after authoring and accepting the PRD statement. Preserve source handoff ID, source candidate ID, evidence references, disposition, rationale, and resulting PRD ID in the Feasibility Candidate Disposition register.
• Preserve signed-off BRD authority. Record and explicitly resolve BRD and feasibility conflicts, or retain them as Build gaps when current evidence cannot support a responsible resolution.
• Author acceptance criteria using EARS Acceptance and the Connextra Template.
• Classify non-functional requirements with the NIST 800-160 NFR taxonomy and check stories against INVEST.
• Maintain author traceability across requirements, goals, and metrics using Traceability Naming, Traceability Matrix, and id-schema.md.

Hard exit gate

Build exits only when:

• Requirements are complete, testable, and traceable.
• Acceptance criteria follow EARS or Given-When-Then form.
• Non-functional requirements are categorized.
• Coverage meets the active thresholds or records a blocker.
• Every forward-verdict feasibility candidate has exactly one disposition row, every accepted row names its final PRD ID, and negative verdicts have no candidate rows.

Output artifacts

• Full PRD requirement set.
• Author-maintained traceability matrix.
• Acceptance criteria and NFR classifications.
• Feasibility Candidate Disposition register when a forward feasibility handoff exists.

PRD Integrate {#prd-integrate}

Activities

• Incorporate user-provided references, documents, and external materials.
• Reconcile incoming content with existing requirements and resolve conflicts.
• Link supporting evidence to requirements and metrics.

Hard exit gate

Integrate exits only when:

• Provided references are incorporated or explicitly deferred.
• Conflicts between sources are resolved.
• Supporting evidence is linked.

Output artifacts

• Updated PRD sections with integrated references.
• Reference and evidence linkage record.

PRD Validate {#prd-validate}

Activities

• Assess completeness and quality before approval.
• Run the PRD Quality Reviewer to emit PRD_STANDARD_FINDINGS_V1 and PRD_QUALITY_REPORT_V1 per PRD Quality Formats.
• Review findings against the rubric and resolve or disposition gaps.

Hard exit gate

Validate exits only when:

• Quality findings and the consolidated report are generated.
• The report authorizes Validate exit via gate_decisions.validate_exit.
• Coverage and quality thresholds are met or waived.

Output artifacts

• PRD quality findings and report payloads.
• Validate gate decision record.

PRD Finalize {#prd-finalize}

Activities

• Deliver the complete, actionable PRD.
• Resolve remaining findings and record version and approval metadata.
• Run a Finalize drift check and publish downstream artifacts.

Hard exit gate

Finalize exits only when:

• Approval status and required reviewers are recorded.
• The final quality report authorizes Finalize exit via gate_decisions.finalize_exit.
• No unresolved blocking findings remain.

Output artifacts

• Approved PRD release artifact.
• Finalize decision log with approval evidence.

References

The skill bundles reference documents under references/, organized into three scopes: shared requirements-engineering knowledge in references/_shared/, BRD-specific knowledge in references/brd/, and PRD-specific knowledge in references/prd/. Load a reference body only when its phase activity requires it; each body links to its own sub-references (standards pointers, scoring sheets, and worked examples).

Shared references (references/_shared/)

• requirements-definition.md - Requirement categories, canonical statement form, acceptance-criteria formats, and quality dimensions.
• stakeholder-analysis.md - Mendelow Power/Interest grid and RACI accountability variants.
• process-modeling.md - Optional process, decision, and structural diagram guidance.
• prioritization-schemes.md - Required MoSCoW prioritization scheme.
• traceability-naming.md - Requirement, goal, and decision identifier routing plus traceability conventions.
• id-schema.md - Canonical prefix, digit, and adjacent identifier rules.
• traceability-matrix.md - Author-maintained FR-to-AC, FR-to-BG, and BR-to-FR matrix views.
• design-decisions.md - Registry for DD-### design decision codes.
• quality-rubric.md - Operational status taxonomy (RISK / CAUTION / COVERED / NOT_APPLICABLE) and the gate decision rule.
• standards-excerpts.md - Cite-only registry of third-party standards (ISO, IIBA, PMI, ISTQB) referenced by name.

BRD references (references/brd/)

• brd-quality-formats.md - Producer and consumer map for the BRD data contracts.
• requirements-quality-rubric.md - Combined per-requirement, per-NFR-category, and per-business-goal scoring sheets.
• handoff-payload-schema.md - BRD-author view of the BRD-to-PRD handoff payload.

PRD references (references/prd/)

• product-discovery.md - Problem-space exploration and discovery questioning for PRD scope.
• mvp-framing.md - MVP framing and scope-boundary guidance.
• metrics-frameworks.md - JTBD, HEART, and AARRR success-metric frameworks.
• ears-acceptance.md - EARS acceptance-criteria patterns for PRD requirements.
• nist-800-160-nfr.md - NIST 800-160 non-functional requirement taxonomy.
• invest.md - INVEST quality criteria for user stories.
• connextra-template.md - Connextra user-story template.
• prd-quality-formats.md - Producer and consumer map for the PRD data contracts.
• feasibility-to-prd-handoff.md - Consumer rules for feasibility Assess ingestion, Create persistence, Build disposition, BRD coexistence, and source traceability.

Templates

Templates under templates/ are selected by the document frontmatter and canonical document shape.

• brd-full.md - Canonical BRD template covering every section from Executive Summary through Sign-Off.
• brd-frontmatter-overlay.md - Schema for BRD YAML frontmatter, including diagram_format, lineage, coverage thresholds, and requirement-prefix overrides.
• diagram-mermaid.md - Mermaid flowchart fragment; the default diagram format.
• diagram-ascii.md - ASCII process-diagram fragment for low-fidelity Discover-phase sketches.
• prd-full.md - Canonical PRD template covering every section from product overview through acceptance and metrics.

Data Contracts

Payload contracts govern quality assessment and downstream handoff for each document type. The quality and BRD handoff payloads carry a fixed schema_version; consumers fail fast on any other value, so those constants MUST NOT change. The feasibility-to-PRD handoff instead carries a plain kind marker, because its producer and consumer ship together and no version negotiation applies.

BRD data contracts:

PRD data contracts:

Upstream PRD input contracts:

The PRD lifecycle consumes both upstream contracts during Assess. BRD input supplies approved business context, coverage, and waivers. Feasibility input supplies a confirmed verdict, evidence, constraints, gaps, and candidate proposals for PRD Build. Neither contract bypasses PRD authoring.

Mandatory Load Directives

The BRD Builder and PRD Builder agents each enforce a phase → section load contract. Each phase MUST load its section of this skill before executing phase work, and MUST append the section anchor to state.phaseSkillsLoaded.

BRD Builder directives:

PRD Builder directives:

The agent loads sections via read_file against this skill file and records the entry in state.phaseSkillsLoaded before any phase work executes. Re-entering a previously loaded phase does not require reloading; the agent checks phaseSkillsLoaded first.

Source Attribution

The bundled reference bodies cite third-party standards and frameworks by name and clause only; no upstream prose is reproduced or paraphrased. Where a reference names a standard's characteristics or categories, the accompanying review criteria, anchors, and indicators are original Microsoft content under CC BY 4.0, not reproductions of the standard's definitions; the authoritative definitions live in the cited standards. The cite-only registry in standards-excerpts.md is the single place new standards citations are added. Standards referenced by name include ISO/IEC/IEEE 29148:2018, ISO/IEC 25010:2023, IIBA BABOK v3, PMI Business Analysis for Practitioners, the ISTQB Glossary, OMG BPMN / DMN / UML, the Cucumber Gherkin pattern, and MoSCoW prioritization, each the property of its respective rights holder.

License

This skill is original Microsoft content licensed under CC BY 4.0.