# New Product > Deep research and architecture design for new product development. Use when Codex should run the converted new-product workflow. Inputs: input. - Skill: `artsmc/new-product` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add artsmc/new-product` - Raw SKILL.md: https://api.skillmd.com/api/skills/artsmc/new-product/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: artsmc (https://skillmd.com/u/artsmc) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/artsmc/new-product --- # New Product Converted Claude skill workflow for Codex/OpenAI use. ## Source Converted from `skills/new-product/SKILL.md`. ## Bundled Resources Supporting files copied from the Claude source: - `references/README.md` ## Converted Instructions The content below was adapted from the Claude source. Rewrite tool and runtime assumptions as needed when they refer to Claude-only features. # New Product - Deep Research & Architecture Design Given documentation or a product description, perform deep research and cross-reference technologies to determine the optimal architecture for building a new application. ## Your Task You are orchestrating a deep research workflow to design product architecture. Follow these stages in order, using parallel agents for deep research, and present a final comprehensive review at the end. --- ## Stage 0: Initialize Product Workspace **Parse input argument:** - If the input is a file path (contains `/` or ends in `.md`, `.txt`, etc.), read the documentation - If the input is plain text, treat it as a product description **Extract product name:** - From documentation: look for project title, product name - From description: derive a short kebab-case name (e.g., "real-time chat app" → "realtime-chat") **Create folder structure:** ```bash mkdir -p /job-queue/product-{name}/research-notes ``` **Output:** - Display: "🚀 Stage 0/6: Workspace created at /job-queue/product-{name}/" - Store the product name for use in later stages --- ## Stage 1: Big Idea & High-Level Research **Goal:** Generate a comprehensive high-level understanding of the product and initial technology landscape. ### Step 1.1: Analyze Input **If documentation provided:** - Read all provided files - Extract key concepts: features, user flows, requirements - Identify technical hints or constraints mentioned **If product description provided:** - Parse the description for: - Core functionality - Target users - Key features - Scale expectations ### Step 1.2: Ask Initial Clarifying Questions Use `ask the user` to gather essential context: **Questions to ask:** 1. **Product Vision** - Header: "Vision" - Question: "What is the primary goal of this product?" - Options: - "Solve a specific problem for users" - "Focus on targeted pain points" - "Innovate in an existing space" - "Bring new approach to established market" - "Integrate multiple services" - "Connect disparate systems" - "Explore new technology" - "Research/experimental project" 2. **Scale & Audience** - Header: "Scale" - Question: "What scale are you targeting?" - Options: - "Prototype/MVP (100s of users)" - "Proof of concept" - "Small-Medium (1,000s of users)" - "Early stage product" - "Medium-Large (100,000s of users)" - "Established product" - "Enterprise scale (1M+ users)" - "High-scale production" 3. **Deployment Context** - Header: "Deployment" - Question: "Where will this product run?" - Options: - "Cloud-hosted (AWS/GCP/Azure)" - "Managed infrastructure" - "Self-hosted/On-prem" - "Customer infrastructure" - "Edge/Distributed" - "CDN, edge compute" - "Hybrid" - "Mix of cloud and local" ### Step 1.3: High-Level Technology Research Use `WebSearch` to research broad technology landscape: **Search queries:** - "[product type] architecture patterns 2026" - "[product type] technology stack comparison 2026" - "[product type] best practices 2026" - "[scale level] architecture considerations 2026" **For each search result:** - Use `WebFetch` to read top 2-3 articles - Extract: common patterns, recommended technologies, pitfalls to avoid **Save research notes:** ```bash Write to: /job-queue/product-{name}/research-notes/stage1-research.md ``` ### Step 1.4: Generate big-idea.md **Content structure:** ```markdown # Big Idea: [Product Name] ## Product Overview [2-3 paragraphs describing what the product does, who it's for, and why it matters] ## Core Value Proposition [What makes this product unique or valuable] ## High-Level Architecture Approach [Based on research, what architectural style makes sense?] - Monolithic vs Microservices - Serverless vs Server-based - Event-driven vs Request-response - [Any other key architectural decisions] ## Technology Landscape [Summary of technology options researched] ### Frontend Options - Option 1: [technology] - [pros/cons] - Option 2: [technology] - [pros/cons] - Option 3: [technology] - [pros/cons] ### Backend Options - Option 1: [technology] - [pros/cons] - Option 2: [technology] - [pros/cons] - Option 3: [technology] - [pros/cons] ### Database Options - Option 1: [technology] - [pros/cons] - Option 2: [technology] - [pros/cons] ### Deployment Options - Option 1: [platform] - [pros/cons] - Option 2: [platform] - [pros/cons] ## Key Challenges Identified 1. [Challenge 1 and mitigation approach] 2. [Challenge 2 and mitigation approach] 3. [Challenge 3 and mitigation approach] ## Next Steps - Deep dive into runtime execution patterns - Research abstraction layer approaches - Evaluate integration strategies - Design output rendering pipeline ## Research Sources [List of URLs and documentation consulted] ``` **Save to:** ```bash Write to: /job-queue/product-{name}/big-idea.md ``` **Output:** - Display: "✅ Stage 1/6: Big idea generated at product-{name}/big-idea.md" --- ## Stage 2-5: Parallel Deep Research for Architectural Documents Launch **4 parallel research agents** using the `Task` tool with `skill="general-purpose"`. Each agent is assigned one architectural document and operates independently. ### Stage 2: Runtime Execution Research (Agent 1) **Agent task:** ``` You are researching runtime execution architecture for: [Product Name] CONTEXT: [Include big-idea.md content] YOUR GOAL: Create a comprehensive `runtime-execution.md` document that explains how the system executes work. RESEARCH APPROACH: 1. Based on the technology options in big-idea.md, research each option's runtime model 2. Use WebSearch to find: - "[technology] runtime architecture 2026" - "[technology] execution model 2026" - "[technology] process lifecycle 2026" - "[technology] concurrency model 2026" 3. Use WebFetch to read official documentation for top candidates 4. Ask user clarifying questions about runtime preferences using ask the user QUESTIONS TO ASK USER: 1. **Execution Model** - Header: "Execution" - Question: "How should the system execute work?" - Options: - "Request-response" - "Traditional HTTP request/response" - "Event-driven" - "Async processing with queues" - "Stream processing" - "Continuous data flow" - "Batch processing" - "Scheduled periodic jobs" 2. **Concurrency Needs** - Header: "Concurrency" - Question: "What concurrency model do you need?" - Options: - "Single-threaded async" - "Node.js style, high I/O" - "Multi-threaded" - "Python/Java threads, CPU work" - "Actor model" - "Erlang/Akka style isolation" - "Function-based" - "Serverless auto-scaling" 3. **State Management** - Header: "State" - Question: "How should runtime state be managed?" - Options: - "Stateless" - "No server-side state, scale easily" - "In-memory cache" - "Redis/Memcached for sessions" - "Persistent state" - "Database-backed state" - "Distributed state" - "Multi-node coordination" DOCUMENT STRUCTURE: Create: /job-queue/product-{name}/runtime-execution.md # Runtime Execution Architecture ## Executive Summary [2-3 paragraphs: What runtime model was chosen and why] ## Core Execution Engine ### Selected Technology - **Primary Runtime**: [chosen technology] - **Rationale**: [why this choice] - **Trade-offs**: [what we're giving up] ### Execution Paradigm [Describe: request-response, event-driven, streaming, batch] ## Process Lifecycle ### Initialization [How the system starts up, bootstraps, loads config] ### Request Handling [How incoming work is received and routed] ### Execution Flow [Step-by-step: what happens when work arrives] ### Teardown/Cleanup [How resources are released, graceful shutdown] ## State Management ### State Architecture [Where state lives: memory, cache, database] ### State Lifecycle [How state is created, updated, invalidated] ### State Consistency [How consistency is maintained across requests] ## Concurrency Model ### Concurrency Approach [Threads, async, actors, serverless] ### Parallelism Strategy [How work is distributed across cores/nodes] ### Synchronization [Locks, queues, coordination mechanisms] ## Hot-Reload & Dynamic Updates ### Development Experience [Hot reload during dev? How does it work?] ### Production Updates [Zero-downtime deploys? Blue-green? Rolling?] ## Resource Constraints & Optimization ### Memory Management [How memory is allocated, GC considerations] ### CPU Utilization [How CPU is used, optimization strategies] ### I/O Patterns [Network, disk, database access patterns] ### Scaling Strategy [Vertical vs horizontal, auto-scaling triggers] ## Technology Comparison ### Evaluated Options | Technology | Pros | Cons | Fit Score | |------------|------|------|-----------| | [Tech 1] | ... | ... | 8/10 | | [Tech 2] | ... | ... | 6/10 | | [Tech 3] | ... | ... | 4/10 | ### Decision Rationale [Why we chose what we chose] ## Implementation Considerations ### Development Setup [How to run locally] ### Testing Strategy [How to test runtime behavior] ### Monitoring Needs [What metrics to track] ## Research Sources [URLs consulted during research] --- After completing research and asking user questions, write this document to: /job-queue/product-{name}/runtime-execution.md Also save your raw research notes to: /job-queue/product-{name}/research-notes/runtime-research.md ``` ### Stage 3: Abstraction Layer Research (Agent 2) **Agent task:** ``` You are researching abstraction layer architecture for: [Product Name] CONTEXT: [Include big-idea.md content] YOUR GOAL: Create a comprehensive `abstraction-layer.md` document that explains how user intent translates to executable logic. RESEARCH APPROACH: 1. Research how modern frameworks handle abstraction 2. Use WebSearch for: - "[technology] abstraction patterns 2026" - "[technology] DSL design 2026" - "no-code/low-code architecture 2026" (if applicable) - "[technology] configuration vs code 2026" 3. Use WebFetch to read architectural docs 4. Ask user clarifying questions QUESTIONS TO ASK USER: 1. **Input Format** - Header: "Input" - Question: "How will users define what they want the system to do?" - Options: - "Code (APIs, SDKs)" - "Developer-focused, programmatic" - "Configuration (YAML, JSON)" - "Declarative configs" - "Visual interface (drag-drop)" - "No-code UI builder" - "Natural language" - "AI-powered interpretation" 2. **Translation Approach** - Header: "Translation" - Question: "How should user intent become executable code?" - Options: - "Direct interpretation" - "Runtime interpretation, flexible" - "Compilation to native" - "Compiled ahead-of-time, fast" - "IR/AST transformation" - "Intermediate representation" - "Template-based generation" - "Code generation from templates" 3. **Extensibility** - Header: "Extensibility" - Question: "How should users extend default behavior?" - Options: - "Plugin system" - "Loadable extensions" - "Hooks/callbacks" - "Event-based extension points" - "Subclassing/inheritance" - "OOP-style extension" - "Middleware/interceptors" - "Pipeline-based modification" DOCUMENT STRUCTURE: Create: /job-queue/product-{name}/abstraction-layer.md # Abstraction Layer Architecture ## Executive Summary [How user intent becomes executable logic] ## Input Formats ### Primary Input Method [Code, config, visual, NLP] ### Input Schema [Structure of input: JSON schema, API surface, grammar] ### Validation & Parsing [How inputs are validated and parsed] ## Intermediate Representation ### IR Design [AST, JSON schema, custom IR - what does it look like?] ### Why This IR [Rationale for chosen representation] ### Example Transformation [Show: input → IR → output] ## Translation Mechanisms ### Chosen Approach [Interpretation vs compilation vs generation] ### Translation Pipeline [Step-by-step: input → IR → executable] ### Optimization Passes [Any optimization during translation?] ## Mapping Tables ### UI/Config → System Primitives [How high-level concepts map to low-level operations] ### Example Mappings | User Concept | System Primitive | Implementation | |--------------|------------------|----------------| | [Concept 1] | [Primitive 1] | [How it works] | ## Extension Points ### Extension Architecture [Plugin system, hooks, inheritance] ### Extension Registration [How extensions are discovered and loaded] ### Extension API [What APIs are exposed to extensions] ### Example Extension [Code sample showing how to extend] ## Trade-offs Analysis ### Flexibility vs Performance [What we optimized for] ### Simplicity vs Power [Where we drew the line] ### Developer Experience [How easy is it to use?] ## Technology Comparison ### Evaluated Approaches | Approach | Flexibility | Performance | DX | Chosen | |----------------|-------------|-------------|-----|--------| | [Approach 1] | High | Medium | Low | ❌ | | [Approach 2] | Medium | High | High| ✅ | ## Implementation Considerations ### Schema Evolution [How to version the abstraction layer] ### Backward Compatibility [How to handle breaking changes] ### Documentation Strategy [How users learn the abstraction] ## Research Sources [URLs consulted] --- Write to: /job-queue/product-{name}/abstraction-layer.md Research notes: /job-queue/product-{name}/research-notes/abstraction-research.md ``` ### Stage 4: Integration Layer Research (Agent 3) **Agent task:** ``` You are researching integration layer architecture for: [Product Name] CONTEXT: [Include big-idea.md content] YOUR GOAL: Create a comprehensive `integration-layer.md` document that explains how the system connects to external resources. RESEARCH APPROACH: 1. Research connector patterns and integration architectures 2. Use WebSearch for: - "[technology] connector architecture 2026" - "API integration best practices 2026" - "[technology] authentication patterns 2026" - "service mesh architecture 2026" (if microservices) 3. Use WebFetch for vendor-specific docs (if integrating with known services) 4. Ask user clarifying questions QUESTIONS TO ASK USER: 1. **Integration Scope** - Header: "Integrations" - Question: "What external systems will this product integrate with?" - MultiSelect: true - Options: - "Databases" - "PostgreSQL, MySQL, MongoDB, etc." - "APIs (REST/GraphQL)" - "External HTTP APIs" - "Message queues" - "RabbitMQ, Kafka, SQS, etc." - "Storage services" - "S3, GCS, Azure Storage" 2. **Authentication Strategy** - Header: "Auth" - Question: "How should the system authenticate to external services?" - Options: - "API keys" - "Simple token-based auth" - "OAuth 2.0" - "Delegated authorization" - "Mutual TLS" - "Certificate-based auth" - "Service accounts" - "Cloud provider IAM" 3. **Discovery Mechanism** - Header: "Discovery" - Question: "How should the system discover external services?" - Options: - "Static configuration" - "Hardcoded endpoints" - "Environment variables" - "Deploy-time config" - "Service discovery" - "Consul, Eureka, k8s DNS" - "Dynamic registry" - "Runtime service registration" DOCUMENT STRUCTURE: Create: /job-queue/product-{name}/integration-layer.md # Integration Layer Architecture ## Executive Summary [How the system connects to external resources] ## Connector Architecture ### Connector Pattern [Plugin-based, driver-based, adapter pattern] ### Supported Protocols - REST API - GraphQL - gRPC - Message queues - Database protocols - Custom protocols ### Connector Lifecycle [How connectors are initialized, used, closed] ## Authentication & Credential Management ### Authentication Methods [API keys, OAuth, mTLS, service accounts] ### Credential Storage [Where credentials live: env vars, secrets manager, vault] ### Rotation Strategy [How credentials are rotated without downtime] ### Security Boundaries [How credentials are isolated per service] ## Service Discovery ### Discovery Mechanism [Static, env-based, service discovery, dynamic] ### Configuration Format ```json { "services": { "database": { "type": "postgresql", "discovery": "static", "endpoint": "..." } } } ``` ### Health Checking [How to detect unhealthy services] ## Data Flow Patterns ### Pull Pattern [Request-response, polling] ### Push Pattern [Webhooks, callbacks] ### Streaming Pattern [WebSockets, SSE, gRPC streams] ### Chosen Approach per Integration | Integration | Pattern | Rationale | |-------------|---------|-----------| | [Service 1] | Pull | [Why] | | [Service 2] | Stream | [Why] | ## Error Handling & Retry Logic ### Error Classification - Transient errors (retry) - Permanent errors (fail fast) - Rate limit errors (backoff) ### Retry Strategy - Exponential backoff - Circuit breaker pattern - Fallback mechanisms ### Example: Retry Configuration ```json { "retry": { "maxAttempts": 3, "backoff": "exponential", "initialDelay": "100ms" } } ``` ## Security & Isolation ### Network Segmentation [How integrations are network-isolated] ### Data Encryption [TLS for transit, encryption at rest] ### Least Privilege [IAM policies, scoped credentials] ## Technology Comparison ### Evaluated Integration Patterns | Pattern | Complexity | Reliability | Chosen | |-------------------|------------|-------------|--------| | Direct API calls | Low | Medium | ✅ | | Message queue | Medium | High | ❌ | | Service mesh | High | High | ❌ | ## Implementation Considerations ### Local Development [How to run external dependencies locally] ### Testing Strategy [Mocking, test containers, integration tests] ### Monitoring & Observability [Metrics, logs, traces for integrations] ## Research Sources [URLs consulted] --- Write to: /job-queue/product-{name}/integration-layer.md Research notes: /job-queue/product-{name}/research-notes/integration-research.md ``` ### Stage 5: Output Rendering Research (Agent 4) **Agent task:** ``` You are researching output rendering architecture for: [Product Name] CONTEXT: [Include big-idea.md content] YOUR GOAL: Create a comprehensive `output-rendering.md` document that explains how results are delivered to consumers. RESEARCH APPROACH: 1. Research rendering strategies for the chosen tech stack 2. Use WebSearch for: - "[technology] rendering strategies 2026" - "SSR vs CSR vs SSG comparison 2026" - "[technology] streaming rendering 2026" - "[technology] caching strategies 2026" 3. Use WebFetch for framework-specific rendering docs 4. Ask user clarifying questions QUESTIONS TO ASK USER: 1. **Rendering Strategy** - Header: "Rendering" - Question: "How should content be rendered?" - Options: - "Server-side (SSR)" - "Render on server, send HTML" - "Client-side (CSR)" - "Render in browser with JS" - "Static generation (SSG)" - "Pre-render at build time" - "Hybrid" - "Mix of SSR/CSR/SSG per route" 2. **Real-time Requirements** - Header: "Real-time" - Question: "Do outputs need real-time updates?" - Options: - "No real-time needed" - "Traditional request-response" - "Polling" - "Client polls for updates" - "WebSockets" - "Bidirectional real-time" - "Server-sent events (SSE)" - "Unidirectional streaming" 3. **Output Formats** - Header: "Formats" - Question: "What output formats do you need?" - MultiSelect: true - Options: - "HTML" - "Web pages" - "JSON/XML" - "API responses" - "Binary (images, PDFs)" - "Generated files" - "Streams" - "Continuous data streams" DOCUMENT STRUCTURE: Create: /job-queue/product-{name}/output-rendering.md # Output Rendering Architecture ## Executive Summary [How results are delivered to consumers] ## Output Formats ### Supported Formats - HTML (web UI) - JSON (API responses) - Binary (files, images) - Streams (continuous data) ### Serialization Strategy [How data is serialized for each format] ### Content Negotiation [How clients request specific formats] ## Rendering Pipeline ### Chosen Rendering Strategy [SSR, CSR, SSG, hybrid] ### Rendering Flow [Step-by-step: data → rendered output] ### Server-Side Rendering (if applicable) - Template engine: [e.g., React Server Components, Jinja2] - Hydration strategy - Performance characteristics ### Client-Side Rendering (if applicable) - JavaScript framework: [React, Vue, Svelte] - Bundle strategy - Initial load performance ### Static Generation (if applicable) - Build-time generation - Incremental static regeneration (ISR) - When to use vs SSR ## Streaming & Real-Time Updates ### Real-Time Strategy [None, polling, WebSockets, SSE] ### Streaming Architecture [How data streams to client] ### Example: Real-Time Flow ``` 1. Client subscribes to updates 2. Server pushes incremental changes 3. Client updates UI reactively ``` ## Template/Component System ### Component Architecture [How UI is composed: components, templates, views] ### Component Library [Design system, reusable components] ### Composition Patterns [How components are nested and composed] ### Example Component Structure ```