amazingteam 3.0.0

package/.ai-team/skills/issue-triage/skill.md

@@ -0,0 +1,163 @@
+# Issue Triage
+
+## Purpose
+
+This skill provides a systematic approach to classifying, prioritizing, and performing initial analysis on incoming issues.
+
+## When to Use
+
+- New issue created
+- Bug report received
+- Feature request submitted
+- Starting work on untriaged issues
+
+## Steps
+
+### 1. Initial Classification
+
+```
+1. Read issue title and description
+2. Classify issue type:
+   - bug: Something is broken
+   - feature: New functionality requested
+   - enhancement: Improvement to existing feature
+   - docs: Documentation issue
+   - tech: Technical debt or infrastructure
+   - question: Clarification needed
+3. Assign priority:
+   - critical: Blocks production or security issue
+   - high: Major functionality impacted
+   - medium: Standard priority
+   - low: Nice to have
+```
+
+### 2. Validation
+
+```
+1. Verify issue is reproducible
+2. Check for duplicate issues
+3. Validate user-provided information
+4. Request missing information if needed
+5. Add reproduction steps if missing
+```
+
+### 3. Root Cause Investigation
+
+```
+1. Examine error messages and stack traces
+2. Identify affected components
+3. Review recent changes to affected areas
+4. Check logs for related errors
+5. Document findings
+```
+
+### 4. Scope Assessment
+
+```
+1. Identify affected modules
+2. Determine if fix requires:
+   - Single file change
+   - Multiple files
+   - Architectural change
+   - External dependency update
+3. Assess risk level
+4. Estimate effort (small/medium/large)
+```
+
+### 5. Assignment Decision
+
+```
+1. Determine appropriate owner:
+   - architect: Design needed
+   - developer: Implementation needed
+   - qa: Testing focus
+   - triage: More investigation needed
+2. Add appropriate labels
+3. Link related issues
+4. Set milestone if applicable
+```
+
+### 6. Documentation
+
+```
+1. Update issue with analysis
+2. Add investigation notes
+3. Document reproduction steps
+4. Link to relevant code
+5. Provide recommendation
+```
+
+## Triage Report Template
+
+```markdown
+## Triage Analysis: [Issue Title]
+
+### Classification
+- **Type**: bug | feature | enhancement | docs | tech | question
+- **Priority**: critical | high | medium | low
+- **Risk Level**: low | medium | high
+
+### Summary
+[Brief summary of the issue]
+
+### Root Cause Analysis
+[Findings from investigation, if applicable]
+
+### Affected Components
+- `module/component` - [Impact description]
+
+### Reproduction Steps
+1. [Step 1]
+2. [Step 2]
+3. [Step 3]
+
+### Expected Behavior
+[What should happen]
+
+### Actual Behavior
+[What actually happens]
+
+### Recommendation
+- **Owner**: architect | developer | qa
+- **Effort**: small | medium | large
+- **Notes**: [Additional context]
+
+### Related Issues
+- #[issue number] - [description]
+```
+
+## Classification Matrix
+
+| Symptom | Likely Type | Likely Priority |
+|---------|-------------|-----------------|
+| Production down | bug | critical |
+| Data loss | bug | critical |
+| Security vulnerability | bug | critical |
+| Feature not working | bug | high |
+| Performance degradation | bug | medium |
+| UI glitch | bug | low |
+| New capability needed | feature | medium |
+| Improvement request | enhancement | low |
+| Missing documentation | docs | low |
+
+## Checklist
+
+- [ ] Issue type classified
+- [ ] Priority assigned
+- [ ] Duplicates checked
+- [ ] Reproduction steps verified
+- [ ] Root cause investigated
+- [ ] Scope assessed
+- [ ] Owner assigned
+- [ ] Labels added
+- [ ] Documentation complete
+
+## Best Practices
+
+- Always verify before assigning priority
+- Request more info rather than guessing
+- Check recent commits for context
+- Link related issues
+- Document even negative findings
+- Update issue status promptly
+- Follow up on blocked issues

package/.ai-team/skills/regression-checklist/skill.md

@@ -0,0 +1,176 @@
+# Regression Checklist
+
+## Purpose
+
+This skill ensures comprehensive regression testing and prevents unintended side effects from code changes.
+
+## When to Use
+
+- Before merging a PR
+- After implementing a feature
+- After fixing a bug
+- Before a release
+- After refactoring code
+
+## Steps
+
+### 1. Identify Change Scope
+
+```
+1. Review the changes in the PR/commit
+2. Identify affected modules
+3. Map dependencies to other modules
+4. Identify integration points
+5. Note any API changes
+```
+
+### 2. Check Core Functionality
+
+```
+1. Application startup/shutdown
+2. Core user flows
+3. Authentication/authorization
+4. Data persistence
+5. Critical business logic
+```
+
+### 3. Check Affected Areas
+
+```
+1. Unit tests for changed modules
+2. Integration tests for affected paths
+3. E2E tests for user flows
+4. Performance benchmarks
+5. Security validations
+```
+
+### 4. Check Neighboring Modules
+
+```
+1. Modules that depend on changed code
+2. Modules that provide dependencies
+3. Shared utilities and helpers
+4. Configuration changes
+5. Database migrations
+```
+
+### 5. Check Edge Cases
+
+```
+1. Error handling paths
+2. Boundary conditions
+3. Null/empty inputs
+4. Concurrent access scenarios
+5. Resource exhaustion
+```
+
+### 6. Verify Non-Functional
+
+```
+1. Performance: No significant degradation
+2. Security: No new vulnerabilities
+3. Accessibility: WCAG compliance maintained
+4. Compatibility: Browser/platform support
+5. Logging: Appropriate log levels
+```
+
+### 7. Run Test Suite
+
+```
+1. Run all unit tests
+2. Run all integration tests
+3. Run E2E tests
+4. Check test coverage
+5. Verify no flaky tests
+```
+
+## Regression Checklist Template
+
+```markdown
+## Regression Checklist: [PR/Task Title]
+
+### Change Summary
+[Brief description of changes]
+
+### Affected Modules
+- [ ] `module1` - [Description of change]
+- [ ] `module2` - [Description of change]
+
+### Core Functionality
+- [ ] Application starts correctly
+- [ ] Application shuts down gracefully
+- [ ] Core user flows work
+- [ ] Authentication works
+- [ ] Authorization works
+- [ ] Data can be saved
+- [ ] Data can be retrieved
+
+### Module-Specific Tests
+- [ ] Unit tests pass for affected modules
+- [ ] Integration tests pass for affected paths
+- [ ] E2E tests pass for affected flows
+
+### Dependency Checks
+- [ ] Upstream modules work correctly
+- [ ] Downstream modules work correctly
+- [ ] Shared utilities function properly
+- [ ] External integrations work
+
+### Edge Cases
+- [ ] Error handling works
+- [ ] Boundary conditions handled
+- [ ] Null/empty inputs handled
+- [ ] Concurrent access safe
+
+### Non-Functional
+- [ ] Performance acceptable
+- [ ] No security regressions
+- [ ] Accessibility maintained
+- [ ] Compatible with supported platforms
+- [ ] Logs appropriate
+
+### Test Results
+- Unit Tests: PASS / FAIL
+- Integration Tests: PASS / FAIL
+- E2E Tests: PASS / FAIL
+- Coverage: XX%
+
+### Notes
+[Any additional observations or concerns]
+```
+
+## Risk Assessment Matrix
+
+| Change Type | Risk Level | Recommended Testing |
+|-------------|------------|---------------------|
+| Single file bug fix | Low | Unit tests + affected module tests |
+| Multi-file bug fix | Medium | All tests + integration tests |
+| New feature | Medium | All tests + E2E + manual |
+| API change | High | All tests + E2E + contract tests |
+| Database migration | High | All tests + migration tests |
+| Refactoring | Medium | All tests + coverage check |
+| Dependency update | Medium | All tests + compatibility check |
+| Configuration change | Low-Medium | Integration tests + E2E |
+
+## Checklist
+
+- [ ] Change scope identified
+- [ ] Core functionality verified
+- [ ] Affected modules tested
+- [ ] Neighboring modules checked
+- [ ] Edge cases tested
+- [ ] Non-functional requirements met
+- [ ] Test suite passed
+- [ ] Coverage acceptable
+- [ ] Documentation updated
+
+## Best Practices
+
+- Test more than just the changed code
+- Pay attention to error paths
+- Check for race conditions in async code
+- Verify logging and monitoring
+- Test in realistic environments
+- Include performance-critical paths
+- Check backward compatibility
+- Document any known issues

package/.ai-team/skills/release-readiness-check/skill.md

@@ -0,0 +1,216 @@
+# Release Readiness Check
+
+## Purpose
+
+This skill ensures code is ready for production release through comprehensive pre-release validation.
+
+## When to Use
+
+- Before merging to main/release branch
+- Before deploying to production
+- Before creating a release
+- During release candidate review
+
+## Steps
+
+### 1. Code Quality Verification
+
+```
+1. All tests pass (unit, integration, E2E)
+2. Code coverage meets threshold (≥80%)
+3. No linting errors
+4. No type errors
+5. No security vulnerabilities
+6. Technical debt documented
+```
+
+### 2. Documentation Review
+
+```
+1. README updated if needed
+2. API documentation current
+3. CHANGELOG/RELEASE_NOTES updated
+4. Breaking changes documented
+5. Migration guide provided (if needed)
+6. Configuration changes documented
+```
+
+### 3. Breaking Changes Assessment
+
+```
+1. Identify API changes
+2. Check backward compatibility
+3. Document deprecation notices
+4. Plan migration path for users
+5. Version bump appropriate
+```
+
+### 4. Security Review
+
+```
+1. No hardcoded secrets
+2. No SQL injection vulnerabilities
+3. No XSS vulnerabilities
+4. Authentication flows correct
+5. Authorization checks in place
+6. Sensitive data encrypted
+7. Dependencies checked for vulnerabilities
+```
+
+### 5. Performance Validation
+
+```
+1. No significant performance regressions
+2. Memory usage acceptable
+3. Startup time acceptable
+4. Response times within SLA
+5. Resource cleanup correct
+6. No memory leaks
+```
+
+### 6. Infrastructure Readiness
+
+```
+1. Database migrations ready
+2. Feature flags configured
+3. Rollback plan documented
+4. Monitoring/alerting updated
+5. Load testing completed (if applicable)
+```
+
+### 7. Release Documentation
+
+```
+1. Version number determined
+2. Release notes prepared
+3. Known issues documented
+4. Breaking changes listed
+5. Upgrade instructions provided
+```
+
+## Release Readiness Checklist Template
+
+```markdown
+## Release Readiness: [Version X.Y.Z]
+
+### Code Quality
+- [ ] All unit tests pass
+- [ ] All integration tests pass
+- [ ] All E2E tests pass
+- [ ] Code coverage: XX% (threshold: 80%)
+- [ ] No linting errors
+- [ ] No type errors
+- [ ] Static analysis clean
+
+### Security
+- [ ] No hardcoded secrets
+- [ ] No known vulnerabilities in dependencies
+- [ ] Security scan passed
+- [ ] Authentication verified
+- [ ] Authorization verified
+- [ ] Input validation in place
+- [ ] Output encoding correct
+
+### Documentation
+- [ ] README up to date
+- [ ] API documentation current
+- [ ] CHANGELOG updated
+- [ ] Breaking changes documented
+- [ ] Migration guide provided
+- [ ] Configuration documented
+
+### Performance
+- [ ] No performance regressions
+- [ ] Memory usage acceptable
+- [ ] Startup time acceptable
+- [ ] Response times within SLA
+- [ ] Load tested (if applicable)
+
+### Infrastructure
+- [ ] Database migrations ready
+- [ ] Feature flags configured
+- [ ] Monitoring updated
+- [ ] Rollback plan ready
+- [ ] Deployment tested
+
+### Versioning
+- [ ] Version number appropriate
+- [ ] Breaking changes → Major version
+- [ ] New features → Minor version
+- [ ] Bug fixes → Patch version
+
+### Release Notes Draft
+```
+## [Version X.Y.Z] - YYYY-MM-DD
+
+### Added
+- [New features]
+
+### Changed
+- [Changes]
+
+### Fixed
+- [Bug fixes]
+
+### Breaking Changes
+- [Breaking changes with migration guide]
+
+### Known Issues
+- [Known issues]
+```
+
+### Approval
+- [ ] Code review approved
+- [ ] QA approved
+- [ ] Security review (if applicable)
+- [ ] Product owner approval (if applicable)
+
+### Sign-off
+- **Prepared by**: [Name]
+- **Reviewed by**: [Name]
+- **Approved by**: [Name]
+- **Target Date**: [Date]
+```
+
+## Version Bumping Guide
+
+| Change Type | Version Bump | Example |
+|-------------|--------------|---------|
+| Breaking API change | Major | 1.0.0 → 2.0.0 |
+| New feature (backward compatible) | Minor | 1.0.0 → 1.1.0 |
+| Bug fix (backward compatible) | Patch | 1.0.0 → 1.0.1 |
+| Internal change | Patch | 1.0.0 → 1.0.1 |
+
+## Release Gates
+
+| Gate | Must Pass | Can Waive |
+|------|-----------|-----------|
+| All tests pass | Yes | No |
+| No security vulnerabilities | Yes | No |
+| Code coverage met | Yes | With approval |
+| Documentation updated | Yes | With approval |
+| Performance acceptable | Yes | With approval |
+| Code review approved | Yes | No |
+
+## Checklist
+
+- [ ] Code quality verified
+- [ ] Security reviewed
+- [ ] Documentation complete
+- [ ] Performance validated
+- [ ] Infrastructure ready
+- [ ] Release notes prepared
+- [ ] Version bumped appropriately
+- [ ] All gates passed
+- [ ] Approvals obtained
+
+## Best Practices
+
+- Never skip security review
+- Document all decisions
+- Test rollback procedure
+- Communicate breaking changes early
+- Provide upgrade guides
+- Keep release notes user-friendly
+- Test in production-like environment
+- Have a rollback plan ready

package/.ai-team/skills/repo-architecture-reader/skill.md

@@ -0,0 +1,139 @@
+# Repository Architecture Reader
+
+## Purpose
+
+This skill enables an agent to quickly understand and document a repository's architecture, structure, and design patterns.
+
+## When to Use
+
+- Starting work on a new repository
+- Analyzing codebase for the first time
+- Creating architecture documentation
+- Planning major refactoring
+- Onboarding new team members
+
+## 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 dependencies
+   - Development dependencies
+   - Peer dependencies
+3. Identify the tech stack:
+   - Framework(s)
+   - Build tools
+   - Testing frameworks
+   - Linting/formatting tools
+```
+
+### 3. Code Organization
+
+```
+1. Identify source code directories
+2. Map module structure:
+   - Core modules
+   - Shared/utilities
+   - Domain-specific modules
+   - Third-party integrations
+3. Identify architectural patterns:
+   - MVC/MVVM/MVI
+   - Layered architecture
+   - Microservices
+   - Monorepo structure
+```
+
+### 4. Data Flow Analysis
+
+```
+1. Trace main data flows
+2. Identify state management
+3. Map API boundaries
+4. Document event flows
+```
+
+### 5. Configuration & Environment
+
+```
+1. Identify environment configuration
+2. Map configuration sources
+3. Document secrets management
+4. Note feature flags
+```
+
+### 6. Testing Structure
+
+```
+1. Locate test files
+2. Identify test types:
+   - Unit tests
+   - Integration tests
+   - E2E tests
+3. Document test utilities and fixtures
+```
+
+## Output Format
+
+```markdown
+# Repository Architecture: [Project Name]
+
+## Overview
+[Brief description of the project]
+
+## Tech Stack
+- **Language**: [Primary language]
+- **Framework**: [Main framework]
+- **Build Tool**: [Build tool]
+- **Testing**: [Testing framework]
+
+## Directory Structure
+```
+project/
+├── src/           # Source code
+│   ├── core/      # Core business logic
+│   ├── api/       # API layer
+│   ├── utils/     # Utilities
+│   └── index.ts   # Entry point
+├── tests/         # Test files
+├── docs/          # Documentation
+└── config/        # Configuration
+```
+
+## Key Modules
+
+### [Module Name]
+- **Purpose**: [What this module does]
+- **Dependencies**: [What it depends on]
+- **Consumers**: [What depends on it]
+- **Key Files**: [Important files]
+
+## Data Flow
+[Description or diagram of data flow]
+
+## Configuration
+[How configuration is managed]
+
+## Testing Strategy
+[How testing is organized]
+
+## Notes
+[Any special considerations or gotchas]
+```
+
+## Best Practices
+
+- Start with high-level understanding before diving deep
+- Use diagrams for complex relationships
+- Note any anti-patterns or technical debt
+- Keep documentation updated as codebase evolves