aigent-team 0.1.0 → 0.3.0

package/templates/teams/lead/skills/parallel-orchestration.md

@@ -0,0 +1,46 @@
+# Skill: Parallel Agent Orchestration
+
+**Trigger**: When implementing a feature that requires multiple specialist agents working simultaneously.
+
+## Steps
+
+1. **Map the dependency graph**:
+   - List all subtasks and which agent owns each
+   - Identify dependencies: which tasks must complete before others can start
+   - Group independent tasks that can run in parallel
+   - Example:
+     ```
+     BA (specs) → [FE (UI) + BE (API)] → QA (integration tests) → DevOps (deploy config)
+     ```
+
+2. **Define the API contract first** (if FE + BE are both involved):
+   - Have BA produce the API contract specification
+   - Both FE and BE must acknowledge the contract before starting
+   - Contract includes: endpoints, request/response schemas, error codes, auth requirements
+
+3. **Spawn parallel agents with full context**:
+   - Each agent gets: task description, relevant specs, file scope, acceptance criteria
+   - Each agent gets: the API contract (if applicable)
+   - Each agent gets: constraints and deadlines
+
+4. **Monitor and coordinate**:
+   - Check agent outputs at each milestone
+   - If one agent's output changes the contract, pause and realign all affected agents
+   - Resolve conflicts immediately — don't let agents proceed on divergent assumptions
+
+5. **Integration checkpoint**:
+   - After parallel work completes, verify FE and BE outputs match the same contract
+   - Have QA write integration tests that exercise the full flow
+   - Run all unit tests from all agents together
+
+6. **Final review**:
+   - Review combined diff for consistency
+   - Verify no duplicate code or conflicting patterns across agent outputs
+   - Confirm all acceptance criteria are met
+
+## Expected Output
+
+- Dependency graph (which tasks depend on which)
+- Agent assignments with full context templates
+- Integration verification results
+- Combined review summary

package/templates/teams/lead/skills/sprint-review.md

@@ -0,0 +1,38 @@
+# Skill: Sprint Review
+
+**Trigger**: When reviewing completed work at the end of a sprint or milestone, assessing quality and completeness.
+
+## Steps
+
+1. **Gather deliverables** — Collect all outputs from the sprint:
+   - List all PRs merged or in review
+   - List all tasks completed and their acceptance criteria status
+   - Identify any tasks that were carried over (incomplete)
+
+2. **Quality assessment** — For each deliverable:
+   - Does it meet the acceptance criteria defined by BA?
+   - Has it passed code review by the relevant specialist agent?
+   - Are tests written and passing (unit, integration, E2E as appropriate)?
+   - Are there any open review comments or unresolved discussions?
+
+3. **Cross-team alignment check**:
+   - FE and BE APIs match — no mismatched contracts
+   - Shared components modified by one team don't break another
+   - Database changes are compatible with both current and previous app versions
+
+4. **Technical debt assessment**:
+   - Were any shortcuts taken that need follow-up tickets?
+   - Are there TODO comments that should be tracked?
+   - Were any rules or constraints violated with justification?
+
+5. **Produce sprint summary**:
+   - Completed: what was delivered and working
+   - Carried over: what wasn't finished and why
+   - Risks: what might cause issues in the next sprint
+   - Improvements: what went well, what should change
+
+## Expected Output
+
+- Sprint summary document with completed/carried/risks sections
+- Quality scorecard per deliverable
+- Follow-up tickets for technical debt or unfinished work

package/templates/teams/qa/rules.md

@@ -0,0 +1,27 @@
+# Rules (Hard Constraints)
+
+## Scope Rules
+- **DO NOT** modify production source code — only test files, test utilities, and test configuration
+- **DO NOT** modify infrastructure or deployment configs
+- You may read any source file to understand behavior, but only write test code
+
+## Action Rules
+- **NEVER** commit `.only` or `.skip` on tests — all tests must run in CI
+- **NEVER** use `sleep()` or fixed delays in tests — use explicit waits and polling
+- **NEVER** disable or delete existing tests without documenting the reason
+- **NEVER** mock what you can test against a real implementation (prefer integration over mocking)
+- **DO NOT** write tests that depend on execution order or shared mutable state
+- **DO NOT** assert on implementation details (internal state, private methods, CSS classes)
+
+## Escalation Rules — Stop and Ask
+- Test coverage would drop below the project threshold after changes
+- Flaky test requires infrastructure fix (timing, race condition, external dependency)
+- Cannot write meaningful test because the source code has no testable interface
+- Security test reveals an actual vulnerability — report immediately, don't just log it
+- Performance test shows regression > 20% from baseline
+
+## Output Rules
+- Every test must have a clear description that reads as a behavior specification
+- No empty test bodies or placeholder tests — every `it()` must assert something
+- Test data must be self-contained — no dependency on external fixtures or seed data that isn't in the test
+- E2E tests must clean up after themselves (created records, uploaded files, etc.)

package/templates/teams/qa/skills/flaky-test-diagnosis.md

@@ -0,0 +1,50 @@
+# Skill: Diagnose Flaky Test
+
+**Trigger**: When a test is intermittently failing in CI or locally, passing on retry but failing inconsistently.
+
+## Steps
+
+1. **Reproduce the flake** — Run the test in a loop to confirm:
+   ```bash
+   # Run 20 times, stop on first failure
+   for i in $(seq 1 20); do npx vitest run path/to/test.ts || break; done
+   # Or with Jest
+   npx jest --forceExit --runInBand path/to/test.ts --repeat=20
+   ```
+
+2. **Classify the flake** — Common root causes:
+   - **Timing**: test depends on setTimeout, animation frames, or network delays
+   - **Shared state**: tests modify global/module state that leaks between runs
+   - **Order dependency**: test passes alone but fails when run with others
+   - **Race condition**: async operations complete in unpredictable order
+   - **External dependency**: test hits a real API, database, or file system
+   - **Resource exhaustion**: port conflicts, file descriptor leaks, memory pressure
+
+3. **Isolate** — Narrow down the cause:
+   ```bash
+   # Run the failing test alone
+   npx vitest run --testNamePattern "specific test name"
+   # Run with the test before it
+   npx vitest run path/to/test.ts --sequence
+   # Check for shared state
+   npx vitest run --isolate path/to/test.ts
+   ```
+
+4. **Fix by category**:
+   - **Timing**: Replace `sleep()` with explicit waits (`waitFor`, `waitForElement`, polling)
+   - **Shared state**: Add proper `beforeEach`/`afterEach` cleanup, avoid global mutations
+   - **Order dependency**: Make each test fully self-contained with its own setup
+   - **Race condition**: Use proper async/await, avoid fire-and-forget promises
+   - **External dependency**: Mock the external service, use test containers for databases
+
+5. **Verify the fix** — Run the loop again to confirm stability:
+   ```bash
+   for i in $(seq 1 50); do npx vitest run path/to/test.ts || { echo "FAILED on run $i"; exit 1; }; done
+   echo "All 50 runs passed"
+   ```
+
+## Expected Output
+
+- Root cause classification (timing, shared state, race condition, etc.)
+- Specific fix applied with explanation
+- Verification that the test passes 50 consecutive runs

package/templates/teams/qa/skills/generate-test-data.md

@@ -0,0 +1,56 @@
+# Skill: Generate Test Data
+
+**Trigger**: When setting up test fixtures, creating seed data for E2E tests, or testing edge cases and boundary conditions.
+
+## Steps
+
+1. **Analyze data requirements**:
+   - Read the schema/types for entities involved
+   - Identify required fields, constraints (unique, foreign keys, enums)
+   - Identify edge cases: empty strings, max-length values, unicode, special characters
+
+2. **Create factory functions** — Use the project's factory pattern:
+   ```typescript
+   // Example with factory pattern
+   function createUser(overrides?: Partial<User>): User {
+     return {
+       id: crypto.randomUUID(),
+       name: `Test User ${Date.now()}`,
+       email: `test-${Date.now()}@example.com`,
+       role: 'user',
+       createdAt: new Date(),
+       ...overrides,
+     };
+   }
+   ```
+
+3. **Generate edge case data sets**:
+   - **Boundary values**: empty string, 1 char, max length
+   - **Unicode**: emoji, CJK characters, RTL text, zero-width characters
+   - **Numeric edges**: 0, -1, MAX_SAFE_INTEGER, NaN, Infinity
+   - **Date edges**: epoch, far future, timezone boundaries, DST transitions
+   - **Null/undefined**: every nullable field tested with null
+
+4. **Create relationship data** — For entities with foreign keys:
+   - Build parent entities before children
+   - Create both happy-path and orphan scenarios
+   - Test cascade delete/update behavior
+
+5. **Seed data for E2E**:
+   ```typescript
+   async function seedTestDatabase() {
+     const admin = await createUser({ role: 'admin' });
+     const users = await Promise.all(
+       Array.from({ length: 10 }, () => createUser())
+     );
+     // Create related entities...
+     return { admin, users };
+   }
+   ```
+
+## Expected Output
+
+- Factory functions for each entity involved
+- Edge case data sets organized by category
+- Seed script for E2E test environment
+- Cleanup function to reset test data after runs