fix: auto-discover PRD in validate-prd workflow#1619
fix: auto-discover PRD in validate-prd workflow#1619bmadcode merged 2 commits intobmad-code-org:mainfrom
Conversation
When only one PRD exists in planning_artifacts, use it automatically instead of prompting the user for its path. Still asks when multiple PRDs are found or falls back to manual input when none are discovered. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
🤖 Augment PR SummarySummary: Updates the validate-PRD workflow to auto-discover PRD markdown files under 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
|
|
||
| **Wait for user to provide PRD path.** | ||
| **If no PRD path provided, auto-discover:** | ||
| - Search `{planning_artifacts}` for files matching `*prd*.md` |
There was a problem hiding this comment.
The glob *prd*.md may be case-sensitive depending on how discovery is implemented; if PRDs are commonly named PRD.md, auto-discovery could miss them. Consider explicitly stating/ensuring the search is case-insensitive (or includes an exact PRD.md match) so the “common case” is reliably detected.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
📝 WalkthroughWalkthroughModified the PRD discovery workflow to auto-search planning_artifacts for PRD files instead of directly prompting users for a path. Added branching logic to handle single discovery (auto-use), multiple discoveries (user selection), and no discovery (prompt for path) cases. Removed the PRD path prompt from the main workflow. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (6)
src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-01-discovery.md (6)
94-97:⚠️ Potential issue | 🟠 MajorExistence check is insufficient—readability and file type aren’t validated.
A path can exist but be unreadable, a directory, or a binary. You don’t define handling for those.
Suggested addition
- - If found: Load the complete PRD file including frontmatter + - If found: Verify it is a readable text file (not a directory/binary) + - If unreadable/invalid: report and request a corrected path
100-104:⚠️ Potential issue | 🟡 MinorNo fallback for invalid or missing frontmatter.
You assume frontmatter is parseable. When it isn’t, the rest of the step breaks silently. Provide explicit error handling and a fallback behavior.
Suggested addition
+ - If frontmatter is missing or invalid YAML: inform user and proceed with PRD-only validation
110-114:⚠️ Potential issue | 🟠 MajorSecurity gap: arbitrary path loading enables data exfiltration.
Input documents and additional documents can point outside the project root. This is a classic path traversal issue for automated agents. Restrict to
{project-root}or require explicit user confirmation for external paths.Suggested guardrail
- - Attempt to load the document + - Reject paths outside {project-root}, or ask for explicit confirmation before loading them
121-137:⚠️ Potential issue | 🟡 MinorNo de-duplication or validation for additional documents.
You load extra documents but don’t say to deduplicate against frontmatter docs or to validate readability before accepting them. This will cause duplicate entries and avoidable load failures.
Suggested addition
+ - De-duplicate against frontmatter documents + - Validate readability before adding to the loaded list
139-152:⚠️ Potential issue | 🟡 Minor
{current_date}format is ambiguous and inconsistent across locales.You don’t specify an ISO format, which will cause inconsistent reports and parsing failures later.
Suggested change
- validationDate: '{current_date}' + validationDate: '{current_date_iso_8601}' # e.g., 2026-02-10
176-180:⚠️ Potential issue | 🟠 MajorSummary expects categorized counts you never actually define.
You list counts for Product Brief/Research/Additional, but earlier steps only build a generic list of loaded documents. There’s no rule for categorizing. That’s a contradiction.
Suggested fix
- **Input Documents Loaded:** - - Product Brief: {count} ... - - Research: {count} ... - - Additional References: {count} ... + **Input Documents Loaded:** + - {list all documents with their detected type or a default label} + - If type detection is required, define the rules during Step 5
🤖 Fix all issues with AI agents
In
`@src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-01-discovery.md`:
- Around line 81-85: Add a validation path for the "If MULTIPLE PRDs found"
flow: after presenting the numbered list and asking "I found multiple PRDs.
Which one would you like to validate?" (the prompt text and the "Wait for user
selection" step), explicitly handle out-of-range numbers, non-numeric inputs,
and filename/ambiguous responses by prompting the user with a clear error
message, re-displaying the numbered options, and offering example valid inputs
(e.g., "Enter the number 1–N" or "type 'cancel' to abort"); include a limited
retry loop and a fallback option to list PRD details or ask to refine the search
if ambiguity persists.
- Around line 86-88: Update the "If NO PRDs found" prompt to explicitly tell the
user how to provide the path: require either an absolute path or a
workspace-relative path (and state the workspace root as the resolution base),
allow quoted paths to include spaces, trim surrounding whitespace, and
validate/normalize the received path before proceeding; reference the existing
prompt text ("I couldn't find any PRD files in {planning_artifacts}") and the
user-response step so you add guidance like "Provide an absolute path or a path
relative to the workspace root. If the path contains spaces, wrap it in quotes.
We will resolve relative paths against the workspace root and normalize the path
before validating." Ensure the step also describes what happens on invalid path
(re-prompt with the same rules).
- Around line 74-76: The discovery glob patterns `{planning_artifacts}/*prd*.md`
and `{planning_artifacts}/*prd*/*.md` are too broad and produce false positives;
tighten them to target PRD filenames (e.g., require a `-prd` token or exact
suffix) and/or add a frontmatter check for a PRD marker. Replace `*prd*.md` with
a narrower glob like `*-prd*.md` or `**/*-prd*.md` (and `*-prd*/**/*.md` for
sharded folders) and, after matching, parse the file frontmatter to ensure it
contains a PRD marker (for example `type: prd` or `document: prd`) before
treating it as a PRD.
- Around line 74-76: The discovery step currently searches planning_artifacts
using patterns `*prd*.md` and `{planning_artifacts}/*prd*/*.md` which are
case-sensitive and will miss files like `PRD.md` or `Prd.md` on case-sensitive
filesystems; update the discovery logic in step-v-01-discovery (the code that
uses the glob patterns `*prd*.md` and `*prd*/*.md`) to perform case-insensitive
matching (e.g., normalize filenames to lowercase before matching or use a
case-insensitive glob option) and extend patterns to cover variations (e.g.,
`*prd*.md`, `*PRD*.md`, or apply a lowercase transform to both the filename and
pattern) so all PRD filename casing variants are found, including sharded PRDs
under `{planning_artifacts}/*prd*/*.md`.
- Around line 74-76: The two glob searches for `{planning_artifacts}` using the
patterns `*prd*.md` and `{planning_artifacts}/*prd*/*.md` can return the same
file; after collecting matches from both globs, deduplicate the combined list
(e.g., by path string using a Set or unique filter) before presenting selection
prompts or further processing so files that match both patterns are only
shown/handled once.
- Around line 73-80: The step currently auto-uses a discovered PRD ("If exactly
ONE PRD found" and the message "Found PRD: {discovered_path} — using it for
validation.") which violates the rule "NEVER generate content without user
input"; change the flow and wording so that when one PRD is discovered you
present the found path and ask for explicit user confirmation before loading or
using it (e.g., replace the automatic-use sentence with a prompt like "Found
PRD: {discovered_path}. Do you want to use this for validation? (yes/no)"), and
ensure the discovery bullets (searching {planning_artifacts} and sharded PRDs)
remain informational only until the user confirms.
| **If no PRD path provided, auto-discover:** | ||
| - Search `{planning_artifacts}` for files matching `*prd*.md` | ||
| - Also check for sharded PRDs: `{planning_artifacts}/*prd*/*.md` | ||
|
|
||
| **If exactly ONE PRD found:** | ||
| - Use it automatically | ||
| - Inform user: "Found PRD: {discovered_path} — using it for validation." | ||
|
|
There was a problem hiding this comment.
Auto-using a discovered PRD conflicts with the “no content without user input” rule.
You’re declaring the PRD “used automatically” without explicit confirmation. That’s incompatible with the step rule at Line 22 (“NEVER generate content without user input”) and with a facilitation stance. Require an explicit confirmation before loading/creating anything.
Suggested text change
- **If exactly ONE PRD found:**
- - Use it automatically
- - Inform user: "Found PRD: {discovered_path} — using it for validation."
+ **If exactly ONE PRD found:**
+ - Inform user: "Found PRD: {discovered_path}. Do you want to use this for validation? (yes/no)"
+ - Wait for user confirmation before loading or creating any files🤖 Prompt for AI Agents
In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-01-discovery.md`
around lines 73 - 80, The step currently auto-uses a discovered PRD ("If exactly
ONE PRD found" and the message "Found PRD: {discovered_path} — using it for
validation.") which violates the rule "NEVER generate content without user
input"; change the flow and wording so that when one PRD is discovered you
present the found path and ask for explicit user confirmation before loading or
using it (e.g., replace the automatic-use sentence with a prompt like "Found
PRD: {discovered_path}. Do you want to use this for validation? (yes/no)"), and
ensure the discovery bullets (searching {planning_artifacts} and sharded PRDs)
remain informational only until the user confirms.
| - Search `{planning_artifacts}` for files matching `*prd*.md` | ||
| - Also check for sharded PRDs: `{planning_artifacts}/*prd*/*.md` | ||
|
|
There was a problem hiding this comment.
Discovery patterns are too broad and will match non-PRD files.
*prd*.md will happily match “product-roadmap.md”, “interpretation.md”, etc. That’s going to produce false positives. Tighten the pattern or require a frontmatter marker.
Suggested narrowing
- Search `{planning_artifacts}` for files matching `*prd*.md`
- Also check for sharded PRDs: `{planning_artifacts}/*prd*/*.md`
+ Search `{planning_artifacts}` for files matching `prd-*.md` or `*/*-prd.md`
+ Also check for sharded PRDs: `{planning_artifacts}/prd-*/**/*.md`
+ Prefer a frontmatter marker (e.g., `documentType: prd`) when available📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - Search `{planning_artifacts}` for files matching `*prd*.md` | |
| - Also check for sharded PRDs: `{planning_artifacts}/*prd*/*.md` | |
| - Search `{planning_artifacts}` for files matching `prd-*.md` or `*/*-prd.md` | |
| - Also check for sharded PRDs: `{planning_artifacts}/prd-*/**/*.md` | |
| - Prefer a frontmatter marker (e.g., `documentType: prd`) when available |
🤖 Prompt for AI Agents
In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-01-discovery.md`
around lines 74 - 76, The discovery glob patterns
`{planning_artifacts}/*prd*.md` and `{planning_artifacts}/*prd*/*.md` are too
broad and produce false positives; tighten them to target PRD filenames (e.g.,
require a `-prd` token or exact suffix) and/or add a frontmatter check for a PRD
marker. Replace `*prd*.md` with a narrower glob like `*-prd*.md` or
`**/*-prd*.md` (and `*-prd*/**/*.md` for sharded folders) and, after matching,
parse the file frontmatter to ensure it contains a PRD marker (for example
`type: prd` or `document: prd`) before treating it as a PRD.
Case sensitivity is undefined and will miss PRDs on case-sensitive filesystems.
You never specify whether discovery is case-insensitive, so PRD.md or Prd.md may be skipped on Linux.
Suggested addition
+ - Ensure discovery is case-insensitive for `prd` matches📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - Search `{planning_artifacts}` for files matching `*prd*.md` | |
| - Also check for sharded PRDs: `{planning_artifacts}/*prd*/*.md` | |
| - Search `{planning_artifacts}` for files matching `*prd*.md` | |
| - Also check for sharded PRDs: `{planning_artifacts}/*prd*/*.md` | |
| - Ensure discovery is case-insensitive for `prd` matches |
🤖 Prompt for AI Agents
In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-01-discovery.md`
around lines 74 - 76, The discovery step currently searches planning_artifacts
using patterns `*prd*.md` and `{planning_artifacts}/*prd*/*.md` which are
case-sensitive and will miss files like `PRD.md` or `Prd.md` on case-sensitive
filesystems; update the discovery logic in step-v-01-discovery (the code that
uses the glob patterns `*prd*.md` and `*prd*/*.md`) to perform case-insensitive
matching (e.g., normalize filenames to lowercase before matching or use a
case-insensitive glob option) and extend patterns to cover variations (e.g.,
`*prd*.md`, `*PRD*.md`, or apply a lowercase transform to both the filename and
pattern) so all PRD filename casing variants are found, including sharded PRDs
under `{planning_artifacts}/*prd*/*.md`.
Duplicate discovery is likely and not handled.
The two glob patterns can return the same file (e.g., when a shard path also matches *prd*.md). There’s no de-duplication step, which can inflate the list and force unnecessary selection prompts.
Suggested addition
+ - De-duplicate and normalize discovered paths before counting
+ - Sort results deterministically (e.g., lexicographically)🤖 Prompt for AI Agents
In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-01-discovery.md`
around lines 74 - 76, The two glob searches for `{planning_artifacts}` using the
patterns `*prd*.md` and `{planning_artifacts}/*prd*/*.md` can return the same
file; after collecting matches from both globs, deduplicate the combined list
(e.g., by path string using a Set or unique filter) before presenting selection
prompts or further processing so files that match both patterns are only
shown/handled once.
| **If MULTIPLE PRDs found:** | ||
| - List all discovered PRDs with numbered options | ||
| - "I found multiple PRDs. Which one would you like to validate?" | ||
| - Wait for user selection | ||
|
|
There was a problem hiding this comment.
No validation path for invalid or ambiguous selection.
You ask the user to choose a number but don’t say what to do if they provide an out-of-range index, a filename, or a non-numeric response. That’s a common failure mode.
Suggested addition
+ - If selection is invalid or ambiguous, explain valid options and re-prompt
+ - Accept either index or exact path match🤖 Prompt for AI Agents
In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-01-discovery.md`
around lines 81 - 85, Add a validation path for the "If MULTIPLE PRDs found"
flow: after presenting the numbered list and asking "I found multiple PRDs.
Which one would you like to validate?" (the prompt text and the "Wait for user
selection" step), explicitly handle out-of-range numbers, non-numeric inputs,
and filename/ambiguous responses by prompting the user with a clear error
message, re-displaying the numbered options, and offering example valid inputs
(e.g., "Enter the number 1–N" or "type 'cancel' to abort"); include a limited
retry loop and a fallback option to list PRD details or ask to refine the search
if ambiguity persists.
| **If NO PRDs found:** | ||
| - "I couldn't find any PRD files in {planning_artifacts}. Please provide the path to the PRD file you want to validate." | ||
| - Wait for user to provide PRD path. |
There was a problem hiding this comment.
Path input is underspecified (relative vs absolute, spaces, quoting).
You never state how the path should be resolved or how to handle spaces. That’s a setup for user error.
Suggested addition
- "Please provide the path to the PRD file you want to validate."
+ "Please provide the path to the PRD file (relative to {project-root} or an absolute path). If it contains spaces, wrap it in quotes."🤖 Prompt for AI Agents
In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-01-discovery.md`
around lines 86 - 88, Update the "If NO PRDs found" prompt to explicitly tell
the user how to provide the path: require either an absolute path or a
workspace-relative path (and state the workspace root as the resolution base),
allow quoted paths to include spaces, trim surrounding whitespace, and
validate/normalize the received path before proceeding; reference the existing
prompt text ("I couldn't find any PRD files in {planning_artifacts}") and the
user-response step so you add guidance like "Provide an absolute path or a path
relative to the workspace root. If the path contains spaces, wrap it in quotes.
We will resolve relative paths against the workspace root and normalize the path
before validating." Ensure the step also describes what happens on invalid path
(re-prompt with the same rules).
2 participants
Summary
{planning_artifacts}instead of always asking the user for a pathTest plan
🤖 Generated with Claude Code