# Skill Product-to-Code Handoff

```markdown
# Skill: Product-to-Code Handoff

## Purpose

This skill turns a messy product idea into a clear set of build-ready documents for coding agents such as Codex, Claude Code, or Cursor.

The skill is designed for projects where the user wants to move from:

Idea / discussion / rough concept

to:

- `PRD.md`
- `TECH_SPEC.md`
- `TASKS.md`
- `AI_CONTEXT.md`

## When to Use This Skill

Use this skill when the user wants to:

- design a new software tool
- convert an idea into a PRD
- prepare documents for Codex or Claude Code
- define MVP scope
- plan a local app, SaaS, internal tool, automation, or AI workflow
- reduce vague product ideas into executable tasks

## Core Principle

The output must be **developer-executable**, not just strategic.

A good output should help a coding agent understand:

- what to build
- why it exists
- what not to build
- what the user flow is
- what data needs to be stored
- what edge cases matter
- what implementation steps should come first

## Skill Workflow

### Step 1: Product Framing

Clarify the product in one sentence.

Required output:

```text
This product is a [type of tool] for [target user] to [core job].
```

### Step 2: Define the User

Identify the primary user.

Required fields:

```text
Primary user:
User context:
User pain:
User goal:
```

### Step 3: Define the Core Job

Identify the main job-to-be-done.

Required output:

```text
When I [situation], I want to [action], so that I can [outcome].
```

### Step 4: Define Goals and Non-Goals

Separate what belongs in V1 from what should be excluded.

Required sections:

```text
Goals:
Non-goals:
```

Non-goals are very important. They prevent scope creep.

### Step 5: Define MVP Scope

The MVP should be the smallest useful version.

Required fields:

```text
MVP must include:
MVP should not include:
Later versions may include:
```

### Step 6: Define User Workflow

Describe the product workflow from beginning to end.

Required format:

```text
Step 1:
Step 2:
Step 3:
Step 4:
Final result:
```

### Step 7: Define Feature Requirements

Break features into clear modules.

Recommended format:

```text
Feature:
Description:
User story:
Requirements:
Acceptance criteria:
```

### Step 8: Define Data Model Requirements

Identify the core objects the app must store.

Required format:

```text
Entity:
Purpose:
Important fields:
Relationships:
```

### Step 9: Define Technical Direction

Choose the likely stack and architecture.

Required fields:

```text
Frontend:
Backend:
Database:
Storage:
Auth/session:
Workers:
External tools/APIs:
```

### Step 10: Define Edge Cases and Risks

List technical, product, legal, data, and UX risks.

Required fields:

```text
Risk:
Impact:
Mitigation:
```

### Step 11: Define Acceptance Criteria

The PRD must end with clear testable success criteria.

Example:

```text
The user can paste one supported URL and successfully save media files locally.
The user can see collected assets in a dashboard.
The user can export approved assets into a local folder.
```

## Required Output Files

This skill should produce four files.

---

# 1. PRD.md

Purpose: explain what we are building and why.

Recommended sections:

```md
# PRD: [Product Name]

## 1. Background
## 2. Problem
## 3. Product Goal
## 4. Target User
## 5. Core Use Cases
## 6. Non-Goals
## 7. MVP Scope
## 8. User Workflow
## 9. Feature Requirements
## 10. Data Requirements
## 11. Permission / Policy / Risk Requirements
## 12. Error Handling
## 13. Acceptance Criteria
## 14. Future Versions
```

---

# 2. TECH_SPEC.md

Purpose: explain how the system should be built.

Recommended sections:

```md
# TECH_SPEC: [Product Name]

## 1. System Overview
## 2. Recommended Stack
## 3. Architecture
## 4. Folder Structure
## 5. Database Schema
## 6. Platform Adapter Design
## 7. Session Management
## 8. Storage Design
## 9. Job Queue / Worker Design
## 10. Export System
## 11. Error Handling
## 12. Security Considerations
## 13. Local Development Setup
```

---

# 3. TASKS.md

Purpose: tell the coding agent what to build step by step.

Recommended format:

```md
# TASKS: [Product Name]

## Phase 1: Project Setup
- [ ] Task
- [ ] Task

## Phase 2: Core Data Model
- [ ] Task
- [ ] Task

## Phase 3: First Working Flow
- [ ] Task
- [ ] Task

## Phase 4: Platform Adapter
- [ ] Task
- [ ] Task

## Phase 5: Export
- [ ] Task
- [ ] Task
```

Each task should be small enough for a coding agent to execute.

---

# 4. AI_CONTEXT.md

Purpose: give the coding agent stable context.

Recommended sections:

```md
# AI_CONTEXT: [Product Name]

## Product Summary
## What This Product Is
## What This Product Is Not
## Important Decisions
## Naming Rules
## UX Principles
## Technical Principles
## Safety / Risk Boundaries
## Current MVP Priority
## Do Not Build Yet
```

## Quality Checklist

Before finalizing output, check:

```text
Is the core user clear?
Is the core workflow clear?
Are non-goals explicit?
Is MVP small enough?
Can Codex start building from TASKS.md?
Are risks and permission boundaries included?
Are data entities clear?
Are acceptance criteria testable?
```

## Style Rules

Use:

- clear markdown
- direct requirements
- short paragraphs
- specific feature names
- implementation-friendly language

Avoid:

- vague business language
- unnecessary theory
- unclear feature scope
- too many future ideas in MVP
- hiding important risks
```