Run any Skill in Manus with one click

Get Started

generate-prd

Stars0

Forks2

UpdatedFebruary 12, 2026 at 13:13

Generate a Product Requirements Document (PRD)

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

jftecnologia

jftecnologia/laravel-package-skeleton

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Project Management SpecialistsBusiness and Financial Operations Occupations·SOC 13-1082

SKILL.md

readonly

name	generate-prd
description	Generate a Product Requirements Document (PRD)
disable-model-invocation	true

Generate a Product Requirements Document (PRD) for the project or module described in: $ARGUMENTS.

Follow the steps below strictly.

1. Load Skill Rules

Read and follow the PRD skill rules defined in this file.
The PRD is the single source of truth for product scope and intent.
Focus on what and why, never on how.

2. Clarify Missing Information

Identify missing or ambiguous information required to generate a complete PRD.
Ask only the minimum necessary questions to proceed.
Ask questions in Portuguese (pt-BR).
Do not guess or assume requirements.

3. PRD Language & Style

Write the PRD in English.
Be concise, explicit, and unambiguous.
Avoid buzzwords, marketing language, and vague statements.
Prefer bullet points and clearly structured sections.

4. Mandatory PRD Structure

Generate the PRD using exactly the structure below.

Product Requirements Document (PRD)

1. Overview

1.1 Product Name

1.2 Problem Statement

1.3 Objectives

2. Stakeholders

3. Target Users

4. Scope

4.1 In Scope

4.2 Out of Scope

5. Functional Requirements

FR-01:
FR-02:

Requirements must describe observable behavior and be testable.

6. Non-Functional Requirements

Include only relevant items:

Performance
Security
Availability
Compliance
Scalability
Usability

7. User Flows (High-Level)

Describe user interactions step-by-step, without diagrams.

8. Assumptions & Constraints

8.1 Assumptions

8.2 Constraints

9. Risks & Mitigations

10. Success Metrics

11. Open Questions

5. Output Rules

Do not include:
- Architecture diagrams
- Database models
- API definitions
- UI mockups
Do not design the solution.
Keep scope explicit and bounded.

6. File Output

Write the final PRD to the documentation folder:
- Default: docs/PRD.md
If a product or module name is provided:
- Use: docs/prd/<semantic-slug>.md

7. Completion Criteria

The PRD is complete only if:

All sections are filled.
Scope is clearly defined (in / out).
Requirements are testable.
Open questions are explicitly listed.
The document can be approved or rejected by stakeholders.

More from this repository

same repository

generate-architecture

jftecnologia/laravel-package-skeleton

Generate architecture documentation for Laravel packages. Use when the user asks to create, update, or define the system architecture, technical organization, folder structure, class responsibilities, or architectural decisions. This skill creates structured documentation in docs/architecture/ based on PRD requirements, code standards, and tech stack constraints.

2026-02-120

generate-task-breakdown

jftecnologia/laravel-package-skeleton

Break down product requirements and architecture into executable development tasks. Use when the user asks to plan implementation, create a task breakdown, generate development roadmap, or organize work into epics and tasks. This skill reads PRD and architecture documentation to generate structured task lists with acceptance criteria in docs/tasks/ and creates progress tracking in docs/progress/.

2026-02-120

generate-test

jftecnologia/laravel-package-skeleton

Generate PestPHP tests for code. Use when the user asks to create tests, add tests, write tests, or when implement-task requires testing. This skill analyzes code to test, follows TESTING.md guidelines, generates appropriate test files, and ensures tests pass. Can be invoked standalone or as part of task implementation.

2026-02-120

implement-task

jftecnologia/laravel-package-skeleton

Implement development tasks from task breakdown documents. Use when the user asks to implement, develop, or code a specific task (e.g., "implement CTI-01", "desenvolva a task SP-02"). This skill reads task definitions from docs/tasks/, follows engineering standards, creates semantic branches/commits, runs quality gates (lint, test, security), and updates progress tracking.

2026-02-120

security-analyst

jftecnologia/laravel-package-skeleton

Analyze code for security vulnerabilities based on OWASP Top 10. Use when the user asks to review security, check for vulnerabilities, analyze code security, or before completing development tasks. This skill identifies security issues, rates their severity, and provides fix recommendations without making automatic changes.

2026-02-120

name	generate-prd
description	Generate a Product Requirements Document (PRD)
disable-model-invocation	true

Generate a Product Requirements Document (PRD) for the project or module described in: $ARGUMENTS.

Follow the steps below strictly.

1. Load Skill Rules

Read and follow the PRD skill rules defined in this file.
The PRD is the single source of truth for product scope and intent.
Focus on what and why, never on how.

2. Clarify Missing Information

Identify missing or ambiguous information required to generate a complete PRD.
Ask only the minimum necessary questions to proceed.
Ask questions in Portuguese (pt-BR).
Do not guess or assume requirements.

3. PRD Language & Style

Write the PRD in English.
Be concise, explicit, and unambiguous.
Avoid buzzwords, marketing language, and vague statements.
Prefer bullet points and clearly structured sections.

4. Mandatory PRD Structure

Generate the PRD using exactly the structure below.

Product Requirements Document (PRD)

1. Overview

1.1 Product Name

1.2 Problem Statement

1.3 Objectives

2. Stakeholders

3. Target Users

4. Scope

4.1 In Scope

4.2 Out of Scope

5. Functional Requirements

FR-01:
FR-02:

Requirements must describe observable behavior and be testable.

6. Non-Functional Requirements

Include only relevant items:

Performance
Security
Availability
Compliance
Scalability
Usability

7. User Flows (High-Level)

Describe user interactions step-by-step, without diagrams.

8. Assumptions & Constraints

8.1 Assumptions

8.2 Constraints

9. Risks & Mitigations

10. Success Metrics

11. Open Questions

5. Output Rules

Do not include:
- Architecture diagrams
- Database models
- API definitions
- UI mockups
Do not design the solution.
Keep scope explicit and bounded.

6. File Output

Write the final PRD to the documentation folder:
- Default: docs/PRD.md
If a product or module name is provided:
- Use: docs/prd/<semantic-slug>.md

7. Completion Criteria

The PRD is complete only if:

All sections are filled.
Scope is clearly defined (in / out).
Requirements are testable.
Open questions are explicitly listed.
The document can be approved or rejected by stakeholders.