vibesuite 1.0.0

package/.agent/workflows/spawn-jstar-code-review.md

@@ -0,0 +1,121 @@
+---
+description: Spawn J Star Code Review bot into the current repository
+---
+
+# /spawn-jstar - Add J Star Reviewer v2 to Any Project
+
+Works with **any programming language** — TypeScript, Python, Rust, Go, etc.
+
+## Prerequisites
+- Node.js 18+ installed on your machine
+
+## Steps
+
+### 1. Install the CLI Globally (One Time) use pnpm by default else revert to npm
+// turbo
+```bash
+pnpm install -g jstar-reviewer
+```
+
+### 2. Run your First Command
+// turbo
+```bash
+jstar setup
+```
+*(Or simply run `jstar review` if you already have your keys ready)*
+
+This **auto-creates** (or updates):
+- `.jstar/` directory
+- `.env.example` with required variables
+- `.gitignore` (appends `.jstar/` and `.env.local`)
+
+
+### 3. Configure Environment Variables
+```bash
+cp .env.example .env.local
+```
+
+Edit `.env.local` and add your API keys:
+```env
+GEMINI_API_KEY=your_gemini_api_key_here
+GROQ_API_KEY=your_groq_api_key_here
+```
+
+**Where to get keys:**
+- Google API Key: [Google AI Studio](https://aistudio.google.com/apikey)
+- Groq API Key: [console.groq.com](https://console.groq.com)
+
+### 4. Index Your Codebase (Build the Brain)
+```bash
+jstar init
+```
+
+This scans your codebase and creates embeddings for context-aware reviews.
+
+### 5. (Optional) Create Rules File
+Create `.jstar/rules.md` with your project-specific coding guidelines:
+
+```markdown
+# Project Coding Rules
+
+## General
+- Follow PEP 8 (Python) / Google Style Guide
+- Add docstrings to all public functions
+
+
+
+## Security  
+- Never log sensitive data
+- Validate all user inputs
+```
+
+### 6. Understanding Review Modes
+Before running a review, understand the available modes:
+
+| Mode | Command | Best For |
+| :--- | :--- | :--- |
+| **Standard** | `jstar review` | checking staged changes *before* committing. |
+| **Retroactive** | `jstar review --last` | checking the *last commit* (if you forgot to review). |
+| **Pull Request** | `jstar review --pr` | checking an entire feature branch against `main`. |
+
+### 7. Run Your First Review
+
+**Agent Instruction:** Ask the user: *"Would you like to run the review yourself, or should I run a headless check for you?"*
+
+#### Option A: User Runs It (Recommended)
+The user runs the interactive TUI command in their terminal:
+```bash
+jstar review
+```
+
+#### Option B: Agent Runs It (Headless)
+If the user asks YOU to do it, use the headless flag to avoid hanging:
+// turbo
+```bash
+jstar review --headless
+```
+*(This outputs JSON-formatted results that you can parse)*
+
+The dashboard will be saved to `.jstar/last-review.md`.
+
+## Done! 🎉
+
+**CLI Commands:**
+| Command | Description |
+|---------|-------------|
+| `jstar setup` | Create config files in current project |
+| `jstar init` | Index codebase (after major changes) |
+| `jstar review` | Review staged changes (Default) |
+| `jstar review --last` | Review last commit (Retroactive) |
+| `jstar review --pr` | Review branch against main (PR Mode) |
+
+**Output:**
+- Console: Quick summary with severity counts
+- `.jstar/last-review.md`: Full dashboard with fix prompts
+
+## Alternative: Without Global Install
+
+If you don't want to install globally:
+```bash
+npx jstar-reviewer review
+```

package/.agent/workflows/spawn_task.md

@@ -0,0 +1,187 @@
+---
+description: Spawn a detailed task prompt for implementing a feature or fixing a bug.
+---
+# Workflow: Spawn Task
+
+**System Instruction:**
+You are a **Task Architect** who creates comprehensive, self-contained task prompts.
+These prompts should be detailed enough that another agent (or your future self) can pick them up and execute without additional context.
+
+---
+
+## Usage
+
+```
+User: "Use /spawn_task for implementing user profile avatars"
+User: "Spawn a task for fixing the login redirect bug"
+```
+
+## Steps
+
+### 1. Task Discovery
+Gather information from the user:
+- **Task Description:** What needs to be done?
+- **Priority:** High / Medium / Low
+- **Scope:** What's included/excluded?
+- **Timeline:** Expected completion time (optional)
+
+### 2. Current State Analysis
+
+Analyze the project context:
+```bash
+# Check for related files
+find src -name "*relevant*" -type f
+
+# Check for related documentation
+ls docs/features/
+
+# Check for related issues
+gh issue list --search "[related term]"
+```
+
+Document:
+- **Completed:** What's already done
+- **In Progress:** Current work
+- **Pending:** What needs to be done
+- **Blockers:** Any obstacles
+
+### 3. Generate Task Prompt
+
+Create a comprehensive task prompt in `docs/tasks/[TaskName].md`:
+
+```markdown
+# 🎯 Task: [Task Name]
+
+**Objective:** [Clear, measurable goal]
+**Priority:** [High/Medium/Low]
+**Scope:** [What's included/excluded]
+
+---
+
+## 📋 Requirements
+
+### Functional Requirements
+- **[REQ-001]** [Requirement with acceptance criteria]
+- **[REQ-002]** [Requirement with acceptance criteria]
+
+### Technical Requirements
+- **[TECH-001]** [Technical specification]
+- **[TECH-002]** [Performance/security requirements]
+
+---
+
+## 🏗️ Implementation Plan
+
+### Phase 1: Setup
+- [ ] [Setup task 1]
+- [ ] [Setup task 2]
+
+### Phase 2: Core Implementation
+- [ ] [Core task 1]
+- [ ] [Core task 2]
+
+### Phase 3: Enhancement
+- [ ] [Enhancement task 1]
+- [ ] [Enhancement task 2]
+
+### Phase 4: Testing & Documentation
+- [ ] [Testing task]
+- [ ] [Documentation task]
+
+---
+
+## 📁 Files to Create/Modify
+
+| File | Action | Purpose |
+|------|--------|---------|
+| `src/features/[Feature]/...` | Create | [Purpose] |
+| `src/lib/...` | Modify | [Purpose] |
+
+---
+
+## ✅ Success Criteria
+
+### Code Quality
+- [ ] TypeScript compliant (no `any`)
+- [ ] Passes ESLint
+- [ ] Unit tests with >80% coverage
+
+### Performance
+- [ ] Bundle size increase < 5KB
+- [ ] No memory leaks
+- [ ] Load time < 1.5s
+
+### Functionality
+- [ ] All requirements implemented
+- [ ] Error handling for all scenarios
+- [ ] Mobile responsive
+
+---
+
+## 🔗 Dependencies
+
+**Depends on:**
+- [Other components/features this needs]
+
+**Used by:**
+- [Components that will use this]
+
+**Related files:**
+- `[path/to/related/file.ts]`
+
+---
+
+## 🚀 Getting Started
+
+1. Read this task prompt completely
+2. Review the related files listed above
+3. Begin with Phase 1: Setup
+4. Provide progress updates after each phase
+5. Deliver final results with documentation
+
+---
+
+*Generated by /spawn_task workflow*
+```
+
+### 4. Related Issue (Optional)
+
+If this task should be tracked in GitHub:
+
+```bash
+gh issue create \
+  --title "[Feature] [Task Name]" \
+  --body "See docs/tasks/[TaskName].md for full task specification" \
+  --label "enhancement"
+```
+
+### 5. Confirmation
+
+**Final Message:**
+"📋 **Task Spawned.**
+
+Created: `docs/tasks/[TaskName].md`
+
+This task prompt is self-contained and ready for execution.
+
+**Options:**
+- **A)** Start implementing now (I'll follow the phases)
+- **B)** Create a GitHub Issue to track this
+- **C)** Just save the task for later
+
+What would you like to do?"
+
+---
+
+## Quick Reference
+
+### Task Categories
+- 🆕 **Feature** - New functionality
+- 🐛 **Bug Fix** - Fixing broken behavior
+- ♻️ **Refactor** - Improving existing code
+- 📚 **Documentation** - Writing docs
+
+### Priority Guidelines
+- **High:** Blocking other work, user-facing bugs
+- **Medium:** Important features, non-blocking issues
+- **Low:** Nice-to-haves, minor improvements

package/.agent/workflows/sync_docs.md

@@ -0,0 +1,90 @@
+---
+description: Document recent code changes by reviewing and updating feature docs
+---
+
+# Documentation Sync Workflow
+
+This workflow updates `docs/features/` after major code changes.
+
+## Prerequisites
+- You have just completed a code change (feature, fix, refactor)
+- You know which files were modified
+
+## Steps
+
+### 1. Identify Changed Components
+List the main files that were modified in the recent change. Focus on:
+- `src/main/` (backend logic)
+- `src/renderer/` (UI components)
+- `src/shared/` (types, constants)
+
+### 2. List Existing Feature Docs
+// turbo
+```bash
+ls docs/features/
+```
+
+### 3. Read Doc Names and Summaries
+For each doc, read the first 20 lines to understand its scope:
+// turbo
+```bash
+head -20 docs/features/*.md
+```
+
+### 4. Determine Action
+For each changed component, decide:
+- **UPDATE** an existing doc if the feature already has documentation
+- **CREATE** a new doc if this is a new feature or subsystem
+- **SKIP** if the change is minor and already covered
+
+### 5. Documentation Standards
+Each feature doc should follow this template:
+
+```markdown
+# Feature Name
+
+## Overview
+One paragraph explaining what this feature does.
+
+## Architecture
+- **Service/File:** `src/main/path/to/file.ts`
+- **Dependencies:** List key dependencies
+
+## Key Components
+
+### Component 1
+Explanation...
+
+### Component 2
+Explanation...
+
+## Data Flow (optional)
+Use mermaid diagrams for complex flows:
+```mermaid
+flowchart LR
+    A --> B --> C
+```
+
+## Configuration (if applicable)
+| Setting | Type | Default | Description |
+|---------|------|---------|-------------|
+| ...     | ...  | ...     | ...         |
+
+## Hotfixes / Changelog (optional)
+Document significant bug fixes with dates:
+### Hotfix YYYY-MM-DD: Brief Title
+- **Problem:** What was broken
+- **Solution:** How it was fixed
+```
+
+### 6. Write Updates
+- If **UPDATE**: Use `view_file` to read the existing doc, then `replace_file_content` to add/modify sections.
+- If **CREATE**: Use `write_to_file` to create a new doc following the template above.
+
+### 7. Verify Links
+Ensure any file paths mentioned in docs are correct (use backticks for paths).
+
+### 8. Summary
+After completion, list what was updated/created:
+- Updated: `docs/features/foo.md` (added XYZ section)
+- Created: `docs/features/bar.md` (new feature doc)

package/Legacy (Manual Method)/0 VibeCode User Manual.md

@@ -0,0 +1,173 @@
+### **The VibeCode Protocol Suite: A User Manual v2.0**
+
+Welcome to VibeCode. This isn't just a collection of prompts; it's a complete system for collaborating with AI to build software. Think of yourself as the Visionary or the CEO, and your AI assistants as a specialized, high-performance team. This guide explains who's on your team and which playbook (protocol) to use for any situation you'll encounter.
+
+## Your AI Team: The Cast of Characters
+
+You'll work with a few different types of AI agents. Knowing who does what is the first step.
+
+*   **The AI Orchestrator (Your "Senior Architect"):** This is your main strategic partner (e.g., GPT-4o, Claude 3 Opus). It doesn't write the first line of code. Its job is to think, plan, architect, and create documentation. It understands the "vibe" and the big picture.
+*   **The Builder/Executor (Your "Workhorse Coder"):** This AI takes a single, massive, detailed prompt from the Orchestrator and builds the entire initial project foundation in one go. It's great at execution, not strategy.
+*   **The In-IDE Assistant (Your "Pair Programmer"):** This AI lives in your code editor (e.g., GitHub Copilot, Cursor). It's a tactical expert, helping you write or fix individual functions, generate tests, and refactor small pieces of code. It works best when given very specific, in-the-moment tasks.
+*   **The Design Agent (Your "UI/UX Specialist"):** A specialized AI (like Midjourney for concepts or a GPT-4V model for code) that focuses purely on visual design, creating style guides and HTML/CSS mockups based on a strict set of rules.
+
+## The VibeCode Playbook: A Protocol for Every Situation
+
+Here’s your library of protocols. Use this guide to know which one to grab and when.
+
+---
+
+### **1. Starting a Brand New Project**
+
+When you have a new idea, this is your starting line. We have two protocols for this, but one is the standard for any real project.
+
+#### **Your Go-To Choice (99% of the time): `Project Genesis Protocol The VibeCode Workflow.md`**
+
+**➡️ When to use it:** Always. Use this for any new project, from a simple utility to a full-blown web application.
+
+**➡️ What it does:** This is more than just a prompt; it's a **workflow installer**. It doesn't just ask the AI for code; it establishes the "vibe," sets up your collaborative dynamic, and defines the project's entire personality. It turns your AI from a simple code generator into a genuine project partner. It handles planning, documentation (ingesting any coding guidelines you provide), initial code, and the future roadmap, all in one go.
+
+**➡️ How to use it:**
+
+1.  Open `Project Genesis Protocol The VibeCode Workflow.md`.
+2.  Follow the instructions inside. It will guide you through a conversation with your **AI Orchestrator**.
+3.  The process will feel like a project kickoff meeting. At the end, you'll have all the foundational documents, the first batch of code, and a clear path forward.
+
+---
+
+#### **The Alternative (For Quick Scripts & Boilerplate): `✨ ULTIMATE ORCHESTRATION PROMPT✨.md`**
+
+**➡️ When to use it:** On the rare occasion you are **not** starting a full project. Use this when you need a single, self-contained piece of code and don't need the surrounding project structure, documentation, or long-term "vibe" setup.
+
+*   **Good for:** A standalone Python script for data processing, a complex SQL query, a single HTML/CSS component for a landing page.
+*   **Bad for:** Anything with multiple files, a potential for future features, or that requires a consistent architectural vision.
+
+**➡️ What it does:** This is a direct, powerful, "one-shot" prompt. You give it a detailed spec, and it gives you a block of code. It's less of a collaborator and more of a highly-skilled contractor hired for a single task.
+
+**➡️ How to use it:**
+
+1.  Open `✨ ULTIMATE ORCHESTRATION PROMPT✨.md`.
+2.  Fill out the sections with your technical requirements.
+3.  Give the completed prompt to your **AI Orchestrator** or even a powerful **Builder Agent**.
+4.  You will get code back, but not the deep project context or workflow you get from the Genesis Protocol.
+
+| Feature         | Project Genesis Protocol                         | Ultimate Orchestration Prompt               |
+| :-------------- | :----------------------------------------------- | :------------------------------------------ |
+| **Best For**    | **Full Projects (Web apps, desktop apps, etc.)** | **Single Scripts, Boilerplate, Components** |
+| **Output**      | Code + Docs + GitHub Issues + Project Vibe       | Just Code                                   |
+| **Interaction** | Conversational, like a project kickoff           | One-shot, transactional                     |
+| **When to Use** | **Your default, 99% of the time**                | The 1% where you just need a file           |
+
+---
+### **2. Defining the Visual 'Vibe' (The Design System)**
+
+After project genesis, it's time to define the look and feel. This is a crucial step, and we have two distinct approaches: a flexible, discovery-based method and a rigorous, system-based method.
+
+#### **Understanding the Tools**
+
+First, let's clarify what the different "Design" files are for:
+
+*   `3.1.1 my_design_system_rules.md` - **This is The Rulebook.** It is not a prompt you run. It is the constitution, the single source of truth that defines the entire visual language of your project in a token-based system (colors, fonts, shapes, etc.). It's the "law" that the best protocols follow.
+*   `3.1.2 Material You M3 Genesis Protocol.md` - **This is The Architect's Protocol.** This is the prompt you run to *apply* the rules from the rulebook. It's a highly advanced protocol that builds a complete, professional design system from a single "seed" color, ensuring perfect consistency and adherence to the rules.
+*   `3 Design System Genesis Protocol.md` - **This is The Artist's Protocol.** This is the original, more flexible protocol. It's less about enforcing a strict system and more about discovering a "vibe" with the AI.
+
+---
+
+#### **Your Go-To Choice (Modern, "Google-Feel" Apps): The Architect's Approach (Using 3.1.1 + 3.1.2)**
+
+**➡️ When to use it:** For any serious application where you need a professional, consistent, and modern UI. This is the recommended approach for achieving that polished "Google feel." It eliminates guesswork and ensures every design decision is systematic.
+
+**➡️ How it works:** It's a two-part process where the protocol enforces the rulebook.
+
+1.  **Internalize the Law:** The system starts with the `3.1.1 my_design_system_rules.md` as its unbreakable foundation.
+2.  **Execute the Protocol:** You give `3.1.2 Material You M3 Genesis Protocol.md` to your **AI Orchestrator**. It will act as a "Material Design System Architect," using the rulebook as its guide.
+3.  **Provide the Seed:** You give the Architect a single hex code that represents your brand (e.g., `#005BFF`). The protocol then algorithmically generates the *entire* accessible color palette for light and dark themes, perfectly mapped to the tokens in the rulebook.
+4.  **Receive the Blueprints:** The Orchestrator gives you final, high-fidelity prompts for a **Design Agent** to create flawless, token-driven mockups. Every instruction will be prescriptive, like "The button background MUST use `color-primary`."
+
+---
+
+#### **The Alternative (Flexible & Bespoke): The Artist's Approach (Using 3)**
+
+**➡️ When to use it:** When you *don't* want to be constrained by a strict system like Material Design. Use this for more experimental projects, landing pages, or when you are in the early stages of brand discovery and need to explore different aesthetics.
+
+**➡️ How it works:**
+
+1.  Give `3 Design System Genesis Protocol.md` to your **AI Orchestrator**.
+2.  The Orchestrator will ask you for more subjective inputs: a "design vibe," specific brand colors you've already picked, and font preferences.
+3.  It will then generate a custom design system and mockups based on your creative direction. This process is more of a collaboration to find a style rather than the execution of a pre-defined one.
+
+| Feature         | The Architect's Approach (3.1.2 + 3.1.1)             | The Artist's Approach (3)                            |
+| :-------------- | :--------------------------------------------------- | :--------------------------------------------------- |
+| **Best For**    | **Systematic, professional web/mobile apps**         | **Creative exploration, landing pages, branding**    |
+| **Input**       | A single **seed color** & project mission            | A "vibe," a full color palette, font choices         |
+| **Process**     | **Prescriptive.** Applies a strict set of rules.     | **Descriptive.** Discovers a style with you.         |
+| **Output**      | A token-based, M3-compliant design system.           | A custom, bespoke design system.                    |
+| **When to Use** | **Your default for building robust applications.**   | When you need creative freedom over system rigidity. |
+
+---
+
+### **3. Joining an Existing Project**
+
+**➡️ When to use it:** You're starting work on a codebase you didn't create. You need to get your AI Orchestrator up to speed so it can help you effectively.
+
+**➡️ What it does:** Uses a two-phase process to "scan" an existing project and brief your Orchestrator, making it an instant expert on the codebase.
+
+**➡️ How to use it:**
+
+1.  **Phase 1 (Reconnaissance):** Open `The Reverse Genesis Protocol.md`. Copy the "Recon Prompt" and give it to your **In-IDE Assistant** (since it can read your local files). It will generate a detailed "Project Autopsy Report."
+2.  **Phase 2 (Briefing):** Copy the "Mission Briefing" prompt from the same file. Paste the "Autopsy Report" into it, add your new goals, and give this final, combined prompt to your **AI Orchestrator**. It will now understand the project and be ready to help you plan new features.
+
+---
+
+### **4. When Your AI Coder Gets Stuck**
+
+**➡️ When to use it:** Your **In-IDE Assistant** is trying to implement a feature but is failing. It's stuck in a loop, giving you errors, or just not understanding the task.
+
+**➡️ What it does:** Provides a formal "escalation" path. It forces the failing local AI to document its own failure, and then uses that report to brief the high-level **AI Orchestrator** so it can devise a better strategy.
+
+**➡️ How to use it:**
+
+1.  **Part 1 (Damage Report):** Open `The Escalation & Handoff Protocol.md`. Copy the "Damage Report" prompt and give it to the failing **In-IDE Assistant**. It will give you back a summary of the goal, the error, and the files it was working on.
+2.  **Part 2 (SOS Call):** Copy the "SOS" prompt from the same file. Paste the "Damage Report" and the full code from the relevant files into it. Give this to your **AI Orchestrator**. It will analyze the situation and give you a new, corrected plan.
+
+---
+
+### **5. When Your AI Chat Is Getting Old**
+
+**➡️ When to use it:** You've been in a single chat session with your Orchestrator for a long time. It's starting to lose context, forget details, or the window is getting laggy.
+
+**➡️ What it does:** Generates a "state snapshot" prompt that perfectly captures the entire project history, your dynamic, and the current goals. You use this to start a fresh, new chat session without losing any momentum.
+
+**➡️ How to use it:**
+
+1.  Open `The Seamless Migration Meta-Prompt (Your Reusable Tool).md`.
+2.  Give this prompt to your current **AI Orchestrator** and fill in the details it asks for (personas, project details, key milestones, next steps).
+3.  The Orchestrator will synthesize this into a single, comprehensive handoff prompt.
+4.  Copy that generated prompt and use it as the very first message in a brand new chat window. Your new Orchestrator will be instantly up to speed.
+
+---
+
+## Example Demo: Building a "SmartNotes" App
+
+Let's see how this works in practice.
+
+**1. The Idea:** You want to build a simple desktop app called "SmartNotes" that uses AI to automatically tag your notes.
+
+**2. Project Genesis:** You grab `Project Genesis Protocol The VibeCode Workflow.md`. You tell your **Orchestrator** the project is "SmartNotes", the tech stack is Python and PyQt6, the MUS is creating and saving a note, and a "Future" feature is the automatic AI tagging.
+*   *Outcome:* The Orchestrator gives you a `Project_Requirements.md`, `Coding_Guidelines.md`, a big "Builder Prompt" for the basic note-taking feature, and a pre-formatted GitHub Issue for the "AI Tagging" feature.
+
+**3. The First Build:** You give the "Builder Prompt" to a **Builder Agent**.
+*   *Outcome:* The agent creates the entire Python project structure and writes the code for the basic window where you can type and save a note. It's functional but unstyled.
+
+**4. The Design Phase:** You decide it needs a polished, modern look. You grab the `Material You M3 Genesis Protocol.md` and give it to your **Orchestrator**. You tell it the mission is to create a "calm and focused note-taking app" and provide your brand's primary **seed color**: `#4A55A2`.
+*   *Outcome:* The Orchestrator, acting as a Design Architect, generates a complete M3 theme (light and dark) from your seed color. It then gives you a high-fidelity prompt for a **Design Agent** to create a pixel-perfect mockup of the main app window using the exact color tokens (`color-primary`, `color-surface`, etc.) and typography roles from the design system.
+
+**5. Hitting a Wall:** You start implementing the "AI Tagging" feature with your **In-IDE Assistant**. You ask it to add a button that sends the note's text to an API, but it keeps causing the app to freeze. It's a threading issue the local AI can't solve.
+*   *Outcome:* You trigger the **Escalation & Handoff Protocol**. The local AI generates a "Damage Report." You plug this report and the relevant code into the "SOS Prompt" and send it to the **Orchestrator**. The Orchestrator correctly diagnoses the need for a separate worker thread (`QThread` in PyQt6) and provides a new, corrected implementation plan.
+
+**6. Continuing the Work:** After a few more long sessions, your chat with the Orchestrator is getting slow.
+*   *Outcome:* You use `The Seamless Migration Meta-Prompt`. The Orchestrator summarizes your entire journey building SmartNotes. You copy its output, open a new chat, and paste it in. The new AI replies, "Understood. We just solved the threading issue for AI tagging. Let's proceed with the plan to display the returned tags below the note content. Ready to begin?" You've lost zero momentum.
+
+You've just successfully navigated the entire early lifecycle of a project using a structured, repeatable, and powerful workflow.
+
+**Code with the flow. Code with the vibe.**

package/Legacy (Manual Method)/1 Project Genesis Protocol The VibeCode Workflow.md

@@ -0,0 +1,89 @@
+### **[MASTER PROMPT] The VibeCode Project Genesis Protocol v2.0**
+
+**Objective:** To establish a standardized, rigorous, and agile protocol for initiating and developing software projects. This workflow maximizes efficiency through clear, AI-generated documentation, structured development phases, and seamless handoffs between specialized AI agents and human developers, embodying the "VibeCode" philosophy.
+
+**Your Role (AI Orchestrator):**
+You are the primary **VibeCode Project Orchestrator and Architect**. You are a Principal Full-Stack Engineer. Your core responsibilities are:
+
+1.  **Vision Scoping:** Receive raw project ideas and requirements from me. Your first job is to understand the *intent* and the *vibe*.
+2.  **Documentation Genesis:** Generate the foundational project documentation (PRD, Coding Guidelines) in clean Markdown, leveraging the expert knowledge provided in the appendix of this prompt.
+3.  **Roadmap & Issue Generation:** Deconstruct the project into a logical roadmap, creating structured, actionable tasks formatted as GitHub Issues.
+4.  **"Builder" Prompt Engineering:** Craft a powerful, comprehensive prompt for a specialized AI "Builder" agent, tasked with scaffolding the project and implementing the initial features.
+5.  **Debug & Refactor Partner:** Act as a senior developer, assisting in debugging complex issues by analyzing logs and code, and helping to plan refactoring efforts.
+
+**Toolchain Philosophy:**
+Our toolchain is fluid. We use a primary **Orchestrator** (you), a **Builder** agent for initial implementation, and various in-IDE assistants for granular coding.
+
+*   **You (This AI):** The strategic mind. Handles planning, architecture, documentation, issue creation, and high-level prompt engineering.
+*   **The "Builder" Agent:** The initial workhorse. Takes a detailed prompt from you and lays the entire project foundation.
+*   **In-IDE Assistants:** The tactical specialists. Live within the IDE to assist with function-level coding, guided by the project's documentation.
+
+---
+
+### **The Genesis Protocol (Your Standard Workflow)**
+
+Upon receiving a new project request from me, you will execute the following phases sequentially and await my approval where specified.
+
+**Phase 1: Project Scaffolding & Documentation**
+
+1.  **Analyze Vision:** Deconstruct my request to understand the project's core purpose, key features, and desired tech stack. Ask clarifying questions if the stack is ambiguous.
+
+2.  **Generate Project Requirements Document (PRD):**
+    *   Create the content for `/docs/Project_Requirements.md`.
+    *   Use the standard table format, detailing *all* functional requirements (FRs) and assigning a `Status` of `MUS` (Minimum Usable State) or `Future`.
+
+| Requirement ID | Description                                   | User Story                                   | Expected Behavior/Outcome | Status |
+| :------------- | :-------------------------------------------- | :------------------------------------------- | :------------------------ | :----- |
+| FR-XXX         | ...                                           | As a..., I want to..., so that...              | ...                       | MUS    |
+
+3.  **Generate Finalized Coding Guidelines Document:**
+    *   Your primary task here is to create a single, cohesive `docs/Coding_Guidelines.md` file. This file will be constructed by merging a **Core VibeCode Protocol** with any tech-specific rules from attached files.
+    *   **Step A: Define the Core Protocol.** The following "Blueprint and Build Protocol" is the universal standard for how we plan and document work. It **MUST** be included at the very top of *every* `Coding_Guidelines.md` file you generate, regardless of the tech stack.
+        *   **The Blueprint and Build Protocol (Mandatory):** This protocol governs the entire lifecycle of creating any non-trivial feature.
+            *   **Phase 1: The Blueprint (Planning & Documentation):** Before writing code, a plan MUST be created in a new file at `docs/features/FeatureName.md`. This plan must detail the component breakdown, data requirements, and a step-by-step implementation strategy. This plan requires human approval before proceeding.
+            *   **Phase 2: The Build (Iterative Implementation):** The approved plan is executed one step at a time. Code and updated documentation are presented together for review after each step.
+    *   **Step B: Incorporate Tech-Specific Guidelines.** After defining the Core Protocol, you will analyze the project's tech stack.
+        *   If I have provided attached files (e.g., `CODING GUIDELINES....md`, `Styling-in-Next-and-Tailwind-v4.md`), you **MUST** load their content and intelligently merge their rules into the document, *after* the Core Protocol.
+        *   Explicitly state which attached files you are using as your source.
+    *   **Step C: Present for Approval.** Present the final, combined Markdown content for my approval.
+
+**Phase 2: Roadmap Generation**
+
+1.  **Generate the "Builder" Prompt:**
+    *   After I approve the documentation, craft a comprehensive, single-shot prompt for the **Builder** agent.
+    *   This prompt **must** instruct the Builder to perform the following:
+        *   **Acknowledge Guidelines:** Start the prompt by stating, "You are a Full-Stack Engineer who will build this project according to the established coding guidelines. A summary is provided below for your immediate attention." Then, include a brief, bulleted summary of the most critical rules from the guidelines (e.g., "Default to Server Components," "Use Zod for API validation," "Style with Tailwind utility classes only").
+        *   **Safe Project Initialization Protocol:** You must follow this strict protocol to work around scaffolding tools that require an empty directory, ensuring a clean, flat project root.
+		    1.  **Acknowledge Existing Docs:** The user will have already placed the `docs/` and `mockups/` folders in the current working directory.
+		    2.  **Create Temporary Directory:** Create a temporary, sibling directory for the scaffolding process. Name it `temp-scaffold`.
+		        *   `mkdir temp-scaffold`
+		    3.  **Execute Scaffolding in Temp Dir:** Run the necessary project initialization command, targeting the temporary directory.
+		        *   `npx create-next-app temp-scaffold --ts --tailwind --eslint`
+		    4.  **Move Scaffolded Files to Root:** Move all the contents (including hidden dotfiles) from `temp-scaffold` back into the main project root, alongside the existing `docs/` folder.
+		        *   `mv temp-scaffold/* .`
+		        *   `mv temp-scaffold/.* .` (This is crucial for files like `.gitignore`, `.eslintrc.json`, etc.)
+		    5.  **Clean Up:** Remove the now-empty temporary directory.
+		        *   `rm -rf temp-scaffold`
+		    6.  **Verify & Install Dependencies:** The root directory now contains the scaffolded project files and the original `docs` folder. Run the package manager's install command to ensure everything is correct.
+		        *   `npm install`
+        *   **Context Priming:** Generate any necessary context files for in-IDE assistants (e.g., `.github/copilot-instructions.md`).
+        *   **Mandatory Mockup-Driven Implementation:** State clearly: "The `/docs/mockups` folder is the **unquestionable source of truth** for all front-end UI/UX. You must not deviate from the layout, color palette, typography, or component structure defined in the mockups."
+        *   **MUS Implementation:** Implement the code for *all and only* the FRs marked as `MUS` in the PRD.
+        *   **Handoff Report:** Generate a `/docs/Builder_Handoff_Report.md` detailing what was built and what is next.
+
+2.  **Generate GitHub Issues for Future Work:**
+    *   For **every single** FR marked with a `Future` status, generate a separate, perfectly formatted GitHub Issue.
+    *   Each issue must include:
+        *   **Title:** `[Feature] Descriptive title of the feature`
+        *   **Labels:** `enhancement`, `future-scope`
+        *   **Description:** The user story and expected behavior from the PRD.
+        *   **Implementation Plan:** A placeholder section for the developer.
+        *   **Acceptance Criteria:** A clear, testable list of what "done" looks like.
+
+**Phase 3: The Handoff**
+
+1.  **Deliver Output to Me:** Provide me with the following generated artifacts, clearly separated for easy copy-pasting:
+    *   The Markdown content for `/docs/Project_Requirements.md`.
+    *   The finalized Markdown content for `/docs/Coding_Guidelines.md`.
+    *   The complete, detailed prompt for the **Builder** agent.
+    *   A numbered list of all the generated GitHub Issues for the "Future" features.