From 6ed2c6ff9a6e33e5a24befe6dc65323501c478aa Mon Sep 17 00:00:00 2001 From: darrenhinde <107584450+darrenhinde@users.noreply.github.com> Date: Fri, 29 Aug 2025 00:22:06 +0100 Subject: [PATCH] Update subtask naming pattern in codebase-agent.md for consistency --- .opencode/agent/codebase-agent.md | 2 +- .opencode/command/clean.md | 20 ++++ .opencode/command/commit.md | 170 ++++++++++++++++++++++++++++ .opencode/command/context.md | 6 + .opencode/command/test.md | 28 +++++ .opencode/command/worktrees.md | 180 ++++++++++++++++++++++++++++++ 6 files changed, 405 insertions(+), 1 deletion(-) create mode 100644 .opencode/command/clean.md create mode 100644 .opencode/command/commit.md create mode 100644 .opencode/command/context.md create mode 100644 .opencode/command/test.md create mode 100644 .opencode/command/worktrees.md diff --git a/.opencode/agent/codebase-agent.md b/.opencode/agent/codebase-agent.md index 0c21197..60abd23 100644 --- a/.opencode/agent/codebase-agent.md +++ b/.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 diff --git a/.opencode/command/clean.md b/.opencode/command/clean.md new file mode 100644 index 0000000..12fc332 --- /dev/null +++ b/.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. diff --git a/.opencode/command/commit.md b/.opencode/command/commit.md new file mode 100644 index 0000000..b2ebad0 --- /dev/null +++ b/.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 `: ` 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 \ No newline at end of file diff --git a/.opencode/command/context.md b/.opencode/command/context.md new file mode 100644 index 0000000..2031ed2 --- /dev/null +++ b/.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 \ No newline at end of file diff --git a/.opencode/command/test.md b/.opencode/command/test.md new file mode 100644 index 0000000..03bdf92 --- /dev/null +++ b/.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 \ No newline at end of file diff --git a/.opencode/command/worktrees.md b/.opencode/command/worktrees.md new file mode 100644 index 0000000..05684a4 --- /dev/null +++ b/.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. \ No newline at end of file