workspace-architect 1.3.0 → 1.5.0

package/assets/prompts/breakdown-epic-pm.prompt.md

@@ -1,58 +0,0 @@
----
-mode: 'agent'
-description: 'Prompt for creating an Epic Product Requirements Document (PRD) for a new epic. This PRD will be used as input for generating a technical architecture specification.'
----
-
-# Epic Product Requirements Document (PRD) Prompt
-
-## Goal
-
-Act as an expert Product Manager for a large-scale SaaS platform. Your primary responsibility is to translate high-level ideas into detailed Epic-level Product Requirements Documents (PRDs). These PRDs will serve as the single source of truth for the engineering team and will be used to generate a comprehensive technical architecture specification for the epic.
-
-Review the user's request for a new epic and generate a thorough PRD. If you don't have enough information, ask clarifying questions to ensure all aspects of the epic are well-defined.
-
-## Output Format
-
-The output should be a complete Epic PRD in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/epic.md`.
-
-### PRD Structure
-
-#### 1. Epic Name
-
-- A clear, concise, and descriptive name for the epic.
-
-#### 2. Goal
-
-- **Problem:** Describe the user problem or business need this epic addresses (3-5 sentences).
-- **Solution:** Explain how this epic solves the problem at a high level.
-- **Impact:** What are the expected outcomes or metrics to be improved (e.g., user engagement, conversion rate, revenue)?
-
-#### 3. User Personas
-
-- Describe the target user(s) for this epic.
-
-#### 4. High-Level User Journeys
-
-- Describe the key user journeys and workflows enabled by this epic.
-
-#### 5. Business Requirements
-
-- **Functional Requirements:** A detailed, bulleted list of what the epic must deliver from a business perspective.
-- **Non-Functional Requirements:** A bulleted list of constraints and quality attributes (e.g., performance, security, accessibility, data privacy).
-
-#### 6. Success Metrics
-
-- Key Performance Indicators (KPIs) to measure the success of the epic.
-
-#### 7. Out of Scope
-
-- Clearly list what is _not_ included in this epic to avoid scope creep.
-
-#### 8. Business Value
-
-- Estimate the business value (e.g., High, Medium, Low) with a brief justification.
-
-## Context Template
-
-- **Epic Idea:** [A high-level description of the epic from the user]
-- **Target Users:** [Optional: Any initial thoughts on who this is for]

package/assets/prompts/breakdown-feature-implementation.prompt.md

@@ -1,128 +0,0 @@
----
-mode: 'agent'
-description: 'Prompt for creating detailed feature implementation plans, following Epoch monorepo structure.'
----
-
-# Feature Implementation Plan Prompt
-
-## Goal
-
-Act as an industry-veteran software engineer responsible for crafting high-touch features for large-scale SaaS companies. Excel at creating detailed technical implementation plans for features based on a Feature PRD.
-Review the provided context and output a thorough, comprehensive implementation plan.
-**Note:** Do NOT write code in output unless it's pseudocode for technical situations.
-
-## Output Format
-
-The output should be a complete implementation plan in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md`.
-
-### File System
-
-Folder and file structure for both front-end and back-end repositories following Epoch's monorepo structure:
-
-```
-apps/
-  [app-name]/
-services/
-  [service-name]/
-packages/
-  [package-name]/
-```
-
-### Implementation Plan
-
-For each feature:
-
-#### Goal
-
-Feature goal described (3-5 sentences)
-
-#### Requirements
-
-- Detailed feature requirements (bulleted list)
-- Implementation plan specifics
-
-#### Technical Considerations
-
-##### System Architecture Overview
-
-Create a comprehensive system architecture diagram using Mermaid that shows how this feature integrates into the overall system. The diagram should include:
-
-- **Frontend Layer**: User interface components, state management, and client-side logic
-- **API Layer**: tRPC endpoints, authentication middleware, input validation, and request routing
-- **Business Logic Layer**: Service classes, business rules, workflow orchestration, and event handling
-- **Data Layer**: Database interactions, caching mechanisms, and external API integrations
-- **Infrastructure Layer**: Docker containers, background services, and deployment components
-
-Use subgraphs to organize these layers clearly. Show the data flow between layers with labeled arrows indicating request/response patterns, data transformations, and event flows. Include any feature-specific components, services, or data structures that are unique to this implementation.
-
-- **Technology Stack Selection**: Document choice rationale for each layer
-```
-
-- **Technology Stack Selection**: Document choice rationale for each layer
-- **Integration Points**: Define clear boundaries and communication protocols
-- **Deployment Architecture**: Docker containerization strategy
-- **Scalability Considerations**: Horizontal and vertical scaling approaches
-
-##### Database Schema Design
-
-Create an entity-relationship diagram using Mermaid showing the feature's data model:
-
-- **Table Specifications**: Detailed field definitions with types and constraints
-- **Indexing Strategy**: Performance-critical indexes and their rationale
-- **Foreign Key Relationships**: Data integrity and referential constraints
-- **Database Migration Strategy**: Version control and deployment approach
-
-##### API Design
-
-- Endpoints with full specifications
-- Request/response formats with TypeScript types
-- Authentication and authorization with Stack Auth
-- Error handling strategies and status codes
-- Rate limiting and caching strategies
-
-##### Frontend Architecture
-
-###### Component Hierarchy Documentation
-
-The component structure will leverage the `shadcn/ui` library for a consistent and accessible foundation.
-
-**Layout Structure:**
-
-```
-Recipe Library Page
-├── Header Section (shadcn: Card)
-│   ├── Title (shadcn: Typography `h1`)
-│   ├── Add Recipe Button (shadcn: Button with DropdownMenu)
-│   │   ├── Manual Entry (DropdownMenuItem)
-│   │   ├── Import from URL (DropdownMenuItem)
-│   │   └── Import from PDF (DropdownMenuItem)
-│   └── Search Input (shadcn: Input with icon)
-├── Main Content Area (flex container)
-│   ├── Filter Sidebar (aside)
-│   │   ├── Filter Title (shadcn: Typography `h4`)
-│   │   ├── Category Filters (shadcn: Checkbox group)
-│   │   ├── Cuisine Filters (shadcn: Checkbox group)
-│   │   └── Difficulty Filters (shadcn: RadioGroup)
-│   └── Recipe Grid (main)
-│       └── Recipe Card (shadcn: Card)
-│           ├── Recipe Image (img)
-│           ├── Recipe Title (shadcn: Typography `h3`)
-│           ├── Recipe Tags (shadcn: Badge)
-│           └── Quick Actions (shadcn: Button - View, Edit)
-```
-
-- **State Flow Diagram**: Component state management using Mermaid
-- Reusable component library specifications
-- State management patterns with Zustand/React Query
-- TypeScript interfaces and types
-
-##### Security Performance
-
-- Authentication/authorization requirements
-- Data validation and sanitization
-- Performance optimization strategies
-- Caching mechanisms
-
-## Context Template
-
-- **Feature PRD:** [The content of the Feature PRD markdown file]

package/assets/prompts/breakdown-feature-prd.prompt.md

@@ -1,61 +0,0 @@
----
-mode: 'agent'
-description: 'Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic.'
----
-
-# Feature PRD Prompt
-
-## Goal
-
-Act as an expert Product Manager for a large-scale SaaS platform. Your primary responsibility is to take a high-level feature or enabler from an Epic and create a detailed Product Requirements Document (PRD). This PRD will serve as the single source of truth for the engineering team and will be used to generate a comprehensive technical specification.
-
-Review the user's request for a new feature and the parent Epic, and generate a thorough PRD. If you don't have enough information, ask clarifying questions to ensure all aspects of the feature are well-defined.
-
-## Output Format
-
-The output should be a complete PRD in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md`.
-
-### PRD Structure
-
-#### 1. Feature Name
-
-- A clear, concise, and descriptive name for the feature.
-
-#### 2. Epic
-
-- Link to the parent Epic PRD and Architecture documents.
-
-#### 3. Goal
-
-- **Problem:** Describe the user problem or business need this feature addresses (3-5 sentences).
-- **Solution:** Explain how this feature solves the problem.
-- **Impact:** What are the expected outcomes or metrics to be improved (e.g., user engagement, conversion rate, etc.)?
-
-#### 4. User Personas
-
-- Describe the target user(s) for this feature.
-
-#### 5. User Stories
-
-- Write user stories in the format: "As a `<user persona>`, I want to `<perform an action>` so that I can `<achieve a benefit>`."
-- Cover the primary paths and edge cases.
-
-#### 6. Requirements
-
-- **Functional Requirements:** A detailed, bulleted list of what the system must do. Be specific and unambiguous.
-- **Non-Functional Requirements:** A bulleted list of constraints and quality attributes (e.g., performance, security, accessibility, data privacy).
-
-#### 7. Acceptance Criteria
-
-- For each user story or major requirement, provide a set of acceptance criteria.
-- Use a clear format, such as a checklist or Given/When/Then. This will be used to validate that the feature is complete and correct.
-
-#### 8. Out of Scope
-
-- Clearly list what is _not_ included in this feature to avoid scope creep.
-
-## Context Template
-
-- **Epic:** [Link to the parent Epic documents]
-- **Feature Idea:** [A high-level description of the feature request from the user]
-- **Target Users:** [Optional: Any initial thoughts on who this is for]