amazingteam 3.0.0

package/.ai-team/commands/release-check.md

@@ -0,0 +1,142 @@
+# /release-check Command
+
+## Purpose
+
+Validate code is ready for production release through comprehensive pre-release checks.
+
+## Usage
+
+```
+/release-check [pr-number]
+/release-check [branch-name]
+/release-check current
+```
+
+## Examples
+
+```
+/release-check 123
+/release-check release/v1.2.0
+/release-check current
+```
+
+## Agent: Reviewer
+
+## Workflow
+
+### 1. Gather Context
+
+- Identify PR or branch to check
+- Review changes since last release
+- Check current test status
+- Review documentation status
+
+### 2. Code Quality Check
+
+- Verify all tests pass
+- Check code coverage meets threshold
+- Verify no linting errors
+- Check for type errors
+- Run security scan
+
+### 3. Documentation Review
+
+- Check README updates
+- Verify API documentation
+- Review CHANGELOG/RELEASE_NOTES
+- Check for migration guides if needed
+
+### 4. Breaking Changes Assessment
+
+- Identify API changes
+- Check backward compatibility
+- Verify version bump is appropriate
+- Document deprecation notices
+
+### 5. Security Review
+
+- Check for hardcoded secrets
+- Verify dependency vulnerabilities
+- Review authentication flows
+- Check authorization
+
+### 6. Performance Validation
+
+- Check for performance regressions
+- Verify resource usage
+- Review startup time
+- Check memory patterns
+
+### 7. Release Preparation
+
+- Verify version number
+- Prepare release notes
+- Document known issues
+- Create rollback plan
+
+## Output
+
+Produces a release readiness report:
+
+```markdown
+## Release Readiness: [Version]
+
+### Quality Gates
+| Gate | Status | Notes |
+|------|--------|-------|
+| Tests | PASS/FAIL | |
+| Coverage | XX% | Threshold: 80% |
+| Lint | PASS/FAIL | |
+| Types | PASS/FAIL | |
+| Security | PASS/FAIL | |
+
+### Breaking Changes
+- [List or "None"]
+
+### Documentation
+- [ ] README updated
+- [ ] CHANGELOG updated
+- [ ] API docs current
+
+### Security
+- [ ] No secrets in code
+- [ ] Dependencies secure
+- [ ] Auth flows verified
+
+### Performance
+- Memory: OK/Issue
+- Startup: OK/Issue
+- Response times: OK/Issue
+
+### Recommendation
+READY / NOT READY
+
+### Blockers
+- [List of blocking issues]
+
+### Release Notes Draft
+[Prepared release notes]
+```
+
+## Skills Used
+
+- release-readiness-check
+- regression-checklist
+- safe-refactor-checklist
+
+## Gates
+
+| Gate | Blocking | Can Waive |
+|------|----------|-----------|
+| All tests pass | Yes | No |
+| Coverage met | Yes | With approval |
+| No security issues | Yes | No |
+| Documentation complete | Yes | With approval |
+
+## Next Steps
+
+After `/release-check`:
+1. Address any blockers
+2. Get required approvals
+3. Create release
+4. Deploy with rollback plan ready

package/.ai-team/commands/review.md

@@ -0,0 +1,142 @@
+# /review Command
+
+## Purpose
+
+Review code changes for quality, correctness, and best practices.
+
+## Usage
+
+```
+/review
+/review [pr-number]
+/review [branch-name]
+```
+
+## Examples
+
+```
+/review
+/review 42
+/review feature/user-auth
+```
+
+## Agent: Reviewer
+
+## Workflow
+
+### 1. Context Gathering
+- Read PR description
+- Read related issue
+- Understand the purpose
+- Note acceptance criteria
+
+### 2. Code Examination
+- Review all changed files
+- Check coding standards
+- Identify potential issues
+- Note positive aspects
+
+### 3. Quality Analysis
+- Check test coverage
+- Verify documentation
+- Look for security issues
+- Assess maintainability
+
+### 4. Risk Assessment
+- Identify breaking changes
+- Note performance concerns
+- Check backward compatibility
+- Evaluate edge cases
+
+### 5. Feedback Formulation
+- Write constructive comments
+- Provide specific suggestions
+- Explain reasoning
+- Prioritize issues
+
+### 6. Decision
+- Approve
+- Request changes
+- Comment only
+
+## Review Categories
+
+### 🔴 Critical Issues
+- Security vulnerabilities
+- Breaking bugs
+- Data loss risks
+- Performance critical
+
+### 🟡 Warnings
+- Potential bugs
+- Code smell
+- Maintainability concerns
+- Missing edge cases
+
+### 🟢 Suggestions
+- Minor improvements
+- Style preferences
+- Documentation
+- Optional optimizations
+
+### 💬 Questions
+- Clarification needed
+- Design discussion
+- Alternative approaches
+
+### 👍 Praise
+- Good solutions
+- Clean code
+- Well-tested
+- Good documentation
+
+## Output Format
+
+```markdown
+## Code Review
+
+### Summary
+[Brief overview of changes and overall assessment]
+
+### Critical Issues
+1. **[Issue Title]**: `file:line`
+   - Problem: [Description]
+   - Suggestion: [How to fix]
+
+### Warnings
+1. **[Issue Title]**: `file:line`
+   - Problem: [Description]
+   - Suggestion: [How to fix]
+
+### Suggestions
+- [Suggestion 1]
+- [Suggestion 2]
+
+### Positive Notes
+- [Positive 1]
+- [Positive 2]
+
+### Verdict
+**Status**: ✅ APPROVE / ⚠️ REQUEST CHANGES / 💬 COMMENT
+
+**Reasoning**: [Explanation for the decision]
+```
+
+## Checklist
+
+- [ ] All files reviewed
+- [ ] Tests reviewed
+- [ ] Documentation checked
+- [ ] Security considered
+- [ ] Performance considered
+- [ ] Feedback provided
+- [ ] Decision made
+
+## Best Practices
+
+- Be constructive, not critical
+- Explain the "why"
+- Provide code examples
+- Focus on important issues
+- Acknowledge good work
+- Be respectful and professional

package/.ai-team/commands/test.md

@@ -0,0 +1,115 @@
+# /test Command
+
+## Purpose
+
+Run tests and ensure code quality for the current changes.
+
+## Usage
+
+```
+/test
+/test [specific-test-pattern]
+/test --coverage
+/test --watch
+```
+
+## Examples
+
+```
+/test
+/test user-auth
+/test --coverage
+/test src/components/Button
+```
+
+## Agent: QA
+
+## Workflow
+
+### 1. Test Discovery
+- Find test files related to changes
+- Identify test types needed
+- Check test configuration
+
+### 2. Test Execution
+- Run unit tests
+- Run integration tests (if applicable)
+- Run lint checks
+- Run type checks
+
+### 3. Coverage Analysis
+- Check test coverage
+- Identify uncovered lines
+- Note coverage changes
+
+### 4. Validation
+- Verify test results
+- Check for flaky tests
+- Validate test quality
+
+### 5. Reporting
+- Summarize test results
+- Report coverage
+- Note any issues
+
+## Test Types
+
+### Unit Tests
+- Test individual functions
+- Mock dependencies
+- Fast execution
+
+### Integration Tests
+- Test component interactions
+- Use real dependencies
+- Focus on boundaries
+
+### E2E Tests
+- Test complete flows
+- User perspective
+- Browser/API testing
+
+## Output
+
+```markdown
+## Test Report
+
+### Summary
+- **Total Tests**: X
+- **Passed**: Y
+- **Failed**: Z
+- **Skipped**: W
+
+### Coverage
+- **Lines**: X%
+- **Functions**: Y%
+- **Branches**: Z%
+- **Statements**: W%
+
+### Results by File
+| File | Tests | Passed | Failed |
+|------|-------|--------|--------|
+| ... | ... | ... | ... |
+
+### Failures
+[Test failure details]
+
+### Recommendations
+- [Recommendation 1]
+- [Recommendation 2]
+```
+
+## Checklist
+
+- [ ] All tests pass
+- [ ] Coverage meets threshold
+- [ ] No flaky tests
+- [ ] New code is tested
+- [ ] Edge cases covered
+
+## Next Steps
+
+After `/test`:
+- Fix any failing tests
+- Add missing test coverage
+- Use `/review` for code review

package/.ai-team/commands/triage.md

@@ -0,0 +1,138 @@
+# /triage Command
+
+## Purpose
+
+Classify and prioritize issues, determining the appropriate workflow and next steps.
+
+## Usage
+
+```
+/triage [issue-number]
+/triage
+```
+
+## Examples
+
+```
+/triage 123
+/triage
+```
+
+## Agent: Architect
+
+## Workflow
+
+### 1. Issue Analysis
+
+- Read the issue content
+- Understand the request type
+- Identify key information
+- Note missing details
+
+### 2. Classification
+
+Determine the issue type:
+
+| Type | Indicators | Workflow |
+|------|------------|----------|
+| Feature | New capability, enhancement | feature workflow |
+| Bug | Error, crash, incorrect behavior | bugfix workflow |
+| Tech Task | Refactoring, dependency, performance | tech workflow |
+| Question | Clarification, discussion | respond directly |
+| Invalid | Spam, duplicate, not actionable | close/comment |
+
+### 3. Priority Assessment
+
+Assess priority based on:
+
+| Factor | Points |
+|--------|--------|
+| Blocks other work | +3 |
+| Security issue | +3 |
+| Customer impact | +2 |
+| Regression | +2 |
+| Easy fix | +1 |
+| Long-standing | -1 |
+
+**Priority Levels:**
+- **P0 Critical**: Immediate attention required
+- **P1 High**: Should be addressed soon
+- **P2 Medium**: Normal priority
+- **P3 Low**: Nice to have
+
+### 4. Label Assignment
+
+Apply appropriate labels:
+
+| Category | Labels |
+|----------|--------|
+| Type | `feature`, `bug`, `tech-debt`, `question` |
+| Priority | `priority:critical`, `priority:high`, `priority:medium`, `priority:low` |
+| Module | `module:core`, `module:api`, `module:ui`, etc. |
+| Status | `needs-info`, `ready`, `blocked` |
+
+### 5. Next Steps
+
+Determine and document:
+- Which agent should handle next
+- What information is needed
+- Any dependencies or blockers
+
+## Output Format
+
+```markdown
+## Triage Report
+
+### Classification
+- **Type**: [Feature/Bug/Tech Task/Question]
+- **Priority**: [P0/P1/P2/P3]
+- **Module**: [Affected module(s)]
+
+### Summary
+[Brief summary of the issue]
+
+### Assessment
+[Analysis of the issue]
+
+### Labels Applied
+- `label1`
+- `label2`
+
+### Next Steps
+1. [Next step 1]
+2. [Next step 2]
+
+### Recommended Agent
+[Agent name] - [Reason]
+
+### Questions/Clarifications Needed
+- [Question 1]
+- [Question 2]
+```
+
+## Checklist
+
+- [ ] Issue type determined
+- [ ] Priority assigned
+- [ ] Labels applied
+- [ ] Module identified
+- [ ] Next steps documented
+- [ ] Recommended agent specified
+
+## Automation
+
+When `/triage` is run:
+
+1. Analyze issue content
+2. Apply classification labels
+3. Set priority label
+4. Assign to appropriate module
+5. Comment with triage report
+6. Recommend next action
+
+## Notes
+
+- Triage should be fast but thorough
+- When in doubt, ask for clarification
+- Don't assume missing context
+- Keep the triage report concise

package/.ai-team/memory/architect/architecture_notes.md

@@ -0,0 +1,67 @@
+# Architect Memory - Architecture Notes
+
+This file stores architecture-level observations and decisions made by the Architect agent.
+
+## Purpose
+
+Record architectural insights, module relationships, and design decisions that should be preserved across tasks.
+
+---
+
+## Architecture Notes
+
+### System Overview
+
+- **Project Type**: AI-powered autonomous development team
+- **Primary Language**: TypeScript
+- **Runtime**: Node.js
+- **Key Frameworks**: OpenCode, GitHub Actions
+
+### Key Design Decisions
+
+| Date | Decision | Rationale | Alternatives Considered |
+|------|----------|-----------|------------------------|
+| | | | |
+
+### Module Boundaries
+
+```
+src/
+├── modules/     # Feature modules (independent)
+├── shared/      # Shared utilities (stable)
+├── config/      # Configuration (isolated)
+└── index.ts     # Entry point
+```
+
+### Dependency Rules
+
+- Modules should not have circular dependencies
+- Shared utilities should not depend on modules
+- Config should be loaded at startup
+
+---
+
+## Architecture Evolution Log
+
+### [Date] - [Change Title]
+
+**Context**: [Why this change was needed]
+
+**Decision**: [What was decided]
+
+**Impact**: [What modules were affected]
+
+---
+
+## Pending Architecture Questions
+
+- [ ] [Question 1]
+- [ ] [Question 2]
+
+---
+
+## Notes
+
+- Update this file when making significant architectural decisions
+- Include rationale to help future decision-making
+- Cross-reference to `docs/decisions/` for formal ADRs

package/.ai-team/memory/architect/design_rationale.md

@@ -0,0 +1,113 @@
+# Architect Memory - Design Rationale
+
+This file records the reasoning behind architectural decisions to support future decision-making.
+
+---
+
+## Design Principles
+
+### 1. Memory Isolation
+
+**Decision**: Each AI role has isolated memory directories.
+
+**Rationale**: 
+- Prevents cross-role contamination
+- Allows role-specific knowledge accumulation
+- Reduces context confusion between roles
+
+**Trade-offs**:
+- (+) Clear ownership of knowledge
+- (+) Easier debugging of role behavior
+- (-) Requires explicit sharing for cross-role context
+- (-) More files to maintain
+
+### 2. Task-Scoped Memory
+
+**Decision**: Each issue/task has its own memory directory under `tasks/`.
+
+**Rationale**:
+- Keeps task context isolated
+- Provides traceable history
+- Allows archiving completed tasks
+
+**Trade-offs**:
+- (+) Clean separation of concerns
+- (+) Easy to review specific task decisions
+- (-) Requires manual or automated cleanup
+- (-) Potential duplication with issue comments
+
+### 3. Global Memory Protection
+
+**Decision**: Global memory (`docs/`, `AGENTS.md`) requires human approval for changes.
+
+**Rationale**:
+- Prevents AI from corrupting project truths
+- Maintains human governance
+- Ensures stability of core knowledge
+
+**Trade-offs**:
+- (+) Stable project documentation
+- (+) Human oversight maintained
+- (-) Slower updates to global docs
+- (-) Requires explicit approval workflow
+
+### 4. Role-Based Permissions
+
+**Decision**: Each role has defined read/write permissions for memory locations.
+
+**Rationale**:
+- Enforces separation of concerns
+- Prevents unintended modifications
+- Clarifies responsibility
+
+---
+
+## Architecture Decision Records (ADRs)
+
+For formal architectural decisions, create entries in `docs/decisions/`.
+
+### ADR Template
+
+```markdown
+# ADR-NNN: [Title]
+
+## Status
+[Proposed | Accepted | Deprecated | Superseded]
+
+## Context
+[What is the issue we're addressing]
+
+## Decision
+[What is the change we're proposing/have made]
+
+## Consequences
+[What becomes easier/harder as a result]
+```
+
+---
+
+## Design Patterns Used
+
+| Pattern | Application | Reason |
+|---------|-------------|--------|
+| Layered Architecture | System design | Separation of concerns |
+| Repository Pattern | Data access | Abstraction over storage |
+| Agent Pattern | AI roles | Specialized behavior |
+
+---
+
+## Anti-Patterns to Avoid
+
+| Anti-Pattern | Why Avoid | Alternative |
+|--------------|-----------|-------------|
+| God Object | Hard to maintain, test | Single responsibility |
+| Circular Dependencies | Confusing, hard to debug | Dependency injection |
+| Global State | Hard to track changes | Explicit parameters |
+
+---
+
+## Notes
+
+- Update this file when making significant design decisions
+- Cross-reference formal ADRs in `docs/decisions/`
+- Include trade-off analysis for major decisions