thachvd-kit 1.0.28 → 1.0.30

package/skills/deployment-procedures/SKILL.md

@@ -1,241 +0,0 @@
----
-name: deployment-procedures
-description: Production deployment principles and decision-making. Safe deployment workflows, rollback strategies, and verification. Teaches thinking, not scripts.
-allowed-tools: Read, Glob, Grep, Bash
----
-
-# Deployment Procedures
-
-> Deployment principles and decision-making for safe production releases.
-> **Learn to THINK, not memorize scripts.**
-
----
-
-## ⚠️ How to Use This Skill
-
-This skill teaches **deployment principles**, not bash scripts to copy.
-
-- Every deployment is unique
-- Understand the WHY behind each step
-- Adapt procedures to your platform
-
----
-
-## 1. Platform Selection
-
-### Decision Tree
-
-```
-What are you deploying?
-│
-├── Static site / JAMstack
-│   └── Vercel, Netlify, Cloudflare Pages
-│
-├── Simple web app
-│   ├── Managed → Railway, Render, Fly.io
-│   └── Control → VPS + PM2/Docker
-│
-├── Microservices
-│   └── Container orchestration
-│
-└── Serverless
-    └── Edge functions, Lambda
-```
-
-### Each Platform Has Different Procedures
-
-| Platform | Deployment Method |
-|----------|------------------|
-| **Vercel/Netlify** | Git push, auto-deploy |
-| **Railway/Render** | Git push or CLI |
-| **VPS + PM2** | SSH + manual steps |
-| **Docker** | Image push + orchestration |
-| **Kubernetes** | kubectl apply |
-
----
-
-## 2. Pre-Deployment Principles
-
-### The 4 Verification Categories
-
-| Category | What to Check |
-|----------|--------------|
-| **Code Quality** | Tests passing, linting clean, reviewed |
-| **Build** | Production build works, no warnings |
-| **Environment** | Env vars set, secrets current |
-| **Safety** | Backup done, rollback plan ready |
-
-### Pre-Deployment Checklist
-
-- [ ] All tests passing
-- [ ] Code reviewed and approved
-- [ ] Production build successful
-- [ ] Environment variables verified
-- [ ] Database migrations ready (if any)
-- [ ] Rollback plan documented
-- [ ] Team notified
-- [ ] Monitoring ready
-
----
-
-## 3. Deployment Workflow Principles
-
-### The 5-Phase Process
-
-```
-1. PREPARE
-   └── Verify code, build, env vars
-
-2. BACKUP
-   └── Save current state before changing
-
-3. DEPLOY
-   └── Execute with monitoring open
-
-4. VERIFY
-   └── Health check, logs, key flows
-
-5. CONFIRM or ROLLBACK
-   └── All good? Confirm. Issues? Rollback.
-```
-
-### Phase Principles
-
-| Phase | Principle |
-|-------|-----------|
-| **Prepare** | Never deploy untested code |
-| **Backup** | Can't rollback without backup |
-| **Deploy** | Watch it happen, don't walk away |
-| **Verify** | Trust but verify |
-| **Confirm** | Have rollback trigger ready |
-
----
-
-## 4. Post-Deployment Verification
-
-### What to Verify
-
-| Check | Why |
-|-------|-----|
-| **Health endpoint** | Service is running |
-| **Error logs** | No new errors |
-| **Key user flows** | Critical features work |
-| **Performance** | Response times acceptable |
-
-### Verification Window
-
-- **First 5 minutes**: Active monitoring
-- **15 minutes**: Confirm stable
-- **1 hour**: Final verification
-- **Next day**: Review metrics
-
----
-
-## 5. Rollback Principles
-
-### When to Rollback
-
-| Symptom | Action |
-|---------|--------|
-| Service down | Rollback immediately |
-| Critical errors | Rollback |
-| Performance >50% degraded | Consider rollback |
-| Minor issues | Fix forward if quick |
-
-### Rollback Strategy by Platform
-
-| Platform | Rollback Method |
-|----------|----------------|
-| **Vercel/Netlify** | Redeploy previous commit |
-| **Railway/Render** | Rollback in dashboard |
-| **VPS + PM2** | Restore backup, restart |
-| **Docker** | Previous image tag |
-| **K8s** | kubectl rollout undo |
-
-### Rollback Principles
-
-1. **Speed over perfection**: Rollback first, debug later
-2. **Don't compound errors**: One rollback, not multiple changes
-3. **Communicate**: Tell team what happened
-4. **Post-mortem**: Understand why after stable
-
----
-
-## 6. Zero-Downtime Deployment
-
-### Strategies
-
-| Strategy | How It Works |
-|----------|--------------|
-| **Rolling** | Replace instances one by one |
-| **Blue-Green** | Switch traffic between environments |
-| **Canary** | Gradual traffic shift |
-
-### Selection Principles
-
-| Scenario | Strategy |
-|----------|----------|
-| Standard release | Rolling |
-| High-risk change | Blue-green (easy rollback) |
-| Need validation | Canary (test with real traffic) |
-
----
-
-## 7. Emergency Procedures
-
-### Service Down Priority
-
-1. **Assess**: What's the symptom?
-2. **Quick fix**: Restart if unclear
-3. **Rollback**: If restart doesn't help
-4. **Investigate**: After stable
-
-### Investigation Order
-
-| Check | Common Issues |
-|-------|--------------|
-| **Logs** | Errors, exceptions |
-| **Resources** | Disk full, memory |
-| **Network** | DNS, firewall |
-| **Dependencies** | Database, APIs |
-
----
-
-## 8. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Deploy on Friday | Deploy early in week |
-| Rush deployment | Follow the process |
-| Skip staging | Always test first |
-| Deploy without backup | Backup before deploy |
-| Walk away after deploy | Monitor for 15+ min |
-| Multiple changes at once | One change at a time |
-
----
-
-## 9. Decision Checklist
-
-Before deploying:
-
-- [ ] **Platform-appropriate procedure?**
-- [ ] **Backup strategy ready?**
-- [ ] **Rollback plan documented?**
-- [ ] **Monitoring configured?**
-- [ ] **Team notified?**
-- [ ] **Time to monitor after?**
-
----
-
-## 10. Best Practices
-
-1. **Small, frequent deploys** over big releases
-2. **Feature flags** for risky changes
-3. **Automate** repetitive steps
-4. **Document** every deployment
-5. **Review** what went wrong after issues
-6. **Test rollback** before you need it
-
----
-
-> **Remember:** Every deployment is a risk. Minimize risk through preparation, not speed.

package/skills/desktop-design/SKILL.md

@@ -1,25 +0,0 @@
----
-name: desktop-design
-description: Desktop and cross-platform app design guidance for Tauri and similar desktop shells. Use when building desktop-first interfaces, windowed workflows, keyboard-heavy UX, or cross-platform desktop UI behavior.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
----
-
-# Desktop Design
-
-This skill covers desktop-first product thinking where `mobile-design` is the wrong default.
-
-Use it for Tauri and other desktop-oriented apps with window management, keyboard shortcuts, dense layouts, or multi-panel workflows.
-
-## Guidance
-
-- Design for pointer + keyboard, not touch-first.
-- Use information density deliberately; desktop screens can support richer sidebars and multi-column layouts.
-- Respect platform conventions for menus, shortcuts, dialogs, file pickers, and drag/drop.
-- Assume resizing, multiple windows, and long-running sessions are normal.
-- Pair with `rust-pro` for Tauri backend/native concerns and `frontend-design` for UI execution.
-
-## Related Skills
-
-- `mobile-design` for touch-first mobile products
-- `frontend-design` for visual and interaction design
-- `rust-pro` for Rust and Tauri implementation details

package/skills/dispatching-parallel-agents/SKILL.md

@@ -1,112 +0,0 @@
----
-name: dispatching-parallel-agents
-description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies — dispatch one agent per independent problem domain, let them work concurrently
-allowed-tools: Task, Read
----
-
-# Dispatching Parallel Agents
-
-## Overview
-
-Delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed. They **never inherit your session's context or history** — you construct exactly what they need. This also preserves your own context for coordination work.
-
-**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.
-
-## When to Use
-
-**Use when:**
-- 3+ test files failing with different root causes
-- Multiple subsystems broken independently
-- Each problem can be understood without context from others
-- No shared state between investigations
-
-**Don't use when:**
-- Failures are related (fix one might fix others)
-- Need to understand full system state
-- Agents would interfere with each other (editing same files)
-
-## The Pattern
-
-### 1. Identify Independent Domains
-
-Group failures by what's broken:
-- File A tests: Tool approval flow
-- File B tests: Batch completion behavior
-- File C tests: Abort functionality
-
-Each domain is independent — fixing one doesn't affect the others.
-
-### 2. Create Focused Agent Tasks
-
-Each agent gets:
-- **Specific scope:** One test file or subsystem
-- **Clear goal:** Make these tests pass
-- **Constraints:** Don't change other code
-- **Expected output:** Summary of what you found and fixed
-
-### 3. Dispatch in Parallel
-
-```
-Task("Fix auth-flow.test.ts failures")
-Task("Fix batch-completion.test.ts failures")
-Task("Fix abort-handling.test.ts failures")
-// All three run concurrently
-```
-
-### 4. Review and Integrate
-
-When agents return:
-- Read each summary
-- Verify fixes don't conflict
-- Run full test suite
-- Integrate all changes
-
-## Agent Prompt Structure
-
-Good agent prompts are:
-1. **Focused** — One clear problem domain
-2. **Self-contained** — All context needed to understand the problem
-3. **Specific about output** — What should the agent return?
-
-**Template:**
-```markdown
-Fix the 3 failing tests in src/[file].test.ts:
-
-1. "[test name]" — expects [X] but gets [Y]
-2. "[test name]" — [description]
-3. "[test name]" — [description]
-
-These are [timing/logic/type] issues. Your task:
-
-1. Read the test file and understand what each test verifies
-2. Identify root cause
-3. Fix [specific approach]
-
-Do NOT just increase timeouts — find the real issue.
-
-Return: Summary of what you found and what you fixed.
-```
-
-## Common Mistakes
-
-| ❌ Wrong | ✅ Right |
-|----------|---------|
-| "Fix all the tests" — too broad | "Fix auth-flow.test.ts" — focused scope |
-| "Fix the race condition" — no context | Paste the error messages and test names |
-| No constraints — agent might refactor everything | "Do NOT change production code" |
-| "Fix it" — vague output | "Return summary of root cause and changes" |
-
-## Verification
-
-After agents return:
-1. **Review each summary** — Understand what changed
-2. **Check for conflicts** — Did agents edit same code?
-3. **Run full suite** — Verify all fixes work together
-4. **Spot check** — Agents can make systematic errors
-
-## Key Benefits
-
-1. **Parallelization** — Multiple investigations happen simultaneously
-2. **Focus** — Each agent has narrow scope, less context to track
-3. **Independence** — Agents don't interfere with each other
-4. **Speed** — 3 problems solved in time of 1

package/skills/doc.md

@@ -1,177 +0,0 @@
-# Antigravity Skills
-
-> **Guide to creating and using Skills in the Antigravity Kit**
-
----
-
-## 📋 Overview
-
-While Antigravity's base models (like Gemini) are powerful generalists, they don't know your specific project context or your team's standards. Loading every rule or tool into the agent's context window leads to "tool bloat," higher costs, latency, and confusion.
-
-**Antigravity Skills** solve this through **Progressive Disclosure**. A Skill is a package of specialized knowledge that remains dormant until needed. This information is only loaded into the agent's context when your specific request matches the skill's description.
-
----
-
-## 📁 Structure and Scope
-
-Skills are folder-based packages. You can define these scopes based on your needs:
-
-| Scope         | Path                              | Description                          |
-| ------------- | --------------------------------- | ------------------------------------ |
-| **Workspace** | `<workspace-root>/.agent/skills/` | Available only in a specific project |
-
-### Skill Directory Structure
-
-```
-my-skill/
-├── SKILL.md      # (Required) Metadata & instructions
-├── scripts/      # (Optional) Python or Bash scripts
-├── references/   # (Optional) Text, documentation, templates
-└── assets/       # (Optional) Images or logos
-```
-
----
-
-## 🔍 Example 1: Code Review Skill
-
-This is an instruction-only skill; you only need to create the `SKILL.md` file.
-
-### Step 1: Create the directory
-
-```bash
-mkdir -p .agent/skills/code-review
-```
-
-### Step 2: Create SKILL.md
-
-```markdown
----
-name: code-review
-description: Reviews code changes for bugs, style issues, and best practices. Use when reviewing PRs or checking code quality.
----
-
-# Code Review Skill
-
-When reviewing code, follow these steps:
-
-## Review checklist
-
-1. **Correctness**: Does the code do what it's supposed to?
-2. **Edge cases**: Are error conditions handled?
-3. **Style**: Does it follow project conventions?
-4. **Performance**: Are there obvious inefficiencies?
-
-## How to provide feedback
-
-- Be specific about what needs to change
-- Explain why, not just what
-- Suggest alternatives when possible
-```
-
-> **Note**: The `SKILL.md` file contains metadata (name, description) at the top, followed by the instructions. The agent will only read the metadata and load the full instructions only when needed.
-
-### Try it out
-
-Create a file `demo_bad_code.py`:
-
-```python
-import time
-
-def get_user_data(users, id):
-    # Find user by ID
-    for u in users:
-        if u['id'] == id:
-            return u
-    return None
-
-def process_payments(items):
-    total = 0
-    for i in items:
-        # Calculate tax
-        tax = i['price'] * 0.1
-        total = total + i['price'] + tax
-        time.sleep(0.1)  # Simulate slow network call
-    return total
-
-def run_batch():
-    users = [{'id': 1, 'name': 'Alice'}, {'id': 2, 'name': 'Bob'}]
-    items = [{'price': 10}, {'price': 20}, {'price': 100}]
-
-    u = get_user_data(users, 3)
-    print("User found: " + u['name'])  # Will crash if None
-
-    print("Total: " + str(process_payments(items)))
-
-if __name__ == "__main__":
-    run_batch()
-```
-
-**Prompt**: `review the @demo_bad_code.py file`
-
-The Agent will automatically identify the `code-review` skill, load the information, and follow the instructions.
-
----
-
-## 📄 Example 2: License Header Skill
-
-This skill uses a reference file in the `resources/` (or `references/`) directory.
-
-### Step 1: Create the directory
-
-```bash
-mkdir -p .agent/skills/license-header-adder/resources
-```
-
-### Step 2: Create the template file
-
-**`.agent/skills/license-header-adder/resources/HEADER.txt`**:
-
-```
-/*
- * Copyright (c) 2026 YOUR_COMPANY_NAME LLC.
- * All rights reserved.
- * This code is proprietary and confidential.
- */
-```
-
-### Step 3: Create SKILL.md
-
-**`.agent/skills/license-header-adder/SKILL.md`**:
-
-```markdown
----
-name: license-header-adder
-description: Adds the standard corporate license header to new source files.
----
-
-# License Header Adder
-
-This skill ensures that all new source files have the correct copyright header.
-
-## Instructions
-
-1. **Read the Template**: Read the content of `resources/HEADER.txt`.
-2. **Apply to File**: When creating a new file, prepend this exact content.
-3. **Adapt Syntax**:
-   - For C-style languages (Java, TS), keep the `/* */` block.
-   - For Python/Shell, convert to `#` comments.
-```
-
-### Try it out
-
-**Prompt**: `Create a new Python script named data_processor.py that prints 'Hello World'.`
-
-The Agent will read the template, convert the comments to Python style, and automatically add it to the top of the file.
-
----
-
-## 🎯 Conclusion
-
-By creating Skills, you transform a general AI model into an expert for your project:
-
-- ✅ Systematize best practices
-- ✅ Adhere to code review rules
-- ✅ Automatically add license headers
-- ✅ The Agent automatically knows how to work with your team
-
-Instead of constantly reminding the AI to "remember to add the license" or "fix the commit format," now the Agent will do it automatically!