amazingteam 3.0.0

package/.ai-team/skills/safe-refactor-checklist/skill.md

@@ -0,0 +1,215 @@
+# Safe Refactor Checklist
+
+## Purpose
+
+This skill provides a systematic checklist for safely refactoring code without introducing bugs.
+
+## When to Use
+
+- Improving code structure
+- Reducing technical debt
+- Optimizing performance
+- Preparing for new features
+- Cleaning up legacy code
+
+## Pre-Refactor Checklist
+
+### 1. Verify Test Coverage
+- [ ] Adequate test coverage exists
+- [ ] Tests are reliable and passing
+- [ ] Edge cases are covered
+- [ ] Can add more tests if needed
+
+### 2. Understand Current Code
+- [ ] Read and understand the code
+- [ ] Identify dependencies
+- [ ] Note any side effects
+- [ ] Document current behavior
+
+### 3. Identify Refactor Scope
+- [ ] Define clear boundaries
+- [ ] Identify affected modules
+- [ ] Check for code that uses this code
+- [ ] Document entry points
+
+### 4. Create Safety Net
+- [ ] Ensure all tests pass before starting
+- [ ] Create a feature branch
+- [ ] Consider creating characterization tests
+- [ ] Document current behavior if unclear
+
+## Refactor Principles
+
+### 1. Small Steps
+- Make one small change at a time
+- Run tests after each change
+- Commit frequently
+- Keep changes reversible
+
+### 2. Preserve Behavior
+- Don't change what the code does
+- Only change how it does it
+- Keep the same public interface
+- Maintain backward compatibility
+
+### 3. Tests Are Your Friend
+- Run tests constantly
+- Add tests before refactoring
+- Trust failing tests
+- Fix issues immediately
+
+## Refactor Patterns
+
+### Extract Method
+```
+Before:
+function complexFunction() {
+  // lots of code
+  // section A
+  // section B
+  // section C
+}
+
+After:
+function complexFunction() {
+  doSectionA();
+  doSectionB();
+  doSectionC();
+}
+
+function doSectionA() { /* ... */ }
+function doSectionB() { /* ... */ }
+function doSectionC() { /* ... */ }
+```
+
+### Extract Variable
+```
+Before:
+if (item.price * (1 + taxRate) > threshold) { ... }
+
+After:
+const totalWithTax = item.price * (1 + taxRate);
+if (totalWithTax > threshold) { ... }
+```
+
+### Rename Variable/Method
+```
+Before:
+function calc(x, y) { return x * y; }
+
+After:
+function calculateTotal(price, quantity) {
+  return price * quantity;
+}
+```
+
+### Move Method/Field
+- Move to the class that uses it most
+- Update all references
+- Consider creating a delegate
+
+### Inline Method
+- When the method body is clearer than the name
+- Replace calls with the body
+- Remove the method
+
+## During Refactor Checklist
+
+### After Each Change
+- [ ] Run tests (all must pass)
+- [ ] Check for compile errors
+- [ ] Verify behavior unchanged
+- [ ] Commit if tests pass
+
+### Periodic Checks
+- [ ] Run full test suite
+- [ ] Check for performance impact
+- [ ] Review for unintended changes
+- [ ] Update documentation
+
+## Post-Refactor Checklist
+
+### Verification
+- [ ] All tests pass
+- [ ] No new lint warnings
+- [ ] No type errors
+- [ ] Performance is acceptable
+
+### Quality
+- [ ] Code is more readable
+- [ ] Duplication is reduced
+- [ ] Complexity is reduced
+- [ ] Tests are improved
+
+### Documentation
+- [ ] Comments updated
+- [ ] API docs updated
+- [ ] README updated if needed
+- [ ] Migration guide if breaking
+
+### Final Checks
+- [ ] Peer review done
+- [ ] Merge conflicts resolved
+- [ ] CI/CD passes
+- [ ] Ready for merge
+
+## Red Flags - Stop Refactoring
+
+- Tests start failing unexpectedly
+- Behavior changes unexpectedly
+- Scope keeps expanding
+- Can't verify behavior
+- No test coverage for critical code
+- Changes are too risky
+
+## Refactor Log Template
+
+```markdown
+## Refactor: [Description]
+
+### Date
+[Date]
+
+### Scope
+[What was refactored]
+
+### Changes
+1. [Change 1]
+2. [Change 2]
+
+### Files Modified
+- `file1.ts`: [Description]
+- `file2.ts`: [Description]
+
+### Tests Added
+- [Test 1]
+- [Test 2]
+
+### Risks Mitigated
+- [Risk 1]: [How it was addressed]
+
+### Review Notes
+[Any notes for reviewers]
+```
+
+## Best Practices
+
+1. **Never refactor without tests**
+   - If no tests, write them first
+   - Characterization tests for legacy code
+
+2. **One thing at a time**
+   - Don't mix refactoring with feature changes
+   - Keep refactor commits separate
+
+3. **Test frequently**
+   - After every small change
+   - Don't wait until the end
+
+4. **Revert if stuck**
+   - It's okay to abandon a refactor
+   - Learn from what didn't work
+
+5. **Document why, not what**
+   - Explain the reason for refactoring
+   - Let code show what changed

package/.ai-team/skills/task-breakdown-and-dispatch/skill.md

@@ -0,0 +1,151 @@
+# Task Breakdown and Dispatch
+
+## Purpose
+
+This skill enables systematic decomposition of tasks into actionable subtasks and intelligent dispatching to appropriate roles.
+
+## When to Use
+
+- Starting a new feature or large task
+- Planning sprint work
+- Breaking down complex issues
+- Coordinating multi-role workflows
+
+## Steps
+
+### 1. Analyze Task Scope
+
+```
+1. Read the task description and acceptance criteria
+2. Identify the task type: feature, bug, refactor, docs, infra
+3. Assess complexity: simple, moderate, complex
+4. Estimate risk level: low, medium, high
+5. Identify affected modules/domains
+```
+
+### 2. Identify Required Roles
+
+```
+1. Architect: Needed for design decisions
+2. Developer: Needed for implementation
+3. QA: Needed for validation
+4. Reviewer: Needed for code review
+5. Triage: Needed for initial investigation
+6. CI Analyst: Needed for CI-related tasks
+```
+
+### 3. Decompose into Subtasks
+
+```
+1. Break task into logical phases
+2. Identify dependencies between phases
+3. Define clear deliverables for each phase
+4. Estimate effort for each subtask
+5. Assign appropriate role to each subtask
+```
+
+### 4. Define Dependencies
+
+```
+1. Map task dependencies
+2. Identify blocking relationships
+3. Find parallelizable work
+4. Define critical path
+5. Document external dependencies
+```
+
+### 5. Create Task Manifest
+
+```
+1. Generate task.yaml with metadata
+2. List all subtasks
+3. Define state transitions
+4. Set acceptance criteria
+5. Assign owner_role
+```
+
+### 6. Dispatch Tasks
+
+```
+1. Start with unblocked tasks
+2. Notify appropriate role
+3. Track task progress
+4. Handle blocking issues
+5. Coordinate handoffs between roles
+```
+
+## Task Manifest Template
+
+```yaml
+id: issue-123
+title: Implement user authentication
+type: feature
+status: ready
+priority: high
+owner_role: planner
+depends_on: []
+blocked_by: []
+acceptance_criteria:
+  - Users can log in with email/password
+  - Sessions persist across page reloads
+  - Failed login attempts are rate-limited
+risk_level: medium
+module_scope:
+  - auth
+  - api
+  - database
+subtasks:
+  - id: design-auth-flow
+    title: Design authentication flow
+    owner_role: architect
+    status: ready
+    depends_on: []
+  - id: implement-auth-api
+    title: Implement authentication API
+    owner_role: developer
+    status: blocked
+    depends_on: [design-auth-flow]
+  - id: add-auth-tests
+    title: Add authentication tests
+    owner_role: qa
+    status: pending
+    depends_on: [implement-auth-api]
+```
+
+## State Machine
+
+```
+backlog → ready → in_analysis → in_design → in_implementation → in_validation → in_review → release_candidate → done
+                              ↓                                              ↓
+                           blocked ←───────────────────────────────────────── ←
+```
+
+## Dispatch Matrix
+
+| Task Type | First Role | Handoff Sequence |
+|-----------|------------|------------------|
+| Feature | Architect | Architect → Developer → QA → Reviewer |
+| Bug | Triage | Triage → Developer → QA → Reviewer |
+| Refactor | Architect | Architect → Developer → QA |
+| Docs | Developer | Developer → Reviewer |
+| CI Failure | CI Analyst | CI Analyst → Developer → QA |
+
+## Checklist
+
+- [ ] Task scope analyzed
+- [ ] Required roles identified
+- [ ] Task decomposed into subtasks
+- [ ] Dependencies mapped
+- [ ] Task manifest created
+- [ ] Initial tasks dispatched
+- [ ] Progress tracking in place
+- [ ] Blocking issues addressed
+
+## Best Practices
+
+- Start with clear acceptance criteria
+- Keep subtasks atomic and focused
+- Minimize dependencies where possible
+- Document assumptions
+- Update task status regularly
+- Escalate blocked tasks promptly

package/.ai-team/skills/test-first-feature-dev/skill.md

@@ -0,0 +1,205 @@
+# Test-First Feature Development
+
+## Purpose
+
+This skill guides developers through implementing features using a test-driven development approach.
+
+## 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
+5. Document assumptions
+```
+
+### 2. Write Test Cases
+
+```
+1. Start with happy path tests
+2. Add edge case tests
+3. Add error scenario tests
+4. Consider boundary conditions
+5. Document test intentions
+```
+
+### 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
+4. Ignore optimization for now
+```
+
+### 5. Make Tests Pass
+
+```
+1. Run tests to verify pass
+2. If failing, debug and fix
+3. Ensure test is testing the right thing
+4. Confirm implementation is minimal
+```
+
+### 6. Refactor
+
+```
+1. Review the implementation
+2. Identify code smells
+3. Refactor while keeping tests green
+4. Improve code organization
+5. Remove duplication
+```
+
+### 7. Repeat
+
+```
+1. Write next failing test
+2. Implement minimum code
+3. Make test pass
+4. Refactor
+5. Continue until feature complete
+```
+
+## 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);
+    });
+
+    it('should handle edge case', () => {
+      // Test edge case
+    });
+
+    it('should throw error for invalid input', () => {
+      // Test error handling
+    });
+  });
+});
+```
+
+## Test Categories
+
+### Unit Tests
+- Test individual functions/methods
+- Mock external dependencies
+- Fast execution
+- Isolated scope
+
+### Integration Tests
+- Test component interactions
+- Use real dependencies where appropriate
+- Focus on boundaries
+- Verify data flow
+
+### Acceptance Tests
+- Test complete user scenarios
+- Verify acceptance criteria
+- End-to-end flow
+- User perspective
+
+## Test Naming Convention
+
+```
+test_[method]_[scenario]_[expectedResult]
+
+Examples:
+- test_calculateTotal_withEmptyCart_returnsZero
+- test_login_withInvalidPassword_throwsException
+- test_processOrder_withValidInput_completesSuccessfully
+```
+
+## Checklist
+
+- [ ] Requirements understood
+- [ ] Test cases designed
+- [ ] Happy path tests written
+- [ ] Edge case tests written
+- [ ] Error handling tests written
+- [ ] All tests passing
+- [ ] Code refactored
+- [ ] Test coverage adequate
+- [ ] Code reviewed
+
+## Common Patterns
+
+### Parameterized Tests
+```typescript
+describe.each([
+  ['input1', 'expected1'],
+  ['input2', 'expected2'],
+  ['input3', 'expected3'],
+])('with input %s', (input, expected) => {
+  it(`returns ${expected}`, () => {
+    expect(fn(input)).toBe(expected);
+  });
+});
+```
+
+### Mocking
+```typescript
+// Mock a module
+jest.mock('../dependency', () => ({
+  method: jest.fn(),
+}));
+
+// Mock implementation
+mock.method.mockImplementation(() => 'mocked value');
+```
+
+### Async Testing
+```typescript
+// Promise
+it('should handle async', async () => {
+  const result = await asyncFunction();
+  expect(result).toBe('expected');
+});
+
+// Callback
+it('should call callback', (done) => {
+  functionWithCallback((result) => {
+    expect(result).toBe('expected');
+    done();
+  });
+});
+```
+
+## Best Practices
+
+- One assertion per test (when practical)
+- Test behavior, not implementation
+- Keep tests independent
+- Use descriptive test names
+- Don't test implementation details
+- Test edge cases thoroughly
+- Make tests deterministic

package/.ai-team/workflows/ci.yml

@@ -0,0 +1,81 @@
+name: CI
+
+on:
+  push:
+    branches: [main, develop]
+  pull_request:
+    branches: [main, develop]
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          
+      - name: Install dependencies
+        run: npm install
+        
+      - name: Run Lint
+        run: npm run lint
+
+  typecheck:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          
+      - name: Install dependencies
+        run: npm install
+        
+      - name: Run TypeCheck
+        run: npm run typecheck
+
+  test:
+    runs-on: ubuntu-latest
+    needs: [lint, typecheck]
+    steps:
+      - uses: actions/checkout@v4
+      
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          
+      - name: Install dependencies
+        run: npm install
+        
+      - name: Run Tests
+        run: npm test
+
+  build:
+    runs-on: ubuntu-latest
+    needs: [lint, typecheck]
+    steps:
+      - uses: actions/checkout@v4
+      
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          
+      - name: Install dependencies
+        run: npm install
+        
+      - name: Build
+        run: npm run build
+        
+      - name: Upload Build Artifacts
+        uses: actions/upload-artifact@v4
+        with:
+          name: build-output
+          path: dist/
+          retention-days: 7