cclohmar/OpenWriterControle
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

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

Browse source
This commit is contained in:
darrenhinde 2025-08-29 00:22:06 +01:00
parent 412d5141c3
commit 6ed2c6ff9a
6 changed files with 405 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
.opencode/agent/codebase-agent.md
View file

@ -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
View 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
View 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
View 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
View 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
View 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.