Update subtask naming pattern in codebase-agent.md for consistency

.opencode/agent/codebase-agent.md

@@ -62,7 +62,7 @@ Code Standards
 
 Subtask Strategy
 
-- When a feature spans multiple modules or is estimated > 60 minutes, delegate planning to `@task-manager` to generate atomic subtasks under `tasks/subtasks/{feature}/` using the `{minutes}-{task-description}-{sequence}.md` pattern and a feature `README.md` index.
+- When a feature spans multiple modules or is estimated > 60 minutes, delegate planning to `@task-manager` to generate atomic subtasks under `tasks/subtasks/{feature}/` using the `{sequence}-{task-description}.md` pattern and a feature `README.md` index.
 - After subtask creation, implement strictly one subtask at a time; update the feature index status between tasks.
 
 Mandatory Workflow

.opencode/command/clean.md

@@ -0,0 +1,20 @@
+---
+description: Clean the codebase
+agent: build
+model: anthropic/claude-3-5-sonnet-20241022
+---
+
+# Code Quality Cleanup
+
+Cleans the codebase by running the following tools on the files or directories specified by $ARGUMENTS:
+
+- Fixes formatting issues with black
+- Organizes imports using isort
+- Resolves linting issues with flake8
+- Checks and corrects type errors with mypy
+
+Run the command with arguments:
+
+/clean src/utils
+
+$ARGUMENTS will be replaced with the target files or directories to clean.

.opencode/command/commit.md

@@ -0,0 +1,170 @@
+---
+description: Create well-formatted commits with conventional commit messages and emoji
+agent: build
+model: anthropic/claude-3-5-sonnet-20241022
+---
+
+# Commit Command
+
+This command helps you create well-formatted commits with conventional commit messages and emoji.
+
+## Usage
+
+To create a commit, just type:
+```
+/commit
+```
+
+Or with options:
+```
+/commit --no-verify
+```
+
+## What This Command Does
+
+1. Unless specified with `--no-verify`, automatically runs pre-commit checks:
+   - `pnpm lint` to ensure code quality
+   - `pnpm build` to verify the build succeeds
+   - `pnpm generate:docs` to update documentation
+2. Checks which files are staged with `git status`
+3. If 0 files are staged, automatically adds all modified and new files with `git add`
+4. Performs a `git diff` to understand what changes are being committed
+5. Analyzes the diff to determine if multiple distinct logical changes are present
+6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
+7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format
+
+## Best Practices for Commits
+
+- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated
+- **Atomic commits**: Each commit should contain related changes that serve a single purpose
+- **Split large changes**: If changes touch multiple concerns, split them into separate commits
+- **Conventional commit format**: Use the format `<type>: <description>` where type is one of:
+  - `feat`: A new feature
+  - `fix`: A bug fix
+  - `docs`: Documentation changes
+  - `style`: Code style changes (formatting, etc.)
+  - `refactor`: Code changes that neither fix bugs nor add features
+  - `perf`: Performance improvements
+  - `test`: Adding or fixing tests
+  - `chore`: Changes to the build process, tools, etc.
+- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
+- **Concise first line**: Keep the first line under 72 characters
+- **Emoji**: Each commit type is paired with an appropriate emoji:
+  - ✨ `feat`: New feature
+  - 🐛 `fix`: Bug fix
+  - 📝 `docs`: Documentation
+  - 💄 `style`: Formatting/style
+  - ♻️ `refactor`: Code refactoring
+  - ⚡️ `perf`: Performance improvements
+  - ✅ `test`: Tests
+  - 🔧 `chore`: Tooling, configuration
+  - 🚀 `ci`: CI/CD improvements
+  - 🗑️ `revert`: Reverting changes
+  - 🧪 `test`: Add a failing test
+  - 🚨 `fix`: Fix compiler/linter warnings
+  - 🔒️ `fix`: Fix security issues
+  - 👥 `chore`: Add or update contributors
+  - 🚚 `refactor`: Move or rename resources
+  - 🏗️ `refactor`: Make architectural changes
+  - 🔀 `chore`: Merge branches
+  - 📦️ `chore`: Add or update compiled files or packages
+  - ➕ `chore`: Add a dependency
+  - ➖ `chore`: Remove a dependency
+  - 🌱 `chore`: Add or update seed files
+  - 🧑‍💻 `chore`: Improve developer experience
+  - 🧵 `feat`: Add or update code related to multithreading or concurrency
+  - 🔍️ `feat`: Improve SEO
+  - 🏷️ `feat`: Add or update types
+  - 💬 `feat`: Add or update text and literals
+  - 🌐 `feat`: Internationalization and localization
+  - 👔 `feat`: Add or update business logic
+  - 📱 `feat`: Work on responsive design
+  - 🚸 `feat`: Improve user experience / usability
+  - 🩹 `fix`: Simple fix for a non-critical issue
+  - 🥅 `fix`: Catch errors
+  - 👽️ `fix`: Update code due to external API changes
+  - 🔥 `fix`: Remove code or files
+  - 🎨 `style`: Improve structure/format of the code
+  - 🚑️ `fix`: Critical hotfix
+  - 🎉 `chore`: Begin a project
+  - 🔖 `chore`: Release/Version tags
+  - 🚧 `wip`: Work in progress
+  - 💚 `fix`: Fix CI build
+  - 📌 `chore`: Pin dependencies to specific versions
+  - 👷 `ci`: Add or update CI build system
+  - 📈 `feat`: Add or update analytics or tracking code
+  - ✏️ `fix`: Fix typos
+  - ⏪️ `revert`: Revert changes
+  - 📄 `chore`: Add or update license
+  - 💥 `feat`: Introduce breaking changes
+  - 🍱 `assets`: Add or update assets
+  - ♿️ `feat`: Improve accessibility
+  - 💡 `docs`: Add or update comments in source code
+  - 🗃️ `db`: Perform database related changes
+  - 🔊 `feat`: Add or update logs
+  - 🔇 `fix`: Remove logs
+  - 🤡 `test`: Mock things
+  - 🥚 `feat`: Add or update an easter egg
+  - 🙈 `chore`: Add or update .gitignore file
+  - 📸 `test`: Add or update snapshots
+  - ⚗️ `experiment`: Perform experiments
+  - 🚩 `feat`: Add, update, or remove feature flags
+  - 💫 `ui`: Add or update animations and transitions
+  - ⚰️ `refactor`: Remove dead code
+  - 🦺 `feat`: Add or update code related to validation
+  - ✈️ `feat`: Improve offline support
+
+## Guidelines for Splitting Commits
+
+When analyzing the diff, consider splitting commits based on these criteria:
+
+1. **Different concerns**: Changes to unrelated parts of the codebase
+2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
+3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
+4. **Logical grouping**: Changes that would be easier to understand or review separately
+5. **Size**: Very large changes that would be clearer if broken down
+
+## Examples
+
+Good commit messages:
+- ✨ feat: add user authentication system
+- 🐛 fix: resolve memory leak in rendering process
+- 📝 docs: update API documentation with new endpoints
+- ♻️ refactor: simplify error handling logic in parser
+- 🚨 fix: resolve linter warnings in component files
+- 🧑‍💻 chore: improve developer tooling setup process
+- 👔 feat: implement business logic for transaction validation
+- 🩹 fix: address minor styling inconsistency in header
+- 🚑️ fix: patch critical security vulnerability in auth flow
+- 🎨 style: reorganize component structure for better readability
+- 🔥 fix: remove deprecated legacy code
+- 🦺 feat: add input validation for user registration form
+- 💚 fix: resolve failing CI pipeline tests
+- 📈 feat: implement analytics tracking for user engagement
+- 🔒️ fix: strengthen authentication password requirements
+- ♿️ feat: improve form accessibility for screen readers
+
+Example of splitting commits:
+- First commit: ✨ feat: add new solc version type definitions
+- Second commit: 📝 docs: update documentation for new solc versions
+- Third commit: 🔧 chore: update package.json dependencies
+- Fourth commit: 🏷️ feat: add type definitions for new API endpoints
+- Fifth commit: 🧵 feat: improve concurrency handling in worker threads
+- Sixth commit: 🚨 fix: resolve linting issues in new code
+- Seventh commit: ✅ test: add unit tests for new solc version features
+- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities
+
+## Command Options
+
+- `--no-verify`: Skip running the pre-commit checks (lint, build, generate:docs)
+
+## Important Notes
+
+- By default, pre-commit checks (`pnpm lint`, `pnpm build`, `pnpm generate:docs`) will run to ensure code quality
+- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
+- If specific files are already staged, the command will only commit those files
+- If no files are staged, it will automatically stage all modified and new files
+- The commit message will be constructed based on the changes detected
+- Before committing, the command will review the diff to identify if multiple commits would be more appropriate
+- If suggesting multiple commits, it will help you stage and commit the changes separately
+- Always reviews the commit diff to ensure the message matches the changes

.opencode/command/context.md

@@ -0,0 +1,6 @@
+---
+description: Get the context of the project
+agent: plan
+model: anthropic/claude-3-5-sonnet-20241022
+---
+Read README.md, THEN run `git ls-files | grep -v -f (sed 's|^|^|; s|$|/|' .cursorignore | psub)` to understand the context of the project

.opencode/command/test.md

@@ -0,0 +1,28 @@
+---
+description: Run the complete testing pipeline
+agent: build
+model: anthropic/claude-3-5-sonnet-20241022
+---
+
+# Testing Pipeline
+
+This command runs the complete testing pipeline for the project.
+
+## Usage
+
+To run the complete testing pipeline, just type:
+
+1. Run pnpm type:check
+2. Run pnpm lint
+3. Run pnpm test
+4. Report any failures
+5. Fix any failures
+6. Repeat until all tests pass
+7. Report success
+
+## What This Command Does
+
+1. Runs `pnpm type:check` to check for type errors
+2. Runs `pnpm lint` to check for linting errors
+3. Runs `pnpm test` to run the tests
+4. Reports any failures

.opencode/command/worktrees.md

@@ -0,0 +1,180 @@
+---
+description: Create worktrees for all open PRs
+agent: build
+model: anthropic/claude-3-5-sonnet-20241022
+---
+
+# Git Worktree Commands
+
+## Create Worktrees for All Open PRs
+
+This command fetches all open pull requests using GitHub CLI, then creates a git worktree for each PR's branch in the `./tree/$ARGUMENTS` directory.
+
+```bash
+# Ensure GitHub CLI is installed and authenticated
+gh auth status || (echo "Please run 'gh auth login' first" && exit 1)
+
+# Create the tree directory if it doesn't exist
+mkdir -p ./tree
+
+# List all open PRs and create worktrees for each branch
+gh pr list --json headRefName --jq '.[].headRefName' | while read branch; do
+  # Handle branch names with slashes (like "feature/foo")
+  branch_path="./tree/${branch}"
+  
+  # For branches with slashes, create the directory structure
+  if [[ "$branch" == */* ]]; then
+    dir_path=$(dirname "$branch_path")
+    mkdir -p "$dir_path"
+  fi
+
+  # Check if worktree already exists
+  if [ ! -d "$branch_path" ]; then
+    echo "Creating worktree for $branch"
+    git worktree add "$branch_path" "$branch"
+  else
+    echo "Worktree for $branch already exists"
+  fi
+done
+
+# Display all created worktrees
+echo "\nWorktree list:"
+git worktree list
+```
+
+### Example Output
+
+```
+Creating worktree for fix-bug-123
+HEAD is now at a1b2c3d Fix bug 123
+Creating worktree for feature/new-feature
+HEAD is now at e4f5g6h Add new feature
+Worktree for documentation-update already exists
+
+Worktree list:
+/path/to/repo                      abc1234 [main]
+/path/to/repo/tree/fix-bug-123     a1b2c3d [fix-bug-123]
+/path/to/repo/tree/feature/new-feature e4f5g6h [feature/new-feature]
+/path/to/repo/tree/documentation-update d5e6f7g [documentation-update]
+```
+
+### Cleanup Stale Worktrees (Optional)
+
+You can add this to remove stale worktrees for branches that no longer exist:
+
+```bash
+# Get current branches
+current_branches=$(git branch -a | grep -v HEAD | grep -v main | sed 's/^[ *]*//' | sed 's|remotes/origin/||' | sort | uniq)
+
+# Get existing worktrees (excluding main worktree)
+worktree_paths=$(git worktree list | tail -n +2 | awk '{print $1}')
+
+for path in $worktree_paths; do
+  # Extract branch name from path
+  branch_name=$(basename "$path")
+  
+  # Skip special cases
+  if [[ "$branch_name" == "main" ]]; then
+    continue
+  fi
+  
+  # Check if branch still exists
+  if ! echo "$current_branches" | grep -q "^$branch_name$"; then
+    echo "Removing stale worktree for deleted branch: $branch_name"
+    git worktree remove --force "$path"
+  fi
+done
+```
+
+## Create New Branch and Worktree
+
+This interactive command creates a new git branch and sets up a worktree for it:
+
+```bash
+#!/bin/bash
+
+# Ensure we're in a git repository
+if ! git rev-parse --is-inside-work-tree > /dev/null 2>&1; then
+  echo "Error: Not in a git repository"
+  exit 1
+fi
+
+# Get the repository root
+repo_root=$(git rev-parse --show-toplevel)
+
+# Prompt for branch name
+read -p "Enter new branch name: " branch_name
+
+# Validate branch name (basic validation)
+if [[ -z "$branch_name" ]]; then
+  echo "Error: Branch name cannot be empty"
+  exit 1
+fi
+
+if git show-ref --verify --quiet "refs/heads/$branch_name"; then
+  echo "Warning: Branch '$branch_name' already exists"
+  read -p "Do you want to use the existing branch? (y/n): " use_existing
+  if [[ "$use_existing" != "y" ]]; then
+    exit 1
+  fi
+fi
+
+# Create branch directory
+branch_path="$repo_root/tree/$branch_name"
+
+# Handle branch names with slashes (like "feature/foo")
+if [[ "$branch_name" == */* ]]; then
+  dir_path=$(dirname "$branch_path")
+  mkdir -p "$dir_path"
+fi
+
+# Make sure parent directory exists
+mkdir -p "$(dirname "$branch_path")"
+
+# Check if a worktree already exists
+if [ -d "$branch_path" ]; then
+  echo "Error: Worktree directory already exists: $branch_path"
+  exit 1
+fi
+
+# Create branch and worktree
+if git show-ref --verify --quiet "refs/heads/$branch_name"; then
+  # Branch exists, create worktree
+  echo "Creating worktree for existing branch '$branch_name'..."
+  git worktree add "$branch_path" "$branch_name"
+else
+  # Create new branch and worktree
+  echo "Creating new branch '$branch_name' and worktree..."
+  git worktree add -b "$branch_name" "$branch_path"
+fi
+
+echo "Success! New worktree created at: $branch_path"
+echo "To start working on this branch, run: cd $branch_path"
+```
+
+### Example Usage
+
+```
+$ ./create-branch-worktree.sh
+Enter new branch name: feature/user-authentication
+Creating new branch 'feature/user-authentication' and worktree...
+Preparing worktree (creating new branch 'feature/user-authentication')
+HEAD is now at abc1234 Previous commit message
+Success! New worktree created at: /path/to/repo/tree/feature/user-authentication
+To start working on this branch, run: cd /path/to/repo/tree/feature/user-authentication
+```
+
+### Creating a New Branch from a Different Base
+
+If you want to start your branch from a different base (not the current HEAD), you can modify the script:
+
+```bash
+read -p "Enter new branch name: " branch_name
+read -p "Enter base branch/commit (default: HEAD): " base_commit
+base_commit=${base_commit:-HEAD}
+
+# Then use the specified base when creating the worktree
+git worktree add -b "$branch_name" "$branch_path" "$base_commit"
+```
+
+This will allow you to specify any commit, tag, or branch name as the starting point for your new branch.