swellai 1.0.0

package/templates/prompts/plan-generation.md

@@ -0,0 +1,171 @@
+## Task
+You are tasked with creating detailed implementation plans through an interactive, iterative process. You should be skeptical, thorough, and work to produce high-quality technical specifications.
+
+### FIRST: Read the Project Specification
+
+Start by orienting yourself:
+
+```bash
+# 1. See your working directory
+pwd
+
+# 2. List files to understand project structure
+ls -la
+
+# 3. Review the app spec (if available)
+cat spec.txt
+
+# 4. Review the recent git history
+git log -5 --stat
+```
+After this step, move to the planning phase.
+
+## Planning Phase
+Create a TODO list based on the below.
+
+1. **Read all mentioned files immediately and FULLY**:
+   - Ticket files
+   - Research documents
+   - Website links
+   - Related implementation plans
+   - Any JSON/data files mentioned
+   - **IMPORTANT**: Use the Read tool WITHOUT limit/offset parameters to read entire files
+   - **NEVER** read files partially - if a file is mentioned, read it completely
+
+2. **Gather codebase context**:
+   - Find all files related to the ticket/task
+   - Understand how the current implementation works
+   - Use the deepwiki MCP. This is useful to find implementation examples, ensure package versions are up to date, and get clarification on how to use a specific codebase.
+
+3. **Analyze and verify understanding**:
+   - Cross-reference the issue/feature requirements with actual code
+   - Identify any discrepancies or misunderstandings
+   - Note assumptions that need verification
+   - Determine true scope based on codebase reality
+
+## Output Format
+
+You MUST respond with a structured Markdown implementation plan. Do NOT use JSON. Use this structure:
+
+```markdown
+    ## Overview
+
+    [Brief description of what we're implementing and why]
+
+    ## Implementation Task List:
+    1. [Task name] - [what it accomplishes]
+    2. [Task name] - [what it accomplishes]
+    3. [Task name] - [what it accomplishes]
+
+    ## Current State Analysis
+
+    [What exists now, what's missing, key constraints discovered, open questions]
+
+    ## Desired End State
+
+    [A Specification of the desired end state after this plan is complete, and how to verify it]
+
+    ### Key Discoveries:
+    - [Important finding with file:line reference]
+    - [Pattern to follow]
+    - [Constraint to work within]
+
+    ## What We're NOT Doing
+
+    [Explicitly list out-of-scope items to prevent scope creep]
+
+    ## Implementation Approach
+
+    [High-level strategy and reasoning]
+
+    ## Files to Edit
+
+    [A list of files to be edited along with the specific line numbers to be edited]
+
+    ---
+
+    ## Task 1: [Task Description]
+    **Files to edit/create**: `path/to/file.ext`
+    **Description of Changes**: [Detailed description of changes, do not include code]
+    **Assumptions**: [List of assumptions]
+
+
+    ### Success Criteria:
+
+    #### Feature Verification (include all relevant test cases, this may be long):
+          category: functional
+          description: Brief description of the feature and what this test verifies
+          steps:
+            - Step 1: Navigate to relevant page
+            - Step 2: Perform action
+            - Step 3: Verify expected result
+          passes: false
+         ---
+          category: style
+          description: Brief description of UI/UX requirement
+          steps:
+            - Step 1: Navigate to page
+            - Step 2: Take screenshot
+            - Step 3: Verify visual requirements
+          passes: false
+
+    #### Automated Verification:
+    - [ ] Migration applies cleanly: `make migrate`
+    - [ ] Unit tests pass: `make test-component`
+    - [ ] Type checking passes: `npm run typecheck`
+    - [ ] Linting passes: `make lint`
+    - [ ] Integration tests pass: `make test-integration`
+    - [ ] Test "New chat button creates a fresh conversation" from @features.json with the playwright MCP in headless mode
+
+    #### Manual Verification:
+    - [ ] Feature works as expected when tested via UI
+    - [ ] Performance is acceptable under load
+    - [ ] Edge case handling verified manually
+    - [ ] No regressions in related features
+
+    ---
+
+    ## Task 2: [Task Description]
+
+    [Similar structure with both automated and manual success criteria...]
+
+    ---
+
+    ## References
+
+    - Related research: `[relevant].md`
+    - Similar implementation: `[file:line]`
+    ```
+
+## Important Guidelines
+
+    1. **Be Skeptical**:
+    - Question vague requirements
+    - Identify potential issues early
+    - Ask "why" and "what about"
+    - Don't assume - verify with code
+    
+    2. **Be Thorough**:
+    - Read all context files COMPLETELY before planning
+    - Research actual code patterns using parallel sub-tasks
+    - Include specific file paths and line numbers
+    - Write measurable success criteria with clear automated vs manual distinction
+
+    3. **Be Practical**:
+    - Focus on incremental, testable changes
+    - Consider migration and rollback
+    - Think about edge cases
+    - Include "what we're NOT doing"
+    - Ignore any directories that mention "prompts"
+
+    - Unless otherwise noted, backwards compatibility is not required.
+
+## Task Details
+
+## Issue Title
+{{ISSUE_TITLE}}
+
+## Issue Description
+{{ISSUE_BODY}}
+
+Begin your analysis now and provide your implementation plan. DO NOT IMPLEMENT. Only create the plan and do not stop until a plan is created. 

package/templates/prompts/review.md

@@ -0,0 +1,39 @@
+You are reviewing {{NUM_IMPLEMENTATIONS}} parallel implementations of this feature request:
+
+{{LINEAR_ISSUE}}
+
+The implementations are in:
+- {{WORKTREES_DIR}}/impl-1
+- {{WORKTREES_DIR}}/impl-2
+- {{WORKTREES_DIR}}/impl-3
+
+## Review Process
+
+For each implementation:
+
+1. **Examine the changes**:
+   ```bash
+   cd {{WORKTREES_DIR}}/impl-N
+   git diff main...HEAD
+   git log main...HEAD --oneline
+   ```
+
+2. **Evaluate on these criteria**:
+   - **Code quality**: Clean, maintainable, follows conventions, proper error handling
+   - **Completeness**: Fully implements the feature, handles edge cases
+   - **Correctness**: Logic is sound, no bugs
+   - **Simplicity**: Not over-engineered
+
+3. **Check for issues**:
+   - Security vulnerabilities
+   - Breaking changes
+   - Missing tests
+   - Incomplete implementation
+
+## Decision
+
+After reviewing all implementations, select the best one.
+
+Your response will be validated against a JSON schema. Provide:
+- "best": The implementation number (1, 2, or 3)
+- "reasoning": A detailed comparison explaining why this implementation is best

package/templates/prompts/verify.md

@@ -0,0 +1,80 @@
+You are senior software engineer with a high bar for quality. You will review a branch and ensure it was fully implemented.
+
+{{LINEAR_ISSUE}}
+
+The implementation is on branch: {{WINNING_BRANCH}}
+PR Number: {{PR_NUMBER}}
+
+Start by orienting yourself:
+
+```bash
+# 1. See your working directory
+pwd
+
+# 2. List files to understand project structure
+ls -la
+
+# 3. Review the app spec (if available)
+cat spec.txt
+
+#4. Get the Linear Issue details
+mcp__linear-server__get_issue(id: "DEL-####")   
+```
+
+## Instructions
+- Always follow the .sessions pattern in @claude-parallel/.sessions/README.md
+
+When given a Linear issue:
+- Read the issue and subissues completely, including any comments.
+- Read all files mentioned in the plan
+- **Read files fully** - never use limit/offset parameters, you need complete context
+- Think deeply about how the pieces fit together
+
+
+## Pre-computed Build Results
+
+The following checks have already been run:
+
+| Check | Status |
+|-------|--------|
+| Build | {{BUILD_STATUS}} |
+| Tests | {{TESTS_STATUS}} |
+| Lint | {{LINT_STATUS}} |
+| TypeCheck | {{TYPECHECK_STATUS}} |
+
+### Build Output
+
+```
+{{BUILD_OUTPUT}}
+```
+
+## Your Verification Tasks
+
+Since builds have already been run, focus on:
+
+1. **Review the code changes**:
+   ```bash
+   git log --oneline -5
+   git diff main...HEAD --stat
+   git diff main...HEAD
+   ```
+
+2. **Analyze build failures** (if any):
+   - If build/tests/lint/typecheck failed, identify the root cause
+   - The Iron Law: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
+   - Use the @agent-debug-agent to find the root cause
+   - Once the root cause is found use a general-puspose subagent to implement the fix
+
+3. **Verify feature implementation**:
+   - It is critical to remember that the implementation does not need to be identical to the linear issue as long as it accomplish the overarching goal and all feature verification is confirmed as passing.
+   - Take your time and only move to this step once all build/tests/lint/typecheck failures are fixed.
+   - Review the changes against the linear issue
+   - Review the implementation against the Feature Verification section in each Linear issue. Be skeptical and review each feature indivudually even if it is marked as passing.
+   - Use the @agent-coding-agent to implement any features that are not implemented.
+   - Once you are VERY confident the implementation is complete and correct, mark each issue as `passing` and assign it a status of `Ready for Review`
+
+4. Update spec.txt
+   - Review and update the spec.txt file to reflect any changes to the application.
+
+4. **Commit and Push**:
+   - Once all changes/fixes have been made commit with a descriptive message and push