@wipal/agent-team 1.0.0

package/.claude/skills/domain/quality/test-planning/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: test-planning
+description: |
+  Test strategy and planning for comprehensive quality assurance. Use when:
+  creating test plans, defining test strategy, planning test coverage, or when
+  user mentions "test plan", "test strategy", "QA plan", "coverage".
+version: 1.0.0
+category: quality
+tags:
+  - test-planning
+  - qa
+  - strategy
+  - coverage
+depends_on: []
+recommends:
+  - test-automation
+used_by:
+  - regression-testing
+---
+
+# Skill: Test Planning
+
+## Core Principle
+**Test early, test often, test smart.** Quality is built in, not tested in.
+
+## Testing Pyramid
+
+```
+         ▲
+        /E2E\         10% - Slow, expensive
+       /─────\
+      /  API  \       20% - Integration
+     /─────────\
+    /   Unit    \     70% - Fast, cheap
+   /─────────────\
+```
+
+## Hard Rules
+
+1. **NEVER test everything manually** - Automate what makes sense
+2. **NEVER skip edge cases** - That's where bugs hide
+3. **ALWAYS define acceptance criteria first** - Know what "done" means
+4. **ALWAYS prioritize by risk** - High-risk areas need more testing
+
+## Test Plan Template
+
+```markdown
+# Test Plan: [Feature/Release Name]
+
+## 1. Overview
+- **Feature:** User authentication
+- **Release:** v2.0
+- **QA Lead:** @name
+- **Timeline:** Sprint 5-6
+
+## 2. Scope
+
+### In Scope
+- Login/logout functionality
+- Password reset
+- Session management
+- OAuth integration
+
+### Out of Scope
+- Biometric auth (Phase 2)
+- Multi-factor auth (Phase 3)
+
+## 3. Test Strategy
+
+### Unit Tests
+- Service layer business logic
+- Input validation
+- Error handling
+
+### Integration Tests
+- API endpoints
+- Database operations
+- External service mocks
+
+### E2E Tests
+- Critical user flows
+- Happy paths only
+
+## 4. Test Cases
+
+| ID | Type | Priority | Description |
+|----|------|----------|-------------|
+| AUTH-001 | Unit | High | Validate email format |
+| AUTH-002 | API | High | Login with valid credentials |
+| AUTH-003 | API | High | Login with invalid credentials |
+| AUTH-004 | E2E | Critical | Complete login flow |
+
+## 5. Entry Criteria
+- [ ] Feature development complete
+- [ ] Unit tests passing
+- [ ] Code review approved
+- [ ] Test environment ready
+
+## 6. Exit Criteria
+- [ ] All test cases executed
+- [ ] No critical bugs open
+- [ ] Coverage > 80%
+- [ ] Performance tests passed
+
+## 7. Risks
+| Risk | Likelihood | Mitigation |
+|------|------------|------------|
+| OAuth delay | Medium | Test with mock first |
+
+## 8. Resources
+- QA: 2 engineers
+- Duration: 5 days
+- Environment: Staging
+```
+
+## Test Case Template
+
+```markdown
+# TC-AUTH-001: Login with valid credentials
+
+## Metadata
+- **Priority:** Critical
+- **Type:** Functional
+- **Automation:** Yes
+
+## Pre-conditions
+- User account exists
+- User is not logged in
+
+## Test Steps
+1. Navigate to login page
+2. Enter valid email
+3. Enter valid password
+4. Click "Login" button
+
+## Expected Result
+- User is redirected to dashboard
+- Session token is set
+- User name displayed in header
+
+## Test Data
+- Email: test@example.com
+- Password: ValidPass123!
+
+## Post-conditions
+- User session created
+- Login timestamp updated
+```
+
+## Coverage Matrix
+
+```markdown
+| Requirement | Unit | Integration | E2E | Manual |
+|-------------|------|-------------|-----|--------|
+| Login       | ✅   | ✅          | ✅  | -      |
+| Password    | ✅   | ✅          | -   | ✅     |
+| OAuth       | ✅   | ✅          | ✅  | ✅     |
+| Session     | ✅   | ✅          | -   | -      |
+```
+
+## Common Mistakes
+
+| ❌ Mistake | ✅ Fix |
+|------------|--------|
+| Testing only happy path | Include edge cases |
+| No prioritization | Risk-based testing |
+| No entry/exit criteria | Define clearly |
+| Manual-only testing | Automate wisely |
+
+## Checklist
+
+- [ ] Scope defined
+- [ ] Strategy documented
+- [ ] Test cases written
+- [ ] Entry criteria met
+- [ ] Exit criteria defined
+- [ ] Risks identified

package/.claude/skills/leadership/code-review-advanced/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: code-review-advanced
+description: |
+  Advanced code review practices for Tech Leads and senior engineers. Use when:
+  reviewing architecture changes, mentoring through review, or when user mentions
+  "advanced review", "architecture review", "lead review", "senior review".
+version: 1.0.0
+category: leadership
+tags:
+  - code-review
+  - leadership
+  - mentorship
+  - architecture
+depends_on:
+  - code-review
+recommends:
+  - technical-debt
+used_by: []
+---
+
+# Skill: Code Review Advanced
+
+## Core Principle
+**Elevate the team through review.** Every review is a mentoring opportunity.
+
+## Beyond Basic Review
+
+| Level | Focus |
+|-------|-------|
+| **Junior** | Correctness, style |
+| **Mid** | Patterns, edge cases |
+| **Senior** | Architecture, maintainability |
+| **Lead** | Team growth, system health |
+
+## Hard Rules
+
+1. **NEVER block without teaching** - Explain the "why"
+2. **NEVER nitpick style** - Automate with linters
+3. **ALWAYS consider alternatives** - Is there a better approach?
+4. **ALWAYS think about future readers** - Code is read 10x more than written
+
+## Review Dimensions
+
+### 1. Correctness
+```
+- Does it work as intended?
+- Are edge cases handled?
+- Are errors handled properly?
+- Is the logic sound?
+```
+
+### 2. Architecture
+```
+- Does it fit the system design?
+- Is the abstraction appropriate?
+- Are dependencies correct?
+- Will it scale?
+```
+
+### 3. Maintainability
+```
+- Is it readable?
+- Is it testable?
+- Is it documented where needed?
+- Will it be easy to change?
+```
+
+### 4. Performance
+```
+- Are there obvious bottlenecks?
+- Is the algorithm efficient?
+- Are resources managed properly?
+- Is caching used appropriately?
+```
+
+### 5. Security
+```
+- Is input validated?
+- Is output sanitized?
+- Are secrets protected?
+- Is access controlled?
+```
+
+## Feedback Framework
+
+### SBI Model
+```
+Situation: "In the handleOrder function..."
+Behavior: "You're querying the database inside a loop..."
+Impact: "This will cause N+1 queries under load..."
+```
+
+### Teaching Through Review
+```markdown
+// ❌ Blocking comment
+"This is wrong, use a Map instead."
+
+// ✅ Teaching comment
+"Consider using a Map here instead of an object.
+Why: Maps have O(1) lookups and preserve insertion order.
+Example:
+```typescript
+const orderMap = new Map<string, Order>();
+for (const order of orders) {
+  orderMap.set(order.id, order);
+}
+```
+What do you think?"
+```
+
+## Architecture Review Checklist
+
+```markdown
+## Design Review
+
+### High-Level
+- [ ] Solution addresses the problem
+- [ ] Alternatives considered
+- [ ] Trade-offs documented
+- [ ] Scalability considered
+- [ ] Security reviewed
+
+### Implementation
+- [ ] Follows existing patterns
+- [ ] Appropriate abstraction level
+- [ ] Testable design
+- [ ] Error handling complete
+- [ ] Logging/monitoring added
+
+### Integration
+- [ ] API contracts clear
+- [ ] Backwards compatible
+- [ ] Migration plan if needed
+- [ ] Documentation updated
+```
+
+## Review Metrics
+
+```markdown
+## Team Health Indicators
+
+| Metric | Target | Current |
+|--------|--------|---------|
+| Review turnaround | < 4 hours | 2.5 hours |
+| Comments per PR | 3-8 | 5 |
+| PR size | < 400 lines | 280 |
+| Rework rate | < 20% | 15% |
+```
+
+## Common Mistakes
+
+| ❌ Mistake | ✅ Fix |
+|------------|--------|
+| Only finding problems | Acknowledge good patterns |
+| Vague comments | Be specific with examples |
+| Personal tone | Focus on code, not person |
+| Blocking without alternative | Suggest solutions |
+| Reviewing too quickly | Take time to understand |
+
+## Checklist
+
+- [ ] Logic verified
+- [ ] Architecture reviewed
+- [ ] Performance considered
+- [ ] Security checked
+- [ ] Mentoring opportunities used
+- [ ] Team patterns followed

package/.claude/skills/leadership/mentoring/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: mentoring
+description: |
+  Developer mentoring and coaching techniques for Tech Leads. Use when:
+  mentoring team members, career development, skill building, or when user
+  mentions "mentor", "coach", "develop", "grow", "career".
+version: 1.0.0
+category: leadership
+tags:
+  - mentoring
+  - coaching
+  - career
+  - development
+depends_on: []
+recommends: []
+used_by: []
+---
+
+# Skill: Mentoring
+
+## Core Principle
+**Grow people, not just code.** A mentor's success is measured by their mentees' growth.
+
+## Mentoring Styles
+
+| Style | When to Use |
+|-------|-------------|
+| **Directive** | New skills, urgent situations |
+| **Coaching** | Problem-solving, growth |
+| **Supportive** | Building confidence |
+| **Delegating** | Experienced, self-directed |
+
+## Hard Rules
+
+1. **NEVER do the work for them** - Guide, don't solve
+2. **NEVER assume knowledge** - Ask what they understand
+3. **ALWAYS give specific feedback** - Not just "good job"
+4. **ALWAYS follow up** - Check progress regularly
+
+## Growth Framework
+
+### 1:1 Meeting Structure
+```
+Week 1: Goal setting (15 min)
+- What do you want to learn?
+- Where do you want to grow?
+- What's blocking you?
+
+Week 2-3: Progress check (30 min)
+- What did you try?
+- What worked? What didn't?
+- What did you learn?
+
+Week 4: Review & adjust (30 min)
+- Progress toward goals?
+- Adjust approach?
+- Next month's focus?
+```
+
+## Feedback Model
+
+### SBI + Growth
+```
+Situation: "In yesterday's code review..."
+Behavior: "You explained the trade-offs clearly..."
+Impact: "The team understood why we chose this approach..."
+Growth: "Next time, consider adding a diagram for complex flows..."
+```
+
+### Radical Candor
+```
+Care Personally + Challenge Directly = Growth
+
+❌ Ruinous Empathy: Nice but not honest
+❌ Obnoxious Aggression: Honest but not kind
+❌ Manipulative Insincerity: Neither honest nor kind
+✅ Radical Candor: Both honest and kind
+```
+
+## Career Development
+
+### Skill Matrix
+```markdown
+| Level | Technical | Leadership | Communication |
+|-------|-----------|------------|---------------|
+| Junior | Learn basics | Follow | Ask questions |
+| Mid | Apply patterns | Collaborate | Explain ideas |
+| Senior | Design systems | Mentor | Influence |
+| Staff | Define direction | Lead teams | Drive change |
+```
+
+### Growth Plan Template
+```markdown
+# Growth Plan: [Name]
+
+## Current Level
+- Role: Mid-level Developer
+- Strengths: API design, testing
+- Areas for growth: System design, mentoring
+
+## 6-Month Goals
+1. Lead design of [feature]
+2. Mentor 1 junior developer
+3. Present at team meeting
+
+## Actions
+- [ ] Shadow architect on [project]
+- [ ] Complete system design course
+- [ ] Pair program with junior weekly
+
+## Check-ins
+- Monthly 1:1 with mentor
+- Bi-weekly progress updates
+```
+
+## Common Mistakes
+
+| ❌ Mistake | ✅ Fix |
+|------------|--------|
+| Doing the work | Guide with questions |
+| Vague feedback | Specific, actionable |
+| No follow-up | Regular check-ins |
+| One-size-fits-all | Adapt to individual |
+| Only fixing problems | Recognize growth |
+
+## Coaching Questions
+
+```
+Discovery:
+- What have you tried?
+- What do you think is the issue?
+- What would success look like?
+
+Growth:
+- What did you learn from this?
+- How would you approach it differently?
+- What support do you need?
+
+Empowerment:
+- What's your next step?
+- When will you try it?
+- How will I know it worked?
+```
+
+## Checklist
+
+- [ ] Regular 1:1s scheduled
+- [ ] Goals documented
+- [ ] Feedback given regularly
+- [ ] Progress tracked
+- [ ] Growth celebrated

package/.claude/skills/leadership/technical-debt/SKILL.md

@@ -0,0 +1,166 @@
+---
+name: technical-debt
+description: |
+  Technical debt management and prioritization strategies. Use when: managing
+  technical debt, prioritizing refactoring, or when user mentions "tech debt",
+  "refactor", "legacy", "cleanup", "improvement".
+version: 1.0.0
+category: leadership
+tags:
+  - technical-debt
+  - refactoring
+  - maintenance
+  - prioritization
+depends_on:
+  - code-review-advanced
+recommends: []
+used_by: []
+---
+
+# Skill: Technical Debt
+
+## Core Principle
+**Not all debt is bad.** Some debt is an investment. Manage it deliberately.
+
+## Types of Technical Debt
+
+| Type | Cause | Example |
+|------|-------|---------|
+| **Deliberate** | Strategic shortcut | MVP with hardcoded config |
+| **Accidental** | Lack of knowledge | Wrong abstraction |
+| **Bit rot** | Time/environment | Outdated dependencies |
+| **Design debt** | Evolving requirements | Architectural mismatch |
+
+## Debt Assessment
+
+### Impact vs Effort Matrix
+```
+        High Impact
+            │
+   Quick    │   Strategic
+   Wins     │   Refactors
+────────────┼────────────
+   Ignore   │   Consider
+   (For now)│   Carefully
+            │
+        Low Impact
+
+   Low Effort    High Effort
+```
+
+## Hard Rules
+
+1. **NEVER ignore debt** - Document it
+2. **NEVER refactor without value** - What problem are we solving?
+3. **ALWAYS quantify the cost** - Time lost, bugs caused, velocity impact
+4. **ALWAYS allocate time** - 10-20% of sprint capacity
+
+## Debt Tracking
+
+### Debt Register
+```markdown
+# Technical Debt Register
+
+| ID | Description | Impact | Effort | Priority | Status |
+|----|-------------|--------|--------|----------|--------|
+| TD-001 | Legacy auth module | High | 5 days | P1 | Planned |
+| TD-002 | Missing tests for payments | High | 3 days | P1 | In Progress |
+| TD-003 | Outdated React version | Medium | 2 days | P2 | Backlog |
+| TD-004 | Hardcoded feature flags | Low | 1 day | P3 | Backlog |
+```
+
+### Debt Cost Calculator
+```markdown
+# Debt Cost: Legacy Auth Module
+
+## Symptoms
+- 2 hours/week debugging auth issues
+- 3 security patches in last quarter
+- Can't add new OAuth providers
+
+## Quantified Cost
+- Engineering time: 2 hrs/week × $100/hr × 52 weeks = $10,400/year
+- Security risk: Medium (estimated $50K if exploited)
+- Opportunity cost: 2 features delayed
+
+## Fix Cost
+- Refactor: 5 days × $800/day = $4,000
+- Testing: 2 days × $800/day = $1,600
+- Total: $5,600
+
+## ROI
+- Payback: ~6 months
+- Year 1 savings: $4,800
+- Risk reduction: Significant
+
+## Recommendation
+Fix in Q2 - High priority
+```
+
+## Prioritization Framework
+
+### SQALE Method
+```
+S - Severity: How bad is it?
+Q - Quality: What does it affect?
+U - Urgency: When must it be fixed?
+A - Area: Where in the codebase?
+L - Level: What skill needed?
+E - Effort: How long to fix?
+```
+
+## Refactoring Strategies
+
+### Strangler Fig Pattern
+```typescript
+// 1. Create new implementation
+const newUserService = new UserServiceV2();
+
+// 2. Route new features to new code
+if (featureFlags.useNewUserService) {
+  return newUserService.getUser(id);
+}
+
+// 3. Gradually migrate existing calls
+const userService = isNewFeature ? newUserService : legacyUserService;
+
+// 4. Remove old code when complete
+```
+
+### Incremental Refactoring
+```
+Week 1: Add tests to legacy code
+Week 2: Extract first module
+Week 3: Extract second module
+Week 4: Remove legacy code
+```
+
+## Common Mistakes
+
+| ❌ Mistake | ✅ Fix |
+|------------|--------|
+| "Rewrite everything" | Incremental improvement |
+| No debt tracking | Maintain debt register |
+| Zero debt goal | Accept some debt |
+| Ignoring until crisis | Regular debt review |
+| Refactoring without tests | Test first |
+
+## Debt Review Meeting
+
+```markdown
+## Agenda (30 min)
+
+1. Review new debt items (5 min)
+2. Update existing debt status (5 min)
+3. Prioritize for next sprint (10 min)
+4. Assign owners (5 min)
+5. Action items (5 min)
+```
+
+## Checklist
+
+- [ ] Debt register maintained
+- [ ] Costs quantified
+- [ ] Sprint capacity allocated
+- [ ] Regular reviews scheduled
+- [ ] Fixes tested before removing debt