artsmc 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:
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:
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"
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"
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
WebFetchto read top 2-3 articles - Extract: common patterns, recommended technologies, pitfalls to avoid
Save research notes:
Write to: /job-queue/product-{name}/research-notes/stage1-research.md
Step 1.4: Generate big-idea.md
Content structure:
# 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:
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
{
"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:
Research rendering strategies for the chosen tech stack
Use WebSearch for:
- "[technology] rendering strategies 2026"
- "SSR vs CSR vs SSG comparison 2026"
- "[technology] streaming rendering 2026"
- "[technology] caching strategies 2026"
Use WebFetch for framework-specific rendering docs
Ask user clarifying questions
QUESTIONS TO ASK USER:
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"
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"
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
<Layout>
<Header />
<Main>
<DataGrid data={...} />
</Main>
<Footer />
</Layout>
Caching & Persistence
Caching Layers
- CDN caching: [CloudFlare, CloudFront]
- Server caching: [Redis, in-memory]
- Client caching: [Service worker, browser cache]
Cache Invalidation
[How caches are invalidated when data changes]
Persistence Strategy
[How outputs are stored: database, file system, object storage]
Performance Optimization
Bundle Optimization
- Code splitting
- Tree shaking
- Lazy loading
Image Optimization
- Responsive images
- Format selection (WebP, AVIF)
- CDN delivery
Data Fetching
- Parallel fetching
- Request deduplication
- Prefetching strategies
Technology Comparison
Evaluated Rendering Approaches
| Approach | SEO | Performance | Complexity | Chosen |
|---|---|---|---|---|
| SSR | ✅ | Medium | Medium | ✅ |
| CSR | ❌ | Slow | Low | ❌ |
| SSG | ✅ | Fast | Low | ✅ |
Implementation Considerations
Development Experience
[Hot reload, dev server, debugging]
Testing Strategy
[Component tests, visual regression, E2E]
Monitoring
[Performance metrics, Core Web Vitals]
Research Sources
[URLs consulted]
Write to: /job-queue/product-{name}/output-rendering.md Research notes: /job-queue/product-{name}/research-notes/output-research.md
### Parallel Execution
**Launch all 4 agents at once:**
```bash
# Agent 1: Runtime Execution
delegation workflow:
subagent_type: "general-purpose"
description: "Runtime execution research"
prompt: [Stage 2 agent task]
# Agent 2: Abstraction Layer
delegation workflow:
subagent_type: "general-purpose"
description: "Abstraction layer research"
prompt: [Stage 3 agent task]
# Agent 3: Integration Layer
delegation workflow:
subagent_type: "general-purpose"
description: "Integration layer research"
prompt: [Stage 4 agent task]
# Agent 4: Output Rendering
delegation workflow:
subagent_type: "general-purpose"
description: "Output rendering research"
prompt: [Stage 5 agent task]
Wait for all agents to complete.
Output:
- Display: "✅ Stage 2/6: Runtime execution research complete"
- Display: "✅ Stage 3/6: Abstraction layer research complete"
- Display: "✅ Stage 4/6: Integration layer research complete"
- Display: "✅ Stage 5/6: Output rendering research complete"
Stage 6: Final Review & Presentation
Goal: Present all generated documents to the user for review and approval.
Step 6.1: Read All Generated Documents
Read:
- /job-queue/product-{name}/big-idea.md
- /job-queue/product-{name}/runtime-execution.md
- /job-queue/product-{name}/abstraction-layer.md
- /job-queue/product-{name}/integration-layer.md
- /job-queue/product-{name}/output-rendering.md
Step 6.2: Generate Executive Summary
Create a final summary document:
File: /job-queue/product-{name}/ARCHITECTURE-SUMMARY.md
# Architecture Summary: [Product Name]
## Research Completion
**Date:** [timestamp]
**Input:** [original input]
**Product Name:** [derived name]
## Recommended Architecture
### Technology Stack
- **Frontend**: [chosen technology]
- **Backend**: [chosen technology]
- **Database**: [chosen technology]
- **Deployment**: [chosen platform]
### Architectural Style
- [Monolithic/Microservices/Serverless]
- [Event-driven/Request-response]
- [SSR/CSR/SSG]
### Key Design Decisions
#### Runtime Execution
[1-2 sentence summary from runtime-execution.md]
#### Abstraction Layer
[1-2 sentence summary from abstraction-layer.md]
#### Integration Layer
[1-2 sentence summary from integration-layer.md]
#### Output Rendering
[1-2 sentence summary from output-rendering.md]
## Trade-offs & Risks
### Major Trade-offs
1. [Trade-off 1]: Chose X over Y because [reason]
2. [Trade-off 2]: Chose X over Y because [reason]
### Identified Risks
1. [Risk 1]: [Mitigation strategy]
2. [Risk 2]: [Mitigation strategy]
## Next Steps
To proceed with implementation:
1. Review detailed architecture documents:
- `runtime-execution.md`
- `abstraction-layer.md`
- `integration-layer.md`
- `output-rendering.md`
2. Set up development environment
3. Create initial project structure
4. Begin implementation with chosen tech stack
## Research Artifacts
All research is saved in:
- `/job-queue/product-{name}/`
- `/job-queue/product-{name}/research-notes/`
Total research sources consulted: [count]
Step 6.3: Present to User
Display:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🎉 PRODUCT RESEARCH COMPLETE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Product: [Product Name]
Location: /job-queue/product-{name}/
Generated Documents:
✅ big-idea.md - High-level vision and approach
✅ runtime-execution.md - How the system executes work
✅ abstraction-layer.md - How user intent becomes logic
✅ integration-layer.md - How system connects externally
✅ output-rendering.md - How results are delivered
✅ ARCHITECTURE-SUMMARY.md - Executive summary
Recommended Stack:
Frontend: [technology]
Backend: [technology]
Database: [technology]
Deployment: [platform]
Research Sources: [count] URLs consulted
Next Steps:
1. Review detailed architecture docs in /job-queue/product-{name}/
2. Approve or request revisions
3. Begin implementation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Ask for feedback:
Use ask the user:
- Question: "Would you like to revise any architectural decisions?"
- Options:
- "Approve - looks good" - "Proceed with this architecture"
- "Revise runtime execution" - "Re-research execution model"
- "Revise abstraction layer" - "Re-research abstraction approach"
- "Revise integration layer" - "Re-research integrations"
- "Revise output rendering" - "Re-research rendering strategy"
If user approves:
- Display: "✅ Architecture approved! Ready for implementation."
If user requests revision:
- Re-run the specific stage's research agent with feedback
- Regenerate that document
- Re-present for approval
Error Handling
At any stage failure:
- Display which stage failed
- Show what was completed
- Provide recovery instructions
Example:
❌ Research Failed at Stage 3/6: Abstraction Layer
Completed:
✓ [Stage 0] Workspace created
✓ [Stage 1] Big idea generated
✓ [Stage 2] Runtime execution researched
✗ [Stage 3] Abstraction layer FAILED
Error: [error message]
Partial work saved at: /job-queue/product-{name}/
Recovery:
- Fix the issue and resume with: $new-product [input]
- Or manually continue research
Tools Used
- WebSearch - Technology research and comparisons
- WebFetch - Reading official documentation
- Task Tool - Parallel research agents
- ask the user - Iterative clarification
- Read/Write - Document generation
Expected Outcomes
After completion:
- ✅ Comprehensive architecture research
- ✅ 5 detailed architecture documents
- ✅ Technology stack recommendations
- ✅ Trade-offs and risks identified
- ✅ User approval obtained
- ✅ Ready for implementation
Notes
- Deep research: Use WebSearch + WebFetch extensively
- Parallel execution: Launch all 4 document agents at once
- Iterative questions: Ask questions during each stage, not all upfront
- Cross-referencing: Each agent reads big-idea.md for context
- Documentation quality: Comprehensive, well-structured, actionable
Total Expected Duration:
- Stage 0: ~10 seconds (folder creation)
- Stage 1: ~5-10 minutes (high-level research + big-idea.md)
- Stages 2-5: ~15-25 minutes (parallel deep research for 4 docs)
- Stage 6: ~2-3 minutes (summary generation + review)
Total: ~20-40 minutes (depending on research depth and user interaction speed)