
Product Development
Turn an approved PRD into a concrete iOS or macOS technical architecture document before you start coding.
Overview
Product-development is an agent skill most often used in Validate (also Build docs and pm) that generates an iOS/macOS technical architecture specification from an approved PRD.
Install
npx skills add https://github.com/rshankras/claude-code-apple-skills --skill product-developmentWhat is this skill?
- Generates ARCHITECTURE.md from docs/PRD.md with architecture pattern, tech stack, data models, and app structure
- Opinionated Apple-platform decisions aligned with iOS/macOS best practices
- Gated on approved PRD and clear MVP scope from product-agent or PRD
- Uses Read, Write, Glob, Grep, and AskUserQuestion—no shell or network in allowed-tools
- Activates on phrases like generate architecture, create ARCHITECTURE.md, or design technical architecture
- Skill version 1.0.0 (architecture-spec metadata)
- Covers architecture pattern, tech stack, data models, and app structure
- Hard prerequisite: docs/PRD.md reviewed and approved
Adoption & trust: 1 installs on skills.sh; 396 GitHub stars; 2/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You have an approved PRD but no shared technical architecture, stack choices, or data model plan for your Apple app.
Who is it for?
Solo builders shipping iOS or macOS apps who maintain docs/PRD.md and want ARCHITECTURE.md before coding.
Skip if: Teams without a PRD, web-only products, or builders who only need quick spikes without documented architecture.
When should I use this skill?
User says generate architecture, create technical spec, write architecture document, generate architecture spec, design technical architecture, or create ARCHITECTURE.md.
What do I get? / Deliverables
You get ARCHITECTURE.md and aligned technical decisions so implementation can start without re-debating stack and structure in ad-hoc chat.
- ARCHITECTURE.md (or equivalent architecture specification under docs/)
- Documented tech stack and architecture pattern choices
- Data models and app structure outline derived from the PRD
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Architecture spec sits after PRD sign-off and before implementation—it locks MVP technical scope, which is the last major scoping step in Validate before Build. Subphase scope covers how the product will be built (patterns, stack, data model), not writing UI code yet.
Where it fits
After PRD sign-off, generate ARCHITECTURE.md so MVP technical boundaries match the product spec.
Refresh architecture docs when PRD features change mid-build so agents do not drift from the agreed stack.
Hand contractors a single architecture file alongside the PRD before sprint planning.
How it compares
Use instead of vague stack brainstorming in chat when you need a PRD-linked architecture file in the repo.
Common Questions / FAQ
Who is product-development for?
Solo and indie developers building iOS or macOS apps with Claude Code-style agents who already use or plan to use docs/PRD.md and want a formal architecture step.
When should I use product-development?
In Validate scope after PRD approval to nail technical scope; in Build docs or pm when you need ARCHITECTURE.md for agents and contractors; before scaffolding Swift/SwiftUI projects when MVP boundaries are already clear.
Is product-development safe to install?
Allowed-tools are limited to read/write and search in the workspace plus AskUserQuestion—review the Security Audits panel on this Prism page before enabling the skill in production repos.
SKILL.md
READMESKILL.md - Product Development
# Architecture Spec Skill Generate technical architecture specification for iOS/macOS app. ## Metadata - **Name**: architecture-spec - **Version**: 1.0.0 - **Role**: iOS/macOS Architect - **Author**: ProductAgent Team ## When This Skill Activates This skill activates when the user says: - "generate architecture" - "create technical spec" - "write architecture document" - "generate architecture spec" - "design technical architecture" - "create ARCHITECTURE.md" ## Description You are an iOS/macOS Architect AI agent specializing in Apple platform app architecture. Your job is to design a comprehensive technical architecture based on the Product Requirements Document (PRD) and make opinionated technology stack decisions following Apple best practices. ## Prerequisites Before activating this skill, ensure: 1. PRD exists at `docs/PRD.md` 2. User has reviewed and approved the PRD 3. MVP scope is clear (from product-agent output or PRD) ## Input Sources Read and extract information from: 1. **docs/PRD.md** - Core features and their complexity - Non-functional requirements - Data model hints - Platform requirements - Technical considerations 2. **Product development plan** (if available) - MVP scope with technical requirements - Third-party dependencies mentioned - Platform and timeline constraints 3. **User preferences** (ask if needed): - SwiftUI vs UIKit preference - Third-party library preferences - Architecture pattern preference (if strong opinion) - Backend API availability (determines data strategy) ## Output Generate `docs/ARCHITECTURE.md` with the following structure: ```markdown # Technical Architecture: [App Name] **Version**: 1.0.0 **Last Updated**: [Date] **Status**: Draft / In Review / Approved **Owner**: Technical Architect **Platform**: iOS [version]+ / macOS [version]+ --- ## 1. Architecture Overview ### 1.1 Architecture Pattern **Selected Pattern**: MVVM (Model-View-ViewModel) with SwiftUI *or* Clean Architecture *or* TCA (The Composable Architecture) **Reasoning**: [Explain why this pattern was chosen based on app complexity] **Characteristics**: - **Layers**: [Describe the architectural layers] - **Data Flow**: [Unidirectional / Bidirectional] - **State Management**: [@Observable, Combine, TCA Store, etc.] - **Testability**: [How architecture supports testing] ### 1.2 High-Level Component Diagram ``` ┌─────────────────────────────────────────────────┐ │ Presentation Layer │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Views │ │ViewModels│ │ Models │ │ │ │ (SwiftUI)│←→│(@Observ.)│←→│ (Data) │ │ │ └──────────┘ └──────────┘ └──────────┘ │ └────────────────────┬────────────────────────────┘ │ ┌────────────────────┴────────────────────────────┐ │ Business Logic Layer │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Services │ │ Use │ │Repository│ │ │ │ │ │ Cases │ │ Pattern │ │ │ └──────────┘ └──────────┘ └──────────┘ │ └────────────────────┬────────────────────────────┘ │ ┌────────────────────┴────────────────────────────┐ │ Data Layer │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │SwiftData │ │ Network │ │ Keychain │ │ │ │ / Core │ │ Client │ │ Storage │ │ │ │ Data │ │ (URLSess)│ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ │ └─────────────────────────────────────────────────┘ ``` ### 1.3 Key Architectural Decisions | Decision | Choice | Alternative Considered | Rationale | |----------|-------