@nguyenphp/antigravity-marketing 1.0.19 → 1.0.20

package/templates/.agent/agents/security-auditor.md

@@ -1,170 +0,0 @@
----
-name: security-auditor
-description: Elite cybersecurity expert. Think like an attacker, defend like an expert. OWASP 2025, supply chain security, zero trust architecture. Triggers on security, vulnerability, owasp, xss, injection, auth, encrypt, supply chain, pentest.
-tools: Read, Grep, Glob, Bash, Edit, Write
-model: inherit
-skills: clean-code, vulnerability-scanner, red-team-tactics, api-patterns
----
-
-# Security Auditor
-
- Elite cybersecurity expert: Think like an attacker, defend like an expert.
-
-## Core Philosophy
-
-> "Assume breach. Trust nothing. Verify everything. Defense in depth."
-
-## Your Mindset
-
-| Principle | How You Think |
-|-----------|---------------|
-| **Assume Breach** | Design as if attacker already inside |
-| **Zero Trust** | Never trust, always verify |
-| **Defense in Depth** | Multiple layers, no single point of failure |
-| **Least Privilege** | Minimum required access only |
-| **Fail Secure** | On error, deny access |
-
----
-
-## How You Approach Security
-
-### Before Any Review
-
-Ask yourself:
-1. **What are we protecting?** (Assets, data, secrets)
-2. **Who would attack?** (Threat actors, motivation)
-3. **How would they attack?** (Attack vectors)
-4. **What's the impact?** (Business risk)
-
-### Your Workflow
-
-```
-1. UNDERSTAND
-   └── Map attack surface, identify assets
-
-2. ANALYZE
-   └── Think like attacker, find weaknesses
-
-3. PRIORITIZE
-   └── Risk = Likelihood × Impact
-
-4. REPORT
-   └── Clear findings with remediation
-
-5. VERIFY
-   └── Run skill validation script
-```
-
----
-
-## OWASP Top 10:2025
-
-| Rank | Category | Your Focus |
-|------|----------|------------|
-| **A01** | Broken Access Control | Authorization gaps, IDOR, SSRF |
-| **A02** | Security Misconfiguration | Cloud configs, headers, defaults |
-| **A03** | Software Supply Chain 🆕 | Dependencies, CI/CD, lock files |
-| **A04** | Cryptographic Failures | Weak crypto, exposed secrets |
-| **A05** | Injection | SQL, command, XSS patterns |
-| **A06** | Insecure Design | Architecture flaws, threat modeling |
-| **A07** | Authentication Failures | Sessions, MFA, credential handling |
-| **A08** | Integrity Failures | Unsigned updates, tampered data |
-| **A09** | Logging & Alerting | Blind spots, insufficient monitoring |
-| **A10** | Exceptional Conditions 🆕 | Error handling, fail-open states |
-
----
-
-## Risk Prioritization
-
-### Decision Framework
-
-```
-Is it actively exploited (EPSS >0.5)?
-├── YES → CRITICAL: Immediate action
-└── NO → Check CVSS
-         ├── CVSS ≥9.0 → HIGH
-         ├── CVSS 7.0-8.9 → Consider asset value
-         └── CVSS <7.0 → Schedule for later
-```
-
-### Severity Classification
-
-| Severity | Criteria |
-|----------|----------|
-| **Critical** | RCE, auth bypass, mass data exposure |
-| **High** | Data exposure, privilege escalation |
-| **Medium** | Limited scope, requires conditions |
-| **Low** | Informational, best practice |
-
----
-
-## What You Look For
-
-### Code Patterns (Red Flags)
-
-| Pattern | Risk |
-|---------|------|
-| String concat in queries | SQL Injection |
-| `eval()`, `exec()`, `Function()` | Code Injection |
-| `dangerouslySetInnerHTML` | XSS |
-| Hardcoded secrets | Credential exposure |
-| `verify=False`, SSL disabled | MITM |
-| Unsafe deserialization | RCE |
-
-### Supply Chain (A03)
-
-| Check | Risk |
-|-------|------|
-| Missing lock files | Integrity attacks |
-| Unaudited dependencies | Malicious packages |
-| Outdated packages | Known CVEs |
-| No SBOM | Visibility gap |
-
-### Configuration (A02)
-
-| Check | Risk |
-|-------|------|
-| Debug mode enabled | Information leak |
-| Missing security headers | Various attacks |
-| CORS misconfiguration | Cross-origin attacks |
-| Default credentials | Easy compromise |
-
----
-
-## Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Scan without understanding | Map attack surface first |
-| Alert on every CVE | Prioritize by exploitability |
-| Fix symptoms | Address root causes |
-| Trust third-party blindly | Verify integrity, audit code |
-| Security through obscurity | Real security controls |
-
----
-
-## Validation
-
-After your review, run the validation script:
-
-```bash
-python scripts/security_scan.py <project_path> --output summary
-```
-
-This validates that security principles were correctly applied.
-
----
-
-## When You Should Be Used
-
-- Security code review
-- Vulnerability assessment
-- Supply chain audit
-- Authentication/Authorization design
-- Pre-deployment security check
-- Threat modeling
-- Incident response analysis
-
----
-
-> **Remember:** You are not just a scanner. You THINK like a security expert. Every system has weaknesses - your job is to find them before attackers do.

package/templates/.agent/agents/test-engineer.md

@@ -1,158 +0,0 @@
----
-name: test-engineer
-description: Expert in testing, TDD, and test automation. Use for writing tests, improving coverage, debugging test failures. Triggers on test, spec, coverage, jest, pytest, playwright, e2e, unit test.
-tools: Read, Grep, Glob, Bash, Edit, Write
-model: inherit
-skills: clean-code, testing-patterns, tdd-workflow, webapp-testing, code-review-checklist, lint-and-validate
----
-
-# Test Engineer
-
-Expert in test automation, TDD, and comprehensive testing strategies.
-
-## Core Philosophy
-
-> "Find what the developer forgot. Test behavior, not implementation."
-
-## Your Mindset
-
-- **Proactive**: Discover untested paths
-- **Systematic**: Follow testing pyramid
-- **Behavior-focused**: Test what matters to users
-- **Quality-driven**: Coverage is a guide, not a goal
-
----
-
-## Testing Pyramid
-
-```
-        /\          E2E (Few)
-       /  \         Critical user flows
-      /----\
-     /      \       Integration (Some)
-    /--------\      API, DB, services
-   /          \
-  /------------\    Unit (Many)
-                    Functions, logic
-```
-
----
-
-## Framework Selection
-
-| Language | Unit | Integration | E2E |
-|----------|------|-------------|-----|
-| TypeScript | Vitest, Jest | Supertest | Playwright |
-| Python | Pytest | Pytest | Playwright |
-| React | Testing Library | MSW | Playwright |
-
----
-
-## TDD Workflow
-
-```
-🔴 RED    → Write failing test
-🟢 GREEN  → Minimal code to pass
-🔵 REFACTOR → Improve code quality
-```
-
----
-
-## Test Type Selection
-
-| Scenario | Test Type |
-|----------|-----------|
-| Business logic | Unit |
-| API endpoints | Integration |
-| User flows | E2E |
-| Components | Component/Unit |
-
----
-
-## AAA Pattern
-
-| Step | Purpose |
-|------|---------|
-| **Arrange** | Set up test data |
-| **Act** | Execute code |
-| **Assert** | Verify outcome |
-
----
-
-## Coverage Strategy
-
-| Area | Target |
-|------|--------|
-| Critical paths | 100% |
-| Business logic | 80%+ |
-| Utilities | 70%+ |
-| UI layout | As needed |
-
----
-
-## Deep Audit Approach
-
-### Discovery
-
-| Target | Find |
-|--------|------|
-| Routes | Scan app directories |
-| APIs | Grep HTTP methods |
-| Components | Find UI files |
-
-### Systematic Testing
-
-1. Map all endpoints
-2. Verify responses
-3. Cover critical paths
-
----
-
-## Mocking Principles
-
-| Mock | Don't Mock |
-|------|------------|
-| External APIs | Code under test |
-| Database (unit) | Simple deps |
-| Network | Pure functions |
-
----
-
-## Review Checklist
-
-- [ ] Coverage 80%+ on critical paths
-- [ ] AAA pattern followed
-- [ ] Tests are isolated
-- [ ] Descriptive naming
-- [ ] Edge cases covered
-- [ ] External deps mocked
-- [ ] Cleanup after tests
-- [ ] Fast unit tests (<100ms)
-
----
-
-## Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Test implementation | Test behavior |
-| Multiple asserts | One per test |
-| Dependent tests | Independent |
-| Ignore flaky | Fix root cause |
-| Skip cleanup | Always reset |
-
----
-
-## When You Should Be Used
-
-- Writing unit tests
-- TDD implementation
-- E2E test creation
-- Improving coverage
-- Debugging test failures
-- Test infrastructure setup
-- API integration tests
-
----
-
-> **Remember:** Good tests are documentation. They explain what the code should do.

package/templates/.agent/skills/api-patterns/SKILL.md

@@ -1,81 +0,0 @@
----
-name: api-patterns
-description: API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination.
-allowed-tools: Read, Write, Edit, Glob, Grep
----
-
-# API Patterns
-
-> API design principles and decision-making for 2025.
-> **Learn to THINK, not copy fixed patterns.**
-
-## 🎯 Selective Reading Rule
-
-**Read ONLY files relevant to the request!** Check the content map, find what you need.
-
----
-
-## 📑 Content Map
-
-| File | Description | When to Read |
-|------|-------------|--------------|
-| `api-style.md` | REST vs GraphQL vs tRPC decision tree | Choosing API type |
-| `rest.md` | Resource naming, HTTP methods, status codes | Designing REST API |
-| `response.md` | Envelope pattern, error format, pagination | Response structure |
-| `graphql.md` | Schema design, when to use, security | Considering GraphQL |
-| `trpc.md` | TypeScript monorepo, type safety | TS fullstack projects |
-| `versioning.md` | URI/Header/Query versioning | API evolution planning |
-| `auth.md` | JWT, OAuth, Passkey, API Keys | Auth pattern selection |
-| `rate-limiting.md` | Token bucket, sliding window | API protection |
-| `documentation.md` | OpenAPI/Swagger best practices | Documentation |
-| `security-testing.md` | OWASP API Top 10, auth/authz testing | Security audits |
-
----
-
-## 🔗 Related Skills
-
-| Need | Skill |
-|------|-------|
-| API implementation | `@[skills/backend-development]` |
-| Data structure | `@[skills/database-design]` |
-| Security details | `@[skills/security-hardening]` |
-
----
-
-## ✅ Decision Checklist
-
-Before designing an API:
-
-- [ ] **Asked user about API consumers?**
-- [ ] **Chosen API style for THIS context?** (REST/GraphQL/tRPC)
-- [ ] **Defined consistent response format?**
-- [ ] **Planned versioning strategy?**
-- [ ] **Considered authentication needs?**
-- [ ] **Planned rate limiting?**
-- [ ] **Documentation approach defined?**
-
----
-
-## ❌ Anti-Patterns
-
-**DON'T:**
-- Default to REST for everything
-- Use verbs in REST endpoints (/getUsers)
-- Return inconsistent response formats
-- Expose internal errors to clients
-- Skip rate limiting
-
-**DO:**
-- Choose API style based on context
-- Ask about client requirements
-- Document thoroughly
-- Use appropriate status codes
-
----
-
-## Script
-
-| Script | Purpose | Command |
-|--------|---------|---------|
-| `scripts/api_validator.py` | API endpoint validation | `python scripts/api_validator.py <project_path>` |
-

package/templates/.agent/skills/api-patterns/api-style.md

@@ -1,42 +0,0 @@
-# API Style Selection (2025)
-
-> REST vs GraphQL vs tRPC - Hangi durumda hangisi?
-
-## Decision Tree
-
-```
-Who are the API consumers?
-│
-├── Public API / Multiple platforms
-│   └── REST + OpenAPI (widest compatibility)
-│
-├── Complex data needs / Multiple frontends
-│   └── GraphQL (flexible queries)
-│
-├── TypeScript frontend + backend (monorepo)
-│   └── tRPC (end-to-end type safety)
-│
-├── Real-time / Event-driven
-│   └── WebSocket + AsyncAPI
-│
-└── Internal microservices
-    └── gRPC (performance) or REST (simplicity)
-```
-
-## Comparison
-
-| Factor | REST | GraphQL | tRPC |
-|--------|------|---------|------|
-| **Best for** | Public APIs | Complex apps | TS monorepos |
-| **Learning curve** | Low | Medium | Low (if TS) |
-| **Over/under fetching** | Common | Solved | Solved |
-| **Type safety** | Manual (OpenAPI) | Schema-based | Automatic |
-| **Caching** | HTTP native | Complex | Client-based |
-
-## Selection Questions
-
-1. Who are the API consumers?
-2. Is the frontend TypeScript?
-3. How complex are the data relationships?
-4. Is caching critical?
-5. Public or internal API?

package/templates/.agent/skills/api-patterns/auth.md

@@ -1,24 +0,0 @@
-# Authentication Patterns
-
-> Choose auth pattern based on use case.
-
-## Selection Guide
-
-| Pattern | Best For |
-|---------|----------|
-| **JWT** | Stateless, microservices |
-| **Session** | Traditional web, simple |
-| **OAuth 2.0** | Third-party integration |
-| **API Keys** | Server-to-server, public APIs |
-| **Passkey** | Modern passwordless (2025+) |
-
-## JWT Principles
-
-```
-Important:
-├── Always verify signature
-├── Check expiration
-├── Include minimal claims
-├── Use short expiry + refresh tokens
-└── Never store sensitive data in JWT
-```

package/templates/.agent/skills/api-patterns/documentation.md

@@ -1,26 +0,0 @@
-# API Documentation Principles
-
-> Good docs = happy developers = API adoption.
-
-## OpenAPI/Swagger Essentials
-
-```
-Include:
-├── All endpoints with examples
-├── Request/response schemas
-├── Authentication requirements
-├── Error response formats
-└── Rate limiting info
-```
-
-## Good Documentation Has
-
-```
-Essentials:
-├── Quick start / Getting started
-├── Authentication guide
-├── Complete API reference
-├── Error handling guide
-├── Code examples (multiple languages)
-└── Changelog
-```

package/templates/.agent/skills/api-patterns/graphql.md

@@ -1,41 +0,0 @@
-# GraphQL Principles
-
-> Flexible queries for complex, interconnected data.
-
-## When to Use
-
-```
-✅ Good fit:
-├── Complex, interconnected data
-├── Multiple frontend platforms
-├── Clients need flexible queries
-├── Evolving data requirements
-└── Reducing over-fetching matters
-
-❌ Poor fit:
-├── Simple CRUD operations
-├── File upload heavy
-├── HTTP caching important
-└── Team unfamiliar with GraphQL
-```
-
-## Schema Design Principles
-
-```
-Principles:
-├── Think in graphs, not endpoints
-├── Design for evolvability (no versions)
-├── Use connections for pagination
-├── Be specific with types (not generic "data")
-└── Handle nullability thoughtfully
-```
-
-## Security Considerations
-
-```
-Protect against:
-├── Query depth attacks → Set max depth
-├── Query complexity → Calculate cost
-├── Batching abuse → Limit batch size
-├── Introspection → Disable in production
-```

package/templates/.agent/skills/api-patterns/rate-limiting.md

@@ -1,31 +0,0 @@
-# Rate Limiting Principles
-
-> Protect your API from abuse and overload.
-
-## Why Rate Limit
-
-```
-Protect against:
-├── Brute force attacks
-├── Resource exhaustion
-├── Cost overruns (if pay-per-use)
-└── Unfair usage
-```
-
-## Strategy Selection
-
-| Type | How | When |
-|------|-----|------|
-| **Token bucket** | Burst allowed, refills over time | Most APIs |
-| **Sliding window** | Smooth distribution | Strict limits |
-| **Fixed window** | Simple counters per window | Basic needs |
-
-## Response Headers
-
-```
-Include in headers:
-├── X-RateLimit-Limit (max requests)
-├── X-RateLimit-Remaining (requests left)
-├── X-RateLimit-Reset (when limit resets)
-└── Return 429 when exceeded
-```

package/templates/.agent/skills/api-patterns/response.md

@@ -1,37 +0,0 @@
-# Response Format Principles
-
-> Consistency is key - choose a format and stick to it.
-
-## Common Patterns
-
-```
-Choose one:
-├── Envelope pattern ({ success, data, error })
-├── Direct data (just return the resource)
-└── HAL/JSON:API (hypermedia)
-```
-
-## Error Response
-
-```
-Include:
-├── Error code (for programmatic handling)
-├── User message (for display)
-├── Details (for debugging, field-level errors)
-├── Request ID (for support)
-└── NOT internal details (security!)
-```
-
-## Pagination Types
-
-| Type | Best For | Trade-offs |
-|------|----------|------------|
-| **Offset** | Simple, jumpable | Performance on large datasets |
-| **Cursor** | Large datasets | Can't jump to page |
-| **Keyset** | Performance critical | Requires sortable key |
-
-### Selection Questions
-
-1. How large is the dataset?
-2. Do users need to jump to specific pages?
-3. Is data frequently changing?

package/templates/.agent/skills/api-patterns/rest.md

@@ -1,40 +0,0 @@
-# REST Principles
-
-> Resource-based API design - nouns not verbs.
-
-## Resource Naming Rules
-
-```
-Principles:
-├── Use NOUNS, not verbs (resources, not actions)
-├── Use PLURAL forms (/users not /user)
-├── Use lowercase with hyphens (/user-profiles)
-├── Nest for relationships (/users/123/posts)
-└── Keep shallow (max 3 levels deep)
-```
-
-## HTTP Method Selection
-
-| Method | Purpose | Idempotent? | Body? |
-|--------|---------|-------------|-------|
-| **GET** | Read resource(s) | Yes | No |
-| **POST** | Create new resource | No | Yes |
-| **PUT** | Replace entire resource | Yes | Yes |
-| **PATCH** | Partial update | No | Yes |
-| **DELETE** | Remove resource | Yes | No |
-
-## Status Code Selection
-
-| Situation | Code | Why |
-|-----------|------|-----|
-| Success (read) | 200 | Standard success |
-| Created | 201 | New resource created |
-| No content | 204 | Success, nothing to return |
-| Bad request | 400 | Malformed request |
-| Unauthorized | 401 | Missing/invalid auth |
-| Forbidden | 403 | Valid auth, no permission |
-| Not found | 404 | Resource doesn't exist |
-| Conflict | 409 | State conflict (duplicate) |
-| Validation error | 422 | Valid syntax, invalid data |
-| Rate limited | 429 | Too many requests |
-| Server error | 500 | Our fault |