anchi-kit 1.2.0 → 1.2.2

package/.antigravity/skills/review-implementing/SKILL.md

@@ -0,0 +1,287 @@
+---
+name: review-implementing
+description: Evaluate code implementations against specifications and architectural requirements. Ensures alignment with design docs, verifies pattern compliance, and identifies deviations before code review.
+---
+
+# Review Implementing
+
+Pre-merge implementation verification against specifications and architecture standards.
+
+## When to Use
+
+- Before creating pull requests
+- After completing feature implementation
+- When aligning code with specs
+- During architecture compliance reviews
+- Before claiming "implementation complete"
+
+## Review Process
+
+### 1. Specification Alignment
+
+**Check:** Does implementation match the spec?
+
+```markdown
+Spec Says:
+
+- API endpoint: POST /api/users
+- Required fields: email, password, name
+- Return: 201 with user object
+
+Implementation Review:
+✅ Endpoint correct: POST /api/users
+✅ Validates all required fields
+❌ Returns 200 instead of 201
+❌ Missing 'name' in response
+
+Actions:
+
+- Fix status code
+- Add 'name' to response
+```
+
+### 2. Architecture Compliance
+
+**Check:** Follows architectural patterns?
+
+```javascript
+// Spec: Use repository pattern
+❌ BAD:
+async function createUser(email) {
+  return await db.users.create({ email });
+}
+
+✅ GOOD:
+class UserRepository {
+  async create(userData) {
+    return await this.db.users.create(userData);
+  }
+}
+```
+
+### 3. Design Pattern Verification
+
+**Check:** Correct patterns applied?
+
+```typescript
+// Spec: Use Builder pattern for complex objects
+❌ VIOLATION:
+const config = new Config(url, timeout, retries, headers, auth);
+
+✅ COMPLIANT:
+const config = new ConfigBuilder()
+  .setUrl(url)
+  .setTimeout(timeout)
+  .setRetries(retries)
+  .build();
+```
+
+## Review Checklist
+
+### Functional Requirements
+
+- [ ] All specified features implemented
+- [ ] Edge cases handled
+- [ ] Error responses match spec
+- [ ] Success responses match spec
+- [ ] Validation rules correct
+
+### Non-Functional Requirements
+
+- [ ] Performance meets targets
+- [ ] Security requirements satisfied
+- [ ] Scalability considered
+- [ ] Logging/monitoring added
+- [ ] Documentation complete
+
+### Code Quality
+
+- [ ] Follows project conventions
+- [ ] No code smells
+- [ ] Proper error handling
+- [ ] Tests comprehensive
+- [ ] Comments where needed
+
+## Common Deviations
+
+### Deviation Type 1: API Changes
+
+```diff
+Spec:
+GET /api/products?category=electronics
+
+Implementation:
+- GET /api/products/:category
++ GET /api/products?category=electronics
+
+Status: ✅ FIXED - Now matches spec
+```
+
+### Deviation Type 2: Missing Validation
+
+```javascript
+// Spec requires email validation
+❌ Missing:
+function createUser(email) {
+  return db.users.create({ email });
+}
+
+✅ Added:
+function createUser(email) {
+  if (!isValidEmail(email)) {
+    throw new ValidationError('Invalid email');
+  }
+  return db.users.create({ email });
+}
+```
+
+### Deviation Type 3: Incomplete Error Handling
+
+```typescript
+// Spec: Return specific error codes
+❌ Generic:
+catch (error) {
+  res.status(500).json({ error: 'Internal error' });
+}
+
+✅ Specific:
+catch (error) {
+  if (error instanceof ValidationError) {
+    return res.status(400).json({ error: error.message });
+  }
+  if (error instanceof NotFoundError) {
+    return res.status(404).json({ error: 'User not found' });
+  }
+  res.status(500).json({ error: 'Internal server error' });
+}
+```
+
+## Alignment Strategies
+
+### 1. Specification Traceability
+
+Map code to spec requirements:
+
+```markdown
+| Requirement                 | Implementation     | Status     |
+| --------------------------- | ------------------ | ---------- |
+| REQ-001: User signup        | src/auth/signup.ts | ✅         |
+| REQ-002: Email verification | src/auth/verify.ts | ✅         |
+| REQ-003: Password reset     | src/auth/reset.ts  | ⚠️ Partial |
+```
+
+### 2. Architecture Decision Records (ADRs)
+
+Document deviations from spec:
+
+```markdown
+# ADR-023: Changed Authentication Method
+
+## Context
+
+Spec specifies JWT tokens, but team decided OAuth2.
+
+## Decision
+
+Use OAuth2 with refresh tokens instead of plain JWT.
+
+## Consequences
+
+- Better security
+- More complex implementation
+- Requires spec update
+
+## Status
+
+Approved by architect
+```
+
+### 3. Progressive Alignment
+
+Fix misalignments incrementally:
+
+```
+Phase 1: Core functionality aligned
+Phase 2: Error handling aligned
+Phase 3: Performance optimizations
+Phase 4: Documentation complete
+```
+
+## Review Workflow
+
+### Pre-Implementation Review
+
+```markdown
+Before coding:
+
+1. Read spec thoroughly
+2. Identify unclear requirements
+3. Ask clarifying questions
+4. Create implementation plan
+5. Get plan approved
+```
+
+### Mid-Implementation Checkpoint
+
+```markdown
+At 50% complete:
+
+1. Review progress vs spec
+2. Identify deviations early
+3. Course-correct if needed
+4. Update estimates
+```
+
+### Pre-PR Review
+
+```markdown
+Before pull request:
+
+1. Self-review against spec
+2. Run compliance checks
+3. Fix all deviations
+4. Document intentional changes
+5. Request formal review
+```
+
+## Automated Checks
+
+### Linting Rules
+
+```javascript
+// .eslintrc.js - Enforce architecture patterns
+rules: {
+  'no-direct-db-access': 'error',  // Must use repository
+  'require-error-codes': 'error',  // Specific error types
+  'api-versioning': 'error'        // Version all endpoints
+}
+```
+
+### API Contract Testing
+
+```javascript
+// Verify API matches OpenAPI spec
+test('POST /users matches spec', () => {
+  const response = await request(app).post('/users').send(validUser);
+
+  expect(response.status).toBe(201);  // From spec
+  expect(response.body).toMatchSchema(userSchema);  // From spec
+});
+```
+
+## Best Practices
+
+1. **Spec First** - Read spec before coding
+2. **Early Alignment** - Check alignment frequently
+3. **Document Deviations** - Explain why if different
+4. **Seek Clarification** - Ask when spec unclear
+5. **Automated Validation** - Use tools to enforce compliance
+
+## References
+
+See [references/implementation-review-checklist.md](references/implementation-review-checklist.md) for:
+
+- Comprehensive review checklists
+- Common compliance issues
+- Specification templates
+- Alignment verification tools

package/.antigravity/skills/security-audit/SKILL.md

@@ -0,0 +1,263 @@
+# Security Audit Skill
+
+> Domain knowledge for writing secure code and preventing vulnerabilities.
+
+---
+
+## 🔐 OWASP Top 10 Prevention
+
+### 1. Injection (SQL, NoSQL, Command)
+
+**❌ Vulnerable:**
+
+```typescript
+// SQL Injection
+const user = await db.query(`SELECT * FROM users WHERE id = ${id}`);
+
+// Command Injection
+exec(`ls ${userInput}`);
+```
+
+**✅ Secure:**
+
+```typescript
+// Parameterized queries
+const user = await prisma.user.findUnique({ where: { id } });
+
+// Avoid shell commands, use libraries
+import { readdir } from "fs/promises";
+const files = await readdir(safeDirectory);
+```
+
+---
+
+### 2. Broken Authentication
+
+**Checklist:**
+
+- [ ] Passwords hashed with bcrypt/argon2 (cost ≥ 10)
+- [ ] Session tokens are random and long (≥ 32 bytes)
+- [ ] Sessions expire (max 24h for sensitive, 30d for remember-me)
+- [ ] Rate limiting on login (5 attempts/minute)
+- [ ] Account lockout after repeated failures
+- [ ] MFA available for sensitive accounts
+
+```typescript
+// Password hashing
+import bcrypt from "bcrypt";
+const hash = await bcrypt.hash(password, 12);
+const valid = await bcrypt.compare(password, hash);
+
+// Secure session
+import { randomBytes } from "crypto";
+const sessionToken = randomBytes(32).toString("hex");
+```
+
+---
+
+### 3. Sensitive Data Exposure
+
+**Checklist:**
+
+- [ ] HTTPS everywhere (no HTTP)
+- [ ] Sensitive data encrypted at rest
+- [ ] API keys in environment variables, never in code
+- [ ] Passwords never logged
+- [ ] PII masked in logs
+
+```typescript
+// Never log sensitive data
+console.log(`User login: ${email}`); // ❌
+console.log(`User login: ${maskEmail(email)}`); // ✅
+
+// Environment variables
+const apiKey = process.env.STRIPE_SECRET_KEY; // ✅
+const apiKey = "sk_live_abc123"; // ❌ NEVER
+```
+
+---
+
+### 4. Cross-Site Scripting (XSS)
+
+**❌ Vulnerable:**
+
+```typescript
+// React dangerouslySetInnerHTML
+<div dangerouslySetInnerHTML={{ __html: userContent }} />;
+
+// Direct DOM manipulation
+document.getElementById("output").innerHTML = userInput;
+```
+
+**✅ Secure:**
+
+```typescript
+// React auto-escapes
+<div>{userContent}</div>;
+
+// Sanitize HTML if needed
+import DOMPurify from "dompurify";
+<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userContent) }} />;
+
+// CSP Headers
+res.setHeader("Content-Security-Policy", "default-src 'self'");
+```
+
+---
+
+### 5. Cross-Site Request Forgery (CSRF)
+
+**Protection:**
+
+```typescript
+// 1. CSRF Token (forms)
+<input type="hidden" name="_csrf" value={csrfToken} />;
+
+// 2. SameSite cookies
+res.cookie("session", token, {
+  httpOnly: true,
+  secure: true,
+  sameSite: "lax", // or 'strict' for sensitive
+});
+
+// 3. Verify origin header
+const origin = req.headers.origin;
+if (!allowedOrigins.includes(origin)) {
+  return res.status(403).json({ error: "Forbidden" });
+}
+```
+
+---
+
+### 6. Security Misconfiguration
+
+**Checklist:**
+
+- [ ] Debug mode OFF in production
+- [ ] Default credentials changed
+- [ ] Unnecessary features disabled
+- [ ] Error messages don't leak stack traces
+- [ ] Security headers configured
+
+```typescript
+// Security headers (Helmet.js)
+import helmet from "helmet";
+app.use(helmet());
+
+// Custom error handler
+app.use((err, req, res, next) => {
+  console.error(err); // Log full error
+  res.status(500).json({
+    error: "Internal Server Error", // Generic message to user
+  });
+});
+```
+
+---
+
+## 🛡️ API Security
+
+### Rate Limiting
+
+```typescript
+import rateLimit from "express-rate-limit";
+
+const limiter = rateLimit({
+  windowMs: 15 * 60 * 1000, // 15 minutes
+  max: 100, // 100 requests per window
+  message: "Too many requests",
+});
+
+app.use("/api/", limiter);
+
+// Stricter for auth endpoints
+const authLimiter = rateLimit({
+  windowMs: 60 * 1000,
+  max: 5,
+});
+app.use("/api/auth/", authLimiter);
+```
+
+---
+
+### Input Validation
+
+```typescript
+import { z } from "zod";
+
+const UserSchema = z.object({
+  email: z.string().email(),
+  password: z.string().min(8).max(128),
+  age: z.number().int().min(13).max(120).optional(),
+});
+
+// Validate
+const result = UserSchema.safeParse(req.body);
+if (!result.success) {
+  return res.status(400).json({ errors: result.error.issues });
+}
+```
+
+---
+
+### Authorization
+
+```typescript
+// Role-based access
+const requireRole = (roles: string[]) => {
+  return (req, res, next) => {
+    if (!roles.includes(req.user.role)) {
+      return res.status(403).json({ error: "Forbidden" });
+    }
+    next();
+  };
+};
+
+app.delete("/api/users/:id", requireRole(["admin"]), deleteUser);
+
+// Resource ownership
+app.put("/api/posts/:id", async (req, res) => {
+  const post = await prisma.post.findUnique({ where: { id: req.params.id } });
+  if (post.authorId !== req.user.id && req.user.role !== "admin") {
+    return res.status(403).json({ error: "Forbidden" });
+  }
+  // proceed with update
+});
+```
+
+---
+
+## 🔑 Secrets Management
+
+```typescript
+// ✅ Environment variables
+DATABASE_URL=postgresql://...
+STRIPE_SECRET_KEY=sk_live_...
+
+// ✅ .env files (gitignored)
+// .env.local, .env.production
+
+// ✅ Secret managers (production)
+// AWS Secrets Manager, HashiCorp Vault, Doppler
+
+// ❌ NEVER commit secrets
+// ❌ NEVER log secrets
+// ❌ NEVER hardcode in source
+```
+
+---
+
+## 📋 Quick Security Checklist
+
+Before any implementation:
+
+- [ ] All inputs validated and sanitized
+- [ ] Authentication on protected routes
+- [ ] Authorization checks (ownership, roles)
+- [ ] No SQL/command injection
+- [ ] XSS prevention (escape output)
+- [ ] CSRF tokens for forms
+- [ ] Rate limiting on sensitive endpoints
+- [ ] Secrets in env vars, not code
+- [ ] HTTPS enforced
+- [ ] Security headers configured

package/.antigravity/skills/software-architecture/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: software-architecture
+description: Clean Architecture, SOLID principles, and design patterns for building maintainable software. Use when designing system architecture, refactoring codebases, conducting code reviews, or implementing complex features that require architectural decisions.
+---
+
+# Software Architecture
+
+Comprehensive guide to software architecture principles, patterns, and best practices.
+
+## When to Use
+
+- Designing system architecture
+- Refactoring existing codebase
+- Code reviews focusing on architecture
+- Implementing complex features
+- Making architectural decisions
+- Solving scalability challenges
+
+## Core Principles
+
+### SOLID Principles
+
+See [references/solid-principles.md](references/solid-principles.md) for detailed explanations and examples.
+
+**Quick Reference:**
+
+- **S**ingle Responsibility - One class, one reason to change
+- **O**pen/Closed - Open for extension, closed for modification
+- **L**iskov Substitution - Subclasses should be substitutable
+- **I**nterface Segregation - Many specific interfaces over one general
+- **D**ependency Inversion - Depend on abstractions, not concretions
+
+### Clean Architecture
+
+See [references/clean-architecture.md](references/clean-architecture.md) for layer-by-layer guide.
+
+**Layers (outer to inner):**
+
+1. Frameworks & Drivers (UI, DB, External APIs)
+2. Interface Adapters (Controllers, Presenters, Gateways)
+3. Application Business Rules (Use Cases)
+4. Enterprise Business Rules (Entities)
+
+**Rule:** Dependencies point inward only
+
+## Common Design Patterns
+
+See [references/design-patterns.md](references/design-patterns.md) for full catalog.
+
+### Creational Patterns
+
+- Factory Pattern - Object creation
+- Builder Pattern - Complex object construction
+- Singleton Pattern - Single instance
+
+### Structural Patterns
+
+- Adapter Pattern - Interface compatibility
+- Decorator Pattern - Add behavior dynamically
+- Repository Pattern - Data access abstraction
+
+### Behavioral Patterns
+
+- Strategy Pattern - Interchangeable algorithms
+- Observer Pattern - Event notification
+- Command Pattern - Encapsulate requests
+
+## Architecture Best Practices
+
+1. **Separation of Concerns** - Each module has distinct responsibility
+2. **Dependency Injection** - Inject dependencies, don't create them
+3. **Interface Programming** - Code to interfaces, not implementations
+4. **Single Source of Truth** - One canonical source for each data type
+5. **Test-Driven Design** - Design for testability from the start
+6. **Incremental Refactoring** - Improve architecture continuously
+
+## Code Organization
+
+```
+src/
+├── domain/           # Business logic (entities, use cases)
+├── infrastructure/   # External concerns (DB, API clients)
+├── application/      # Application services
+└── presentation/     # UI, controllers, views
+```
+
+## References
+
+- [SOLID Principles](references/solid-principles.md) - Detailed examples
+- [Clean Architecture](references/clean-architecture.md) - Layer guide
+- [Design Patterns](references/design-patterns.md) - Pattern catalog