What happens if context is unclear?

The tool will ask the CEO for clarification on what they want to build and for whom before drafting the PRD.

Who validates the PRD and how?

Subagents validate in parallel: @engineer assesses technical feasibility and risks, while @designer reviews user flows and UX touchpoints. Feedback is then integrated into the final PRD.

Where is the PRD stored and how is it named?

The final document is saved to .solopreneur/specs/{date}-{slug}.md, creating directories as needed and using a slug derived from the idea.

spec

Scanned

npx machina-cli add skill pcatattacks/solopreneur-plugin/spec --openclaw

Files (1)

SKILL.md

2.4 KB

Product Specification: $ARGUMENTS

You are writing a PRD (Product Requirement Document) for the CEO. If $ARGUMENTS is a file path, read that file for context. Otherwise, treat it as the idea description.

Process

If context is insufficient, ask the CEO what they want to build and for whom.
Draft a structured PRD with these sections:
- Overview: One-paragraph summary of what we're building and why
- User Stories: 3-7 stories in format: "As a [role], I want [feature], so that [benefit]"
- Acceptance Criteria: For each user story, define Given/When/Then scenarios
- Release Phases: Categorize user stories into phases:
  - MVP: Core features needed for the product to be usable at all
  - P1: Important features for the next release after MVP
  - P2: Nice-to-have features that can wait Ask the CEO to confirm the phasing before finalizing.
- Technical Requirements: Stack, integrations, data model, API endpoints
- Non-Functional Requirements: Performance targets, security, scalability
- Out of Scope: Explicitly list what we're NOT building (prevents scope creep)
- Open Questions: Anything that needs CEO input before building
Validate with subagents in parallel:
- Delegate to @engineer with the draft PRD. Task: validate technical feasibility of each requirement. For each: rate as feasible / needs-design-decision / risky. Flag anything overly complex, suggest simpler alternatives where possible.
- Delegate to @designer with the user stories section. Task: identify what screens and user flows are needed. For each user story, note which screens it touches and any UX concerns.
Incorporate subagent feedback into the final PRD.
Save to .solopreneur/specs/{date}-{slug}.md (create the directory if needed).

End with the next step prompt. If the spec has 5+ user stories, suggest breaking it into tickets first:

-> Next: Break this into implementable tickets:
   /solopreneur:backlog .solopreneur/specs/{filename}

Or for smaller specs, go straight to design:
   /solopreneur:design .solopreneur/specs/{filename}

Source

git clone https://github.com/pcatattacks/solopreneur-plugin/blob/main/skills/spec/SKILL.mdView on GitHub

Overview

This skill guides you to write a structured PRD (Product Requirements Document) from a validated idea or feature request. It defines the problem, user value, acceptance criteria, technical requirements, and release phases to align stakeholders. The process includes input handling, sectioned deliverables, parallel validation by engineering and design subagents, and automatic saving to .solopreneur/specs.

How This Skill Works

Input is treated as either a file path (to read context) or a direct idea description. The tool drafts a PRD with sections: Overview, User Stories, Acceptance Criteria, Release Phases (MVP, P1, P2), Technical Requirements, Non-Functional Requirements, Out of Scope, and Open Questions. It then runs parallel validation with @engineer (technical feasibility) and @designer (UX impact), incorporates feedback, saves the final Markdown to .solopreneur/specs/{date}-{slug}.md, and prints a next-step prompt.

When to Use It

You have a validated idea or feature request and need to define requirements, user stories, acceptance criteria, or technical specs before building.
You want to align product, engineering, and design teams with a single, structured PRD.
You need a clear MVP scope plus phased releases (P1, P2) to prevent scope creep.
You require explicit acceptance criteria (Given/When/Then) tied to each user story.
You want to document open questions and non-functional requirements early to guide implementation.

Quick Start

Step 1: Provide idea description or discovery brief path
Step 2: The tool drafts the PRD with all required sections (Overview, User Stories, Acceptance Criteria, Release Phases, Technical & Non-Functional Requirements, Out of Scope, Open Questions)
Step 3: Validate with engineering and design subagents, incorporate feedback, and save to .solopreneur/specs/{date}-{slug}.md
Step 4: If the spec has 5+ user stories, consider breaking into tickets using: -> Next: Break this into implementable tickets: /solopreneur:backlog .solopreneur/specs/{filename} Or for smaller specs, go straight to design: /solopreneur:design .solopreneur/specs/{filename}

Best Practices

Start with a concise Overview that explains the problem, value, and success metrics.
Write user stories in the format: As a [role], I want [feature], so that [benefit].
Define Acceptance Criteria per story with Given/When/Then scenarios.
Clearly separate MVP, P1, and P2 in Release Phases and confirm phasing with stakeholders.
Involve @engineer and @designer early and incorporate their feedback before finalizing.

Example Use Cases

PRD for onboarding revamp to reduce time-to-value by 30% for new users
PRD for a checkout optimization feature to improve conversion
PRD for a mobile push notification system to boost engagement
PRD for an API rate-limiter with analytics dashboards
PRD for unifying analytics event schema across platforms

Frequently Asked Questions

Add this skill to your agents