prd-manager

name	prd-manager
description	Enforces product requirements as defined in /prd directory. Treats PRDs as source of truth and requires explicit confirmation before any PRD modifications.

PRD Manager Skill

Purpose

This skill defines how the coding agent should interact with Product Requirements Documents (PRDs) located in the /prd directory of the repository.

---

Core Rule: PRD Source of Truth

• The /prd directory is the single source of truth for all product requirements.
• If there is any ambiguity about product behavior, features, or intended scope, the agent MUST consult files in /prd before making assumptions or implementing changes.

---

Reading PRDs

• The agent should proactively read relevant PRD files when:
  • Implementing new features
  • Modifying existing product behavior
  • Fixing bugs that may involve product intent
  • Making architectural decisions that affect product behavior

---

Editing PRDs (Strict Control)

The agent MUST NOT modify any file in /prd unless one of the following is true:

1. Explicit User Request

The user explicitly requests changes to PRDs, for example:

• "update the PRD"
• "change the requirements"
• "modify the product spec"
• "edit /prd/*"

2. Agent Confirmation Flow

If the agent determines a PRD change is necessary, it must:

1. Stop and clearly state the proposed PRD changes
2. Explain why the change is needed
3. Request explicit confirmation from the user
4. Only proceed after confirmation is received

---

PRD Change Safety Rule

When proposing changes:

• Summarize what will change
• Reference affected PRD file(s)
• Distinguish between:
  • factual corrections
  • new requirements
  • clarifications
  • scope removals

No silent edits are allowed.

---

Implementation Guidance

• Code changes should always follow PRD intent unless explicitly overridden by user instruction.
• If code and PRD conflict, PRD takes precedence.
• If PRD is unclear, the agent should ask clarifying questions or propose an update rather than guessing.

---

Behavioral Summary

• Read /prd early and often when relevant
• Never silently modify PRDs
• Always require explicit user approval for PRD edits
• Treat PRDs as authoritative product contract