@wipal/agent-team 1.0.3 → 1.1.0

package/.claude/rules/role-rules/dev-be-rules.md

@@ -0,0 +1,241 @@
+# dev-be Rules - Rules riêng cho Backend Developers
+
+---
+
+## BE-Specific Rules
+
+### 1. API Documentation First
+- Luôn document API trước khi implement (OpenAPI/Swagger)
+- Define request/response schemas rõ ràng
+- Include error responses trong docs
+- Version APIs properly (`/api/v1/...`)
+
+### 2. Database Best Practices
+- Luôn dùng parameterized queries (tránh SQL injection)
+- Add proper indexes cho frequently queried columns
+- Use transactions cho operations liên quan đến nhiều tables
+- Implement soft delete cho important data
+- Never store plaintext passwords
+
+### 3. Error Handling
+- Never expose internal errors to clients
+- Use consistent error response format
+- Log errors với đủ context
+- Implement proper HTTP status codes
+- Include request ID for debugging
+
+### 4. Security Hardening
+- Validate ALL user input
+- Implement rate limiting
+- Use HTTPS everywhere
+- Sanitize data before logging
+- Implement proper authentication/authorization
+
+### 5. Performance
+- Avoid N+1 queries (use joins, batch loading)
+- Implement caching where appropriate
+- Use connection pooling
+- Monitor query performance
+- Paginate list endpoints
+
+### 6. Testing Requirements
+- Unit tests cho business logic
+- Integration tests cho API endpoints
+- Test edge cases và error paths
+- Mock external dependencies
+- Aim for >80% coverage cho critical paths
+
+---
+
+## Tool Access Control (Capability-Based)
+
+> Pattern từ OpenFang: Fine-grained permissions thay vì all-or-nothing
+
+### File Operations
+
+| Action | Allowed Paths | Denied Paths |
+|--------|---------------|--------------|
+| READ | `src/**`, `prisma/**`, `*.config.*`, `package.json`, `docker-compose.*` | `.env*`, `secrets/**`, `credentials/**` |
+| WRITE | `src/**`, `prisma/**`, `tests/**` | `.env*`, `secrets/**`, `*.lock`, `dist/**` |
+| DELETE | `src/**/*.test.ts` (with confirmation) | Production files, migrations (applied) |
+
+### Shell Commands
+
+| Category | ALLOW | DENY |
+|----------|-------|------|
+| Package | `npm run *`, `npm install`, `yarn *` | `npm publish`, `yarn publish` |
+| Database | `npx prisma *`, `npm run db:*` | Direct DB mutations on prod |
+| Git | `git status`, `git diff`, `git log`, `git branch` | `git push --force`, `git reset --hard` |
+| Docker | `docker compose up`, `docker compose down` | `docker system prune` |
+| System | `node *` | `sudo *`, `rm -rf`, `chmod 777` |
+
+### Network Access
+
+| ALLOW | DENY |
+|-------|------|
+| `localhost:*` | Production databases (without approval) |
+| `*.internal.company.com` | External services with secrets |
+| `api.staging.*` | Production APIs (without approval) |
+| Database: dev/staging instances | Database: production instances |
+
+### Memory Scope
+
+| Scope | Access |
+|-------|--------|
+| `self.*` | Full read/write |
+| `shared.backend.*` | Full read/write |
+| `shared.project.*` | Read only |
+| `shared.frontend.*` | Read only (for API contracts) |
+
+---
+
+## Operational Phases
+
+> Multi-phase methodology từ OpenFang
+
+### Phase 1: ANALYZE
+
+- Read existing code and understand architecture
+- Review database schema and relationships
+- Understand API contracts and dependencies
+- Check for existing solutions/patterns
+
+### Phase 2: PLAN
+
+- Design API endpoints và data models
+- Consider scalability và performance implications
+- Identify security considerations
+- Get approval for non-trivial changes
+- Plan database migrations if needed
+
+### Phase 3: IMPLEMENT
+
+- Write clean, maintainable code
+- Follow existing conventions và patterns
+- Implement proper error handling
+- Add input validation
+- Write self-documenting code
+
+### Phase 4: VERIFY
+
+- Run unit tests và integration tests
+- Test error scenarios
+- Verify API documentation is updated
+- Check performance với realistic data
+- Security review cho sensitive endpoints
+
+### Phase 5: DOCUMENT
+
+- Update API documentation
+- Document new environment variables
+- Update README nếu cần
+- Add migration notes nếu có
+- Share knowledge với team
+
+---
+
+## API Response Standards
+
+### Success Response
+
+```json
+{
+  "success": true,
+  "data": { ... },
+  "meta": {
+    "page": 1,
+    "total": 100
+  }
+}
+```
+
+### Error Response
+
+```json
+{
+  "success": false,
+  "error": {
+    "code": "VALIDATION_ERROR",
+    "message": "Invalid input",
+    "details": [...]
+  },
+  "requestId": "req_abc123"
+}
+```
+
+---
+
+## Code Quality Checklist
+
+Before submitting:
+
+- [ ] Input validation implemented
+- [ ] Error handling complete
+- [ ] Tests written (unit + integration)
+- [ ] API documentation updated
+- [ ] No hardcoded values
+- [ ] Proper logging added
+- [ ] SQL queries use parameters
+- [ ] Sensitive data not logged
+
+---
+
+## Anti-Patterns to Avoid
+
+### Database
+
+- ❌ N+1 queries (use joins/batching)
+- ❌ Missing indexes on foreign keys
+- ❌ Storing JSON blobs when normalized tables work
+- ❌ Hardcoding connection strings
+
+### Security
+
+- ❌ Trusting user input
+- ❌ Exposing internal errors
+- ❌ Storing passwords in plaintext
+- ❌ Missing authentication checks
+- ❌ SQL string concatenation
+
+### Performance
+
+- ❌ Fetching unnecessary columns
+- ❌ No pagination on list endpoints
+- ❌ Missing cache headers
+- ❌ Synchronous operations cho long tasks
+
+### Code Quality
+
+- [ ] Files > 500 lines (split into modules)
+- [ ] Functions > 50 lines (extract helpers)
+- [ ] Missing error handling
+- [ ] Magic numbers/strings
+
+---
+
+## Environment Variables Template
+
+```bash
+# Database
+DATABASE_URL="postgresql://..."
+DIRECT_URL="postgresql://..."
+
+# Auth
+JWT_SECRET=""
+JWT_EXPIRES_IN="7d"
+
+# External Services
+REDIS_URL=""
+S3_BUCKET=""
+
+# Logging
+LOG_LEVEL="info"
+```
+
+---
+
+## Related Documentation
+
+- [General Rules](../common/general-rules.md)
+- [SA Rules](./sa-rules.md)
+- [API Design Skill](../../skills/domain/backend/api-design/SKILL.md)

package/.claude/rules/role-rules/dev-fe-rules.md

@@ -41,6 +41,82 @@
 
 ---
 
+## Tool Access Control (Capability-Based)
+
+> Pattern từ OpenFang: Fine-grained permissions thay vì all-or-nothing
+
+### File Operations
+
+| Action | Allowed Paths | Denied Paths |
+|--------|---------------|--------------|
+| READ | `src/**`, `public/**`, `*.config.*`, `package.json` | `.env*`, `secrets/**`, `credentials/**` |
+| WRITE | `src/**`, `public/**` | `.env*`, `secrets/**`, `*.lock`, `dist/**` |
+| DELETE | `src/**/*.test.ts` (with confirmation) | Production files, config files |
+
+### Shell Commands
+
+| Category | ALLOW | DENY |
+|----------|-------|------|
+| Package | `npm run *`, `npm install`, `yarn *` | `npm publish`, `yarn publish` |
+| Git | `git status`, `git diff`, `git log`, `git branch` | `git push --force`, `git reset --hard` |
+| Build | `npm run build`, `npm run dev` | `sudo *` |
+| System | `node *` | `rm -rf`, `chmod 777`, `curl * | bash` |
+
+### Network Access
+
+| ALLOW | DENY |
+|-------|------|
+| `localhost:*` | Production databases |
+| `*.internal.company.com` | External secrets managers |
+| `api.staging.*` | Production APIs (without explicit approval) |
+
+### Memory Scope
+
+| Scope | Access |
+|-------|--------|
+| `self.*` | Full read/write |
+| `shared.frontend.*` | Full read/write |
+| `shared.project.*` | Read only |
+| `shared.backend.*` | No access |
+
+---
+
+## Operational Phases
+
+> Multi-phase methodology từ OpenFang
+
+### Phase 1: ANALYZE
+- Read existing code and context
+- Identify relevant patterns and conventions
+- Understand requirements fully
+- Check Context7 for latest API docs
+
+### Phase 2: PLAN
+- Design approach for non-trivial changes
+- Consider alternatives and trade-offs
+- Get approval before implementation
+- Break down into subtasks if complex
+
+### Phase 3: IMPLEMENT
+- Write clean, production-quality code
+- Follow existing conventions
+- Handle errors explicitly
+- Add appropriate logging
+
+### Phase 4: VERIFY
+- Run tests and check coverage
+- Validate output meets requirements
+- Self-review changes
+- Check for console errors/warnings
+
+### Phase 5: DOCUMENT
+- Update relevant documentation
+- Capture lessons learned
+- Update MEMORY.md if significant
+- Share knowledge with team
+
+---
+
 ## Component Checklist
 
 Before submitting component:

package/.claude/skills/SKILL-INDEX.md

@@ -13,6 +13,9 @@
 | [code-review](core/code-review/SKILL.md) | Systematic code review with technical rigor | - |
 | [git-automation](core/git-automation/SKILL.md) | Git workflow automation and commit standards | - |
 | [retrospect-work](core/retrospect-work/SKILL.md) | Self-learning retrospects for continuous improvement | - |
+| [agent-creation](core/agent-creation/SKILL.md) | Guide for creating agents with skills.sh integration | - |
+| [sequential-thinking](core/sequential-thinking/SKILL.md) | Systematic step-by-step reasoning for complex problems | - |
+| [knowledge-graph](core/knowledge-graph/SKILL.md) | Entity-relation storage for cross-agent knowledge | - |
 
 ### Domain Skills
 
@@ -25,6 +28,7 @@
 | [state-management](domain/frontend/state-management/SKILL.md) | Zustand, TanStack Query patterns | frontend-design |
 | [testing-fe](domain/frontend/testing-fe/SKILL.md) | Vitest + Testing Library | code-review |
 | [performance-fe](domain/frontend/performance-fe/SKILL.md) | React optimization, Core Web Vitals | frontend-design |
+| [ui-ux-pro-max](domain/frontend/ui-ux-pro-max/SKILL.md) | UI/UX design intelligence with 67 styles, 96 palettes | frontend-design |
 
 #### Backend
 
@@ -46,6 +50,8 @@
 | [tech-selection](domain/architecture/tech-selection/SKILL.md) | Technology evaluation framework | adr-writing |
 | [performance-engineering](domain/architecture/performance-engineering/SKILL.md) | Performance optimization strategies | system-design |
 | [security-architecture](domain/architecture/security-architecture/SKILL.md) | Security architecture patterns | system-design, security |
+| [c4-architecture](domain/architecture/c4-architecture/SKILL.md) | Generate C4 model architecture diagrams in Mermaid | system-design |
+| [mermaid-diagrams](domain/architecture/mermaid-diagrams/SKILL.md) | Comprehensive guide for creating Mermaid diagrams | - |
 
 #### DevOps
 
@@ -66,6 +72,7 @@
 | [sprint-planning](domain/product/sprint-planning/SKILL.md) | Sprint planning and estimation | user-stories |
 | [roadmap-planning](domain/product/roadmap-planning/SKILL.md) | Product roadmap creation | sprint-planning |
 | [stakeholder-communication](domain/product/stakeholder-communication/SKILL.md) | Stakeholder management | - |
+| [requirements-clarity](domain/product/requirements-clarity/SKILL.md) | Transform vague requirements into actionable PRDs | requirements-gathering |
 
 #### Quality
 
@@ -76,6 +83,16 @@
 | [test-automation](domain/quality/test-automation/SKILL.md) | Test automation frameworks | test-planning |
 | [regression-testing](domain/quality/regression-testing/SKILL.md) | Regression test strategies | test-automation |
 
+#### Design
+
+| Skill | Description | Dependencies |
+|-------|-------------|--------------|
+| [ui-design](domain/design/ui-design/SKILL.md) | UI design principles for professional, accessible interfaces | - |
+| [design-system](domain/design/design-system/SKILL.md) | Design system with tokens, components, patterns | ui-design |
+| [responsive-design](domain/design/responsive-design/SKILL.md) | Mobile-first responsive design with breakpoints | ui-design |
+| [html-css-output](domain/design/html-css-output/SKILL.md) | Converting designs to HTML/CSS for developers | ui-design, design-system |
+| [mockup-creation](domain/design/mockup-creation/SKILL.md) | Creating wireframes and mockups with DrawIO | ui-design |
+
 ### Leadership Skills
 
 | Skill | Description | Dependencies |
@@ -276,15 +293,17 @@ used_by: []              # Reverse reference
 
 | Category | Count | Status |
 |----------|-------|--------|
-| Core | 3 | ✅ Complete |
-| Frontend | 5 | ✅ Complete |
+| Core | 6 | ✅ Complete |
+| Frontend | 6 | ✅ Complete |
 | Backend | 5 | ✅ Complete |
-| Architecture | 6 | ✅ Complete |
+| Architecture | 8 | ✅ Complete |
 | DevOps | 5 | ✅ Complete |
-| Product | 5 | ✅ Complete |
+| Product | 6 | ✅ Complete |
 | Quality | 4 | ✅ Complete |
+| Design | 5 | ✅ Complete |
 | Leadership | 4 | ✅ Complete |
-| **Total** | **37** | ✅ All Complete |
+| Community | 1 | ✅ Complete |
+| **Total** | **50** | ✅ All Complete |
 
 ---
 

package/.claude/skills/core/knowledge-graph/SKILL.md

@@ -0,0 +1,214 @@
+---
+name: knowledge-graph
+description: |
+  Maintain structured knowledge about project components and their relationships.
+  Use when implementing new features, making architectural decisions, refactoring
+  components, or when user mentions "relationships", "dependencies", "architecture
+  map", "component connections", "knowledge graph".
+version: 1.0.0
+category: core
+tags:
+  - knowledge
+  - architecture
+  - relationships
+  - memory
+depends_on: []
+recommends:
+  - retrospect-work
+used_by:
+  - system-design
+  - architecture-patterns
+  - tech-decision
+---
+
+# Skill: Knowledge Graph
+
+## Core Principle
+
+**Projects are networks of connected components.**
+Understanding relationships is as important as understanding individual parts.
+
+## Purpose
+
+Maintain structured knowledge about:
+- Components and their types
+- Relationships between components
+- Decisions and their rationale
+- Dependencies (internal and external)
+
+## Entity Types
+
+| Type | Description | Examples |
+|------|-------------|----------|
+| `component` | Code modules | auth-service, login-page, user-api |
+| `api` | API endpoints | POST /auth/login, GET /users |
+| `database` | Data stores | users-table, sessions-table |
+| `decision` | ADRs/decisions | use-jwt-auth, postgres-choice |
+| `external` | Third-party services | stripe-api, sendgrid |
+| `pattern` | Design patterns | repository-pattern, factory-pattern |
+
+## Relationship Types
+
+| Relation | Meaning | Example |
+|----------|---------|---------|
+| `calls` | A invokes B | login-page → calls → auth-api |
+| `depends_on` | A requires B | auth-service → depends_on → users-table |
+| `implements` | A implements B | auth-service → implements → decision:use-jwt |
+| `relates_to` | General connection | login-page → relates_to → register-page |
+| `produces` | A outputs B | auth-api → produces → jwt-token |
+| `consumes` | A uses B | dashboard → consumes → jwt-token |
+
+## Storage Format
+
+### File: `.claude/knowledge/graph.json`
+
+```json
+{
+  "version": "1.0",
+  "updated": "2025-02-27T10:00:00Z",
+  "entities": [
+    {
+      "id": "auth-service",
+      "type": "component",
+      "description": "JWT authentication service",
+      "owner": "dev-be",
+      "tags": ["auth", "security"],
+      "created": "2025-01-15"
+    }
+  ],
+  "relations": [
+    {
+      "from": "login-page",
+      "to": "auth-service",
+      "type": "calls",
+      "via": "POST /auth/login"
+    }
+  ]
+}
+```
+
+## When to Update
+
+### After Implementing New Features
+
+```markdown
+1. Identify new components created
+2. Map connections to existing components
+3. Add entities and relations to graph
+4. Update MEMORY.md with key relationships
+```
+
+### When Making Architectural Decisions
+
+```markdown
+1. Create decision entity
+2. Link to affected components
+3. Document rationale in entity description
+4. Cross-reference with ADR if exists
+```
+
+### After Refactoring
+
+```markdown
+1. Update component relationships
+2. Mark deprecated relations
+3. Add new relations created by refactor
+4. Update descriptions if behavior changed
+```
+
+## Usage Patterns
+
+### Query: What depends on X?
+
+```
+Find all relations where to = X and type = depends_on
+```
+
+### Query: What does X affect?
+
+```
+Find all relations where from = X
+```
+
+### Query: Decision trace
+
+```
+Find all entities of type decision
+Follow implements relations to components
+```
+
+## Integration with Memory
+
+### MEMORY.md Section
+
+```markdown
+## Component Relationships
+
+### Authentication Flow
+- login-page → calls → auth-service
+- auth-service → depends_on → users-table
+- auth-service → implements → decision:use-jwt
+
+### Key Decisions
+- decision:use-jwt → affects → auth-service, api-gateway
+```
+
+## Quick Commands
+
+### Add Entity
+
+```json
+{
+  "id": "new-component",
+  "type": "component",
+  "description": "...",
+  "owner": "dev-fe",
+  "tags": ["ui", "forms"]
+}
+```
+
+### Add Relation
+
+```json
+{
+  "from": "new-component",
+  "to": "existing-component",
+  "type": "depends_on"
+}
+```
+
+## Visualization
+
+Generate Mermaid diagram from graph:
+
+```mermaid
+graph TD
+    login-page -->|calls| auth-service
+    auth-service -->|depends_on| users-table
+    auth-service -->|implements| decision-use-jwt
+```
+
+## Best Practices
+
+1. **Update incrementally** - Don't batch updates, add as you learn
+2. **Be specific** - Use clear, unambiguous entity IDs
+3. **Include context** - Add descriptions that explain purpose
+4. **Cross-reference** - Link to ADRs and documentation
+5. **Keep current** - Remove obsolete relations during refactoring
+
+## Anti-Patterns
+
+| Avoid | Instead |
+|-------|---------|
+| Vague IDs: "the auth thing" | Specific: "auth-service" |
+| Missing relations | Map all connections |
+| Stale data | Update during refactors |
+| Over-documenting | Focus on important relationships |
+| Isolated updates | Share with team |
+
+## Integration
+
+- **After** implementing features → Update graph
+- **Before** major refactors → Query affected components
+- **During** architecture reviews → Visualize relationships
+- **When** onboarding → Use as component map