DOCSEARCHbyAlgolia
Submit Docs

PRP (Product Requirement Prompts) for Agentic Engineering

repository·development·Indexed 24 days ago

https://github.com/wirasm/prps-agentic-eng

A collection of prompts and agent skills designed for AI-assisted development with Claude Code. PRP extends traditional PRDs by adding curated codebase intelligence and agent runbooks (Context, Implementation Strategy, and Validation Gates) to achieve 'one-pass' implementation success. Includes a suite of core workflow skills such as /prp-prd, /prp-plan, /prp-implement, and the /prp-loop autonomous execution pipeline.

Tokens
194K
Snippets
321
Records
632
Agent score
31%

What's inside PRP-library

  1. What is a Product Requirement Prompt (PRP)?

    development

    A Product Requirement Prompt (PRP) is a structured prompt designed to provide an AI coding agent with the complete information required to deliver a specific vertical slice of working software. It combines the goal-oriented scope of a traditional Product Requirements Document (PRD) with technical context and implementation strategies necessary for agentic engineering.

    A PRP is composed of three critical layers that distinguish it from a standard PRD:

    1. Context: Provides precise file paths, content, library versions, and code snippets. It often utilizes an ai_docs/ directory to pipe in relevant library documentation to ensure the LLM has direct references.
    2. Implementation Details and Strategy: Explicitly defines how the software will be built. This includes specifying API endpoints, test runners, agent patterns (e.g., ReAct, Plan-and-Execute), typehints, dependencies, and architectural patterns.
    3. Validation Gates: Defines deterministic checks to ensure quality, such as pytest, ruff, or static type passes. A common validation gate is requiring that all individual function tests pass before proceeding.

    In essence, a PRP follows the formula: PRP = PRD + curated codebase intelligence + agent/runbook.

  2. What is PRP (Product Requirement Prompts)?

    development
    PRP is a framework that combines a PRD (Product Requirement Document), codebase intelligence, and a validation loop. It allows an AI to receive a detailed plan with context and validation commands, enabling it to implement, test, and self-correct until all requirements are met.

  3. Use the Story PRP workflow for tactical tasks

    development

    The Story PRP workflow is designed for converting specific user stories, bug reports, or technical tasks (from tools like Jira or Linear) into executable implementation plans. Unlike the comprehensive Base PRP flow, Story PRPs are tactical, task-oriented, and focused on single stories or sprint tasks rather than full product blueprints.

    Key Differences from Base PRPs

    AspectBase PRPStory PRP
    ScopeFull feature/productSingle story/task
    ContextExtensive documentationFocused references
    FormatDetailed blueprintTask checklist
    Validation4-level comprehensiveInline per-task
    Use CaseNew features, major changesSprint tasks, bug fixes

    When to use Story PRPs

    • Sprint tasks and user stories
    • Bug fixes and small features
    • Refactoring and optimization
    • Tasks with clear scope

  4. Follow the standard Go project architecture

    development

    The project follows a standard Go module layout to separate entry points from private application logic:

    • cmd/: Contains subdirectories for each binary (e.g., cmd/myapp/main.go). main.go should be thin, handling only flag parsing and dependency wiring.
    • internal/: Contains private application code that is not intended for external import. This is where the core business logic and domain types reside.
    • testdata/: Used for test fixtures.
    • pkg/: Only used for exported packages intended for external consumers (YAGNI principle).

    Note: Test files must live next to the code they test (e.g., user.go $\rightarrow$ user_test.go).

    myproject/
    go.mod
    go.sum
    README.md
    Makefile

    cmd/                      # Entry points
        myapp/
            main.go           
        myworker/
            main.go

    internal/                 # Private application code
        server/
            server.go
            server_test.go
        user/
            user.go           
            user_test.go
            repository.go     
            repository_test.go

    testdata/                 # Test fixtures

  5. Follow the TypeScript/Next.js Implementation Task Order

    development

    When implementing a feature using the PRP template, follow this specific dependency order to ensure type safety and architectural consistency:

    1. Types: Create domain models in lib/types/{domain}.types.ts using TypeScript interfaces or Zod schemas.
    2. Components: Create React components in components/{domain}/{ComponentName}.tsx using the types from Task 1.
    3. API Routes: Implement Next.js API handlers in app/api/{resource}/route.ts.
    4. Pages: Create Next.js page components in app/{feature}/page.tsx using the components and types.
    5. Hooks: Implement custom React hooks in hooks/use{DomainAction}.ts for state and API logic.
    6. Tests: Implement Jest/Testing Library tests in __tests__/{component}.test.tsx alongside the code.

  6. Configure the project structure using Domain-Driven Design

    development

    The project follows a Domain-Driven Design (DDD) structure to separate business logic from technical concerns:

    • src/domains/: Contains business domains. Each domain includes __tests__/, entities/, services/, repos/, and a public index.ts API.
    • src/infrastructure/: Technical concerns like database/, cache/, messaging/, and monitoring/.
    • src/interfaces/: External interfaces such as http/, grpc/, and cli/.
    • src/shared/: Cross-cutting concerns like errors/, types/, and utils/.
    • tests/: Integration tests.
    • scripts/: Build and deployment scripts.

  7. Research Strategy: Speed-First Approach

    development

    The Speed-First approach focuses on rapid prototyping and minimal custom development to achieve the fastest possible time-to-market. It is ideal for hackathons where speed is the primary constraint.

    Research Matrix (5 Agents):

    • Agent A1 (Technical Feasibility): Focuses on the fastest tech stack, existing libraries, and minimal custom requirements.
    • Agent A2 (Speed-to-Market): Investigates MVP scope, no-code/low-code integration, and testing shortcuts.
    • Agent A3 (Market Research): Analyzes competitive positioning for fast-moving solutions and market timing.
    • Agent A4 (Design Research): Researches UI component libraries and proven UX patterns for rapid development.
    • Agent A5 (User Research): Analyzes critical user journeys that must work in the MVP and feedback loops for rapid iteration.

  8. Configure Claude Code subagents

    development

    Claude Code supports custom AI subagents defined as Markdown files with YAML frontmatter. These subagents allow you to create specialized assistants with specific prompts and tool permissions. They can be scoped to a single project or made available globally.

    • User subagents: Store in ~/.claude/agents/ to make them available across all projects.
    • Project subagents: Store in .claude/agents/ to make them specific to a project and shareable with a team.

  9. How to use matchers in Claude Code hooks

    development

    Matchers allow you to target specific tools or patterns for PreToolUse and PostToolUse events.

    • Exact Match: A simple string like Write matches only the Write tool.
    • Regex: Supports regular expressions, e.g., Edit|Write or Notebook.*.
    • Wildcard: Use * to match all tools.
    • Global/No Matcher: For events that don't use matchers (like Notification or UserPromptSubmit), you can omit the matcher field or use an empty string "" to apply the hook to every occurrence of that event.

  10. Adhere to Java Development Critical Guidelines

    development

    Maintain high code quality by following these mandatory rules:

    • Generics: No raw types; always use generics.
    • Null Safety: No null returns; use Optional<T>.
    • Validation: Validate all inputs using Jakarta Validation.
    • Documentation: Document all public APIs with Javadoc AND OpenAPI annotations.
    • MANDATORY OpenAPI: Every REST endpoint must include @Operation, @ApiResponses, @Parameter, and @Schema annotations.
    • Testing: Minimum 80% code coverage.
    • Error Handling: Handle all exceptions; no empty catch blocks.
    • Constants: No magic numbers; extract to constants.
    • Structure: One class per file (except inner classes).
    • API Design: Follow a Frontend-first approach. Endpoints must be React-developer friendly with complete examples and schemas.

  11. Configure prp-review modes

    development

    The prp-review skill operates in two distinct modes depending on the input provided:

    • Single-pass (Default): Triggered when no --agents flag is present. A single reviewer performs an 8-phase review process. This is the cheaper, standard option.
    • Multi-agent fan-out: Triggered by the --agents flag, aspect keywords (comments, tests, errors, types, code, docs, simplify, or all), or a request for a "multi-agent" or "thorough" review. This dispatches specialized agents in parallel to handle specific review aspects.

  12. Manage PRP artifacts and project state

    development

    PRP stores all artifacts and runtime state outside of your repository in a per-project directory to keep your codebase clean.

    Default Location: ~/.prp/<project-key>/ Override Location: Set the PRP_HOME environment variable to change the root.

    Directory Structure:

    • project.json: Canonical project path and name.
    • prds/: Product requirement documents.
    • plans/: Implementation plans (includes completed/ archive).
    • research/: Codebase research artifacts.
    • research-plans/: Multi-agent research plans.
    • reports/: Implementation reports.
    • reviews/: Human-readable PR reviews.
    • issues/: Issue investigation artifacts (includes completed/ archive).
    • debug/: Root-cause analysis reports.
    • orchestration/: Parallel-workstream run files.
    • state/: Loop state, verdicts, logs, and hook sentinels.