Include the conversation link for memory items.

.github/prompts/design_system.prompt.md

@@ -0,0 +1,199 @@
+---
+mode: agent
+---
+# Design System
+
+For the feature or bug in question, create a design document using the template below.
+
+Save the design using incrementing numbers like the following: memory/design/001_some_feature.md
+
+# [Feature/Component Name] Design Document
+
+## Metadata
+- **Status:** [Draft | In Review | Approved | Implemented]
+- **Author(s):** 
+- **Reviewers:** 
+- **Created:** 
+- **Updated:** 
+- **Implementation PR(s):** 
+
+## Overview
+<!-- What problem are we solving and why now? (2-3 paragraphs max) -->
+
+## Goals
+
+## Proposed Solution
+
+### High-Level Approach
+<!-- 2-3 paragraphs explaining the core solution -->
+
+### Key Components
+<!-- Major pieces and how they fit together -->
+- **Component A:** 
+- **Component B:** 
+- **Component C:** 
+
+### Simple Architecture Diagram
+<!-- Boxes and arrows diagram showing data flow and component interaction -->
+```
+[Diagram here - can be ASCII, Mermaid, or embedded image]
+```
+
+## Design Considerations
+
+### 1. [Design Choice Name]
+**Context:** <!-- Why this decision matters -->
+
+**Options:**
+- **Option A:** 
+  - Pros: 
+  - Cons: 
+- **Option B:** 
+  - Pros: 
+  - Cons: 
+- **Option C:** 
+  - Pros: 
+  - Cons: 
+
+**Recommendation:** <!-- What we're choosing and why -->
+
+### 2. [Design Choice Name]
+**Context:** 
+
+**Options:**
+- **Option A:** 
+  - Pros: 
+  - Cons: 
+- **Option B:** 
+  - Pros: 
+  - Cons: 
+
+**Recommendation:** 
+
+## Lifecycle of Code for Key Use Case
+<!-- Step-by-step flow of how the system handles the main use case -->
+
+1. **User initiates action:** 
+2. **System validates:** 
+3. **Processing step:** 
+4. **Data persistence:** 
+5. **Response to user:** 
+6. **Post-processing (if any):** 
+
+### Error Scenarios
+- **If validation fails:** 
+- **If external service is down:** 
+- **If database write fails:** 
+
+## Detailed Design
+
+### Schema Updates
+```sql
+-- Example table or schema changes
+CREATE TABLE example (
+    id UUID PRIMARY KEY,
+    created_at TIMESTAMP NOT NULL,
+    ...
+);
+```
+
+### API Endpoints
+
+#### `POST /api/v1/[endpoint]`
+**Request:**
+```json
+{
+  "field1": "value",
+  "field2": 123
+}
+```
+
+**Response (200 OK):**
+```json
+{
+  "id": "uuid",
+  "status": "success",
+  "data": {}
+}
+```
+
+**Error Response (4xx/5xx):**
+```json
+{
+  "error": "error_code",
+  "message": "Human readable message"
+}
+```
+
+#### `GET /api/v1/[endpoint]/{id}`
+**Response (200 OK):**
+```json
+{
+  "id": "uuid",
+  "field1": "value",
+  "field2": 123
+}
+```
+
+### UI Changes
+<!-- Screenshots, mockups, or description of UI changes -->
+- **Screen/Component:** 
+- **User flow:** 
+- **Key interactions:** 
+
+### Services / Business Logic
+
+#### Service A
+```python
+# Pseudocode or key algorithm
+def process_request(input):
+    # Validate
+    # Transform
+    # Persist
+    # Return
+```
+
+#### Service B
+<!-- Key business logic or processing steps -->
+
+### Data Migration Plan
+<!-- If applicable - how do we migrate existing data? -->
+- **Migration strategy:** 
+- **Rollback plan:** 
+- **Estimated data volume:** 
+
+## Risks & Mitigations
+
+| Risk | Impact | Likelihood | Mitigation |
+|------|--------|------------|------------|
+| [Risk description] | High/Med/Low | High/Med/Low | [How we prevent/handle it] |
+| | | | |
+
+### Technical Debt
+<!-- What shortcuts are we taking that we'll need to address later? -->
+- 
+
+## Rollout Plan
+
+### Deployment Strategy
+- [ ] Feature flag implementation
+- [ ] Canary deployment percentage: 
+- [ ] Full rollout criteria: 
+
+### Rollback Plan
+<!-- How do we undo this if something goes wrong? -->
+
+### Monitoring & Alerts
+<!-- What metrics/logs will we watch? -->
+- **Key metrics:** 
+- **Alert thresholds:** 
+- **Dashboards:** 
+
+## Open Questions
+
+
+
+## References
+- [Link to related documents]
+- [Link to previous ADRs this supersedes or relates to]
+- [Link to external resources]

.github/prompts/evaluate_me.prompt.md

@@ -0,0 +1,8 @@
+---
+mode: agent
+---
+# Implement
+
+For the indicated milestone, ask any clarifying questions. If relevant, review different implementation choices with pros and cons.
+
+Implement the milestone, and be clear with that I need to check in the final integration tests. Where possible, write temporary scripts to test the milestone.

.github/prompts/explore_use_cases.prompt.md

@@ -0,0 +1,9 @@
+---
+mode: agent
+---
+I am a new developer onboarding onto this codebase. I want to explore it through its primary use cases first. Explore this repository and identify the most common, essential, and core use cases.
+
+- Create a section that has an ordered list of use cases
+- Create a section with some typical user journeys
+
+Write to memory/system/use_cases.md

.github/prompts/implement.prompt.md

@@ -0,0 +1,8 @@
+---
+mode: agent
+---
+# Implement
+
+For the indicated milestone, ask any clarifying questions. If relevant, review different implementation choices with pros and cons.
+
+Implement the milestone, and be clear with that I need to check in the final integration tests. Where possible, write temporary scripts to test the milestone.

.github/prompts/lifecycle.prompt.md

@@ -0,0 +1,27 @@
+---
+mode: agent
+---
+# Trace the lifecycle of a use case
+
+I’m a junior developer onboarding onto a new codebase, and I think the best way to ramp up is to follow the lifecycle of a use case. Generate a cheatsheet of the lifecycle, using the guidelines below.
+
+Structure:
+- Title with use case name and user story
+- Layer 1: Simple Mermaid flowchart showing user journey (6-8 steps max)
+- Layer 2: Mermaid component architecture diagram showing UI/State/Service/External layers with data flow arrows, plus a table mapping each component to its actual implementation (function/class name, file:line)
+- Layer 3: Mermaid sequence diagram showing the detailed interaction flow, followed by 2-3 key design patterns used
+- Data Structures: TypeScript interfaces/types with inline comments
+- Quick Reference: Bullet points of practical info (event triggers, formats, error handling)
+- Related Lifecycles: List 3-5 related use case traces
+
+Component Overview
+- List the key components and services with their roles
+
+Guidelines:
+- Use Mermaid for all diagrams
+- Add actual key classnames, as appropriate 
+- Focus on visual understanding, not verbose explanations
+- Include file paths and line numbers in tables
+- NO code duplication (reference files instead)
+
+Output lifecycle into a file like “/memory/system/001_lifecycle_xxx_xxx_xxx.md”

.github/prompts/plan_milestones.prompt.md

@@ -0,0 +1,12 @@
+---
+mode: agent
+---
+# Plan Milestones
+
+Reference the relevant design document, and create or update a doc in the `memory/milestones` directory, following the naming convention: `001_xxx_milestones.md`.
+
+Create a series of milestones to implement the design. The milestones should implement the design in an iterative, progressive way, so that we can verify and test along the way.
+
+Each milestone should be relatively small and simple, so that I am able to more easily audit the implementation and debug issues. Each milestone should be designed to be easily verifiable via a manual test.
+
+Create checkboxes like `[ ]`, so we can track completion.

.github/prompts/research.prompt.md

@@ -0,0 +1,11 @@
+---
+mode: agent
+---
+## Research
+I'm a new developer, and I want to use AI to code, but I want to understand and review all the code that's being developed.
+Before starting with a feature, I want to first get an overview of the flow of code around that feature. It's useful to get an orientation on where I'll need to make edits, and get an overview of the relevant system overview that's related to that feature (where views are generated, actions are handled, etc).
+Sort
+If there is UI involved, where is the code that renders the UI?
+If there is event handling, where is the event handler registered, and where is it implemented?
+If there are services involved, which ones are called?
+Before we dive into this feature, guide me through exploring how nearby or similar features work, so that our solution will be consistent with the existing architecture.

.github/prompts/system_overview.prompt.md

@@ -0,0 +1,64 @@
+---
+mode: agent
+---
+Look for the lifecycle documentation files, and trace through the flow to create a system architecture document that shows the major actors and their relationships.
+
+## Goal
+Identify the heavyweight components/services where most logic lives, show how they're wired together, and indicate key technologies used.
+
+## Structure
+
+### 1. System Overview Diagram (Mermaid)
+- Show 5-10 major actors (components/services that do the heavy lifting)
+- Wire them together with labeled arrows showing data/control flow
+- Use subgrouping to show deployment boundaries (processes, machines, external services)
+- Color-code or annotate with key technologies
+
+### 2. Component Catalog (Table)
+For each major actor:
+- **Component Name** 
+- **Technology/Framework** (e.g., "React + MUI", "Node.js custom", "FastAPI")
+- **Primary Responsibility** (one sentence)
+- **Key Files** (2-3 main files)
+- **Heavy Logic** (what complex operations happen here?)
+
+### 3. Technology Stack (Quick Reference)
+List the key technologies by layer:
+- UI Layer: [technologies]
+- State/Logic Layer: [technologies]
+- Service/API Layer: [technologies]
+- Data Layer: [technologies]
+- External Dependencies: [services/APIs]
+
+### 4. Integration Points
+Show how major actors communicate:
+- Protocol (HTTP, IPC, WebSocket, etc.)
+- Data format (JSON, protobuf, etc.)
+- Sync vs Async
+
+### 5. Where to Start
+- "To understand user interactions, read: [lifecycle docs]"
+- "To understand data flow, start with: [component]"
+- "To understand business logic, start with: [component]"
+
+## Guidelines
+- Focus on "major actors" - components where significant logic lives
+- Exclude simple pass-through components, thin wrappers, pure UI components
+- Maximum 10 major actors (force prioritization)
+- The diagram should fit on one screen
+- Each actor should be substantial enough to deserve documentation
+- This is a companion to lifecycle documents, not a replacement
+
+## Example Major Actors (not minor ones)
+✅ API Gateway with routing logic
+✅ Authentication service with token management
+✅ State management layer with complex sync logic
+✅ Background job processor
+✅ Real-time event handler
+
+❌ Simple React component that just renders props
+❌ Utility function file
+❌ Thin HTTP client wrapper
+❌ Config file
+
+The test: "If this component disappeared, would significant logic need to be rewritten?" If no, it's not a major actor.