amazingteam 3.0.0

package/.opencode/commands/resume.md

@@ -0,0 +1,88 @@
+---
+description: Resume a blocked workflow after blocker resolution
+agent: planner
+---
+Resume a previously blocked workflow after the blocker has been resolved.
+
+## Usage
+
+Comment on the blocked issue:
+
+```
+/oc /resume
+```
+
+Or with additional context:
+
+```
+/oc /resume
+The permission issue has been fixed. Please continue from where you left off.
+```
+
+## When to Use
+
+Use `/resume` when:
+- A blocker sub-issue has been resolved
+- Human has provided required input/approval
+- External dependency is now available
+- Permission/access has been granted
+
+## Process
+
+1. **Verify Blocker Resolution**
+   - Check blocker sub-issue status
+   - Verify fix was applied
+   - Confirm dependencies are available
+
+2. **Restore Workflow State**
+   - Load saved workflow state
+   - Identify last successful step
+   - Prepare to continue
+
+3. **Resume Execution**
+   - Continue from where workflow paused
+   - Execute remaining steps
+   - Create PR when complete
+
+## Output
+
+```markdown
+## Workflow Resumed
+
+- **Original Issue**: #{issue_id}
+- **Blocker**: #{blocker_id} - ✅ Resolved
+- **Resuming From**: {phase}
+- **Status**: In progress...
+
+Continuing with {next_step}...
+```
+
+## If Blocker Not Resolved
+
+```markdown
+## Cannot Resume
+
+- **Blocker**: #{blocker_id} - ❌ Not resolved
+- **Status**: {blocker_status}
+
+### Required Actions
+{list of required actions to resolve blocker}
+
+Please resolve the blocker first, then run `/resume` again.
+```
+
+## Example
+
+```
+User: /oc /resume
+      Branch protection has been disabled temporarily.
+
+Planner:
+## Workflow Resumed
+
+- **Original Issue**: #120
+- **Blocker**: #206 (Permission denied) - ✅ Resolved
+- **Resuming From**: Implementation phase
+
+Continuing with implementation...
+```

package/.opencode/commands/review.md

@@ -0,0 +1,15 @@
+---
+description: Review code for quality and correctness
+agent: reviewer
+---
+Review the code changes for quality, correctness, and maintainability.
+
+## Steps
+
+1. Review the pull request changes
+2. Check coding standards compliance
+3. Identify potential issues
+4. Provide constructive feedback
+5. Document review results in `tasks/{task_id}/review.md`
+
+Use the `safe-refactor-checklist` skill for thorough review.

package/.opencode/commands/show-blockers.md

@@ -0,0 +1,97 @@
+---
+description: List all blocked subtasks and required actions to unblock them
+agent: planner
+---
+Show all blocked subtasks and what is needed to unblock them.
+
+## Steps
+
+### 1. Scan Task Directory
+
+List all tasks and subtasks:
+```
+tasks/
+├── issue-{N}/
+├── issue-{N}-subtask-01/
+├── issue-{N}-subtask-02/
+...
+```
+
+### 2. Check for Blocked Status
+
+For each task/subtask, check `task.yaml`:
+- status: blocked
+- blocked_by field
+- depends_on field
+
+### 3. Analyze Blocker Types
+
+Common blocker types:
+- `missing_design_decision` - Design not complete
+- `failing_dependency` - Dependency task not done
+- `ci_failure` - CI failing on related PR
+- `unclear_requirements` - Issue needs clarification
+- `missing_approval` - Waiting for human approval
+- `external_dependency` - Waiting for external artifact
+
+### 4. Check GitHub Status
+
+```bash
+gh issue view {issue-number}
+gh pr list --state open --search "fixes #{issue-number}"
+```
+
+### 5. Determine Unblock Actions
+
+For each blocked item, identify:
+- What is blocking
+- What must happen to unblock
+- Who should act
+- Recommended next command
+
+## Output Format
+
+```
+Blocked Subtasks Report
+========================
+
+Parent Task: issue-{N}
+
+┌─────────────────────────────────────────────────────────────┐
+│ Blocked: issue-{N}-subtask-02                                │
+├─────────────────────────────────────────────────────────────┤
+│ Title: [Subtask] Implement feature                           │
+│ GitHub: #202                                                 │
+│ Owner: developer                                             │
+│                                                              │
+│ Blocker Type: failing_dependency                             │
+│ Blocker Source: issue-{N}-subtask-01 (design pending)       │
+│                                                              │
+│ Required Action: Complete design phase                       │
+│ Recommended Next: Dispatch to architect                      │
+│ Command: /design --subtask issue-{N}-subtask-01              │
+└─────────────────────────────────────────────────────────────┘
+
+┌─────────────────────────────────────────────────────────────┐
+│ Blocked: issue-{M}-subtask-03                                │
+├─────────────────────────────────────────────────────────────┤
+│ Title: [Subtask] Add tests                                   │
+│ GitHub: #305                                                 │
+│ Owner: qa                                                    │
+│                                                              │
+│ Blocker Type: ci_failure                                     │
+│ Blocker Source: PR #304 failing                              │
+│                                                              │
+│ Required Action: Fix CI failure                              │
+│ Recommended Next: Dispatch to ci-analyst                     │
+│ Command: /ci-analyze --pr 304                                │
+└─────────────────────────────────────────────────────────────┘
+
+Summary:
+- 2 blocked subtasks
+- 1 requires architecture work
+- 1 requires CI fix
+
+Next Recommended Action:
+Dispatch to ci-analyst for immediate CI fix (blocking implementation)
+```

package/.opencode/commands/summarize-parent.md

@@ -0,0 +1,121 @@
+---
+description: Summarize current progress of all child issues under a parent issue
+agent: planner
+---
+Summarize the progress of all child issues under a parent issue.
+
+## Steps
+
+### 1. Identify Parent Issue
+
+Parse the issue reference or read from `tasks/issue-{N}/task.yaml`
+
+### 2. List All Child Issues
+
+From parent task.yaml:
+```yaml
+subtasks:
+  - id: issue-{N}-subtask-01
+    github_issue: 201
+  - id: issue-{N}-subtask-02
+    github_issue: 202
+  ...
+```
+
+### 3. Check GitHub Status
+
+For each child issue:
+```bash
+gh issue view {issue-number} --json number,title,state,labels
+```
+
+### 4. Check Linked PRs
+
+```bash
+gh pr list --state all --search "fixes #{issue-number}"
+```
+
+### 5. Calculate Progress
+
+- Count: total, done, in_progress, pending, blocked
+- Calculate completion percentage
+- Identify critical path items
+
+### 6. Identify Risks
+
+- Long-running blocked items
+- Dependencies not progressing
+- Missing assignments
+
+## Output Format
+
+```
+Parent Issue Summary
+====================
+
+Parent: issue-{N} - {title}
+GitHub: #{issue-number}
+Status: in_implementation
+Priority: high
+
+Progress Overview
+-----------------
+Total Subtasks: 5
+✓ Done:         2 (40%)
+● In Progress:  1 (20%)
+○ Pending:      1 (20%)
+✗ Blocked:      1 (20%)
+
+Completion: 40%
+
+Subtask Details
+---------------
+
+✓ #201 [Subtask] Design API
+  Role: architect | Status: done
+  PR: #250 (merged)
+  Completed: 2024-01-15
+
+✓ #202 [Subtask] Implement core
+  Role: developer | Status: done
+  PR: #251 (merged)
+  Completed: 2024-01-18
+
+● #203 [Subtask] Add tests
+  Role: qa | Status: in_validation
+  PR: #252 (open)
+  Started: 2024-01-19
+
+○ #204 [Subtask] Update docs
+  Role: developer | Status: pending
+  Depends on: #203
+  ETA: after #203
+
+✗ #205 [Subtask] Integration test
+  Role: qa | Status: blocked
+  Blocker: CI failure in #203
+  Blocked since: 2024-01-20
+
+Dependency Graph
+----------------
+#201 (done) → #202 (done) → #203 (in_progress) → #204 (pending)
+                              ↓
+                           #205 (blocked)
+
+Critical Path
+-------------
+Current: #203 (validation)
+Next: #204 (docs), #205 (integration)
+
+Risks
+-----
+- #205 blocked for 2 days (CI failure)
+- #204 waiting on #203
+
+Recommendations
+---------------
+1. Resolve CI failure in #203 to unblock #205
+2. Consider parallelizing #204 after #203 validation passes
+
+Next Action: /dispatch-next
+```

package/.opencode/commands/test.md

@@ -0,0 +1,15 @@
+---
+description: Validate implementation through testing
+agent: qa
+---
+Validate the implementation and ensure quality.
+
+## Steps
+
+1. Review acceptance criteria
+2. Verify all tests pass
+3. Test edge cases
+4. Check for regressions
+5. Document validation results in `tasks/{task_id}/validation.md`
+
+Use the `regression-checklist` skill for thorough validation.

package/.opencode/commands/triage.md

@@ -0,0 +1,109 @@
+---
+description: Classify issue, determine decomposition need, and perform initial analysis
+agent: triage
+---
+Classify this issue, determine whether decomposition is needed, and perform initial analysis.
+
+## Steps
+
+### 1. Read Issue Description
+
+Understand:
+- What is being reported or requested?
+- What is the expected behavior?
+- What is the actual behavior (for bugs)?
+- What is the business goal (for features)?
+
+### 2. Classify by Type
+
+| Type | Indicators |
+|------|------------|
+| bug | Error, crash, incorrect behavior |
+| feature | New functionality, enhancement |
+| tech-task | Refactoring, dependency update, infrastructure |
+| docs | Documentation changes |
+
+### 3. Assess Priority and Severity
+
+**Severity (bugs):**
+- critical: System down, data loss, security issue
+- high: Major feature broken, no workaround
+- medium: Feature partially broken, workaround exists
+- low: Minor issue, cosmetic
+
+**Priority:**
+- critical: Immediate action required
+- high: This sprint
+- medium: Next sprint
+- low: Backlog
+
+### 4. Determine Decomposition Need
+
+**Decomposition Required if:**
+- Touches multiple modules
+- Requires design before implementation
+- Impacts public interfaces
+- Changes data model, API contract, or protocol
+- Likely needs multiple PRs
+- Contains several distinct implementation steps
+- Requires staged validation
+
+**No Decomposition if:**
+- Single module change
+- No architecture decision needed
+- One implementation step sufficient
+- One PR likely enough
+- Simple validation
+
+### 5. Perform Initial Investigation
+
+- Check if similar issues exist
+- Identify affected files/modules
+- Note relevant code paths
+- Check for related PRs
+
+### 6. Suggest Next Steps
+
+Based on classification and decomposition decision:
+
+| Scenario | Next Step |
+|----------|-----------|
+| Bug, no decomposition | /implement |
+| Bug, needs decomposition | /breakdown-issue |
+| Feature, no decomposition | /design |
+| Feature, needs decomposition | /breakdown-issue |
+| Unclear issue | Ask for clarification |
+
+## Output Format
+
+```
+Triage Report
+=============
+
+Issue: #{number} - {title}
+
+Classification:
+- Type: bug | feature | tech-task | docs
+- Severity: critical | high | medium | low
+- Priority: critical | high | medium | low
+
+Scope Analysis:
+- Affected modules: [list]
+- Affected components: [list]
+- Related issues: [list]
+
+Decomposition Decision: required | not_required
+
+Reason:
+- [reasons for decomposition decision]
+
+Estimated Complexity: simple | moderate | complex
+
+Recommended Next Steps:
+1. [first action]
+2. [second action]
+
+Command: /breakdown-issue | /design | /implement
+```
+
+Use the `issue-triage` skill for systematic classification.

package/.opencode/skills/bugfix-playbook/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: bugfix-playbook
+description: Systematic approach to identifying, analyzing, and fixing bugs
+license: MIT
+---
+# Bug Fix Playbook
+
+## When to Use
+
+- Fixing reported bugs
+- Debugging production issues
+- Investigating test failures
+- Resolving regression issues
+
+## Steps
+
+### 1. Reproduce the Bug
+1. Document exact reproduction steps
+2. Verify the bug exists in current version
+3. Create minimal reproduction case
+4. Capture relevant logs/errors
+
+### 2. Gather Information
+1. Review bug report details
+2. Check for related issues
+3. Review recent changes
+4. Collect stack traces
+
+### 3. Locate the Source
+1. Use stack traces to identify locations
+2. Search for error messages in codebase
+3. Trace execution flow
+4. Identify the specific file and function
+
+### 4. Analyze the Root Cause
+1. Understand the expected behavior
+2. Compare with actual behavior
+3. Identify why the discrepancy occurs
+4. Document the root cause clearly
+
+### 5. Design the Fix
+1. Determine the minimal change needed
+2. Consider potential side effects
+3. Plan any necessary refactoring
+
+### 6. Implement the Fix
+1. Write the fix (minimal, targeted)
+2. Add/update tests
+3. Verify fix resolves the issue
+4. Run all tests to catch regressions
+
+## Root Cause Analysis Template
+
+```markdown
+## Bug Analysis: [Bug Title]
+
+### Issue
+[Description of the bug]
+
+### Root Cause
+[Explanation of why the bug occurs]
+
+### Affected Code
+- `file_path:line_number` - [Description]
+
+### Fix Approach
+[Description of how to fix]
+
+### Tests to Add
+1. [Test case 1]
+2. [Test case 2]
+```
+
+## Checklist
+
+- [ ] Bug reproduced
+- [ ] Root cause identified
+- [ ] Fix implemented (minimal change)
+- [ ] Tests added for the bug
+- [ ] All tests pass
+- [ ] No regressions detected

package/.opencode/skills/ci-failure-analysis/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: ci-failure-analysis
+description: Investigate CI failures systematically and find root causes
+license: MIT
+---
+# CI Failure Analysis
+
+## When to Use
+
+- CI pipeline failed
+- Tests failing in CI but not locally
+- Build errors
+- Deployment failures
+
+## Analysis Steps
+
+### 1. Identify Failure Type
+- **Build failure**: Compilation/transpilation error
+- **Test failure**: Tests not passing
+- **Lint failure**: Code style issues
+- **Deploy failure**: Deployment step failed
+
+### 2. Gather Information
+1. Read the CI logs
+2. Identify the failing step
+3. Note the error message
+4. Check for recent changes
+
+### 3. Analyze Root Cause
+
+#### Build Failures
+- Missing dependencies
+- Type errors
+- Syntax errors
+- Configuration issues
+
+#### Test Failures
+- Flaky tests
+- Environment differences
+- Missing test data
+- Timing issues
+
+#### Lint Failures
+- New lint rules
+- Code style violations
+- Unused imports
+
+### 4. Propose Fix
+1. Identify the minimal fix
+2. Consider side effects
+3. Document the solution
+
+## Common CI Issues
+
+### Environment Differences
+```bash
+# Check Node version
+node --version
+
+# Check package versions
+npm list [package]
+```
+
+### Flaky Tests
+- Look for timing issues
+- Check for race conditions
+- Verify test isolation
+
+### Memory Issues
+- Increase Node memory: `NODE_OPTIONS=--max-old-space-size=4096`
+- Check for memory leaks
+
+## Report Template
+
+```markdown
+## CI Failure Analysis
+
+### Failure Type
+[Build|Test|Lint|Deploy]
+
+### Error Message
+```
+[Paste error]
+```
+
+### Root Cause
+[Explanation]
+
+### Fix
+[Proposed solution]
+
+### Prevention
+[How to prevent in future]
+```

package/.opencode/skills/issue-triage/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: issue-triage
+description: Classify issues by type, priority, and assign appropriate handling
+license: MIT
+---
+# Issue Triage
+
+## When to Use
+
+- New issue created
+- Bug reports received
+- Feature requests submitted
+- Technical debt identified
+
+## Classification Categories
+
+### Type
+- **bug**: Something is broken
+- **feature**: New functionality requested
+- **enhancement**: Improvement to existing feature
+- **tech**: Technical task (refactor, upgrade, etc.)
+- **docs**: Documentation changes
+
+### Priority
+- **critical**: Blocks production or major functionality
+- **high**: Significant impact, should be addressed soon
+- **medium**: Normal priority, standard timeline
+- **low**: Nice to have, can wait
+
+### Severity (for bugs)
+- **blocker**: System unusable
+- **major**: Significant functionality broken
+- **minor**: Small issue, workaround available
+- **cosmetic**: UI/UX issue, no functional impact
+
+## Triage Steps
+
+### 1. Read the Issue
+1. Understand the reported problem/request
+2. Identify the reporter's intent
+3. Note any reproduction steps
+
+### 2. Classify
+1. Determine the type
+2. Assess priority
+3. Estimate severity (if bug)
+4. Identify affected components
+
+### 3. Validate
+1. Reproduce the issue (if bug)
+2. Verify it's not a duplicate
+3. Check for related issues
+
+### 4. Assign
+1. Identify the right agent
+2. Add appropriate labels
+3. Set milestone if applicable
+
+## Issue Template
+
+```markdown
+## Classification
+- **Type**: [bug|feature|enhancement|tech|docs]
+- **Priority**: [critical|high|medium|low]
+- **Severity**: [blocker|major|minor|cosmetic]
+
+## Summary
+[Brief description]
+
+## Affected Components
+- [Component 1]
+- [Component 2]
+
+## Next Steps
+1. [Action 1]
+2. [Action 2]
+
+## Assigned To
+[Agent name]
+```