@riligar/agents-kit 1.11.0 → 1.12.0

package/.agent/skills/riligar-dev-backend/security-testing.md

@@ -1,122 +0,0 @@
-# API Security Testing
-
-> Principles for testing API security. OWASP API Top 10, authentication, authorization testing.
-
----
-
-## OWASP API Security Top 10
-
-| Vulnerability | Test Focus |
-|---------------|------------|
-| **API1: BOLA** | Access other users' resources |
-| **API2: Broken Auth** | JWT, session, credentials |
-| **API3: Property Auth** | Mass assignment, data exposure |
-| **API4: Resource Consumption** | Rate limiting, DoS |
-| **API5: Function Auth** | Admin endpoints, role bypass |
-| **API6: Business Flow** | Logic abuse, automation |
-| **API7: SSRF** | Internal network access |
-| **API8: Misconfiguration** | Debug endpoints, CORS |
-| **API9: Inventory** | Shadow APIs, old versions |
-| **API10: Unsafe Consumption** | Third-party API trust |
-
----
-
-## Authentication Testing
-
-### JWT Testing
-
-| Check | What to Test |
-|-------|--------------|
-| Algorithm | None, algorithm confusion |
-| Secret | Weak secrets, brute force |
-| Claims | Expiration, issuer, audience |
-| Signature | Manipulation, key injection |
-
-### Session Testing
-
-| Check | What to Test |
-|-------|--------------|
-| Generation | Predictability |
-| Storage | Client-side security |
-| Expiration | Timeout enforcement |
-| Invalidation | Logout effectiveness |
-
----
-
-## Authorization Testing
-
-| Test Type | Approach |
-|-----------|----------|
-| **Horizontal** | Access peer users' data |
-| **Vertical** | Access higher privilege functions |
-| **Context** | Access outside allowed scope |
-
-### BOLA/IDOR Testing
-
-1. Identify resource IDs in requests
-2. Capture request with user A's session
-3. Replay with user B's session
-4. Check for unauthorized access
-
----
-
-## Input Validation Testing
-
-| Injection Type | Test Focus |
-|----------------|------------|
-| SQL | Query manipulation |
-| NoSQL | Document queries |
-| Command | System commands |
-| LDAP | Directory queries |
-
-**Approach:** Test all parameters, try type coercion, test boundaries, check error messages.
-
----
-
-## Rate Limiting Testing
-
-| Aspect | Check |
-|--------|-------|
-| Existence | Is there any limit? |
-| Bypass | Headers, IP rotation |
-| Scope | Per-user, per-IP, global |
-
-**Bypass techniques:** X-Forwarded-For, different HTTP methods, case variations, API versioning.
-
----
-
-## GraphQL Security
-
-| Test | Focus |
-|------|-------|
-| Introspection | Schema disclosure |
-| Batching | Query DoS |
-| Nesting | Depth-based DoS |
-| Authorization | Field-level access |
-
----
-
-## Security Testing Checklist
-
-**Authentication:**
-- [ ] Test for bypass
-- [ ] Check credential strength
-- [ ] Verify token security
-
-**Authorization:**
-- [ ] Test BOLA/IDOR
-- [ ] Check privilege escalation
-- [ ] Verify function access
-
-**Input:**
-- [ ] Test all parameters
-- [ ] Check for injection
-
-**Config:**
-- [ ] Check CORS
-- [ ] Verify headers
-- [ ] Test error handling
-
----
-
-> **Remember:** APIs are the backbone of modern apps. Test them like attackers will.

package/.agent/skills/riligar-dev-backend/trpc.md

@@ -1,41 +0,0 @@
-# tRPC Principles
-
-> End-to-end type safety for TypeScript monorepos.
-
-## When to Use
-
-```
-✅ Perfect fit:
-├── TypeScript on both ends
-├── Monorepo structure
-├── Internal tools
-├── Rapid development
-└── Type safety critical
-
-❌ Poor fit:
-├── Non-TypeScript clients
-├── Public API
-├── Need REST conventions
-└── Multiple language backends
-```
-
-## Key Benefits
-
-```
-Why tRPC:
-├── Zero schema maintenance
-├── End-to-end type inference
-├── IDE autocomplete across stack
-├── Instant API changes reflected
-└── No code generation step
-```
-
-## Integration Patterns
-
-```
-Common setups:
-├── Next.js + tRPC (most common)
-├── Monorepo with shared types
-├── Remix + tRPC
-└── Any TS frontend + backend
-```

package/.agent/skills/riligar-dev-backend/versioning.md

@@ -1,22 +0,0 @@
-# Versioning Strategies
-
-> Plan for API evolution from day one.
-
-## Decision Factors
-
-| Strategy | Implementation | Trade-offs |
-|----------|---------------|------------|
-| **URI** | /v1/users | Clear, easy caching |
-| **Header** | Accept-Version: 1 | Cleaner URLs, harder discovery |
-| **Query** | ?version=1 | Easy to add, messy |
-| **None** | Evolve carefully | Best for internal, risky for public |
-
-## Versioning Philosophy
-
-```
-Consider:
-├── Public API? → Version in URI
-├── Internal only? → May not need versioning
-├── GraphQL? → Typically no versions (evolve schema)
-├── tRPC? → Types enforce compatibility
-```