feat: add more skills (from everything-claude-code), config (rules, agents, tools, learning), add new 2 tempalte for dev-team and qc-team

This commit is contained in:
2026-04-06 15:38:01 +07:00
parent 9c80fd3e8f
commit c4c881bba2
22 changed files with 2296 additions and 51 deletions
+77 -2
View File
@@ -125,16 +125,36 @@ Skills provide your tools. When you need one, check its `SKILL.md`. Keep local n
**IMPORTANT**: For multi-agent work, always use **ClawTeam CLI** (via the `clawteam-multi-agent-coordination` skill). Never use `sessions_spawn`, `subagents`, or other OpenClaw session-spawn mechanisms for coordinating multiple agents. Doing so bypasses task management, git worktree isolation, and proper monitoring.
### Three-Tier Review Workflow (Mandatory)
### Three-Tier Review Workflow (Mandatory — ZERO EXCEPTIONS)
All ClawTeam workers must follow this review sequence for every completed task:
1. **Self-Review** (worker reviews their own code first)
2. **Peer Review** (other team members review)
3. **Leader Review** (orchestrator gives final approval)
3. **PM Review** (Project Manager gives final approval — Tier 3)
No peer or leader review should begin until the worker has completed their self-review using the review checklist below. This ensures quality control and knowledge sharing across the team.
### Quality Gate — NO SUBSTANDARD WORK ALLOWED
**Every task MUST pass ALL checks before moving to `completed`:**
- TDD: tests written BEFORE production code
- Coverage: 80%+ line, 70%+ branch, 100% critical paths
- Zero lint errors, zero type errors
- Error handling complete (no swallowed errors, no bare catch)
- Security: input validated, parameterized queries, no secrets
- Edge cases: null, empty, unicode, boundaries, special chars
- Architecture: SOLID, single responsibility, loose coupling
- All UI states present (loading, error, empty, disabled)
- Lighthouse 90+, responsive mobile AND desktop
- Conventional Commits format
**If ANY check fails:**
1. Reject task with specific issues (not vague feedback)
2. Send back to worker with exact file:line + what to fix
3. If worker fails same task 2x → reassign to different worker
4. PM must verify diff personally after each rework — NEVER trust reports
**Review Checklist** (adapt as needed):
1. **Plan Alignment Analysis**:
@@ -175,6 +195,61 @@ No peer or leader review should begin until the worker has completed their self-
**Output Expectation**: Your review should be structured, actionable, and focused on helping maintain high code quality while ensuring project goals are met. Be thorough but concise, and always provide constructive feedback that helps improve both the current implementation and future development practices.
### PM Code Review Checklist (Tier 3 — Final Gate)
The PM (Project Manager) performs the final quality gate. This is not a rubber stamp.
**For every task moving to `completed`, PM MUST verify:**
1. **Spec Compliance** — Did worker implement EXACTLY what was asked?
- No scope creep, no missing features
- No over-engineering
- No accidental deletions of existing code
2. **TDD Verification** — Are tests written first?
- Check git history: test commit before implementation commit
- Tests are meaningful (not just calling function without assertions)
- Red-Green-Refactor cycle was followed
3. **Test Coverage** — Run actual coverage report
- `npm test -- --coverage` or equivalent
- Line coverage ≥ 80%, Branch ≥ 70%, Critical paths 100%
- Edge cases covered: null, empty, unicode, boundaries, special chars
4. **Code Quality** — Line by line review
- Type safety: no `any`, proper generics
- Error handling: specific types, no bare `catch`
- No dead code, no console.log in production
- Functions < 30 lines, clear names
- SOLID principles followed
5. **Security** — Must have:
- Input validation at every layer
- Parameterized queries (no SQL string concat)
- No hardcoded secrets
- Auth on protected endpoints
6. **Performance** — Check for:
- No N+1 queries
- Proper indexing
- Lighthouse ≥ 90
- No layout shift (CLS < 0.1)
7. **Production Readiness** — All states covered:
- Loading, error, empty, disabled states
- Structured logging on critical paths
- Health checks implemented
**Rejection is the default until proven otherwise.** If any item above is unclear or missing, reject the task.
### Re-Assignment Protocol
**When a task is rejected:**
1. PM sends specific feedback with exact file:line references
2. Worker fixes and resubmits for re-review
3. If same worker fails same task twice → reassign to different worker with full context
4. PM must verify diff personally after every rework
Enforce this sequence in your task board by marking statuses appropriately (e.g., `needs-self-review``needs-peer-review``needs-leader-review``completed`).
ClawTeam enables you to: