amazingteam 3.0.0

package/.opencode/skills/regression-checklist/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: regression-checklist
+description: Checklist for detecting regressions after changes
+license: MIT
+---
+# Regression Checklist
+
+## When to Use
+
+- After implementing changes
+- Before merging PRs
+- After refactoring
+- Before releases
+
+## Pre-Change Baseline
+
+- [ ] All tests passing
+- [ ] No lint errors
+- [ ] No TypeScript errors
+- [ ] Build succeeds
+- [ ] Documentation current
+
+## Regression Tests
+
+### Functional Tests
+- [ ] Core features work as expected
+- [ ] User flows complete successfully
+- [ ] API responses correct
+- [ ] Data integrity maintained
+
+### Performance Tests
+- [ ] Response times acceptable
+- [ ] No memory leaks
+- [ ] No CPU spikes
+- [ ] Bundle size not increased significantly
+
+### Integration Tests
+- [ ] External services work
+- [ ] Database operations correct
+- [ ] Authentication/authorization works
+- [ ] File operations work
+
+### UI Tests (if applicable)
+- [ ] Layouts render correctly
+- [ ] Responsive design works
+- [ ] Accessibility maintained
+- [ ] No console errors
+
+## Post-Change Verification
+
+### Code Quality
+- [ ] No new lint warnings
+- [ ] Test coverage maintained
+- [ ] No deprecated API usage
+- [ ] Security best practices followed
+
+### Documentation
+- [ ] README updated if needed
+- [ ] API docs updated if needed
+- [ ] Changelog updated
+- [ ] Comments accurate
+
+## Regression Report Template
+
+```markdown
+## Regression Check: [PR/Change]
+
+### Tests Run
+- [ ] Unit tests: X passing
+- [ ] Integration tests: X passing
+- [ ] E2E tests: X passing
+
+### Issues Found
+| Issue | Severity | Status |
+|-------|----------|--------|
+| [Description] | [High/Med/Low] | [Fixed/Open] |
+
+### Sign-off
+- [ ] All regressions addressed
+- [ ] Ready for merge
+```

package/.opencode/skills/release-readiness-check/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: release-readiness-check
+description: Validate that the project is ready for release
+license: MIT
+---
+# Release Readiness Check
+
+## When to Use
+
+- Before creating a release
+- Before merging to main
+- Before deploying to production
+
+## Pre-Release Checklist
+
+### Code Quality
+- [ ] All tests pass
+- [ ] Test coverage meets threshold (≥80%)
+- [ ] No lint errors
+- [ ] No TypeScript errors
+- [ ] No security vulnerabilities
+
+### Documentation
+- [ ] CHANGELOG.md updated
+- [ ] README.md current
+- [ ] API documentation updated
+- [ ] Migration guide (if breaking changes)
+
+### Version
+- [ ] Version bumped appropriately
+- [ ] Version in package.json correct
+- [ ] Git tag prepared
+
+### Dependencies
+- [ ] Dependencies up to date
+- [ ] No known vulnerabilities in dependencies
+- [ ] Lock file committed
+
+## Breaking Changes Check
+
+If this release includes breaking changes:
+
+- [ ] Breaking changes documented
+- [ ] Migration guide provided
+- [ ] Deprecation warnings added in previous version
+- [ ] Major version bumped (semver)
+
+## Deployment Readiness
+
+- [ ] Environment variables documented
+- [ ] Database migrations ready (if needed)
+- [ ] Feature flags configured
+- [ ] Rollback plan documented
+
+## Release Notes Template
+
+```markdown
+## [Version] - YYYY-MM-DD
+
+### Added
+- [New features]
+
+### Changed
+- [Changes to existing features]
+
+### Fixed
+- [Bug fixes]
+
+### Breaking Changes
+- [Breaking changes with migration guide]
+
+### Dependencies
+- [Updated dependencies]
+```
+
+## Sign-off
+
+- [ ] All checks passed
+- [ ] Release notes reviewed
+- [ ] Stakeholders notified
+- [ ] Ready to release

package/.opencode/skills/repo-architecture-reader/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: repo-architecture-reader
+description: Quickly understand and document a repository's architecture, structure, and design patterns
+license: MIT
+---
+# Repository Architecture Reader
+
+## When to Use
+
+- Starting work on a new repository
+- Analyzing codebase for the first time
+- Creating architecture documentation
+- Planning major refactoring
+
+## Steps
+
+### 1. Initial Exploration
+1. Identify the project type (web app, library, CLI, etc.)
+2. Locate configuration files (package.json, tsconfig.json, etc.)
+3. Identify the main entry point(s)
+4. Map the top-level directory structure
+
+### 2. Dependency Analysis
+1. Parse package.json / requirements.txt / Cargo.toml
+2. Categorize dependencies (production, dev, peer)
+3. Identify the tech stack (framework, build tools, testing)
+
+### 3. Code Organization
+1. Identify source code directories
+2. Map module structure (core, shared, domain-specific)
+3. Identify architectural patterns (MVC, layered, microservices)
+
+### 4. Data Flow Analysis
+1. Trace main data flows
+2. Identify state management
+3. Map API boundaries
+
+### 5. Testing Structure
+1. Locate test files
+2. Identify test types (unit, integration, E2E)
+3. Document test utilities
+
+## Output Format
+
+```markdown
+# Repository Architecture: [Project Name]
+
+## Overview
+[Brief description]
+
+## Tech Stack
+- **Language**: [Primary language]
+- **Framework**: [Main framework]
+- **Build Tool**: [Build tool]
+- **Testing**: [Testing framework]
+
+## Directory Structure
+[Directory tree]
+
+## Key Modules
+### [Module Name]
+- **Purpose**: [What this module does]
+- **Dependencies**: [What it depends on]
+- **Key Files**: [Important files]
+```

package/.opencode/skills/safe-refactor-checklist/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: safe-refactor-checklist
+description: Checklist for safe code refactoring without breaking changes
+license: MIT
+---
+# Safe Refactor Checklist
+
+## When to Use
+
+- Refactoring existing code
+- Improving code structure
+- Reducing technical debt
+- Optimizing performance
+
+## Pre-Refactor Checklist
+
+- [ ] All existing tests pass
+- [ ] Test coverage is adequate (>80%)
+- [ ] Understand the code's current behavior
+- [ ] Identify all consumers of the code
+- [ ] Document the refactoring goal
+
+## During Refactor
+
+### 1. Make Small Changes
+- One refactoring at a time
+- Run tests after each change
+- Commit frequently
+
+### 2. Preserve Behavior
+- Don't change public interfaces
+- Keep the same inputs/outputs
+- Maintain backward compatibility
+
+### 3. Update Tests
+- Update tests if behavior changes
+- Add tests for new code paths
+- Remove obsolete tests
+
+## Post-Refactor Checklist
+
+- [ ] All tests pass
+- [ ] No new lint errors
+- [ ] No TypeScript errors
+- [ ] Test coverage maintained or improved
+- [ ] Documentation updated
+- [ ] No breaking changes to public API
+
+## Common Refactoring Patterns
+
+### Extract Method
+```typescript
+// Before
+function process(data) {
+  // validation logic
+  // processing logic
+  // formatting logic
+}
+
+// After
+function process(data) {
+  validate(data);
+  const result = processData(data);
+  return formatResult(result);
+}
+```
+
+### Rename Variable
+- Use IDE refactoring tools
+- Update all references
+- Run tests to verify
+
+### Move Method
+- Update imports
+- Check for circular dependencies
+- Verify all callers updated

package/.opencode/skills/task-breakdown-and-dispatch/SKILL.md

@@ -0,0 +1,255 @@
+---
+name: task-breakdown-and-dispatch
+description: Decompose complex tasks into GitHub sub-issues and coordinate workflow
+license: MIT
+---
+# Task Breakdown and Dispatch (GitHub Issue-Based)
+
+## When to Use
+
+- Large feature requests requiring multiple steps
+- Complex bugs affecting multiple modules
+- Tasks that need design before implementation
+- Work items requiring staged validation
+- Issues impacting public interfaces or contracts
+
+## Decomposition Decision
+
+### No Decomposition Needed
+
+A task may remain single-scope if:
+- Touches only one module
+- No architecture decision needed
+- One implementation step is enough
+- One PR is likely enough
+- Validation is simple
+- Rollback is straightforward
+
+### Decomposition Required
+
+Decompose if ANY of these are true:
+- 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
+- Has clear dependency order between subproblems
+
+## Steps
+
+### 1. Analyze the Parent Issue
+
+1. Read the issue description carefully
+2. Identify the problem scope
+3. List affected modules and components
+4. Note existing constraints
+5. Check for related issues or PRs
+
+### 2. Determine Decomposition Need
+
+Answer these questions:
+- Does this touch multiple modules?
+- Is there a clear design phase needed?
+- Will this likely need multiple PRs?
+- Are there logical dependency chains?
+- Is the scope clear and bounded?
+
+If 2+ answers are "yes", decomposition is recommended.
+
+### 3. Define Subtask Boundaries
+
+1. Identify logical phases (analysis, design, implement, validate, review)
+2. Group related work into bounded subtasks
+3. Define clear acceptance criteria for each subtask
+4. Specify module scope for each subtask
+5. Assign recommended owner role
+
+### 4. Define Dependencies
+
+1. Map which subtasks depend on others
+2. Identify parallelizable work
+3. Document external dependencies
+4. Consider risk ordering (high-risk first)
+
+### 5. Create GitHub Sub-Issues
+
+Use `gh issue create` for each subtask:
+
+```bash
+gh issue create \
+  --title "[Subtask] Subtask title" \
+  --body "Parent Issue: #XXX
+Dependencies: #YYY, #ZZZ
+Owner Role: developer
+Scope: ...
+Acceptance Criteria: ..." \
+  --label "type:subtask,role:developer"
+```
+
+### 6. Create Local Task Records
+
+For each subtask, create:
+- `tasks/issue-{N}-subtask-{M}/task.yaml`
+- Include GitHub issue number
+- Include parent reference
+- Include dependency references
+
+### 7. Update Parent Issue
+
+Add to parent issue body:
+- List of child issues
+- Dependency graph
+- Overall completion rule
+
+### 8. Dispatch First Subtask
+
+Identify the first ready subtask:
+- All dependencies satisfied
+- Clear acceptance criteria
+- Assigned owner role
+- Document dispatch decision
+
+## Parent Task Manifest Template
+
+```yaml
+id: issue-120
+title: Improve startup reliability
+type: bug
+status: in_analysis
+priority: high
+requires_decomposition: true
+
+github_issue: 120
+github_url: https://github.com/org/repo/issues/120
+
+subtasks:
+  - id: issue-120-subtask-01
+    github_issue: 201
+    title: "[Subtask] Isolate configuration validation"
+    status: ready
+    owner_role: architect
+  - id: issue-120-subtask-02
+    github_issue: 202
+    title: "[Subtask] Refactor startup error path"
+    status: pending
+    depends_on: [201]
+    owner_role: developer
+  - id: issue-120-subtask-03
+    github_issue: 203
+    title: "[Subtask] Add regression coverage"
+    status: pending
+    depends_on: [202]
+    owner_role: qa
+
+overall_acceptance_criteria:
+  - startup crash no longer occurs
+  - root cause documented
+  - regression coverage added
+```
+
+## Subtask Manifest Template
+
+```yaml
+id: issue-120-subtask-01
+github_issue: 201
+github_url: https://github.com/org/repo/issues/201
+parent_task: issue-120
+parent_github_issue: 120
+
+title: "[Subtask] Isolate configuration validation"
+type: implementation
+status: ready
+priority: high
+owner_role: architect
+
+depends_on: []
+blocked_by: []
+
+acceptance_criteria:
+  - configuration validation is isolated
+  - no startup crash for missing optional fields
+  - existing startup path unchanged
+
+module_scope:
+  - config_loader
+  - startup
+
+risk_level: medium
+```
+
+## Dispatch Output Format
+
+```
+Active sub-issue: #202
+Role: developer
+Reason: #201 is completed and architecture is stable
+Dependencies: satisfied (depends on #201 which is done)
+Next action: Create feature branch and implement
+Blocked: no
+```
+
+## Blocked Task Recording
+
+```
+Blocked subtask: issue-120-subtask-02
+Blocker type: missing_design_decision
+Blocker source: issue-120-subtask-01 design pending
+Required action: Complete design phase
+Recommended next: Dispatch to architect
+```
+
+## Workflow State Machine
+
+```
+backlog → ready → in_analysis → in_design → in_implementation → in_validation → in_review → release_candidate → done
+                              ↓                                              ↓
+                           blocked ←───────────────────────────────────────── ←
+```
+
+## Role Dispatch Guide
+
+| Subtask Type | Target Role |
+|--------------|-------------|
+| analysis | architect |
+| design | architect |
+| implementation | developer |
+| validation | qa |
+| review | reviewer |
+| ci-fix | ci-analyst |
+| triage | triage |
+
+## Completion Rules
+
+### Subtask Completion
+- Acceptance criteria satisfied
+- Required validation complete
+- Linked PR merged (if applicable)
+- No unresolved blockers
+
+### Parent Task Completion
+- All required subtasks done
+- Overall acceptance criteria satisfied
+- Validation coverage complete
+- No unresolved critical blockers
+
+## Anti-Patterns to Avoid
+
+1. **Conversational-Only Breakdown**: No explicit task objects created
+2. **Everything Parallel**: All subtasks dispatched at once
+3. **No Acceptance Criteria**: No clear done condition
+4. **Planner Writes Code**: Planner implements instead of dispatching
+5. **Parent Closed Early**: Parent closed before subtasks complete
+6. **No GitHub Mapping**: Only local files, no GitHub issues
+
+## Checklist
+
+- [ ] Decomposition need determined
+- [ ] Subtask boundaries defined
+- [ ] Dependencies mapped
+- [ ] GitHub sub-issues created
+- [ ] Local task records created
+- [ ] Parent issue updated
+- [ ] First subtask dispatched
+- [ ] State machine enforced

package/.opencode/skills/test-first-feature-dev/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: test-first-feature-dev
+description: Implement features using test-driven development approach
+license: MIT
+---
+# Test-First Feature Development
+
+## When to Use
+
+- Implementing new features
+- Adding significant functionality
+- When high confidence is needed
+- For complex business logic
+
+## Steps
+
+### 1. Understand Requirements
+1. Read and analyze the feature requirements
+2. Identify acceptance criteria
+3. Clarify edge cases and error scenarios
+4. Break down into testable units
+
+### 2. Write Test Cases
+1. Start with happy path tests
+2. Add edge case tests
+3. Add error scenario tests
+4. Consider boundary conditions
+
+### 3. Write Failing Tests
+1. Write the test code first
+2. Run tests to confirm they fail
+3. Verify failure reason is correct
+4. Keep tests simple and focused
+
+### 4. Implement Minimum Code
+1. Write just enough code to pass
+2. Don't over-engineer
+3. Focus on the current test
+
+### 5. Make Tests Pass
+1. Run tests to verify pass
+2. If failing, debug and fix
+3. Confirm implementation is minimal
+
+### 6. Refactor
+1. Review the implementation
+2. Identify code smells
+3. Refactor while keeping tests green
+4. Remove duplication
+
+## Test Structure Template
+
+```typescript
+describe('FeatureName', () => {
+  describe('methodName or scenario', () => {
+    it('should do something specific', () => {
+      // Arrange
+      const input = 'test data';
+      const expected = 'expected result';
+
+      // Act
+      const result = functionUnderTest(input);
+
+      // Assert
+      expect(result).toBe(expected);
+    });
+  });
+});
+```
+
+## Checklist
+
+- [ ] Requirements understood
+- [ ] Test cases designed
+- [ ] Happy path tests written
+- [ ] Edge case tests written
+- [ ] All tests passing
+- [ ] Code refactored