Skip to content

vt-c-pd-0-start

Start here for product design projects. Shows the workflow from research to PRD to prototype to specs and development handoff.

Plugin: core-standards
Category: Product Design Workflow
Command: /vt-c-pd-0-start

Product Design: Start

Welcome to the Product Design Workflow. Use this for product conceptual work leading to software development - from user research through PRD, prototyping, and feature specifications.

The Product Design Workflow

┌─────────────────────────────────────────────────────────────────────────────┐
│                      PRODUCT DESIGN WORKFLOW                                 │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│   /vt-c-pd-0-start      You are here - Overview & project setup                  │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-1-research   User research (interviews, personas, analysis)           │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-pid          Technical architecture & stack decisions (PID)           │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-2-prd        Create PRD document with standard template               │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-3-prototype  Generate prototype with VisiTrans Corporate Design       │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-4-validate   Usability testing and iteration                          │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-6-handoff    Prepare and execute development handoff                  │
│       │                                                                      │
│       ╰──────────────────────────────────────────────────────────────────╮  │
│                                                                          │  │
│   ┌──────────────────────────────────────────────────────────────────────┼──┤
│   │                    DEVELOPMENT WORKFLOW                              │  │
│   │                                                                      ▼  │
│   │   /vt-c-0-start → /vt-c-1-bootstrap → /vt-c-2-plan → /vt-c-3-build → /vt-c-4-review → ...       │
│   │                                                                         │
│   │   /vt-c-specs-from-prd generates specs directly from PRD                │
│   └─────────────────────────────────────────────────────────────────────────┤
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

Unified Repo Workflow (when .repo-manifest.yaml exists)

If the project uses unified repo governance, the handoff step transitions to development mode within the same repo, and /vt-c-activate manages the spec execution sequence:

DESIGN PHASE (sequential):
/vt-c-pd-0-start → /vt-c-pd-1-research → /vt-c-pd-pid → /vt-c-pd-2-prd
→ /vt-c-pd-3-prototype → /vt-c-pd-4-validate
→ /vt-c-pd-6-handoff (activates dev mode, bootstraps tech stack)

DEVELOPMENT PHASE (iterative per spec):
/vt-c-specs-from-prd   → generates specs from PRD, shows dashboard
  → /vt-c-2-plan → /vt-c-3-build → /vt-c-4-review
  → /vt-c-complete → auto-advances to next spec
  → repeat until all specs completed

DEPLOYMENT:
/vt-c-5-finalize (governance audit + all standard checks)

When to Use This Workflow

Use Product Design workflow for: - New product development (from idea to implementation) - Feature design requiring user research - PRD creation with prototypes - Creating specifications for development teams - Product Manager / Designer work that leads to code

Use Knowledge Work workflow (/vt-c-kw-0-start) for: - Documentation projects (not leading to code) - Research and analysis (standalone) - Business process design - Internal guides and training materials

Use Development workflow (/vt-c-0-start) for: - Direct software implementation - When you already have specs/specs - Bug fixes and maintenance - Technical tasks without product design phase

Execution Instructions

When this skill is invoked, follow these steps:

Step 0: Ensure Feature Branch

Before any work begins, check the git branch:

  1. Check if this is a git repository: git rev-parse --is-inside-work-tree 2>/dev/null

  2. If NOT a git repo → skip this step (not all design projects use git)

  3. Check current branch: git branch --show-current

  4. If on main or master → create a feature branch before proceeding

  5. If already on a feature branch → confirm and continue

  6. If branch creation needed, use AskUserQuestion:

  7. Suggest a branch name based on the project: design/[project-name]
  8. Let the user choose or provide their own name

  9. Create and checkout: git checkout -b [branch-name]

  10. Display: 

    Branch: [branch-name]
All changes will be committed to this branch.

Step 0.5: Project Registration Check

  1. Read TOOLKIT_ROOT/intake/projects.yaml (resolve TOOLKIT_ROOT from this skill's base directory)
  2. Check if the current working directory appears in the projects list
  3. If NOT registered and the project has a CLAUDE.md or .design-state.yaml:
  4. Ask: "This project is not registered in the toolkit. Register now to enable cross-project scanning and journal aggregation?"
  5. Options: Register now (invoke /vt-c-project-register) | Skip for now
  6. If registered: continue silently

Step 1: Display the Workflow Overview

Show the user the complete workflow diagram above. Explain: - Product Design bridges research to development - Each phase produces artifacts for the next - specs files become the contract with development - Prototypes enable 95% code reuse

Step 2: Determine Project Location

Product Design projects use OneDrive project structure:

OneDrive/[Project]/
├── 00-Inbox/                    # Incoming materials
├── 01-Projektmanagement/        # Project management docs
├── 02-Knowledge/
│   ├── 02-Zielgruppen-Personas/ # User personas
│   └── 04-Dokumente/            # Research findings
├── 03-PRD/
│   ├── PRD.md                   # Product Requirements Document
│   └── PID.md                   # Project Implementation Document (tech)
├── 04-prototyp/                 # Prototype (Git repo)
├── 05-specs/                 # Feature briefs for dev
│   ├── spec-0-project-setup.md
│   └── spec-N-[feature].md
├── 06 BUGchen/                  # Future: Bug tracking
└── 98-Vorlagen/                 # Templates

Ask user: "Where is your project folder? (OneDrive path or create new)"

Step 3: Initialize Design State

Check for and initialize the workflow state file:

# Check if .design-state.yaml exists
if [ -f ".design-state.yaml" ]; then
  echo "✓ Design state file found"
  Read: .design-state.yaml
  # Display current state
else
  echo "Creating design state file..."
  # Copy from template and customize
  cp templates/.design-state-template.yaml .design-state.yaml
  # Update with project name and timestamp
fi

If state file exists (resuming project): 

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Design State Loaded
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Project: {project_name}
Current Phase: {phase}
Iteration: {iteration}
Last Updated: {timestamp}

Quality Gates:
─────────────────────────────────────────────────────────────────
pd-0-start:   {✓ | ○}
pd-1-research: {✓ | ○}
pd-2-prd:      {✓ | ○}
pd-3-prototype: {✓ | ○}
pd-4-validate: {✓ | ○}
pd-6-handoff:  {✓ | ○}

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

If new state file created: 

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Design State Initialized
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Created: .design-state.yaml
Project: {folder_name}
Phase: pd-0-start (Iteration 1)

This file tracks your workflow progress, artifact versions,
and iteration history. It enables the iterative design loop.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 4: Check Prerequisites

Scan the project folder for:

  1. Project folder exists

  2. If missing: "Create project from template at 00-projektvorlage"

  3. PRD.md - Product Requirements Document

  4. If missing: "No PRD found. Start with /vt-c-pd-1-research to gather requirements."

  5. If exists: "PRD found. Check status and continue workflow."

  6. Personas - User personas in 02-Knowledge/02-Zielgruppen-Personas/

  7. If missing: "No personas found. User research recommended."

  8. If exists: "Personas found: [list names]"

  9. Prototype - Check 04-prototyp/ directory

  10. If empty: "No prototype yet. Created after PRD."

  11. If exists: "Prototype found."

  12. specs - Check 05-specs/ directory

  13. If empty: "No specs yet. Created after PRD approval."
  14. If exists: "specs found: [list files]"

Step 4: Determine Current Phase

Based on artifacts found:

Phase A: Starting Fresh 

You're starting a new product design project!

Next steps:
1. Create project folder from 00-projektvorlage (if not exists)
2. Start user research: /vt-c-pd-1-research

Or if you already have requirements:
→ Skip to /vt-c-pd-2-prd to create PRD

Phase B: Research Done, Need PID/PRD 

User research artifacts found in 02-Knowledge/

Next steps:
1. /vt-c-pd-pid   → Define technical architecture and stack (PID)
2. /vt-c-pd-2-prd → Create Product Requirements Document (uses PID)

If you already have a PID (03-PRD/PID.md), skip to /vt-c-pd-2-prd.

Phase C: PRD Exists, Need Prototype 

PRD found: 03-PRD/PRD.md

Next step: /vt-c-pd-3-prototype
This will generate a React prototype with VisiTrans CD.

Phase D: Prototype Exists, Need Validation 

Prototype found: 04-prototyp/

Next step: /vt-c-pd-4-validate
Test your prototype with users before finalizing specs.

Phase E: Ready for Handoff 

PRD approved and prototype validated!

Next step: /vt-c-pd-6-handoff
Prepare development handoff, then /vt-c-specs-from-prd to generate specs.

Phase F: Ready for Development 

specs files ready: [list files]

Next step: /vt-c-pd-6-handoff
Prepare the development handoff package.

Step 5: Show Quick Reference

Quick Reference:
─────────────────────────────────────────────────────
/vt-c-pd-0-start      → This overview
/vt-c-pd-1-research   → User research (interviews, personas)
/vt-c-pd-pid          → Technical architecture & stack (PID)
/vt-c-pd-2-prd        → Create PRD document
/vt-c-pd-3-prototype  → Generate prototype
/vt-c-pd-4-validate   → Usability testing
/vt-c-pd-6-handoff    → Development handoff
/vt-c-activate        → Generate specs from PRD & manage execution
─────────────────────────────────────────────────────

Supporting commands:
/vt-c-journal         → Capture decisions and learnings
/vt-c-consolidate     → Synthesize journal into docs
─────────────────────────────────────────────────────

After handoff, development uses:
/vt-c-specs-from-prd → /vt-c-2-plan → /vt-c-3-build → ...
─────────────────────────────────────────────────────

Step 6: Offer Next Action

Based on the project state, offer to run the appropriate next command:

"Would you like me to help create your project folder?" (if missing)

or

"Would you like me to run /vt-c-pd-1-research to start user research?" (if starting fresh)

or

"Would you like me to run /vt-c-pd-2-prd to create your PRD?" (if research done)

Orchestrator Integration

This workflow is coordinated by the product-design-orchestrator which: - Loads institutional knowledge before each phase - Ensures templates are followed consistently - Tracks progress through phases - Validates handoff readiness

Templates

PRD uses standard templates to ensure consistency: - PRD Template: 12 sections following VisiTrans structure - Spec Template: SpecKit-compatible format for dev handoff

Templates are embedded in the respective skills (/vt-c-pd-2-prd, /vt-c-activate).

Iterative Design Loop

This workflow supports iteration. When new information arrives that impacts the design:

  1. Scan Inbox: /vt-c-pd-inbox-scan detects new items
  2. Analyze Impact: /vt-c-pd-analyze-changes determines affected artifacts
  3. Route Decision: /vt-c-pd-route-decision returns to appropriate phase
New Input → /vt-c-pd-inbox-scan → /vt-c-pd-analyze-changes → /vt-c-pd-route-decision
                                                          │
                              ┌─────────────────────────────┘
                              ▼
                    Return to earlier phase
                    (pd-1, pd-2, pd-3, etc.)

When to Check for Iterations

  • Before starting each phase
  • When usability tests reveal issues
  • When stakeholder feedback arrives
  • When technical constraints are discovered

The .design-state.yaml file tracks: - Current phase and iteration number - Artifact versions and hashes - Quality gate status - Iteration history and decisions

Quality Gate: pd-0-start

Mark phase as complete when: - [ ] Project folder exists with standard structure - [ ] .design-state.yaml initialized - [ ] User understands workflow phases - [ ] Next phase determined

Update state file: 

quality_gates:
  pd-0-start:
    passed: true
    passed_at: "{timestamp}"
    criteria:
      project_folder_created: true
      state_file_initialized: true