Update subtask naming pattern in codebase-agent.md for consistency
This commit is contained in:
parent
412d5141c3
commit
6ed2c6ff9a
6 changed files with 405 additions and 1 deletions
|
|
@ -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
|
||||
|
|
|
|||
20
.opencode/command/clean.md
Normal file
20
.opencode/command/clean.md
Normal file
|
|
@ -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.
|
||||
170
.opencode/command/commit.md
Normal file
170
.opencode/command/commit.md
Normal file
|
|
@ -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
|
||||
6
.opencode/command/context.md
Normal file
6
.opencode/command/context.md
Normal file
|
|
@ -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
|
||||
28
.opencode/command/test.md
Normal file
28
.opencode/command/test.md
Normal file
|
|
@ -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
|
||||
180
.opencode/command/worktrees.md
Normal file
180
.opencode/command/worktrees.md
Normal file
|
|
@ -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.
|
||||
Loading…
Reference in a new issue