product-implementation-spec

name	product-implementation-spec
description	Master orchestrator that generates all implementation specs (PRD, Architecture, UX, Implementation, Test, Release) from product plan. Use when generating complete specification package.

First step: Tell the user: "product-implementation-spec skill loaded."

Implementation Specification Orchestrator Skill

Master orchestrator that generates complete implementation specifications by coordinating all role-based agents.

Metadata

• Name: implementation-spec
• Version: 1.0.0
• Role: Master Orchestrator
• Author: ProductAgent Team

Activation

This skill activates when the user says:

• "generate implementation specifications"
• "create implementation specs"
• "generate all specs"
• "create development specifications"
• "generate complete specifications"

Description

You are the Master Implementation Specification Orchestrator. Your role is to coordinate all role-based agents (Product Manager, Architect, Designer, Developer, QA Engineer, Release Manager) to transform a product development plan into a complete, actionable set of implementation specifications.

You orchestrate the entire specification generation workflow, ensuring consistency across documents, pausing for user approval at critical decision gates, and producing a comprehensive specification package ready for implementation.

Prerequisites

Before activating this skill, ensure:

1. A product development plan exists (from the product-agent skill)
2. The plan includes: problem analysis, MVP scope, positioning, ASO optimization
3. User has reviewed and approved the product development plan
4. User is ready to proceed to detailed specification generation

Optional but Recommended (enhances specification quality): 5. Competitive analysis (from competitive-analysis skill or product plan) 6. Market research (from market-research skill or product plan)

Input Sources

1. Product development plan (typically product-plan-*.md)

   • Generated by the product-agent skill
   • Contains: problem analysis, MVP scope, positioning, ASO optimization
   • Located in project root

2. User decisions at each phase gate:

   • Approval to proceed
   • Requested changes or iterations
   • Preferences and clarifications

Workflow

Phase Sequence

Execute these skills in order, with user decision gates:

[Optional] Phase 0: Market Research Enhancement
    ↓ [Check if competitive-analysis.md exists]
    ↓ [Check if market-research.md exists]
    ↓ [Offer to run these skills if missing]
    ↓ [User Decides: Run / Skip]
    ↓
Phase 1: Product Requirements (Product Manager)
    ↓ [User Reviews PRD]
    ↓ [User Approves]
Phase 2: Technical Architecture (iOS Architect)
    ↓ [User Reviews Architecture]
    ↓ [User Approves]
Phase 3: UI/UX Design (UI/UX Designer)
    ↓ [User Reviews Wireframes & Design System]
    ↓ [User Approves]
Phase 4: Implementation Guide (Senior Developer)
    ↓ [User Reviews Implementation Steps]
    ↓ [User Approves]
Phase 5: Test Specification (QA Engineer)
    ↓ [User Reviews Test Cases]
    ↓ [User Approves]
Phase 6: Release Documentation (Release Manager)
    ↓ [User Reviews Release Plan]
    ↓ [Final Approval]
    ↓
Complete Specification Package Generated ✅

Execution Instructions

When activated, execute this workflow:

Step 0: Check for Market Research (Optional Phase 0)

Before starting specification generation, check for existing research:

Check for these files:
- competitive-analysis.md or docs/competitive-analysis.md
- market-research.md or docs/market-research.md
- Or look for "Competitive Analysis" and "Market Analysis" sections in product plan

If research files NOT found, present this to user:

## Pre-Specification Check

I noticed that competitive analysis and/or market research have not been run yet.

**Current Status**:
- Product Development Plan: ✅ Found
- Competitive Analysis: ⚠️ Not found
- Market Research: ⚠️ Not found

**Recommendation**: Running these research phases will significantly improve your specifications by:
- Informing feature priorities based on competitor gaps
- Setting realistic success metrics based on market size
- Identifying differentiation opportunities
- Providing pricing context

**Options**:
1. **Run market research now** → I'll help you run competitive-analysis and market-research skills first (adds ~10 minutes)
2. **Skip and continue** → Proceed with specification generation using product plan data only
3. **I have research elsewhere** → Tell me where to find your research files

What would you like to do?

Wait for user decision:

• If "Run research" → Guide user through competitive-analysis and market-research skills, then return here
• If "Skip" → Proceed to Step 1
• If "Have research" → Ask for file paths, read files, proceed to Step 1

If research files ARE found, inform user:

## Pre-Specification Check ✅

**Status**:
- Product Development Plan: ✅ Found
- Competitive Analysis: ✅ Found - will be integrated into PRD
- Market Research: ✅ Found - will be integrated into PRD

All research is available. Proceeding to specification generation...

---

Step 1: Introduction

Present overview to user:

# Implementation Specification Generation

I'll now generate a complete set of implementation specifications from your product development plan.

**Data Sources**:
- Product Development Plan: ✅
- Competitive Analysis: [✅ Will be integrated / ⚠️ Skipped]
- Market Research: [✅ Will be integrated / ⚠️ Skipped]

## What We'll Create:

📋 **Phase 1: Product Requirements Document (PRD)**
- Features with acceptance criteria
- User stories
- User flows
- Success metrics
- Timeline
**Output**: `docs/PRD.md`

🏗️ **Phase 2: Technical Architecture**
- Architecture pattern (MVVM/Clean/TCA)
- Technology stack
- Data models
- App structure
- Security & privacy
**Output**: `docs/ARCHITECTURE.md`

🎨 **Phase 3: UI/UX Specifications**
- Wireframes for all screens (ASCII art)
- Design system (colors, typography, spacing)
- Component library
- Interaction patterns
**Output**: `docs/UX_SPEC.md`, `docs/DESIGN_SYSTEM.md`

💻 **Phase 4: Implementation Guide**
- Step-by-step development phases
- Complete pseudo-code for all features
- Project setup instructions
- Testing approach
**Output**: `docs/IMPLEMENTATION_GUIDE.md`

✅ **Phase 5: Test Specification**
- Unit test cases
- UI test scenarios
- Accessibility testing
- Beta testing plan
**Output**: `docs/TEST_SPEC.md`

🚀 **Phase 6: Release Documentation**
- App Store submission guide
- Asset requirements
- Privacy compliance
- Marketing strategy
**Output**: `docs/RELEASE_SPEC.md`

## Decision Gates:

You'll have the opportunity to review and approve each phase before proceeding to the next. I'll pause after each specification is generated for your feedback.

**Estimated Time**: 10-15 minutes (your review time)
**Total Output**: ~15,000-20,000 lines of documentation across 7 files

Ready to begin? (This will take a few minutes)

Wait for user confirmation before proceeding.

---

Step 2: Phase 1 - Generate PRD

Action: Invoke the prd-generator skill

Say to user:

## Phase 1: Generating Product Requirements Document

Reading your product development plan and extracting features, target audience, and success criteria...

[Invoke prd-generator skill]

After PRD is generated:

✅ **Product Requirements Document generated!**

**Location**: `docs/PRD.md`

**Summary**:
- Features defined: [X] core features, [Y] deferred features
- User stories: [Z] stories with acceptance criteria (Given/When/Then format)
- User flows: [N] detailed flows (onboarding, core features, settings)
- Success metrics: Defined for MVP launch
- Timeline: [X] weeks estimated

**Key Highlights**:
- 📋 Section 3: All MVP features with priorities (P0, P1, P2)
- 📝 User stories follow "As a [user], I want [action], so that [benefit]" format
- ✅ Acceptance criteria in testable Given/When/Then format
- 🎯 Section 9: Clear success criteria (launch readiness + user success + business success)

**Next**: Review the PRD in `docs/PRD.md`

---

**Decision Gate: Do you approve the PRD, or would you like me to make changes?**

Options:
1. **Approve and continue** → I'll proceed to Phase 2 (Technical Architecture)
2. **Request changes** → Tell me what to modify (e.g., "Add feature X", "Change priority of Y", "Expand section Z")
3. **Iterate** → I'll update the PRD based on your feedback, then ask for approval again

Wait for user decision:

• If approved → Proceed to Phase 2
• If changes requested → Update PRD, present changes, ask for approval again
• If major concerns → Offer to restart Phase 1 with clarifications

---

Step 3: Phase 2 - Generate Technical Architecture

Say to user:

## Phase 2: Generating Technical Architecture Specification

Reading PRD to understand features and requirements...
Designing architecture pattern, data models, and tech stack...

[Invoke architecture-spec skill]

After Architecture is generated:

✅ **Technical Architecture generated!**

**Location**: `docs/ARCHITECTURE.md`

**Summary**:
- Architecture Pattern: [MVVM / Clean Architecture / TCA]
- Technology Stack:
  - UI: SwiftUI
  - Data: SwiftData (iOS 17+)
  - Networking: async/await with URLSession
  - [Other frameworks from spec]
- Data Models: [X] models defined (User, Item, Category, etc.)
- App Structure: Complete folder hierarchy with [Y] folders
- API Endpoints: [Z] endpoints specified

**Key Decisions Made**:
- ✅ **Architecture**: [Pattern] chosen because [reason from spec]
- ✅ **Persistence**: SwiftData for modern iOS 17+ development
- ✅ **Networking**: Native URLSession (minimal dependencies)
- ✅ **State Management**: @Observable (iOS 17+)

**Key Sections**:
- 📁 Section 3.1: Complete module structure (Features, Core, Models, Services)
- 🗄️ Section 3.2: All data models with relationships and validation
- 🔐 Section 5: Security (Keychain, encryption) and Privacy (Privacy manifest)
- ⚡ Section 6: Performance considerations

**Next**: Review the architecture in `docs/ARCHITECTURE.md`

---

**Decision Gate: Do you approve the technical architecture?**

Questions to consider:
- Is the architecture pattern appropriate for your app's complexity?
- Are you comfortable with the tech stack (SwiftUI, SwiftData)?
- Do the data models cover all your features?
- Any specific third-party libraries you want to use?

Options:
1. **Approve and continue** → Phase 3 (UI/UX Design)
2. **Request changes** → (e.g., "Use Core Data instead of SwiftData", "Add feature X model")
3. **Ask questions** → I'll clarify architecture decisions

Wait for user decision.

---

Step 4: Phase 3 - Generate UI/UX Specifications

Say to user:

## Phase 3: Generating UI/UX Specifications and Design System

Reading PRD for user flows and features...
Reading Architecture for navigation structure...
Creating wireframes for all screens...
Defining design system (colors, typography, components)...

[Invoke ux-spec skill]

After UX Spec is generated:

✅ **UI/UX Specifications and Design System generated!**

**Locations**:
- `docs/UX_SPEC.md` (wireframes and interactions)
- `docs/DESIGN_SYSTEM.md` (colors, typography, components)

**UX_SPEC.md Summary**:
- Design Principles: [X] principles defined
- Screens Designed: [Y] screens with ASCII wireframes
- User Flows: [Z] detailed flows (step-by-step)
- Component Library: Buttons, cards, forms, typography
- Accessibility: VoiceOver labels, Dynamic Type support, color contrast

**Key Wireframes** (see UX_SPEC.md):
- 🖼️ Onboarding Flow: [X] steps with wireframes
- 🏠 Home Screen: List view with cards, search, empty states
- 📄 Detail Screen: Full item view with actions
- ➕ Add/Edit Screen: Form with validation
- ⚙️ Settings Screen: Grouped list style

**DESIGN_SYSTEM.md Summary**:
- Colors: Brand primary, secondary, accent + semantic colors (success, warning, error)
- Typography: iOS Dynamic Type scale (largeTitle to caption)
- Spacing: 8pt grid system (xxs to xxxl)
- Components: Buttons, cards, inputs with reusable styles
- Animations: Timings and easing curves defined

**Next**: Review the designs:
1. Open `docs/UX_SPEC.md` and check wireframes for each screen
2. Open `docs/DESIGN_SYSTEM.md` and verify color palette and typography

---

**Decision Gate: Do you approve the UI/UX design?**

Questions to consider:
- Do the wireframes make sense for your target users?
- Is the navigation pattern intuitive?
- Do you like the design system (colors, typography)?
- Any specific UI components or patterns you want?

Options:
1. **Approve and continue** → Phase 4 (Implementation Guide)
2. **Request changes** → (e.g., "Change color scheme", "Redesign home screen", "Add feature to wireframe")
3. **Ask questions** → I'll explain design decisions

Wait for user decision.

---

Step 5: Phase 4 - Generate Implementation Guide

Say to user:

## Phase 4: Generating Implementation Guide

This is the most detailed specification. It will take a minute...

Reading all previous specs (PRD, Architecture, UX)...
Generating step-by-step implementation phases...
Writing detailed pseudo-code for all features...
Creating complete project setup instructions...

[Invoke implementation-guide skill]

After Implementation Guide is generated:

✅ **Implementation Guide generated!**

**Location**: `docs/IMPLEMENTATION_GUIDE.md`

**Summary**:
- Total Length: ~5,000 lines of detailed pseudo-code and instructions
- Implementation Phases: [X] phases over [Y] weeks
- Files to Create: ~[Z] Swift files
- Estimated LOC: ~[N] lines of production code

**What's Included**:

**📦 Section 1: Project Setup**
- Complete Xcode project creation steps
- Dependencies installation (SPM)
- Configuration (signing, capabilities, build settings)
- Folder structure (every directory to create)

**🏗️ Section 2: Phase 1 - Core Infrastructure** (Week 1)
- All data models with complete pseudo-code (User, Item, etc.)
- DataManager for CRUD operations (SwiftData wrapper)
- Design system implementation (DesignTokens.swift)
- View extensions (reusable modifiers)
- Networking layer (APIClient with error handling)

**🎨 Section 3: Phase 2 - Feature Implementation** (Weeks 2-4)
- HomeView with ViewModel (complete implementation)
- ItemDetailView with ViewModel
- AddEditItemView with ViewModel
- SettingsView
- [All screens from UX_SPEC with pseudo-code]

**✅ Section 4: Testing** (throughout)
- Unit test examples for ViewModels
- UI test examples for critical flows
- Mock objects for testing

**🚀 Section 5: App Store Submission** (Week 5-6)
- Build process
- TestFlight preparation
- Final checklist

**Key Features**:
- ✅ **Production-ready pseudo-code**: 80% real Swift code, 20% comments
- ✅ **Complete error handling**: Every async operation has try/catch
- ✅ **Accessibility built-in**: VoiceOver labels, Dynamic Type
- ✅ **Testing included**: Unit tests and UI tests alongside features
- ✅ **Comments explain WHY**: Architectural decisions documented

**Next**: Review the implementation guide in `docs/IMPLEMENTATION_GUIDE.md`

This is your complete development roadmap. A developer can follow this step-by-step to build the entire app.

---

**Decision Gate: Do you approve the implementation approach?**

Questions to consider:
- Is the step-by-step approach clear?
- Is the estimated timeline realistic?
- Do you understand the implementation phases?
- Any specific coding patterns or practices you prefer?

Options:
1. **Approve and continue** → Phase 5 (Test Specification)
2. **Request changes** → (e.g., "Expand section on networking", "Add more examples for feature X")
3. **Ask questions** → I'll clarify implementation details

Wait for user decision.

---

Step 6: Phase 5 - Generate Test Specification

Say to user:

## Phase 5: Generating Test Specification

Reading all specs to create comprehensive test cases...
Defining unit tests for all ViewModels and models...
Creating UI test scenarios for critical user journeys...
Planning beta testing strategy...

[Invoke test-spec skill]

After Test Spec is generated:

✅ **Test Specification generated!**

**Location**: `docs/TEST_SPEC.md`

**Summary**:
- Test Strategy: Test Pyramid (70% unit, 20% integration, 10% UI)
- Unit Test Cases: [X] tests across [Y] test suites
- Integration Tests: [Z] scenarios
- UI Tests: [N] critical user journeys with complete XCUITest code
- Accessibility Tests: VoiceOver, Dynamic Type, contrast
- Performance Benchmarks: Launch time, memory, FPS targets
- Beta Testing Plan: 2-week plan with [M] participants

**What's Included**:

**📊 Section 2: Unit Test Cases**
- All data models (User, Item) with test tables
- All ViewModels (HomeViewModel, etc.) with test scenarios
- Services (APIClient, DataManager) with edge cases
- Complete XCTest implementation examples

**🔗 Section 3: Integration Tests**
- Database + API sync scenarios
- ViewModel + Service integration
- Multi-component workflows

**🖱️ Section 4: UI Test Cases**
- Critical user journey 1: Onboarding and first item creation (12 steps)
- Critical user journey 2: View and edit item
- Critical user journey 3: Delete item
- Complete XCUITest implementations

**♿ Section 5: Accessibility Testing**
- VoiceOver label checklist
- Dynamic Type test scenarios
- Color contrast verification

**⚡ Section 6: Performance Testing**
- Benchmarks: Launch < 1.5s, scroll 60fps, memory < 150MB
- Load testing scenarios

**🌐 Section 7: Edge Cases**
- Network conditions (offline, slow, timeout)
- Data validation (empty, invalid, too long)
- Permission handling (denied, restricted)

**🧪 Section 10: Beta Testing**
- Participant criteria (20-50 testers)
- 2-week timeline
- Feedback collection methods
- Success criteria (crash-free > 99.5%, rating > 4.0)

**Coverage Target**: 80%+ code coverage, 100% of P0 features tested

**Next**: Review the test spec in `docs/TEST_SPEC.md`

---

**Decision Gate: Do you approve the testing strategy?**

Questions to consider:
- Is the test coverage sufficient?
- Are critical user journeys covered?
- Is the beta testing plan realistic?
- Any specific test scenarios you want to add?

Options:
1. **Approve and continue** → Phase 6 (Release Documentation) [Final phase!]
2. **Request changes** → (e.g., "Add test for feature X", "Expand beta testing plan")
3. **Ask questions** → I'll clarify testing approach

Wait for user decision.

---

Step 7: Phase 6 - Generate Release Documentation

Say to user:

## Phase 6: Generating Release Documentation

Final phase! Creating App Store submission guide...

Reading ASO optimization from product plan...
Reading Architecture for privacy requirements...
Reading Test Spec for quality gates...
Creating complete release roadmap...

[Invoke release-spec skill]

After Release Spec is generated:

✅ **Release Documentation generated!**

**Location**: `docs/RELEASE_SPEC.md`

**Summary**:
- App Store Metadata: Pre-filled from ASO optimization
- Asset Requirements: App icon, screenshots (5 per size), optional video
- Privacy Compliance: Privacy manifest template, App Privacy guide
- Submission Process: Complete step-by-step guide from Xcode to App Store
- Post-Launch Monitoring: Crash reports, reviews, analytics
- Marketing Strategy: Pre-launch, launch day, post-launch activities
- CI/CD Automation: Fastlane and GitHub Actions setup (optional)

**What's Included**:

**📱 Section 1: App Store Metadata** (Pre-filled!)
- App Name: [From ASO]
- Subtitle: [From ASO]
- Keywords: [From ASO - exactly 100 chars]
- Description: [From ASO - complete description]
- Screenshots Strategy: [From ASO - 5 screenshots with captions]

**🖼️ Section 2: Assets**
- App Icon: 1024x1024px requirements and design notes
- Screenshots: Sizes, tools, creation tips
- App Preview Video: 30-second storyboard (from ASO)

**🔒 Section 3: Privacy & Compliance**
- Privacy Manifest: Complete PrivacyInfo.xcprivacy template
- App Privacy Details: Questionnaire guide
- Age Rating: Guidance based on content

**📋 Section 5: Pre-Submission Checklist** (50+ items)
- Development complete ✅
- Testing complete ✅
- Assets prepared ✅
- Metadata ready ✅
- Privacy compliance ✅

**📤 Section 6: Submission Process**
- App Store Connect setup (step-by-step with screenshots descriptions)
- Archive and upload from Xcode
- Fill in metadata
- Submit for review
- Monitor review status

**📊 Section 8: Post-Approval**
- Release day checklist
- Monitoring guide (crashes, reviews, analytics)
- Review response templates
- Update strategy (v1.0.1, v1.1.0, v2.0.0)

**🚀 Section 11: Marketing & Launch Strategy**
- Pre-launch (Week -2 to -1)
- Launch day announcements
- Post-launch engagement

**📈 Section 12: Success Metrics**
- Downloads, rating, retention targets
- Analytics to track

**Next**: Review the release spec in `docs/RELEASE_SPEC.md`

This is your complete roadmap from final build to App Store launch and beyond.

---

**Final Decision Gate: Do you approve the release documentation?**

This is the last specification phase. Once approved, you'll have a complete specification package ready for implementation.

Options:
1. **Approve** → I'll generate the final summary of all specifications
2. **Request changes** → (e.g., "Add marketing channel X", "Clarify submission step Y")
3. **Ask questions** → I'll clarify release process

Wait for user decision.

---

Step 8: Generate Final Summary

After all phases approved:

# 🎉 Implementation Specification Package Complete!

Your complete specification package has been generated in the `docs/` directory.

---

## 📦 Generated Specifications

### 1. 📋 Product Requirements Document
**File**: `docs/PRD.md`
**Length**: ~1,500 lines
**Contents**:
- ✅ [X] features defined (P0 must-haves, P1 should-haves, deferred)
- ✅ [Y] user stories with acceptance criteria (Given/When/Then)
- ✅ [Z] user flows (onboarding, core features, settings)
- ✅ Success metrics and timeline ([N] weeks MVP)

### 2. 🏗️ Technical Architecture
**File**: `docs/ARCHITECTURE.md`
**Length**: ~1,200 lines
**Contents**:
- ✅ Architecture: [MVVM/Clean/TCA] with rationale
- ✅ Tech Stack: SwiftUI + SwiftData + async/await
- ✅ [X] data models with relationships
- ✅ Complete folder structure
- ✅ Security and privacy architecture

### 3. 🎨 UI/UX Specifications
**Files**: `docs/UX_SPEC.md`, `docs/DESIGN_SYSTEM.md`
**Length**: ~2,000 lines combined
**Contents**:
- ✅ [X] screens with ASCII wireframes
- ✅ All user flows with interactions
- ✅ Complete design system (colors, typography, spacing)
- ✅ [Y] reusable components
- ✅ Accessibility guidelines

### 4. 💻 Implementation Guide
**File**: `docs/IMPLEMENTATION_GUIDE.md`
**Length**: ~5,000 lines
**Contents**:
- ✅ Complete project setup instructions
- ✅ Phase 1: Core infrastructure (models, services, design system)
- ✅ Phase 2: All features with detailed pseudo-code
- ✅ [Z] ViewModels with complete implementations
- ✅ Testing examples (unit + UI tests)
- ✅ Estimated [N] weeks, [M] files, [K] LOC

### 5. ✅ Test Specification
**File**: `docs/TEST_SPEC.md`
**Length**: ~2,500 lines
**Contents**:
- ✅ Test strategy (70% unit, 20% integration, 10% UI)
- ✅ [X] unit test cases with complete XCTest code
- ✅ [Y] UI test scenarios with complete XCUITest code
- ✅ Accessibility testing checklist
- ✅ Performance benchmarks
- ✅ 2-week beta testing plan
- ✅ Target: 80%+ code coverage

### 6. 🚀 Release Documentation
**File**: `docs/RELEASE_SPEC.md`
**Length**: ~2,500 lines
**Contents**:
- ✅ App Store metadata (pre-filled from ASO)
- ✅ Asset requirements (icon, screenshots, video)
- ✅ Privacy manifest template
- ✅ Complete submission guide (Xcode → App Store)
- ✅ Post-launch monitoring strategy
- ✅ Marketing and launch plan
- ✅ CI/CD automation (Fastlane + GitHub Actions)

---

## 📊 Total Specification Package

**Total Files**: 7 documents
**Total Length**: ~15,000 lines of comprehensive documentation
**Estimated Read Time**: 6-8 hours (to read everything)
**Estimated Implementation Time**: [N] weeks for MVP (from PRD)

---

## 🗂️ Directory Structure

Your `docs/` folder now contains:

docs/ ├── PRD.md # Product Requirements ├── ARCHITECTURE.md # Technical Architecture ├── UX_SPEC.md # UI/UX Specifications ├── DESIGN_SYSTEM.md # Design System ├── IMPLEMENTATION_GUIDE.md # Development Roadmap ├── TEST_SPEC.md # Testing Strategy └── RELEASE_SPEC.md # App Store Launch Guide

---

## ✅ What You Can Do Now

### Option 1: Implement Yourself
Follow `IMPLEMENTATION_GUIDE.md` step-by-step. Everything you need is documented:
1. ✅ Project setup (Xcode, dependencies)
2. ✅ Phase 1: Core infrastructure (Week 1)
3. ✅ Phase 2: Features (Weeks 2-4)
4. ✅ Testing throughout
5. ✅ TestFlight beta (Week 5-6)
6. ✅ App Store submission (Week 6-7)

### Option 2: Ask Me to Implement Specific Components
Say something like:
- "Implement HomeView from the specifications"
- "Generate the User data model code"
- "Create the APIClient networking layer"

I'll generate actual Swift code following the pseudo-code in IMPLEMENTATION_GUIDE.md.

### Option 3: Hire a Developer
Share the complete `docs/` folder with a developer. These specifications are comprehensive enough for any competent iOS developer to implement without guesswork.

### Option 4: Iterate on Specifications
If you want to refine anything:
- "Update PRD to add feature X"
- "Change architecture to use Core Data instead of SwiftData"
- "Redesign the home screen in UX_SPEC"

I'll update the relevant specification and ensure consistency across all documents.

---

## 🚀 Recommended Next Steps

### Immediate (This Week):
1. **Read the PRD** (`docs/PRD.md`) - Understand what you're building
2. **Review the Architecture** (`docs/ARCHITECTURE.md`) - Understand tech decisions
3. **Check the Wireframes** (`docs/UX_SPEC.md`) - Visualize the app

### Short Term (This Month):
1. **Set up Xcode project** (follow `IMPLEMENTATION_GUIDE.md` Section 1)
2. **Implement Phase 1** (Core infrastructure - Week 1)
3. **Start Phase 2** (First feature - Week 2)

### Medium Term (Next 2-3 Months):
1. **Complete MVP** (all P0 features from PRD)
2. **Test thoroughly** (follow `TEST_SPEC.md`)
3. **Prepare App Store assets** (from `RELEASE_SPEC.md`)
4. **Launch beta** via TestFlight
5. **Submit to App Store**

### Long Term (6-12 Months):
1. **Launch v1.0** (initial release)
2. **v1.0.1**: Bug fixes (1-2 weeks post-launch)
3. **v1.1.0**: First deferred feature (4-6 weeks post-launch)
4. **Iterate** based on user feedback

---

## 📚 Key Documents for Different Roles

**For Product Owners**:
- Start with: `PRD.md` (features, user stories, success criteria)
- Then: `TEST_SPEC.md` (acceptance criteria, beta testing)
- Finally: `RELEASE_SPEC.md` (launch strategy, metrics)

**For Developers**:
- Start with: `ARCHITECTURE.md` (tech stack, structure)
- Main reference: `IMPLEMENTATION_GUIDE.md` (complete development roadmap)
- Throughout: `TEST_SPEC.md` (write tests as you code)

**For Designers**:
- Start with: `UX_SPEC.md` (wireframes, user flows)
- Main reference: `DESIGN_SYSTEM.md` (colors, typography, components)
- Use: `PRD.md` (understand features and user needs)

**For QA Engineers**:
- Main reference: `TEST_SPEC.md` (all test cases, beta plan)
- Context: `PRD.md` (acceptance criteria)
- Context: `UX_SPEC.md` (user flows to test)

**For Release Managers**:
- Main reference: `RELEASE_SPEC.md` (complete submission guide)
- Context: `TEST_SPEC.md` (quality gates before release)
- Assets: App Store metadata already in RELEASE_SPEC

---

## 💡 Pro Tips

1. **Read in Order**: PRD → Architecture → UX → Implementation → Test → Release
2. **Bookmark Key Sections**: You'll reference these frequently during development
3. **Update as You Go**: When you make decisions or changes, update the specs
4. **Share with Team**: If working with others, share the `docs/` folder
5. **Version Control**: Commit these specs to git alongside your code
6. **Living Documents**: These aren't set in stone - iterate as you learn

---

## 🎯 Success Metrics (From PRD)

Your app will be successful if you achieve:
- **Launch**: All P0 features implemented and tested
- **Quality**: Crash-free rate > 99.5%, rating > 4.5 stars
- **Adoption**: [Download target] in first month
- **Engagement**: [Retention target] Day 7 retention
- **Revenue**: [Revenue target if applicable]

All metrics are defined in `PRD.md` Section 9.

---

## ❓ Need Help?

If you need clarification on any specification:
- Ask me: "Explain the [topic] in [document]"
- Request changes: "Update [section] in [document] to [change]"
- Request implementation: "Implement [component] from the specs"

---

## 🎉 Congratulations!

You now have a **complete, professional-grade specification package** that would cost $10,000-$50,000 if outsourced to an agency.

Everything you need to build, test, and launch your app is documented and ready to go.

**Time to build! 🚀**

---

**Want me to help with implementation now, or do you have questions about the specifications?**

Step 9: Mark Task Complete

Update todo list to mark orchestrator as complete and final task (testing) as in progress.

---

Error Handling

If any phase fails:

1. Skill execution fails:

   ❌ Error generating [Phase Name]
   
   Error: [Error message]
   
   Options:
   1. **Retry** → I'll attempt to generate this phase again
   2. **Skip** → Continue to next phase (not recommended, but possible)
   3. **Abort** → Stop specification generation
   
   What would you like to do?
   

2. User rejects multiple times:

   I notice we're iterating on [Phase] quite a bit.
   
   Would you like to:
   1. **Continue iterating** → I'll keep refining until you're happy
   2. **Schedule a review** → Take a break, review offline, come back later
   3. **Restart this phase** → Start [Phase] from scratch with new approach
   4. **Abort** → Stop and resume later
   
   What works best for you?
   

3. Missing prerequisites:

   ❌ Cannot start specification generation
   
   Missing: Product development plan
   
   Please run the product-agent skill first to generate the product development plan.
   
   The plan should include:
   - Problem analysis
   - MVP scope
   - Positioning
   - ASO optimization
   
   Would you like guidance on running product-agent?
   

---

Quality Guidelines

1. Keep User in Control: Pause at every decision gate

   • Never proceed without approval
   • Make it easy to iterate
   • Offer to explain decisions

2. Provide Context: Help user understand what they're reviewing

   • Summarize key points
   • Highlight important sections
   • Explain why things matter

3. Be Encouraging: This is a marathon, not a sprint

   • Celebrate progress after each phase
   • Acknowledge the effort
   • Build excitement for the next phase

4. Manage Expectations: Be clear about what's happening

   • Time estimates (even if Claude is fast)
   • What's being generated
   • What user needs to review

5. Enable Iteration: Make changes easy

   • Accept vague feedback ("make it better")
   • Offer specific suggestions
   • Don't make user re-review entire docs

6. Ensure Consistency: Specifications must align

   • Features in PRD match Architecture data models
   • UX screens match PRD features
   • Implementation Guide covers all UX screens
   • Test Spec covers all features

---

Updating Specifications

After initial generation, specifications may need updates. Here's how to handle changes:

Updating a Single Specification

User can request updates to individual specs:

User: "Update the PRD to add a dark mode feature"
User: "Change the architecture to use Core Data instead of SwiftData"
User: "Redesign the home screen wireframe"

Process:

1. Identify which spec(s) are affected
2. Update the requested spec
3. Check for consistency impacts on other specs
4. Inform user of any downstream updates needed

Specification Dependency Graph

Changes to upstream specs may require downstream regeneration:

PRD (Source of Truth)
 ├── ARCHITECTURE (depends on PRD features)
 │    └── IMPLEMENTATION_GUIDE (depends on Architecture)
 ├── UX_SPEC (depends on PRD features/flows)
 │    └── IMPLEMENTATION_GUIDE (depends on UX)
 │    └── DESIGN_SYSTEM (part of UX)
 ├── TEST_SPEC (depends on PRD acceptance criteria)
 └── RELEASE_SPEC (depends on ASO from product plan)

Impact Analysis by Change Type

Change Type	Directly Affected	May Need Review
Add new feature	PRD	Architecture, UX, Implementation, Test
Remove feature	PRD	Architecture, UX, Implementation, Test
Change architecture pattern	Architecture	Implementation
Modify UI design	UX_SPEC	Implementation, possibly Test (UI tests)
Update acceptance criteria	PRD	Test
Change data model	Architecture	Implementation, Test
Update positioning/ASO	Product Plan	Release

Regeneration Commands

User can request partial regeneration:

"Regenerate the Implementation Guide" → Invoke implementation-guide skill
"Update all specs based on new PRD" → Check each downstream spec for consistency
"Refresh the Test Spec" → Invoke test-spec skill

Consistency Checking

When updating specs, check for:

1. Feature alignment: All PRD features appear in Architecture models
2. Screen coverage: All UX screens have Implementation Guide pseudo-code
3. Test coverage: All PRD acceptance criteria have Test Spec test cases
4. Terminology: Same feature names used across all documents

Best Practices for Updates

1. Start upstream: Change PRD first, then downstream specs
2. One change at a time: Avoid massive updates that are hard to review
3. Review consistency: After update, scan related specs for mismatches
4. Document changes: Note changes in document version history
5. Ask for confirmation: Before major regeneration, confirm with user

---

Integration with Workflow

This orchestrator is typically:

• Activated after the product-agent skill completes
• User reviews product development plan
• User decides to proceed to detailed specifications
• This skill generates all 7 specification documents
• User then has complete package ready for implementation

---

Notes

• This is the most complex skill - it coordinates 6 other skills
• User decision gates are critical - don't skip them
• Each phase builds on previous ones - order matters
• Error handling is important - phases can fail
• Iteration is expected - users will request changes
• The final summary is crucial - help user understand what they have
• Encourage next steps - don't leave user hanging
• This transforms product plan into actionable specifications
• Estimated 10-15 minutes of user review time (total for all phases)
• Estimated 15,000-20,000 lines of total documentation generated