Documentation
The Specification Workflow
Product Manager Phase

Product Manager Phase

The PM agent gathers your requirements and produces a Product Requirements Document (PRD) with job stories and acceptance criteria. This is the foundation that all subsequent phases build on.

What the PM agent does

The PM agent acts as a senior Product Manager. It follows a discovery framework:

  1. Examine context — Analyzes your project description and (if available) your existing codebase to understand the starting point
  2. Ask strategic questions — Generates focused questions based on what it needs to know
  3. Synthesize your answers — Identifies patterns, priorities, and gaps in your responses
  4. Define requirements — Produces a structured PRD
  5. Create job stories — Writes user-centered scenarios with testable acceptance criteria
  6. Document NoGos — Explicitly records what is not being built

The questions

The PM agent generates questions covering six categories:

  • Purpose & Context — Why is this needed? What problem does it solve?
  • Users & Scope — Who will use this? How many users? What segments?
  • Key Requirements — What are the most important functional requirements?
  • Business Logic — What are the core rules and workflows?
  • Data & Integration — What data is involved? What systems does it connect to?
  • Constraints — Business timelines, technical limitations, user accessibility needs?

The number of questions depends on your question depth setting:

DepthQuestions
Light2-3
Standard3-4
Thorough4-6

Each question comes with 2-3 suggested answer options. You can pick one or write your own response.

How your answers are tracked

When you answer a question, SpecWright records not just your choice but also what you decided against:

{
  "question": "What authentication methods should be supported?",
  "decision": "Google OAuth only",
  "rejected_alternatives": [
    "Google + email/password",
    "Full SSO (Google, GitHub, Microsoft)"
  ]
}

This matters because downstream phases and the PRD's NoGos section use your rejected alternatives to document scope exclusions. If you chose "Google OAuth only," the PRD will explicitly note that email/password and multi-provider SSO were considered and rejected.

Outputs

PRD (prd.md)

A Markdown document with these sections:

  1. Executive Summary — Project name, problem statement, solution overview
  2. Job Stories — Requirements in the format: "When [situation], I want [action], so [outcome]." Job stories focus on context and motivation rather than user roles, producing more specific requirements than traditional user stories.
  3. Project Requirements — Business and functional requirements derived from your answers
  4. Functional Requirements — Detailed system capabilities and behaviors
  5. NoGos — What is not being built and why. Includes:
    • Strategic rejections (options you explicitly decided against in your answers)
    • Scope exclusions (features users might expect but won't get)
    • Future considerations (deferred capabilities)

The document length depends on your document length setting (brief: 600-900 words, standard: 1,500-2,100, comprehensive: 3,600-4,500).

Acceptance criteria (acceptance_criteria.json)

Testable criteria linked to each job story, in Given/When/Then format:

{
  "job_stories": [
    {
      "job_story_id": "JS-001",
      "title": "Quick authentication",
      "situation": "When I need to access the app quickly",
      "motivation": "I want to sign in with Google",
      "outcome": "So that I can start using the app immediately",
      "acceptance_criteria": [
        {
          "id": "AC-001",
          "given": "Given I am on the login page",
          "when": "When I click 'Sign in with Google'",
          "then": "Then I am redirected to the Google consent screen"
        }
      ]
    }
  ]
}

Every requirement is traceable to a business or user need. Every job story has comprehensive acceptance criteria. Edge cases and error scenarios are covered.

Review and refinement

After generation, you review the PRD in the Web UI. You can:

  • Approve — Mark the document as complete and move to the Designer phase
  • Edit inline — Modify the Markdown directly in the browser (Ctrl+Enter to save)
  • Refine with AI — Provide text feedback (and optionally upload reference images) to have the AI revise specific parts

You can also edit the generated files directly in your editor. All outputs are plain Markdown and JSON at specwright/outputs/projects/{projectId}/documents/. The Web UI reflects changes on the next page load.

What's next?

  • Designer Phase — UX specifications built from the PRD
  • Output Files — Full file format reference for PRD and acceptance criteria