blockmine 1.24.0 → 1.25.0

package/.claude/skills/api-engineering/SKILL.md

@@ -1,63 +0,0 @@
-# API Engineering
-
-Guide to API design patterns, GraphQL, gRPC, API gateways, rate limiting, and versioning strategies.
-
-**Note:** This is a foundational version. Community contributions welcome to expand coverage!
-
-## Purpose
-
-Enable teams to design, build, and maintain robust, scalable APIs.
-
-## When to Use This Skill
-
-Automatically activates when working on:
-- REST API design and best practices
-- GraphQL schema design
-- gRPC service definition
-- API gateway configuration (Kong, Ambassador)
-- API versioning strategies
-- Rate limiting and throttling
-- API security (OAuth2, JWT)
-
-## Quick Start Checklist
-
-- [ ] Define clear API contract (OpenAPI/GraphQL schema)
-- [ ] Implement authentication/authorization
-- [ ] Add rate limiting
-- [ ] Version your API
-- [ ] Document endpoints
-- [ ] Implement error handling
-- [ ] Add request validation
-
-## Resource Files
-
-- **[rest-api-design.md](resources/rest-api-design.md)** - RESTful principles, resource modeling, HTTP methods
-- **[graphql-patterns.md](resources/graphql-patterns.md)** - Schema design, resolvers, N+1 problem, DataLoader
-- **[api-versioning.md](resources/api-versioning.md)** - URI versioning, header versioning, strategies
-- **[rate-limiting.md](resources/rate-limiting.md)** - Token bucket, sliding window, distributed rate limiting
-
-## Best Practices
-
-✅ Follow RESTful principles
-✅ Use proper HTTP status codes
-✅ Version your API from day one
-✅ Implement rate limiting
-✅ Validate input thoroughly
-✅ Document with OpenAPI/GraphQL introspection
-✅ Use API gateways for centralized concerns
-
-## Integration Points
-
-- **backend-dev-guidelines**: API implementation
-- **documentation-as-code**: API documentation
-- **devsecops**: API security
-- **cloud-engineering**: API Gateway services
-
----
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🎯 SKILL ACTIVATED: api-engineering
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-
-**Total Resources:** 4 foundational guides (community can expand!)
-**Status:** Basic coverage - contributions welcome

package/.claude/skills/api-engineering/resources/api-versioning.md

@@ -1,88 +0,0 @@
-# API Versioning
-
-Guide to API versioning strategies and best practices.
-
-## Versioning Strategies
-
-### URI Versioning
-```
-GET /v1/users/123
-GET /v2/users/123
-
-Pros: Simple, clear
-Cons: Pollutes URI space
-```
-
-### Header Versioning
-```
-GET /users/123
-Accept: application/vnd.myapi.v1+json
-
-Pros: Clean URIs
-Cons: Less visible, harder to test
-```
-
-### Query Parameter
-```
-GET /users/123?version=1
-GET /users/123?version=2
-
-Pros: Simple
-Cons: Easy to forget, not RESTful
-```
-
-## Semantic Versioning
-
-```
-MAJOR.MINOR.PATCH
-
-v1.0.0 → v1.1.0: New feature (backward-compatible)
-v1.1.0 → v2.0.0: Breaking change
-v2.0.0 → v2.0.1: Bug fix
-```
-
-## Breaking vs Non-Breaking Changes
-
-```
-Breaking Changes (require new version):
-- Removing endpoint
-- Removing field
-- Changing field type
-- Changing response structure
-- Renaming field
-
-Non-Breaking (can be same version):
-- Adding new endpoint
-- Adding new optional field
-- Adding new query parameter
-- Deprecating (but not removing) field
-```
-
-## Deprecation Strategy
-
-```typescript
-// Mark deprecated fields
-type User {
-  id: ID!
-  fullName: String!
-  name: String! @deprecated(reason: "Use fullName instead")
-}
-
-// Add deprecation headers
-res.setHeader('Deprecation', 'Sun, 01 Jan 2025 00:00:00 GMT');
-res.setHeader('Link', '</v2/users>; rel="successor-version"');
-```
-
-## Best Practices
-
-✅ Version from day one (v1)
-✅ Support 2-3 versions simultaneously
-✅ Give 6-12 months deprecation notice
-✅ Document breaking changes clearly
-✅ Use semantic versioning
-✅ Provide migration guides
-
----
-
-**Related Resources:**
-- rest-api-design.md - API design principles

package/.claude/skills/api-engineering/resources/graphql-patterns.md

@@ -1,106 +0,0 @@
-# GraphQL Patterns
-
-Guide to GraphQL schema design, resolvers, and common patterns.
-
-## Schema Design
-
-```graphql
-type User {
-  id: ID!
-  email: String!
-  name: String!
-  posts: [Post!]!
-}
-
-type Post {
-  id: ID!
-  title: String!
-  content: String!
-  author: User!
-}
-
-type Query {
-  user(id: ID!): User
-  users(limit: Int, offset: Int): [User!]!
-}
-
-type Mutation {
-  createUser(email: String!, name: String!): User!
-  updateUser(id: ID!, name: String): User!
-}
-```
-
-## Resolvers
-
-```typescript
-const resolvers = {
-  Query: {
-    user: async (parent, { id }, context) => {
-      return await context.prisma.user.findUnique({ where: { id } });
-    },
-    users: async (parent, { limit, offset }, context) => {
-      return await context.prisma.user.findMany({
-        take: limit,
-        skip: offset,
-      });
-    },
-  },
-
-  Mutation: {
-    createUser: async (parent, { email, name }, context) => {
-      return await context.prisma.user.create({
-        data: { email, name },
-      });
-    },
-  },
-
-  User: {
-    posts: async (parent, args, context) => {
-      return await context.prisma.post.findMany({
-        where: { authorId: parent.id },
-      });
-    },
-  },
-};
-```
-
-## N+1 Problem & DataLoader
-
-```typescript
-// ❌ N+1 Problem
-// Fetching 100 users causes 100 additional queries for posts
-const users = await prisma.user.findMany();  // 1 query
-for (const user of users) {
-  const posts = await prisma.post.findMany({ where: { authorId: user.id } });  // N queries
-}
-
-// ✅ Solution: DataLoader
-import DataLoader from 'dataloader';
-
-const postLoader = new DataLoader(async (userIds) => {
-  const posts = await prisma.post.findMany({
-    where: { authorId: { in: userIds } },
-  });
-
-  // Group posts by user ID
-  const postsByUser = {};
-  posts.forEach(post => {
-    if (!postsByUser[post.authorId]) postsByUser[post.authorId] = [];
-    postsByUser[post.authorId].push(post);
-  });
-
-  return userIds.map(id => postsByUser[id] || []);
-});
-
-// In resolver
-User: {
-  posts: (parent, args, context) => {
-    return context.postLoader.load(parent.id);  // Batched!
-  },
-}
-```
-
----
-
-**Related Resources:**
-- rest-api-design.md - REST comparison

package/.claude/skills/api-engineering/resources/rate-limiting.md

@@ -1,118 +0,0 @@
-# Rate Limiting
-
-Guide to implementing rate limiting and throttling for APIs.
-
-## Algorithms
-
-### Token Bucket
-```typescript
-class TokenBucket {
-  constructor(
-    private capacity: number,  // Max tokens
-    private refillRate: number  // Tokens per second
-  ) {}
-
-  async consume(tokens: number = 1): Promise<boolean> {
-    const key = `rate-limit:${userId}`;
-    const current = await redis.get(key) || this.capacity;
-
-    if (current >= tokens) {
-      await redis.decrby(key, tokens);
-      return true;  // Allowed
-    }
-    return false;  // Rate limited
-  }
-}
-
-// Usage: 100 requests per minute
-const limiter = new TokenBucket(100, 100/60);
-```
-
-### Sliding Window
-```typescript
-async function checkRateLimit(userId: string, limit: number, windowMs: number) {
-  const key = `rate-limit:${userId}`;
-  const now = Date.now();
-  const windowStart = now - windowMs;
-
-  // Remove old entries
-  await redis.zremrangebyscore(key, 0, windowStart);
-
-  // Count requests in window
-  const count = await redis.zcard(key);
-
-  if (count < limit) {
-    await redis.zadd(key, now, `${now}-${Math.random()}`);
-    await redis.expire(key, Math.ceil(windowMs / 1000));
-    return true;  // Allowed
-  }
-
-  return false;  // Rate limited
-}
-
-// Usage: 1000 requests per hour
-await checkRateLimit(userId, 1000, 3600000);
-```
-
-## Express Middleware
-
-```typescript
-import rateLimit from 'express-rate-limit';
-import RedisStore from 'rate-limit-redis';
-import Redis from 'ioredis';
-
-const redis = new Redis(process.env.REDIS_URL);
-
-const limiter = rateLimit({
-  store: new RedisStore({ client: redis }),
-  windowMs: 15 * 60 * 1000,  // 15 minutes
-  max: 100,  // 100 requests per window
-  message: 'Too many requests, please try again later',
-  standardHeaders: true,
-  legacyHeaders: false,
-});
-
-app.use('/api/', limiter);
-```
-
-## Response Headers
-
-```
-X-RateLimit-Limit: 100
-X-RateLimit-Remaining: 85
-X-RateLimit-Reset: 1642348800
-
-HTTP 429 Too Many Requests
-Retry-After: 60
-```
-
-## Per-User vs Per-IP
-
-```typescript
-// Per-user (authenticated)
-const userLimiter = rateLimit({
-  keyGenerator: (req) => req.user?.id || req.ip,
-  max: 1000,  // Higher limit for authenticated users
-});
-
-// Per-IP (unauthenticated)
-const ipLimiter = rateLimit({
-  keyGenerator: (req) => req.ip,
-  max: 100,  // Lower limit for anonymous users
-});
-```
-
-## Best Practices
-
-✅ Use distributed rate limiting (Redis)
-✅ Return clear error messages
-✅ Include rate limit headers
-✅ Different limits for authenticated vs anonymous
-✅ Higher limits for premium users
-✅ Monitor rate limit hits
-
----
-
-**Related Resources:**
-- rest-api-design.md - API design
-- api-versioning.md - API versions

package/.claude/skills/api-engineering/resources/rest-api-design.md

@@ -1,105 +0,0 @@
-# REST API Design
-
-Guide to designing RESTful APIs following best practices.
-
-## RESTful Principles
-
-```
-Resources (nouns, not verbs):
-✅ GET /users/123
-✅ POST /orders
-❌ GET /getUser/123
-❌ POST /createOrder
-
-HTTP Methods:
-GET    - Retrieve resource
-POST   - Create resource
-PUT    - Update entire resource
-PATCH  - Partial update
-DELETE - Remove resource
-```
-
-## Resource Modeling
-
-```
-Collection: /users
-Resource:   /users/123
-Sub-resource: /users/123/orders
-```
-
-## HTTP Status Codes
-
-```
-200 OK - Successful GET, PUT, PATCH
-201 Created - Successful POST
-204 No Content - Successful DELETE
-400 Bad Request - Invalid input
-401 Unauthorized - Missing/invalid auth
-403 Forbidden - Authenticated but not authorized
-404 Not Found - Resource doesn't exist
-409 Conflict - Resource conflict (e.g., duplicate email)
-422 Unprocessable Entity - Validation errors
-429 Too Many Requests - Rate limit exceeded
-500 Internal Server Error - Server error
-```
-
-## Request/Response Examples
-
-```typescript
-// POST /users (Create)
-Request:
-{
-  "email": "user@example.com",
-  "name": "John Doe"
-}
-
-Response (201 Created):
-{
-  "id": "usr_123",
-  "email": "user@example.com",
-  "name": "John Doe",
-  "created_at": "2024-01-15T10:30:00Z"
-}
-
-// GET /users?page=1&limit=20 (List with pagination)
-Response (200 OK):
-{
-  "data": [...],
-  "pagination": {
-    "page": 1,
-    "limit": 20,
-    "total": 150,
-    "pages": 8
-  }
-}
-
-// PATCH /users/123 (Partial update)
-Request:
-{
-  "name": "Jane Doe"
-}
-
-Response (200 OK):
-{
-  "id": "usr_123",
-  "email": "user@example.com",
-  "name": "Jane Doe",
-  "updated_at": "2024-01-15T11:00:00Z"
-}
-```
-
-## Best Practices
-
-✅ Use nouns for resources
-✅ Plural resource names (/users, not /user)
-✅ Use proper HTTP methods
-✅ Return appropriate status codes
-✅ Implement pagination
-✅ Use filtering (?status=active)
-✅ Consistent error format
-
----
-
-**Related Resources:**
-- api-versioning.md - API versioning
-- rate-limiting.md - Rate limiting