Instruction file imported from gargislalom/so-ai-training-101-pnw-team2 (.github/instructions/intake/workflows/domain-feature-prds.instructions.md). Copyright stays with the author.

Domain Feature PRDs

Produces the full set of feature-level PRDs for a domain, following the escrow-management folder structure as the canonical reference.

Intake Interview (MANDATORY FIRST STEP)

Ask the user these questions one at a time. Present one question, wait for the user's answer, then present the next. Never display multiple questions at once. Use the AskQuestion tool when available; otherwise ask conversationally. Present only the question text to the user - never show the internal instructions.

Q1 - Domain

Ask: "Please select a domain." (select one only)

Present these options:

• Escrow
• Payment Processing
• Loan Boarding
• Loan Setup & Servicing
• Fee Management
• Loan Payoff
• Bankruptcy
• Loan Offboarding
• Collections
• Loss Mitigation
• Foreclosure Management
• REO Management
• Investor Portal
• Borrower Portal
• Communications
• Compliance & Regulations
• Loan Variants (non-gov)
• Government Programs
• Agency / GSE
• Document Management
• Command Center
• Tasks
• Title & Lien
• System Administration
• Platform NFR (not captured within domains)

Internal: Only one domain may be selected per run. Map the selected domain to its prefix using the registry in reference.md. All 25 domains have assigned prefixes - use them exactly as listed. Do not derive or invent a prefix.

Q2 - Feature PRD List

Ask: "Please provide the name of each feature PRD you want to create, along with its feature ID."

Internal: The user is defining feature-level PRDs, not epics. Each answer becomes one PRD file and one companion change tracker. Name each pair: PRD - {Feature ID} {Feature Name}.md and PRD - {Feature ID} {Feature Name} - Change Tracker.md. Use exactly what the user provides - do not infer, propose, or substitute from epic files.

Q3 - Feature Boundaries

Ask: "Please provide the feature boundaries to help prevent requirements overlap between the PRDs (entry point, handoff/deliverable, explicit exclusions per PRD)."

Internal: Before asking, read the parent domain PRD and any available discussion docs to draft a suggested boundary for each feature the user listed in Q2. Present your suggestions in this format, then ask the user to review and correct:

{Feature ID} {Feature Name}
  - Starts with: [suggested entry point]
  - Ends with: [suggested handoff or deliverable]
  - Explicitly excludes: [suggested exclusions]

Use the user's corrections as the final boundary. These drive the In Scope, Addressed in Separate PRD, and Out of Scope sections of each PRD.

Q4 - Users per PRD

Ask: "Who are the specific users for each feature PRD?"

Internal: Use the exact team and role names the user provides. These populate Section 3 (User Impact) - Target Users and User Workflows. Do not substitute generic role names.

Q5 - Output Location

Ask: "Where do you want me to place the PRD documents? Please provide the file path."

Internal: Use the exact file path the user provides. Do not substitute or default to a different path.

After all five questions are answered, summarize what you heard back to the user and ask for confirmation before generating any files.

Clarification During Generation (CRITICAL)

While writing any PRD, if you encounter missing information, ambiguity, or a decision point that cannot be resolved from the source material:

• Stop and ask the user. Do not assume, infer, or fill in a placeholder.
• Ask one focused question at a time and wait for the answer before continuing.
• Only resume writing after the user has responded.

This applies to any section: business context, requirements, scope boundaries, users, system connections, or data impact. A gap in the PRD is better surfaced as a question than papered over with a guess.

Reference Pattern

The escrow-management domain is the gold standard. Study it before generating:

requirements/features/escrow-management/
  PRD/
    Feature/
      PRD - Escrow Management.md               ← domain/parent PRD
      PRD - ESC-001 Create Escrow Record.md
      PRD - ESC-001 Create Escrow Record - Change Tracker.md
      PRD - ESC-002 Setup Escrow - TIE by Month.md
      PRD - ESC-002 Setup Escrow - TIE by Month - Change Tracker.md
      ...

Workflow

Phase 1: Domain Discovery

1. Identify the domain directory: requirements/features/{domain}/
2. Read the parent/domain PRD if one exists (usually in design/ or PRD/Feature/)
3. List discussion folders under docs/discussions/ that match the domain
4. Look up the prefix from the registry in reference.md

Use this context to populate PRD content (business context, glossary, technical overview). The feature list, boundaries, and users come entirely from the intake interview - do not derive them from epic files.

Phase 2: Feature Confirmation (driven by intake answers)

Use exactly what the user provided in the intake interview. Do not substitute or override with agent-derived assumptions:

• Feature IDs and names from Q2 → file naming
• Scope boundaries from Q3 → In Scope, Addressed in Separate PRD, Out of Scope sections
• Target users and roles from Q4 → Section 3 (User Impact)
• Output path from Q5 → where files are written

Phase 3: KB Enrichment

For each identified feature, query the KB to fill gaps per kb-enrichment.mdc:

aws bedrock-agent-runtime retrieve \
  --knowledge-base-id JOVETQBNBE \
  --retrieval-query text="{domain} {feature name} workflow requirements" \
  --retrieval-configuration 'vectorSearchConfiguration={numberOfResults=5}' \
  --query 'retrievalResults[].content.text' \
  --output text

Query once per feature with contextual phrases. Evaluate relevance strictly - discard noise.

Phase 4: PRD Generation (one PRD at a time)

CRITICAL: Generate, commit, and hand off each feature PRD as a discrete unit before starting the next. Never write multiple PRDs in a single pass. This allows the user to open a separate PR per PRD for review.

For each feature, follow this loop:

Step 1 - Create a dedicated git branch

git checkout -b prd/{domain-prefix}/{PREFIX}-{NNN}-{feature-slug}
# Example: prd/bankruptcy/BK-001-case-setup

Step 2 - Ask per-PRD questions before writing

Before writing each PRD, ask the user these two questions one at a time:

1. "Do you have a design reference for {Feature Name}? If yes, please share the link (e.g. Figma). If not, we can add it later."

   Internal: Use the link provided in Section 5 (Design References). If the user says no or skips, write Section 5 as "Design pending - to be added before review."

2. "Do you have a technical architecture reference for {Feature Name}? If yes, please share the link or describe the key system connections. If not, we can add it later."

   Internal: Use what the user provides in Section 6 (High-Level Technical Overview). If the user says no or skips, write Section 6 with a placeholder: "Architecture reference pending - to be added before review." and leave the Key connections list empty.

Then proceed to write the PRD.

Step 3 - Write the two files

MANDATORY: Read docs/templates/prd-template.md in full before writing the PRD. Every PRD must use that file as its starting structure. Strip all HTML comment blocks (the <!-- ... --> instruction text) from the output - they are authoring guidance, not content.

The template defines these sections in order. Populate every one:

Section 4 note: the template shows only "User Experience Requirements" but all feature PRDs in this repo add a "Functional requirements" subsection above it. Always include both subsections in that order.

After writing the PRD, create the companion change tracker using docs/templates/prd-change-tracker-template.md. List every source document consumed (epics, discussions, KB results) in the "Documents used" section.

Step 4 - Self-contained document check

Each PRD must stand alone for review. Verify before committing:

• No content that depends on a sibling PRD being open simultaneously
• Cross-references to other feature PRDs use only their file name (relative link), not inline content from them
• Scope boundaries clearly state what is in this PRD vs. what is in a sibling PRD
• A reviewer who only opens this file can understand the full scope without reading sibling PRDs

Step 5 - Commit the pair

git add "PRD - {PREFIX}-{NNN} {Feature Name}.md" \
        "PRD - {PREFIX}-{NNN} {Feature Name} - Change Tracker.md"
git commit -m "feat(prd): add {PREFIX}-{NNN} {Feature Name}"

Then immediately proceed to the next feature PRD on its own branch. Repeat until all PRDs are generated and committed.

File naming:

Output location: requirements/features/{domain}/PRD/Feature/

Create the PRD/Feature/ directory if it does not exist. Move or symlink the parent PRD there if appropriate.

Phase 5: Gap & Overlap Analysis Document (separate branch)

After all feature PRDs are committed, generate a single synthesis document on its own branch (prd/{domain-prefix}/gap-overlap-analysis).

File name: PRD - {Domain Name} - Gap & Overlap Analysis.md Output location: requirements/features/{domain}/PRD/Feature/ - the same folder as all feature PRDs for this domain

The document aggregates every feature PRD into four tables:

1. Functional Requirements Registry One row per FR across all PRDs. Columns: FR ID | Feature PRD | Requirement summary | Depends on FR.

2. UX Requirements Registry One row per UX across all PRDs. Columns: UX ID | Feature PRD | Requirement summary.

3. In Scope / Out of Scope Matrix One row per scoped item across all PRDs. Columns: Item | Feature PRD | Status (In / Out / Separate PRD) | Linked PRD (if Separate).

4. Gaps & Overlaps

Flag two types of issues:

• Gap: An item appears in one PRD's "Addressed in Separate PRD" section but no other feature PRD in this set claims it as In Scope. Mark with GAP.
• Overlap: The same capability appears as In Scope in two or more feature PRDs. Mark with OVERLAP.

Format:

| Issue | Type | Feature PRDs involved | Description | Recommended action |
|-------|----|------|-----|-----|
| [capability] | GAP | {PREFIX}-003 | Referenced as separate PRD but no PRD covers it | Create {PREFIX}-00N or move In Scope |
| [capability] | OVERLAP | {PREFIX}-001, {PREFIX}-002 | Both claim ownership of X | Assign to one PRD, add Addressed in Separate PRD to the other |

Commit with:

git commit -m "feat(prd): add {Domain} gap and overlap analysis"

Phase 6: Cross-Reference Validation (final pass, separate branch)

After all PRDs and the gap/overlap analysis are committed, do one final pass on its own branch (prd/{domain-prefix}/cross-reference-cleanup):

• Verify each feature PRD has a **Parent context** line
• Replace any "forthcoming" sibling PRD references with actual relative links only if that PRD file now exists; leave the "forthcoming" note in place if it does not
• Use the gap/overlap analysis to resolve flagged issues where the fix is unambiguous (e.g. add a missing Addressed in Separate PRD entry); leave contested overlaps for the user to decide
• Update the parent domain PRD's scope section to reference each feature PRD

Commit this as a single PR so reviewers can see the full cross-reference picture in one place.

Section-by-Section Guidance

See reference.md for detailed guidance on filling each PRD section from epic and discussion content.

Quality Gates

Before committing each PRD:

• All 8 sections populated (no template placeholders remaining)
• Functional requirements use FR-N identifiers
• UX requirements use UX-N identifiers
• Scope section has no requirement in FR/UX that is also marked Out of Scope
• Change tracker created alongside the PRD
• Parent context line links to the domain PRD and any sibling PRDs
• KB Enrichment Log included (even if "No gaps identified")
• Document is self-contained: a reviewer can assess scope and requirements without opening any sibling PRD
• Cross-references to unwritten sibling PRDs are noted as "forthcoming" rather than broken links
• Committed on its own branch (prd/{domain-prefix}/{PREFIX}-{NNN}-{feature-slug}) so it can be opened as a standalone PR

After all PRDs are committed:

• Gap & overlap analysis document generated covering all feature PRDs
• Every GAP and OVERLAP flagged with a recommended action
• Analysis committed on its own branch as a standalone PR

Additional Resources

• Template: docs/templates/prd-template.md
• Change tracker template: docs/templates/prd-change-tracker-template.md
• Reference examples and prefix registry: reference.md
• KB enrichment protocol: .cursor/rules/kb-enrichment.mdc
• Writing style rules: .cursor/rules/writing-style.mdc
• Domain prefix registry and section guidance: reference.md