| name | feature-workflow |
| description | Standard workflow for developing features. Follow this process for all non-trivial changes - from planning through PR merge. Ensures proper testing, review, and CI verification. |
| metadata | {"author":"opencode-reflection-plugin","version":"1.0"} |
Feature Development Workflow
A structured 11-step process for developing features that ensures quality, traceability, and proper review.
Prerequisites
- Git repository initialized
- GitHub CLI (
gh) authenticated
- Access to run tests (unit and E2E)
- Todo tool available for tracking progress
The 11-Step Process
Step 1: Create a Plan
Before writing any code, plan the work:
## Feature: [Name]
### Goal
[One sentence describing what we're building]
### Why
[Problem this solves or value it provides]
### Scope
- [ ] What's included
- [ ] What's NOT included (explicit boundaries)
### Technical Approach
1. [High-level step 1]
2. [High-level step 2]
3. [etc.]
### Risks / Open Questions
- [Any unknowns or concerns]
Use the Todo tool to capture each major task from the plan.
Step 2: Create GitHub Issue (if not exists)
Check for existing issue or create one:
gh issue list --repo OWNER/REPO --search "feature keywords"
gh issue create --repo OWNER/REPO \
--title "feat: [Feature Name]" \
--body "$(cat <<'EOF'
## Summary
[Brief description]
## Motivation
[Why this is needed]
## Proposed Solution
[High-level approach]
## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Tests pass
- [ ] Documentation updated
EOF
)"
Record the issue number for linking in commits and PR.
Step 3: Define Task Scope in Issue
Update the issue with detailed scope:
gh issue comment ISSUE_NUMBER --body "$(cat <<'EOF'
## Implementation Plan
### Design
[Architecture decisions, data flow, etc.]
### Files to Modify
- `path/to/file1.ts` - [what changes]
- `path/to/file2.ts` - [what changes]
### New Files
- `path/to/new.ts` - [purpose]
### Testing Strategy
- Unit tests for [X]
- E2E tests for [Y]
- Manual verification of [Z]
### Out of Scope
- [Explicitly list what this PR won't do]
EOF
)"
Step 4: Fetch Latest Changes
Always start from up-to-date main:
git fetch origin
git status
If you have uncommitted changes, either:
- Commit them to current branch
- Stash them:
git stash
- Discard them:
git checkout -- .
Step 5: Create Feature Branch
Branch naming convention: feat/issue-number-short-description
git checkout -b feat/123-add-telegram-replies origin/main
git checkout -b fix/456-race-condition origin/main
Update Todo tool: Mark "Create branch" as complete.
Step 6: Implement the Feature
Write the code following these principles:
- Small, focused commits - Each commit should be atomic
- Commit message format:
type(scope): short description
- Detail 1
- Detail 2
Closes #123
- Types:
feat, fix, refactor, test, docs, chore
- Reference issue in commits:
#123 or Closes #123
Update Todo tool after each significant piece of work.
Step 7: Test End-to-End (No Mocks)
Critical: Real testing, not mocked data.
npm run typecheck
npm test
OPENCODE_E2E=1 npm run test:e2e
If tests fail, fix before proceeding. Do not skip failing tests.
Add automated tests for new functionality:
- Unit tests for pure logic
- Integration tests for component interactions
- E2E tests for user-facing flows
Step 8: Create Pull Request
git push -u origin HEAD
gh pr create \
--title "feat: [Short description] (#ISSUE)" \
--body "$(cat <<'EOF'
## Summary
[What this PR does]
## Changes
- [Change 1]
- [Change 2]
## Testing
- [ ] Unit tests pass
- [ ] E2E tests pass
- [ ] Manual testing completed
## Screenshots/Logs
[If applicable]
Closes #ISSUE_NUMBER
EOF
)"
Step 9: Review PR
Self-review checklist:
gh pr diff
gh pr view --json files
Review for:
Clean up if needed:
git rebase -i origin/main
git push --force-with-lease
Step 10: Update GitHub Issue
Post implementation summary to the issue:
gh issue comment ISSUE_NUMBER --body "$(cat <<'EOF'
## Implementation Complete
### What was done
- [Summary of changes]
### Files changed
- `path/to/file.ts` - [description]
### How to test
1. [Step 1]
2. [Step 2]
### PR
#PR_NUMBER
EOF
)"
Step 11: Wait for CI Checks to Pass
gh pr checks --watch
gh run list --limit 5
gh run view RUN_ID --log-failed
If CI fails:
- Read the failure logs
- Fix the issue locally
- Push the fix
- Wait for CI again
Only merge when all checks pass.
gh pr merge --squash --delete-branch
Quick Reference
| Step | Command | Todo Status |
|---|
| 1. Plan | Document in markdown | pending |
| 2. Issue | gh issue create | pending |
| 3. Scope | gh issue comment | pending |
| 4. Fetch | git fetch origin | in_progress |
| 5. Branch | git checkout -b feat/... | in_progress |
| 6. Implement | Write code, commit | in_progress |
| 7. Test | npm test && npm run test:e2e | in_progress |
| 8. PR | gh pr create | in_progress |
| 9. Review | gh pr diff | in_progress |
| 10. Update Issue | gh issue comment | in_progress |
| 11. CI Pass | gh pr checks --watch | completed |
Common Issues
| Issue | Cause | Solution |
|---|
| CI fails on push | Tests not run locally | Always run npm test before pushing |
| Merge conflicts | Branch out of date | git rebase origin/main |
| E2E tests timeout | Model too slow | Increase timeout or use faster model |
| PR has unrelated changes | Wrong base branch | Rebase onto correct branch |
| Forgot to link issue | Missing Closes #N | Edit PR body to add it |
Anti-Patterns to Avoid
- Pushing directly to main - Always use feature branches
- Skipping tests - Tests exist for a reason
- Large PRs - Break into smaller, focused changes
- Mocked E2E tests - Real tests catch real bugs
- Ignoring CI failures - Fix before merge, never skip
- No issue tracking - Issues provide context and history
- Vague commit messages - Be specific about what changed
- Force pushing to main - Never force push to shared branches