@codyswann/lisa 1.0.0

package/all/copy-overwrite/.claude/commands/project/plan.md

@@ -0,0 +1,314 @@
+---
+description: Uses the research.md and brief.md file in the specified directory to create a detailed list of tasks to implement the project
+argument-hint: <project-directory>
+---
+
+## Step 0: MANDATORY SETUP
+
+Use TodoWrite to create workflow tracking todos:
+- Step 1: Read project files
+- Step 2: Validate research
+- Step 3: Discover skills
+- Step 4: Create task list
+- Step 5: Create task files
+- Step 6: Commit plan
+
+⚠️ **CRITICAL**: DO NOT STOP until all 6 todos are marked completed.
+
+## Step 1: Read Project Files
+Mark "Step 1: Read project files" as in_progress.
+
+1. Read the `brief.md` file inside $ARGUMENTS FULLY (no limit/offset)
+2. Read the `research.md` file inside $ARGUMENTS FULLY (no limit/offset)
+
+Mark "Step 1: Read project files" as completed. Proceed to Step 2.
+
+## Step 2: Validate Research
+Mark "Step 2: Validate research" as in_progress.
+
+**VALIDATE RESEARCH COMPLETENESS**:
+- Locate the "## Open Questions" section in the research.md file you just read
+- Examine the content under this section carefully
+
+**VALID STATES** (proceed to Step 3):
+✅ Section contains "None", "[None identified]", "N/A", or is empty
+✅ Section doesn't exist at all
+✅ Section contains questions BUT all `**Answer**:` fields are filled (not empty, not placeholder text like "_[Human fills this in]_")
+
+**INVALID STATE** (stop immediately):
+❌ Section contains questions with unfilled `**Answer**:` fields (empty or placeholder text)
+❌ Section contains unstructured questions without Answer fields
+- If INVALID state is detected, **STOP IMMEDIATELY** and report:
+
+  ```
+  ❌ CANNOT PROCEED WITH PLANNING
+
+  The research.md file has unanswered open questions that must be addressed before planning can begin.
+
+  Unanswered Questions Found:
+  [List each question title and its Question field]
+
+  Action Required:
+  1. Review $ARGUMENTS/research.md "## Open Questions" section
+  2. Fill in the **Answer**: field for each question
+  3. Re-run /project:plan
+
+  Planning has been aborted.
+  ```
+
+**IMPORTANT**: NEVER modify, delete, or replace any existing sections in research.md during validation.
+Only READ and VALIDATE. The research.md file is a historical record and must be preserved as-is.
+
+Mark "Step 2: Validate research" as completed. Proceed to Step 3.
+
+## Step 3: Discover Skills
+Mark "Step 3: Discover skills" as in_progress.
+
+**DISCOVER APPLICABLE SKILLS**:
+- Read all skill descriptions by examining `.claude/skills/*/SKILL.md` files (read only the frontmatter description, first 10 lines of each)
+- For each skill, determine if it applies to ANY task in this project based on brief.md requirements
+- Create a mental map of: skill name → when it applies (e.g., "container-view-pattern → when creating React components")
+- You will use this mapping in Step 5 to annotate each task with its applicable skills
+
+Mark "Step 3: Discover skills" as completed. Proceed to Step 4.
+
+## Step 4: Create Task List
+Mark "Step 4: Create task list" as in_progress.
+
+1. Determine a list of tasks required to complete the project
+2. **CRITICAL: Each task must be small enough to have a single, specific verification**
+   - If a task would require multiple verifications, split it into smaller tasks
+   - Ask: "Can I prove this task is done with ONE command or check?"
+   - **Exception for multi-platform UI recordings**: Tasks with `ui-recording` verification may have one proof command per platform (web/iOS/Android) since the same UI feature must be verified on each target platform
+   - Examples of properly-sized tasks:
+     - ✅ "Add logout button to header" → single Playwright test verifies button exists and works
+     - ✅ "Add unit tests for UserService" → single coverage command shows UserService coverage
+     - ✅ "Create API endpoint for user profile" → single curl command returns expected response
+     - ❌ "Build authentication system" → too large, needs multiple verifications (split into login, logout, session, etc.)
+     - ❌ "Add user management feature" → too large (split into list users, create user, edit user, etc.)
+3. Write that list of tasks to `progress.md` inside $ARGUMENTS
+
+Mark "Step 4: Create task list" as completed. Proceed to Step 5.
+
+## Step 5: Create Task Files
+Mark "Step 5: Create task files" as in_progress.
+
+For each task in `progress.md`, create a new file called `tasks/000<step-number>-<task-name>.md`
+
+**For each task, create a file using this template:**
+
+```markdown
+# Task: [Task Name]
+
+**Type:** Bug | Task | Epic | Story
+**Parent:** [Parent Task Name, or "None"]
+
+## Description
+
+[Write a clear description based on task type:
+- **Bug**: Describe the bug, symptoms, and root cause analysis approach
+- **Story**: Use Gherkin BDD format (Given/When/Then)
+- **Task**: Straightforward description with clear goal
+- **Epic**: Goal overview with list of sub-tasks]
+
+## Acceptance Criteria
+
+[Specific, testable criteria that define "done" for this task]
+
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+## Relevant Research
+
+[Extract and summarize relevant sections from research.md, including:
+- Code references (file:line) that will be modified or referenced
+- Patterns to follow from the codebase
+- Architecture constraints that apply
+- Any resolved questions that affect this task]
+
+## Applicable Skills
+
+Invoke these skills before writing implementation code:
+
+- `/coding-philosophy` - Always required for all code
+- [Add other skills from Step 3 that apply to THIS SPECIFIC task]
+
+## Implementation Details
+
+[Specific implementation guidance:
+- Files to create or modify
+- Functions/classes to implement
+- Integration points with existing code
+- Edge cases to handle]
+
+## Testing Requirements
+
+### Unit Tests
+[List specific unit tests required. Reference patterns from research.md]
+
+- [ ] `describe('X')/it('should Y')`: Test description
+- [ ] `describe('X')/it('should Y')`: Test description
+
+### Integration Tests
+[List integration tests required, or "N/A - no integration points"]
+
+- [ ] Test description
+
+### E2E Tests
+[List e2e tests required, or "N/A - no user-facing changes"]
+
+- [ ] Test scenario description
+
+## Documentation Requirements
+
+### Code Documentation (JSDoc)
+[List functions/types needing JSDoc, or "N/A"]
+
+- [ ] `functionName` - @param, @returns, @throws
+- [ ] `TypeName` - @description
+
+### Database Comments
+[List tables/columns needing comments, or "N/A - no database changes"]
+
+- [ ] `table.column` - purpose description
+
+### GraphQL Descriptions
+[List types/fields needing descriptions, or "N/A - no GraphQL changes"]
+
+- [ ] `Type.field` - purpose description
+
+## Verification
+
+### Type
+[One of: `ui-recording` | `test-coverage` | `api-test` | `manual-check` | `documentation`]
+
+### Proof Command
+```bash
+[Single command to verify task completion - must be specific to THIS task]
+```
+
+<!-- For ui-recording on multi-platform apps, provide one command per platform:
+#### Web
+```bash
+bun run playwright:test e2e/feature.spec.ts --grep "specific test" --trace on
+```
+
+#### iOS
+```bash
+maestro test .maestro/flows/feature-test.yaml --platform ios
+```
+
+#### Android
+```bash
+maestro test .maestro/flows/feature-test.yaml --platform android
+```
+-->
+
+<!-- For api-test, create a documented bash script at scripts/verify/<task-name>.sh:
+- Script must support -h and --help flags with usage documentation
+- Script must handle authentication if required
+- Script must return exit code 0 on success, non-zero on failure
+- Script must output clear success/failure message
+
+Example:
+```bash
+./scripts/verify/user-profile-api.sh --help
+./scripts/verify/user-profile-api.sh
+```
+-->
+
+### Expected Output
+[What the proof command output should show to confirm success]
+
+## Implementation Steps
+
+### Step 0: Setup Tracking
+Use TodoWrite to create task tracking todos:
+- Invoke skills
+- Write failing tests
+- Write implementation
+- Verify implementation
+- Update documentation
+- Commit changes
+
+⚠️ **CRITICAL**: DO NOT STOP until all todos are marked completed.
+
+### Step 1: Invoke Skills
+Mark "Invoke skills" as in_progress.
+
+1. Mark this task as "in progress" in `progress.md`
+2. Invoke each skill listed in "Applicable Skills" using the Skill tool
+
+Mark "Invoke skills" as completed.
+
+### Step 2: Write Failing Tests
+Mark "Write failing tests" as in_progress.
+
+1. Write unit tests based on Testing Requirements
+2. Write integration tests based on Testing Requirements
+3. Run tests to confirm they fail (TDD)
+
+Mark "Write failing tests" as completed.
+
+### Step 3: Write Implementation
+Mark "Write implementation" as in_progress.
+
+Implement code following Implementation Details until tests pass.
+
+Mark "Write implementation" as completed.
+
+### Step 4: Verify Implementation
+Mark "Verify implementation" as in_progress.
+
+1. Run the Proof Command from Verification section
+2. Confirm output matches Expected Output
+3. If verification fails, fix and re-verify
+
+Mark "Verify implementation" as completed.
+
+### Step 5: Update Documentation
+Mark "Update documentation" as in_progress.
+
+Complete all items in Documentation Requirements section.
+
+Mark "Update documentation" as completed.
+
+### Step 6: Commit Changes
+Mark "Commit changes" as in_progress.
+
+1. Run `/git:commit`
+2. Mark this task as "completed" in `progress.md`
+3. Record any learnings in `findings.md`
+
+Mark "Commit changes" as completed.
+```
+
+---
+
+**Verification Type Reference:**
+
+| Type | When to Use | Example Command |
+|------|-------------|-----------------|
+| `ui-recording` | UI/UX changes visible to users | Web: `bun run playwright:test ...`, iOS/Android: `maestro test ...` |
+| `test-coverage` | New code with tests | `bun run test:cov -- --collectCoverageFrom='src/path/to/file.ts'` |
+| `api-test` | New API endpoints | `./scripts/verify/<task-name>.sh` (documented script with -h/--help) |
+| `documentation` | Docs, README updates | `cat path/to/doc.md` |
+| `manual-check` | Config, setup, infrastructure | Command showing the config/state exists |
+
+Mark "Step 5: Create task files" as completed. Proceed to Step 6.
+
+## Step 6: Commit Plan
+Mark "Step 6: Commit plan" as in_progress.
+
+Run /git:commit
+
+Mark "Step 6: Commit plan" as completed.
+
+Report: "📋 Planning complete - X tasks created"
+
+---
+
+IMPORTANT: Each task should contain all the necessary information from `brief.md` and `research.md` and any other support files necessary to complete the task in isolation. Tasks should be completely independent of one another and be as small in scope as possible.
+
+IMPORTANT: If, at the end of a task, the pre-commit blocks you because it is dependent on another task, complete the other task first and then commit.

package/all/copy-overwrite/.claude/commands/project/research.md

@@ -0,0 +1,248 @@
+---
+description: Conducts research of your code base and the web relevant to your project and compiles it for the planning phase
+argument-hint: <project-directory>
+---
+
+# Research Codebase
+
+You are tasked with conducting comprehensive research across the codebase and web that will help create an implementation plan for the brief in $ARGUMENTS
+
+Goals:
+
+1. Determine what existing documentation in the codebase will be needed to fulfill the spec
+2. Determine any gaps in the spec that would prevent a developer from fulfilling the acceptance criteria
+3. Determine any potential pitfalls that should be considered such as performance or security concerns
+4. Determine what code, functions, and modules currently exist within the codebase that could be reused during implementation
+5. Determine testing patterns and locations in the codebase (frameworks, conventions, examples to follow)
+6. Determine documentation patterns in the codebase (JSDoc conventions, DB comment conventions, GraphQL description conventions)
+
+Note: Task-specific concerns (acceptance criteria, specific tests to write, specific documentation to create) are determined during the Planning phase on a per-task basis.
+
+## Step 0: MANDATORY SETUP
+
+Create workflow tracking todos:
+- Step 1: Read mentioned files
+- Step 2: Analyze and decompose
+- Step 3: Spawn research agents
+- Step 4: Wait and synthesize
+- Step 5: Generate document
+- Step 6: Commit
+
+⚠️ **CRITICAL**: DO NOT STOP until all 6 todos are marked completed.
+
+## CRITICAL: YOUR ONLY JOB IS TO DOCUMENT AND EXPLAIN THE CODEBASE AS IT EXISTS TODAY
+
+- DO NOT suggest improvements or changes unless the user explicitly asks for them
+- DO NOT perform root cause analysis unless the user explicitly asks for them
+- DO NOT propose future enhancements unless the user explicitly asks for them
+- DO NOT critique the implementation or identify problems
+- DO NOT recommend refactoring, optimization, or architectural changes
+- ONLY describe what exists, where it exists, how it works, and how components interact
+- You are creating a technical map/documentation of the existing system
+
+## Step 1: Read Mentioned Files
+Mark "Step 1: Read mentioned files" as in_progress.
+
+**Read any directly mentioned files first:**
+- If the user mentions specific files (tickets, docs, JSON), read them FULLY first
+- **IMPORTANT**: Use the Read tool WITHOUT limit/offset parameters to read entire files
+- **CRITICAL**: Read these files yourself in the main context before spawning any sub-tasks
+- This ensures you have full context before decomposing the research
+
+Mark "Step 1: Read mentioned files" as completed. Proceed to Step 2.
+
+## Step 2: Analyze and Decompose
+Mark "Step 2: Analyze and decompose" as in_progress.
+
+**Analyze and decompose the research question:**
+- Break down the brief into composable research areas
+- Take time to ultrathink about the underlying patterns, connections, and architectural implications
+- Identify specific components, patterns, or concepts to investigate
+- Create a research plan using TodoWrite to track all subtasks
+- Consider which directories, files, or architectural patterns are relevant
+
+Mark "Step 2: Analyze and decompose" as completed. Proceed to Step 3.
+
+## Step 3: Spawn Research Agents
+Mark "Step 3: Spawn research agents" as in_progress.
+
+**Spawn parallel sub-agent tasks for comprehensive research:**
+- Create multiple Task agents to research different aspects concurrently
+- We now have specialized agents that know how to do specific research tasks:
+
+**For codebase research:**
+- Use the **codebase-locator** agent to find WHERE files and components live
+- Use the **codebase-analyzer** agent to understand HOW specific code works (without critiquing it)
+- Use the **codebase-pattern-finder** agent to find examples of existing patterns (without evaluating them)
+- Use the **git-history-analyzer** agent to understand what changes the file has undergone that may affect the implementation plan
+
+**For e2e test research:**
+- Use the **codebase-locator** agent to find existing e2e tests in `e2e/` or `tests/` directories that relate to the feature being modified
+- Use the **codebase-analyzer** agent to document what scenarios each relevant test covers
+- Identify tests that will need modification due to UI/flow changes
+- Identify tests that may need to be removed if features are deprecated
+- Identify gaps where new tests will be needed for new functionality
+- Document the test file paths and what each test validates
+
+**IMPORTANT**: All agents are documentarians, not critics. They will describe what exists without suggesting improvements or identifying issues.
+
+**For web research:**
+- Use the **web-search-researcher** agent for external documentation and resources
+- IF you use web-research agents, instruct them to return LINKS with their findings, and please INCLUDE those links in your final report
+
+The key is to use these agents intelligently:
+- Start with locator agents to find what exists
+- Then use analyzer agents on the most promising findings to document how they work
+- Run multiple agents in parallel when they're searching for different things
+- Each agent knows its job - just tell it what you're looking for
+- Don't write detailed prompts about HOW to search - the agents already know
+- Remind agents they are documenting, not evaluating or improving
+
+Mark "Step 3: Spawn research agents" as completed. Proceed to Step 4.
+
+## Step 4: Wait and Synthesize
+Mark "Step 4: Wait and synthesize" as in_progress.
+
+**Wait for all sub-agents to complete and synthesize findings:**
+- ⚠️ **CRITICAL**: Wait for ALL sub-agent tasks to complete before proceeding
+- DO NOT proceed to Step 5 until every spawned Task has returned
+- Compile all sub-agent results (both codebase and thoughts findings)
+- Prioritize live codebase findings as primary source of truth
+- Connect findings across different components
+- Include specific file paths and line numbers for reference
+- Highlight patterns, connections, and architectural decisions
+- Include any frameworks used such as Ruby on Rails, NestJs, Expo, React, React Native, Vue, etc
+- If a framework is used, identify what portions of the framework are relevant to the given project (i.e. ActiveRecord, NestJs Service's, dependency injection, etc)
+
+Mark "Step 4: Wait and synthesize" as completed. Proceed to Step 5.
+
+## Step 5: Generate Document
+Mark "Step 5: Generate document" as in_progress.
+
+**Generate research document:**
+- Structure the document with YAML frontmatter followed by content:
+
+  ```markdown
+  ---
+  date: [Current date and time with timezone in ISO format]
+  status: complete
+  last_updated: [Current date in YYYY-MM-DD format]
+  ---
+
+  # Research
+
+  ## Summary
+
+  [High-level documentation of what was found]
+
+  ## Detailed Findings
+
+  ### [Component/Area 1]
+
+  - Description of what exists ([file.ext:line](link))
+  - How it connects to other components
+  - Current implementation details (without evaluation)
+
+  ### [Component/Area 2]
+
+  ...
+
+  ## Code References
+
+  - `path/to/file.py:123` - Description of what's there
+  - `another/file.ts:45-67` - Description of the code block
+
+  ## Architecture Documentation
+
+  [Current patterns, conventions, and design implementations found in the codebase]
+
+  ## Testing Patterns
+
+  ### Unit Test Patterns
+  - **Location**: `src/**/__tests__/*.test.ts` (or actual pattern found)
+  - **Framework**: Jest/Vitest/etc.
+  - **Example to follow**: `path/to/example.test.ts:line-range`
+  - **Conventions**: [Describe naming, structure, mock patterns]
+
+  ### Integration Test Patterns
+  - **Location**: `src/**/*.integration.test.ts` (or actual pattern found)
+  - **Example to follow**: `path/to/example.integration.test.ts`
+  - **Conventions**: [Describe setup, teardown, database handling]
+
+  ### E2E Test Patterns
+  - **Location**: `e2e/*.spec.ts` (or actual pattern found)
+  - **Framework**: Playwright/Cypress/Maestro/etc.
+  - **Example to follow**: `path/to/example.spec.ts`
+  - **Conventions**: [Describe page objects, fixtures, assertions]
+
+  ## Documentation Patterns
+
+  ### JSDoc Conventions
+  - **Style**: [Describe the JSDoc style used in this codebase]
+  - **Example**: `path/to/well-documented-file.ts:line-range`
+  - **Required tags**: [@param, @returns, @throws, etc.]
+
+  ### Database Comments (Backend Only)
+  - **Convention**: [How tables/columns are documented]
+  - **Example**: `path/to/entity.ts` or migration file
+  - **Required for**: [New tables, new columns, complex relationships]
+
+  ### GraphQL Descriptions (Backend Only)
+  - **Convention**: [How types/fields are documented]
+  - **Example**: `path/to/resolver.ts` or schema file
+  - **Required for**: [Public API fields, complex types]
+
+  ## Open Questions
+
+  <!--
+  Structure each question with context and impact.
+  The Answer field must be filled by a human before planning can proceed.
+  -->
+
+  ### Q1: [Short Question Title]
+  **Question**: [Full question]
+  **Context**: [Why this question arose, what in the brief is unclear]
+  **Impact**: [What parts of implementation this affects]
+  **Answer**: _[Human fills this in before running /project:plan]_
+
+  <!-- Add more questions as needed using the same format -->
+  <!-- If no questions, replace this section with: [None identified] -->
+  ```
+
+- Save the research document as `research.md` in the $ARGUMENTS directory
+
+Mark "Step 5: Generate document" as completed. Proceed to Step 6.
+
+## Step 6: Commit
+Mark "Step 6: Commit" as in_progress.
+
+Run /git:commit
+
+Mark "Step 6: Commit" as completed.
+
+## Important notes:
+
+- Always use parallel Task agents to maximize efficiency and minimize context usage
+- Always run fresh codebase research - never rely solely on existing research documents
+- Focus on finding concrete file paths and line numbers for developer reference
+- Research documents should be self-contained with all necessary context
+- Each sub-agent prompt should be specific and focused on read-only documentation operations
+- Document cross-component connections and how systems interact
+- Include temporal context (when the research was conducted)
+- Keep the main agent focused on synthesis, not deep file reading
+- Have sub-agents document examples and usage patterns as they exist
+- **CRITICAL**: You and all sub-agents are documentarians, not evaluators
+- **REMEMBER**: Document what IS, not what SHOULD BE
+- **NO RECOMMENDATIONS**: Only describe the current state of the codebase
+- **File reading**: Always read mentioned files FULLY (no limit/offset) before spawning sub-tasks
+- **Critical ordering**: Follow the numbered steps exactly
+  - ALWAYS read mentioned files first before spawning sub-tasks (step 1)
+  - ALWAYS wait for all sub-agents to complete before synthesizing (step 4)
+  - ALWAYS gather metadata before writing the document (step 5 before step 6)
+  - NEVER write the research document with placeholder values
+- **Frontmatter consistency**:
+  - Always include frontmatter at the beginning of research documents
+  - Keep frontmatter fields consistent across all research documents
+  - Update frontmatter when adding follow-up research
+  - Use snake_case for multi-word field names (e.g., `last_updated`)
+  - Tags should be relevant to the research topic and components studied

package/all/copy-overwrite/.claude/commands/project/review.md

@@ -0,0 +1,63 @@
+---
+description: Performs extensive code review and optimization on the current project
+argument-hint: <project-directory>
+---
+
+The current branch is a feature branch that contains full implementation of the project described in $ARGUMENTS
+
+IMPORTANT: Perform each step and then move to the next one without stopping
+
+## Step 0: MANDATORY SETUP
+
+Use TodoWrite to create workflow tracking todos:
+- Step 1: Perform Claude Review
+- Step 2: Implement Claude Review Fixes
+- Step 3: Perform CodeRabbit Review
+- Step 4: Implement CodeRabbit Review Fixes
+- Step 5: Perform Claude Optimizations
+
+## Step 1: Perform Claude Review
+
+Mark "Step 1: Perform Claude Review" as in_progress.
+
+If $ARGUMENTS/claude-review.md already exists, Mark "Step 1: Perform Claude Review" as completed. Proceed to Step 2
+
+Otherwise, run /local-code-review $ARGUMENTS
+
+Mark "Step 1: Perform Claude Review" as completed. Proceed to Step 2
+
+## Step 2: Implement Claude Review Fixes
+
+Mark "Step 2: Implement Claude Review Fixes" as in_progress.
+
+1. Read $ARGUMENTS/claude-review.md 
+2. Fix any suggestions that score above 45 in $ARGUMENTS/claude-review.md 
+
+Mark "Step 2: Implement Claude Review Fixes" as completed. Proceed to Step 3
+
+## Step 3: Perform CodeRabbit Review
+
+Mark "Step 3: Perform CodeRabbit Review" as in_progress.
+
+If $ARGUMENTS/coderabbit-review.md already exists, Mark "Step 3: Perform CodeRabbit Review" as completed. Proceed to Step 4
+
+Otherwise, use Task tool with prompt: "Run !`coderabbit review --plain || true` to get comprehensive code analysis and improvement suggestions and write the results to $ARGUMENTS/coderabbit-review.md"
+
+Mark "Step 3: Perform CodeRabbit Review" as completed. Proceed to Step 4
+
+## Step 4: Implement CodeRabbit Review Fixes
+
+Mark "Step 4: Implement CodeRabbit Review Fixes" as in_progress.
+
+Evaluate the suggestions in $ARGUMENTS/coderabbit-review.md and implement fixes/changes for any valid findings
+
+Mark "Step 4: Implement CodeRabbit Review Fixes" as completed. Proceed to Step 5
+
+## Step 5: Perform Claude Optimizations
+
+Mark "Step 5: Perform Claude Optimizations" as in_progress.
+
+Use the code simplifier agent to clean up the code that was added to the current branch.
+
+Mark "Step 5: Perform Claude Optimizations" as completed. 
+

package/all/copy-overwrite/.claude/commands/project/setup.md

@@ -0,0 +1,19 @@
+---
+description: Initialize a comprehensive NestJS backend project with full requirements analysis, planning, and structure setup
+argument-hint: <project-brief-file-or-jira-issue-number>
+allowed-tools: Read, Write, Bash(git*), Glob, Grep, Task, TodoWrite
+---
+
+1. Decide if $ARGUMENTS is a Jira issue number or a path to a file
+2. If $ARGUMENTS is a Jira issue number
+   1. Use the atlassian MCP server to Read the issue FULLY. If the MCP server is not working, STOP WORKING AND LET THE HUMAN KNOW
+   2. Otherwise: $ARGUMENTS is a brief for a project. Read it FULLY (no limit/offset)
+3. Create a project directory in projects/ that is appropriately named for the project and prefixed with today's date like `YYYY-MM-DD-<project-name>`
+4. If $ARGUMENTS is a Jira issue number
+   1. Create a file called `brief.md` in the newly created project directory and populate it with the jira issue number, title and description
+   2. Otherwise: Move $ARGUMENTS into the newly created project directory and rename it `brief.md`
+5. Create an empty file in the new project directory called `findings.md`
+6. If $ARGUMENTS is a Jira issue number
+   1. run /git:commit and add the jira issue number to the newly created branch (e.g. feature/SE-111-<branch-name>)
+   2. OTHERWISE: run /git:commit
+7. If $ARGUMENTS is a Jira issue number Use the atlassian MCP server to update the issue with status "In Progress"

package/all/copy-overwrite/.claude/commands/project/verify.md

@@ -0,0 +1,38 @@
+---
+description: Comprehensive verification that a feature branch fully implements all project requirements with proper code quality, tests, and documentation
+argument-hint: <project-directory>
+---
+
+The current branch is a feature branch that contains full implementation of the project described in $ARGUMENTS
+
+## Step 0: MANDATORY SETUP
+
+Use TodoWrite to create workflow tracking todos:
+- Step 1: Review Requirements for $ARGUMENTS
+- Step 2: Verify Implementation
+- Step 3: Document Drift
+
+## Step 1: Review Requirements
+
+Mark "Step 1: Review Requirements" as in_progress.
+
+Read all the requirements for $ARGUMENTS
+
+Mark "Step 1: Review Requirements" as completed. Proceed to Step 2
+
+## Step 2: Verify Implementation
+
+Mark "Step 2: Verify Implementation" as in_progress.
+
+Verify that the implementation completely and fully satisfies all the requirements from Step 1
+
+Mark "Step 2: Verify Implementation" as completed. Proceed to Step 3
+
+
+## Step 3: Document Drift
+
+Mark "Step 3: Document Drift" as in_progress.
+
+IF there is any divergence from the requirements, document what this drift is to $ARGUMENTS/drift.md
+
+Mark "Step 3: Document Drift" as completed.