codymaster 4.4.4 → 4.5.1

package/skills/release-it/references/stability-patterns.md

@@ -1,355 +0,0 @@
-# Stability Patterns
-
-Stability patterns are the countermeasures to the anti-patterns that cause production failures. Each pattern addresses specific failure modes and, when combined, creates a defense-in-depth strategy that allows systems to absorb shocks, degrade gracefully, and recover automatically.
-
-These patterns are not theoretical -- they are battle-tested responses to the recurring failure modes described in the anti-patterns reference.
-
-## 1. Circuit Breaker
-
-The Circuit Breaker is the single most important stability pattern. It prevents a failing downstream dependency from taking down the calling service by short-circuiting requests when failures exceed a threshold.
-
-### State Machine
-
-```
-     success                  failure count
-    ┌───────┐              exceeds threshold
-    │       │                    │
-    ▼       │                    ▼
- ┌────────┐ │              ┌────────┐
- │ CLOSED │─┘              │  OPEN  │
- └────────┘                └────────┘
-      ▲                         │
-      │    success               │  timeout expires
-      │                         ▼
-      │                    ┌──────────┐
-      └────────────────────│HALF-OPEN │
-           (trial request  └──────────┘
-            succeeds)           │
-                                │  trial request fails
-                                └──────────────────┐
-                                                   │
-                                              ┌────────┐
-                                              │  OPEN  │
-                                              └────────┘
-```
-
-### States Explained
-
-| State | Behavior | Transitions |
-|-------|----------|-------------|
-| **Closed** | Requests pass through normally; failures are counted | Transitions to Open when failure count exceeds threshold within time window |
-| **Open** | All requests fail immediately without calling downstream | Transitions to Half-Open after a recovery timeout expires |
-| **Half-Open** | A limited number of trial requests are allowed through | Transitions to Closed if trials succeed; back to Open if trials fail |
-
-### Configuration Parameters
-
-| Parameter | Description | Typical Range |
-|-----------|-------------|---------------|
-| **Failure threshold** | Number of failures before opening | 5-20 failures |
-| **Time window** | Period over which failures are counted | 30-120 seconds |
-| **Recovery timeout** | Time to wait in Open state before trying Half-Open | 15-60 seconds |
-| **Trial requests** | Number of requests allowed in Half-Open | 1-5 requests |
-| **Success threshold** | Consecutive successes needed to close | 3-5 successes |
-
-### What Counts as a Failure
-
-Not every error should trip the circuit breaker. Configure what counts:
-
-| Should Trip | Should Not Trip |
-|------------|----------------|
-| Connection timeout | 400 Bad Request (client error) |
-| Read timeout | 404 Not Found |
-| 5xx server error | 429 Too Many Requests (handle with retry/backoff) |
-| Connection refused | Business logic validation errors |
-| Circuit breaker open on downstream | Request cancellation by client |
-
-### Implementation Considerations
-
-- **Granularity:** One circuit breaker per downstream service, or per endpoint within a service? Per-endpoint gives finer control but more complexity.
-- **Fallback behavior:** When the circuit is open, what do you return? Cached data? Default value? Error response? The right answer depends on the use case.
-- **Monitoring:** Every circuit breaker state change should emit a metric and a log entry. An open circuit breaker is a critical signal.
-- **Coordination:** In a fleet of instances, each has its own circuit breaker state. Consider whether this is acceptable or if you need coordinated state (usually independent is fine).
-- **Half-open thundering herd:** When the recovery timeout expires, only let one or two trial requests through -- not the full backlog.
-
-### Code Pattern (Pseudocode)
-
-```
-class CircuitBreaker:
-    state = CLOSED
-    failure_count = 0
-    last_failure_time = null
-
-    function call(operation):
-        if state == OPEN:
-            if now() - last_failure_time > recovery_timeout:
-                state = HALF_OPEN
-            else:
-                raise CircuitOpenException()
-
-        try:
-            result = operation()
-            on_success()
-            return result
-        catch Exception:
-            on_failure()
-            raise
-
-    function on_success():
-        if state == HALF_OPEN:
-            state = CLOSED
-        failure_count = 0
-
-    function on_failure():
-        failure_count += 1
-        last_failure_time = now()
-        if failure_count >= threshold:
-            state = OPEN
-```
-
----
-
-## 2. Bulkheads
-
-Named after the watertight compartments in a ship's hull, bulkheads partition system resources so that a failure in one partition does not sink the entire system.
-
-### Types of Bulkheads
-
-| Type | Mechanism | Use Case |
-|------|-----------|----------|
-| **Thread pool isolation** | Separate thread pools per dependency | Service A gets 20 threads, Service B gets 20 threads; A's failure cannot exhaust B's pool |
-| **Connection pool isolation** | Separate connection pools per downstream | Payment DB pool separate from analytics DB pool |
-| **Process isolation** | Separate OS processes per workload | Background jobs in separate processes from request handling |
-| **Container isolation** | Separate containers per service | Each microservice in its own container with resource limits |
-| **Swim lanes** | Complete stack isolation for critical paths | Checkout flow runs on entirely separate infrastructure from browsing |
-
-### Swim Lanes
-
-Swim lanes are the most rigorous form of bulkheading. A swim lane is a complete, isolated stack -- from load balancer to database -- dedicated to a specific function.
-
-**When to use swim lanes:**
-- Revenue-critical paths (checkout, payment processing)
-- Compliance-critical paths (authentication, audit logging)
-- When a non-critical feature has historically caused outages affecting critical features
-
-**Design rules for swim lanes:**
-- No synchronous calls across swim lane boundaries
-- No shared databases, caches, or message queues
-- Asynchronous replication of data between lanes if needed
-- Each lane has independent scaling, deployment, and monitoring
-
-### Sizing Bulkheads
-
-The key question: how many resources does each partition get?
-
-- **Too generous:** Wasted resources; the partition rarely uses its full allocation
-- **Too tight:** The partition cannot handle legitimate load spikes
-- **Right-sized:** Based on measured throughput at p99 load, plus 20-30% headroom
-
-**Approach:** Measure the actual concurrency for each dependency under peak load. Set the bulkhead size to p99 concurrency + 20% headroom. Set a queue/reject policy for requests beyond the limit.
-
----
-
-## 3. Timeouts
-
-Every outbound call needs a timeout. Every. Single. One. A missing timeout is a thread leak waiting to happen.
-
-### Types of Timeouts
-
-| Type | What It Controls | Typical Range |
-|------|-----------------|---------------|
-| **Connect timeout** | Time to establish a TCP connection | 500ms - 2s |
-| **Read timeout** | Time to receive a response after connecting | 1s - 30s (depends on operation) |
-| **Write timeout** | Time to send the request body | 1s - 10s |
-| **Idle timeout** | Time a connection can sit unused in the pool | 30s - 5 min |
-| **Request timeout** | Overall deadline for the entire operation | Varies by use case |
-
-### Timeout Propagation
-
-When Service A calls Service B, which calls Service C, timeouts must propagate down the chain. If the user's request has a 5-second deadline, Service A should not start a 10-second operation.
-
-```
-User request: 10s deadline
-  → Service A: 8s deadline (2s for own processing)
-    → Service B: 5s deadline (3s for A's processing)
-      → Service C: 3s deadline (2s for B's processing)
-```
-
-**Implementation:** Pass the remaining deadline in a request header (e.g., `X-Request-Deadline` or gRPC deadline propagation). Each service subtracts its own processing time and passes the remainder downstream.
-
-### Common Timeout Mistakes
-
-| Mistake | Consequence | Fix |
-|---------|-------------|-----|
-| Using default OS timeout (120-300s) | Threads blocked for minutes | Set explicit timeouts on every call |
-| Same timeout for all operations | Fast reads wait too long; slow writes fail prematurely | Tune timeouts per operation type |
-| No timeout on DNS resolution | DNS failure blocks thread for OS default (30s+) | Use async DNS or set DNS timeout |
-| Not timing out connection pool acquisition | Thread waits forever for a connection from the pool | Set pool checkout timeout (500ms-2s) |
-| Timeout too aggressive | Legitimate slow responses treated as failures | Set timeout based on p99 latency + margin |
-
-### Setting Timeout Values
-
-1. Measure the p99 latency of the operation under normal load
-2. Add a margin (typically 2-3x p99)
-3. Consider the user-facing deadline -- if the user will wait only 5 seconds, your timeout must be less than 5 seconds
-4. Monitor timeout rates -- if timeouts fire frequently, the downstream is degrading
-
----
-
-## 4. Retry with Backoff
-
-Retries are necessary because transient failures are real -- network blips, momentary overloads, and garbage collection pauses cause temporary unavailability that resolves on its own. But naive retries (immediate, unlimited) cause more harm than good.
-
-### Retry Strategy Components
-
-| Component | Purpose | Implementation |
-|-----------|---------|----------------|
-| **Exponential backoff** | Increase delay between retries to give the downstream time to recover | Delay = base * 2^attempt (e.g., 100ms, 200ms, 400ms, 800ms) |
-| **Jitter** | Randomize the delay to prevent all clients from retrying at the same instant | Delay = random(0, base * 2^attempt) |
-| **Maximum retries** | Limit total attempts to prevent infinite retry loops | Typically 3-5 retries |
-| **Retry budget** | Limit the percentage of requests that are retries across the entire fleet | No more than 10-20% of total requests should be retries |
-| **Idempotency** | Ensure the operation is safe to retry without side effects | Use idempotency keys for mutations |
-
-### When to Retry
-
-| Retry | Do Not Retry |
-|-------|-------------|
-| 503 Service Unavailable | 400 Bad Request |
-| 429 Too Many Requests (with backoff) | 401/403 Authentication/Authorization |
-| Connection timeout | 404 Not Found |
-| Connection reset | 422 Validation Error |
-| Read timeout (for idempotent operations) | Read timeout (for non-idempotent operations without idempotency key) |
-
-### Retry Budget
-
-A retry budget limits the total percentage of retried requests across your entire fleet. Without a budget, a fleet of 100 instances each retrying 3 times can amplify load on a struggling downstream by 300x.
-
-**Implementation:**
-- Track the ratio of retries to original requests over a sliding window (e.g., 1 minute)
-- If retry ratio exceeds the budget (e.g., 20%), stop retrying and fail fast
-- This provides fleet-level protection that per-instance retry limits cannot
-
-### The Thundering Herd Problem with Retries
-
-When a downstream service recovers, all clients retry simultaneously, overwhelming it again. Jitter solves this:
-
-- **No jitter:** All 1,000 clients retry at exactly t+100ms, t+200ms, t+400ms
-- **Full jitter:** Each client retries at random(0, 100ms), random(0, 200ms), random(0, 400ms) -- spreading the load evenly
-
----
-
-## 5. Steady State
-
-Production systems accumulate cruft over time. Log files grow. Sessions pile up. Temporary files linger. Database tables bloat. Without active management, this accumulation eventually exhausts a resource -- disk space, memory, database capacity -- and the system fails.
-
-### What Accumulates
-
-| Resource | Growth Mechanism | Consequence of Neglect |
-|----------|-----------------|----------------------|
-| **Log files** | Application logging, access logs | Disk full; application cannot write; crash |
-| **Database rows** | Event logs, audit trails, temp records | Slow queries; backup failures; storage costs |
-| **Sessions** | User sessions stored server-side | Memory exhaustion; swap thrashing |
-| **Temp files** | Upload processing, report generation | Disk full |
-| **Cache entries** | Application cache without TTL | Memory exhaustion |
-| **Message queues** | Unprocessed or dead-letter messages | Queue backpressure; memory/disk exhaustion |
-
-### Steady State Design
-
-Every resource that grows must have a corresponding mechanism to shrink:
-
-- **Log rotation:** Rotate by size (500MB) and time (daily); retain N files; compress rotated files
-- **Data purging:** Delete or archive records older than retention period; run during off-peak hours
-- **Session cleanup:** Set maximum session duration and idle timeout; evict expired sessions automatically
-- **Cache eviction:** Use TTL-based expiration; implement LRU or LFU eviction when memory limit is reached
-- **Queue management:** Set maximum queue depth; dead-letter after N delivery attempts; alert on growing queue size
-
----
-
-## 6. Fail Fast
-
-If a system knows it cannot process a request successfully, it should reject the request immediately rather than consuming resources in a doomed attempt.
-
-### When to Fail Fast
-
-| Condition | Fail-Fast Response |
-|-----------|-------------------|
-| Circuit breaker is open | Return 503 immediately |
-| Required parameter missing | Return 400 immediately |
-| User not authenticated | Return 401 immediately |
-| Resource limit exceeded (rate limit) | Return 429 immediately |
-| Request deadline already expired | Return 504 immediately |
-| Required downstream service unavailable | Return 503 with degraded response |
-
-### Why Fail Fast Is Kind
-
-Failing fast is not hostile -- it is kind. A fast rejection lets the caller know immediately that this request will not work, freeing the caller to retry elsewhere, display an error, or degrade gracefully. A slow failure wastes the caller's time, threads, and hope.
-
----
-
-## 7. Let It Crash
-
-Borrowed from Erlang's "let it crash" philosophy: when a process enters an unrecoverable or uncertain state, it is safer to terminate and restart from a known-good state than to attempt in-process recovery.
-
-### When to Let It Crash
-
-- Corrupted in-memory state that cannot be validated
-- Resource handles (file descriptors, connections) in an unknown state
-- Unhandled exception in a critical path where recovery logic is complex and error-prone
-- Process consuming excessive memory or CPU with no clear cause
-
-### Prerequisites for Let It Crash
-
-- **Fast restart:** Process must start in seconds, not minutes
-- **Supervision:** A supervisor must detect the crash and restart the process
-- **State recovery:** Critical state must be externalized (database, distributed cache) -- not lost on crash
-- **Health checks:** Load balancer must detect the restart and route traffic away during startup
-- **Crash budget:** Monitor crash frequency; excessive crashes indicate a deeper problem, not a healthy recovery mechanism
-
----
-
-## 8. Handshaking
-
-Handshaking is a protocol-level mechanism where the server tells the client whether it is ready to accept work before the client sends a full request. This prevents the server from being overwhelmed when it is already overloaded.
-
-### Handshaking Mechanisms
-
-| Level | Mechanism | Example |
-|-------|-----------|---------|
-| **TCP** | SYN/ACK with backlog queue | OS rejects connections when listen queue is full |
-| **HTTP** | 100 Continue response | Server tells client to proceed with request body, or rejects early |
-| **Application** | Health check + load shedding | Load balancer checks `/ready` endpoint; server returns 503 when overloaded |
-| **gRPC** | Flow control with window updates | Server signals how much data it can receive |
-| **Custom** | Pre-flight capacity check | Client asks "can you handle this request?" before sending payload |
-
-### Application-Level Handshaking
-
-Implement a readiness check that reflects actual capacity:
-
-```
-GET /ready
-
-200 OK          → Server can accept work
-503 Unavailable → Server is overloaded; do not send requests
-
-Readiness considers:
-- Thread pool utilization < 80%
-- Connection pool utilization < 80%
-- Response latency < SLO threshold
-- No critical dependency failures
-```
-
-This allows load balancers and service meshes to route traffic away from overloaded instances before they fail, rather than after.
-
-## Pattern Combinations
-
-These patterns are most effective in combination. Common pairings:
-
-| Combination | Effect |
-|-------------|--------|
-| **Timeout + Circuit Breaker** | Timeout detects slow failures; circuit breaker prevents repeated attempts |
-| **Circuit Breaker + Fallback** | Circuit breaker trips; fallback provides degraded response |
-| **Bulkhead + Circuit Breaker** | Bulkhead limits blast radius; circuit breaker stops the bleeding |
-| **Retry + Timeout + Circuit Breaker** | Retry handles transient failures; timeout limits wait; circuit breaker stops persistent failures |
-| **Fail Fast + Handshaking** | Server signals overload; client fails fast without sending work |
-| **Steady State + Let It Crash** | Cleanup prevents resource exhaustion; crash recovers from unknown states |
-
-The key principle: no single pattern is sufficient. Production-ready systems layer multiple patterns to create defense in depth.

package/skills/skill-creator-ultra/.agents/workflows/skill-audit.md

@@ -1,37 +0,0 @@
----
-description: 🔍 Audit skill theo 7 nguyên tắc hoàn hảo
----
-
-# Skill Audit — Chấm điểm Skill
-
-## Cách dùng
-
-Hỏi user: "Anh muốn audit skill nào? Cho em đường dẫn tới thư mục skill hoặc file SKILL.md"
-
-## Chạy audit
-
-// turbo
-
-1. Chạy lệnh audit:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_audit.py" <đường_dẫn_skill>
-```
-
-1. Nếu user muốn output JSON:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_audit.py" <đường_dẫn_skill> --json
-```
-
-1. Nếu user muốn chấm khắt khe:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_audit.py" <đường_dẫn_skill> --strict
-```
-
-## Sau khi chạy
-
-- Hiển thị kết quả cho user
-- Nếu điểm thấp (<70%) → gợi ý sửa các nguyên tắc bị điểm thấp
-- Nếu điểm cao (≥85%) → khen và gợi ý export ra các nền tảng khác

package/skills/skill-creator-ultra/.agents/workflows/skill-compare.md

@@ -1,34 +0,0 @@
----
-description: 🔄 So sánh 2 phiên bản skill
----
-
-# Skill Compare — So sánh phiên bản
-
-## Cách dùng
-
-Hỏi user 2 đường dẫn:
-
-1. "Đường dẫn tới skill phiên bản CŨ?"
-2. "Đường dẫn tới skill phiên bản MỚI?"
-
-## Chạy compare
-
-// turbo
-
-1. So sánh 2 thư mục:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_compare.py" <đường_dẫn_cũ> <đường_dẫn_mới>
-```
-
-1. Output JSON:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_compare.py" <đường_dẫn_cũ> <đường_dẫn_mới> --json
-```
-
-## Sau khi chạy
-
-- Hiển thị bảng so sánh metrics
-- Cho biết phiên bản mới tốt hơn hay tệ hơn
-- Gợi ý cải thiện nếu cần

package/skills/skill-creator-ultra/.agents/workflows/skill-export.md

@@ -1,51 +0,0 @@
----
-description: 📦 Export skill ra các nền tảng (Cursor, Claude, Windsurf, OpenClaw...)
----
-
-# Skill Export — Chuyển đổi đa nền tảng
-
-## Cách dùng
-
-Hỏi user 2 thông tin:
-
-1. "Đường dẫn tới skill muốn export?"
-2. "Export sang nền tảng nào?" (cursor / claude / windsurf / cline / copilot / openclaw / all)
-
-## Chạy export
-
-// turbo
-
-1. Export sang 1 nền tảng:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_export.py" <đường_dẫn_skill> --platform <nền_tảng>
-```
-
-1. Export tất cả:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_export.py" <đường_dẫn_skill> --platform all
-```
-
-1. Chỉ định thư mục output:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_export.py" <đường_dẫn_skill> --platform all --output <thư_mục>
-```
-
-## Nền tảng hỗ trợ
-
-| Nền tảng | Flag | File output |
-| --- | --- | --- |
-| Cursor | `cursor` | `.mdc` |
-| Claude Code | `claude` | `.md` |
-| Windsurf | `windsurf` | `.md` |
-| Cline | `cline` | `.md` |
-| GitHub Copilot | `copilot` | `.md` |
-| OpenClaw | `openclaw` | `.txt` |
-| Tất cả | `all` | Mỗi nền tảng 1 file |
-
-## Sau khi chạy
-
-- Hiển thị danh sách files đã export
-- Hướng dẫn user copy file vào đúng vị trí cho từng nền tảng

package/skills/skill-creator-ultra/.agents/workflows/skill-generate.md

@@ -1,39 +0,0 @@
----
-description: 🧠 Tạo Skill mới từ ý tưởng (phỏng vấn 5 Phase → sinh full package)
----
-
-# Skill Generator — Tạo Skill từ ý tưởng
-
-Khi user gõ `/skill-generate`, thực hiện quy trình sau:
-
-## Bước 1: Kích hoạt Skill Generator
-
-Đọc file `SKILL.md` trong skill `skill-generator` và bắt đầu quy trình tạo skill mới.
-
-AI sẽ đóng vai **Skill Architect** và thực hiện pipeline 5 Phase:
-
-```
-Phase 1: 🎤 Phỏng vấn thông minh → Hiểu công việc user
-Phase 2: 🔬 Trích xuất thông tin → Cấu trúc hóa
-Phase 3: 🔎 Phát hiện pattern → Chọn kiến trúc
-Phase 4: 🏗️ Sinh skill package → Tạo đầy đủ files
-Phase 5: 🧪 Test & refine → Đảm bảo chất lượng
-```
-
-## Bước 2: Bắt đầu phỏng vấn
-
-Hỏi user câu mở đầu:
-
-> "Anh/chị mô tả cho em nghe công việc mà anh/chị muốn AI tự động hóa đi.
-> Nói tự nhiên thôi, như đang hướng dẫn một đồng nghiệp mới vậy."
-
-## Bước 3: Hoàn thành
-
-Sau khi chạy xong 5 Phase:
-
-- Tạo **full skill package** (SKILL.md + README + resources + examples + scripts + workflows)
-- Hiển thị cấu trúc thư mục
-- Chạy dry run test
-- Hướng dẫn sử dụng
-
-> 💡 **Lưu ý:** Nếu user đã cung cấp flow rõ ràng → AI tự nhận diện Fast Track, skip phỏng vấn.

package/skills/skill-creator-ultra/.agents/workflows/skill-scaffold.md

@@ -1,52 +0,0 @@
----
-description: 🧩 Tạo skeleton skill mới từ 1 lệnh
----
-
-# Skill Scaffold — Tạo skill mới
-
-## Cách dùng
-
-Hỏi user:
-
-1. "Tên skill mới là gì? (kebab-case, ví dụ: price-quoter)"
-2. "Muốn tạo cơ bản hay đầy đủ?" (cơ bản = chỉ SKILL.md / đầy đủ = kèm scripts + resources + examples)
-
-## Chạy scaffold
-
-// turbo
-
-1. Tạo cơ bản:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_scaffold.py" <tên_skill>
-```
-
-1. Tạo đầy đủ:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_scaffold.py" <tên_skill> --full
-```
-
-1. Tạo kèm scripts:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_scaffold.py" <tên_skill> --with-scripts
-```
-
-1. Chế độ tương tác (hỏi từng bước):
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_scaffold.py" <tên_skill> --interactive
-```
-
-1. Chỉ định thư mục output:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_scaffold.py" <tên_skill> --full --output <thư_mục>
-```
-
-## Sau khi chạy
-
-- Hiển thị cấu trúc thư mục đã tạo
-- Mở file SKILL.md cho user điền nội dung
-- Gợi ý chạy /skill-audit sau khi viết xong

package/skills/skill-creator-ultra/.agents/workflows/skill-simulate.md

@@ -1,25 +0,0 @@
----
-description: 🧪 Mô phỏng chạy thử skill
----
-
-# Skill Simulate — Mô phỏng dry-run
-
-## Cách dùng
-
-Hỏi user: "Anh muốn simulate skill nào? Cho em đường dẫn."
-
-## Chạy simulate
-
-// turbo
-
-1. Mô phỏng skill:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\simulate_skill.py" <đường_dẫn_skill>
-```
-
-## Sau khi chạy
-
-- Hiển thị từng bước đã mô phỏng
-- Cảnh báo các bước mơ hồ cần sửa
-- Gợi ý thay thế từ mơ hồ bằng từ chính xác

package/skills/skill-creator-ultra/.agents/workflows/skill-stats.md

@@ -1,31 +0,0 @@
----
-description: 📊 Xem thống kê + Cognitive Load của skill
----
-
-# Skill Stats — Phân tích thống kê
-
-## Cách dùng
-
-Hỏi user: "Anh muốn xem thống kê skill nào? Cho em đường dẫn."
-
-## Chạy stats
-
-// turbo
-
-1. Thống kê bình thường:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_stats.py" <đường_dẫn_skill>
-```
-
-1. Output JSON:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\skill_stats.py" <đường_dẫn_skill> --json
-```
-
-## Sau khi chạy
-
-- Hiển thị kết quả cho user
-- Nếu Cognitive Load > 75 → cảnh báo skill quá phức tạp
-- Nếu thiếu examples hoặc constraints → gợi ý thêm

package/skills/skill-creator-ultra/.agents/workflows/skill-validate.md

@@ -1,25 +0,0 @@
----
-description: ✅ Kiểm tra SKILL.md có hợp lệ không
----
-
-# Skill Validate — Kiểm tra hợp lệ
-
-## Cách dùng
-
-Hỏi user: "Anh muốn validate skill nào? Cho em đường dẫn."
-
-## Chạy validate
-
-// turbo
-
-1. Kiểm tra file hoặc thư mục:
-
-```bash
-python "$env:USERPROFILE\.gemini\antigravity\skills\skill-generator\scripts\validate_skill.py" <đường_dẫn_skill>
-```
-
-## Sau khi chạy
-
-- Hiển thị kết quả pass/fail
-- Nếu có lỗi → gợi ý cách sửa
-- Nếu tất cả pass → gợi ý chạy /skill-audit để chấm điểm chi tiết