@vodailoc/kilo-kit-mcp 1.1.0

package/skills/engineering/render-deploy/references/service-types.md

@@ -0,0 +1,450 @@
+# Render Service Types
+
+Detailed explanation of each service type available on Render. Choose the right service type based on your application's needs.
+
+## Web Services (`type: web`)
+
+### Purpose
+
+Web services are HTTP servers that handle incoming requests from the internet. They're publicly accessible via HTTPS URLs.
+
+### Use Cases
+
+- **REST APIs**: JSON APIs for mobile apps or frontend applications
+- **GraphQL servers**: GraphQL endpoints for client queries
+- **Web applications**: Server-rendered websites (Django, Rails, Express)
+- **Full-stack frameworks**: Next.js, Nuxt.js, Remix, SvelteKit
+- **WebSocket servers**: Real-time communication servers
+- **SSR applications**: Server-side rendered React, Vue, or Angular apps
+
+### Key Characteristics
+
+- **Public URL**: Automatically assigned `https://[service-name].onrender.com`
+- **Port binding required**: Must bind to `0.0.0.0:$PORT`
+- **Health checks**: Render pings your service to verify it's running
+- **HTTPS**: Automatic SSL/TLS certificates
+- **Load balancing**: Traffic distributed across multiple instances
+- **Custom domains**: Support for your own domain names
+
+### Required Configuration
+
+```yaml
+type: web
+name: my-api
+runtime: node
+buildCommand: npm ci
+startCommand: npm start
+```
+
+### Best Practices
+
+1. **Bind to environment PORT**:
+```javascript
+const PORT = process.env.PORT || 3000;
+app.listen(PORT, '0.0.0.0');
+```
+
+2. **Add health check endpoint**:
+```javascript
+app.get('/health', (req, res) => {
+  res.status(200).json({ status: 'ok' });
+});
+```
+
+3. **Use appropriate timeouts**: Web requests should complete within 30 seconds
+
+4. **Implement graceful shutdown**: Handle SIGTERM signals properly
+
+---
+
+## Worker Services (`type: worker`)
+
+### Purpose
+
+Worker services run background tasks without handling HTTP requests. They're not publicly accessible.
+
+### Use Cases
+
+- **Queue processors**: Redis queue, BullMQ, Celery, Sidekiq
+- **Background jobs**: Email sending, image processing, data exports
+- **Event consumers**: Message queue consumers (Kafka, RabbitMQ, etc.)
+- **Data pipeline workers**: ETL processes, data transformation
+- **Scheduled background tasks**: Continuous processes (not cron)
+- **WebSocket backend**: Dedicated WebSocket handler services
+
+### Key Characteristics
+
+- **No public URL**: Not accessible from internet
+- **No port binding**: Doesn't need to listen on a port
+- **No health checks**: Render monitors process health differently
+- **Long-running**: Can run indefinitely
+- **Private communication**: Access via internal networking
+- **Restart on crash**: Automatically restarted if process dies
+
+### Required Configuration
+
+```yaml
+type: worker
+name: queue-processor
+runtime: python
+buildCommand: pip install -r requirements.txt
+startCommand: celery -A tasks worker --loglevel=info
+```
+
+### Best Practices
+
+1. **Connect to message queue**:
+```python
+import redis
+r = redis.from_url(os.environ['REDIS_URL'])
+```
+
+2. **Implement retry logic**: Handle failures gracefully
+
+3. **Monitor queue depth**: Track pending jobs
+
+4. **Log processing status**: Make debugging easier
+
+5. **Graceful shutdown**: Finish current jobs before exiting
+
+### Common Patterns
+
+**Node.js with BullMQ:**
+```yaml
+type: worker
+name: job-processor
+runtime: node
+buildCommand: npm ci
+startCommand: node worker.js
+envVars:
+  - key: REDIS_URL
+    fromDatabase:
+      name: redis
+      property: connectionString
+```
+
+**Python with Celery:**
+```yaml
+type: worker
+name: celery-worker
+runtime: python
+buildCommand: pip install -r requirements.txt
+startCommand: celery -A app.celery worker
+envVars:
+  - key: REDIS_URL
+    fromDatabase:
+      name: redis
+      property: connectionString
+```
+
+---
+
+## Cron Jobs (`type: cron`)
+
+### Purpose
+
+Cron jobs run scheduled tasks on a repeating schedule. They execute, complete, and shut down.
+
+### Use Cases
+
+- **Database backups**: Regular automated backups
+- **Report generation**: Daily/weekly reports
+- **Data cleanup**: Delete old records periodically
+- **Cache warming**: Pre-populate caches
+- **Email digests**: Send scheduled email summaries
+- **Data synchronization**: Sync between systems
+- **Batch processing**: Process accumulated data
+
+### Key Characteristics
+
+- **Scheduled execution**: Runs on cron schedule
+- **Automatic shutdown**: Shuts down after completing
+- **No persistent port**: Doesn't maintain listening port
+- **No health checks**: Task either completes or fails
+- **UTC timezone**: All schedules in UTC
+- **Maximum runtime**: Jobs timeout after configured limit
+
+### Required Configuration
+
+```yaml
+type: cron
+name: daily-backup
+runtime: node
+schedule: "0 2 * * *"  # Daily at 2 AM UTC
+buildCommand: npm ci
+startCommand: node scripts/backup.js
+```
+
+### Schedule Format
+
+Standard cron syntax: `minute hour day month weekday`
+
+**Common schedules:**
+
+| Schedule | Description |
+|----------|-------------|
+| `*/5 * * * *` | Every 5 minutes |
+| `0 * * * *` | Every hour |
+| `0 0 * * *` | Daily at midnight UTC |
+| `0 9 * * 1-5` | Weekdays at 9 AM UTC |
+| `0 0 1 * *` | First day of each month |
+| `0 9 * * 1` | Every Monday at 9 AM UTC |
+
+### Best Practices
+
+1. **Handle failures gracefully**: Jobs should be idempotent
+
+2. **Log completion status**: Track success/failure
+
+3. **Set appropriate timeouts**: Match expected job duration
+
+4. **Use UTC times**: All schedules are UTC-based
+
+5. **Test thoroughly**: Test with different data scenarios
+
+### Example Use Cases
+
+**Daily Database Backup:**
+```yaml
+type: cron
+name: db-backup
+runtime: python
+schedule: "0 1 * * *"  # 1 AM UTC daily
+buildCommand: pip install -r requirements.txt
+startCommand: python scripts/backup.py
+envVars:
+  - key: DATABASE_URL
+    fromDatabase:
+      name: postgres
+      property: connectionString
+  - key: S3_BUCKET
+    value: my-backups
+```
+
+**Hourly Cache Refresh:**
+```yaml
+type: cron
+name: cache-refresh
+runtime: node
+schedule: "0 * * * *"  # Top of every hour
+buildCommand: npm ci
+startCommand: node scripts/refresh-cache.js
+```
+
+---
+
+## Static Sites (`type: web` + `runtime: static`)
+
+### Purpose
+
+Serve static HTML, CSS, and JavaScript files via CDN. No backend runtime.
+
+### Use Cases
+
+- **Single Page Applications (SPAs)**: React, Vue, Angular apps
+- **Static site generators**: Gatsby, Next.js (static export), Hugo
+- **Documentation sites**: MkDocs, Docusaurus, VitePress
+- **Landing pages**: Marketing sites
+- **Portfolio sites**: Personal websites
+- **JAMstack sites**: Static sites with API integration
+
+### Key Characteristics
+
+- **CDN delivery**: Global edge caching
+- **No backend runtime**: Only serves built files
+- **Build output only**: Serves contents of build directory
+- **Routing support**: Rewrite rules for SPA routing
+- **Custom headers**: Cache control, security headers
+- **Fast deployment**: Quick to build and deploy
+
+### Required Configuration
+
+```yaml
+type: web
+name: frontend
+runtime: static
+buildCommand: npm ci && npm run build
+staticPublishPath: ./dist  # or ./build, ./out, ./public
+```
+
+### Routing for SPAs
+
+Single Page Applications need rewrite rules to handle client-side routing:
+
+```yaml
+type: web
+name: react-app
+runtime: static
+buildCommand: npm ci && npm run build
+staticPublishPath: ./build
+routes:
+  - type: rewrite
+    source: /*
+    destination: /index.html
+```
+
+### Custom Headers
+
+Add cache control and security headers:
+
+```yaml
+type: web
+name: static-site
+runtime: static
+buildCommand: npm ci && npm run build
+staticPublishPath: ./dist
+headers:
+  # Cache static assets
+  - path: /static/*
+    name: Cache-Control
+    value: public, max-age=31536000, immutable
+
+  # Security headers
+  - path: /*
+    name: X-Frame-Options
+    value: DENY
+  - path: /*
+    name: X-Content-Type-Options
+    value: nosniff
+```
+
+### Build Filters
+
+For monorepos, only build when frontend files change:
+
+```yaml
+type: web
+name: frontend
+runtime: static
+buildCommand: npm ci && npm run build
+staticPublishPath: ./dist
+buildFilter:
+  paths:
+    - frontend/**
+  ignoredPaths:
+    - frontend/**/*.test.js
+    - frontend/README.md
+```
+
+### Best Practices
+
+1. **Optimize build output**: Minify, compress, tree-shake
+
+2. **Use proper cache headers**: Long cache for hashed assets
+
+3. **Add security headers**: Protect against common attacks
+
+4. **Configure SPA routing**: Add rewrite rules for client routing
+
+5. **Handle 404s**: Create custom 404.html page
+
+---
+
+## Private Services (`type: pserv`)
+
+### Purpose
+
+Internal services accessible only within your Render account. Not exposed to the internet.
+
+### Use Cases
+
+- **Internal APIs**: Services accessed only by other services
+- **Database proxies**: Connection pools, read replicas
+- **Microservices**: Service mesh architectures
+- **Admin tools**: Internal dashboards
+- **Cache layers**: Internal caching services
+- **Message brokers**: Internal message queues
+
+### Key Characteristics
+
+- **No public URL**: Only accessible via internal DNS
+- **Internal networking**: Fast, low-latency connections
+- **Port binding required**: Must bind to `0.0.0.0:$PORT`
+- **Private DNS**: `[service-name].render-internal.com`
+- **Same-account only**: Only accessible from same account
+- **No internet access**: Traffic stays within Render network
+
+### Required Configuration
+
+```yaml
+type: pserv
+name: internal-api
+runtime: node
+buildCommand: npm ci
+startCommand: npm start
+```
+
+### Accessing Private Services
+
+From other services in the same account:
+
+```javascript
+// Use .render-internal.com domain
+const API_URL = 'http://internal-api.render-internal.com:10000';
+```
+
+Or use service references:
+
+```yaml
+services:
+  - type: web
+    name: frontend
+    runtime: node
+    envVars:
+      - key: INTERNAL_API_URL
+        fromService:
+          name: internal-api
+          type: pserv
+          property: hostport
+```
+
+### Best Practices
+
+1. **Use internal DNS**: Always use `.render-internal.com` domains
+
+2. **No authentication needed**: Already isolated to account
+
+3. **Fast communication**: Low latency between services
+
+4. **Simplify architecture**: No need for external load balancers
+
+---
+
+## Comparison Table
+
+| Feature | Web | Worker | Cron | Static | Private |
+|---------|-----|--------|------|--------|---------|
+| Public URL | ✅ Yes | ❌ No | ❌ No | ✅ Yes | ❌ No |
+| Port Binding | ✅ Required | ❌ Not needed | ❌ Not needed | ❌ N/A | ✅ Required |
+| Health Checks | ✅ Yes | ❌ No | ❌ No | ❌ N/A | ✅ Yes |
+| Runtime | ✅ Yes | ✅ Yes | ✅ Yes | ❌ No | ✅ Yes |
+| Persistent | ✅ Yes | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes |
+| Scaling | ✅ Yes | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes |
+| Use Case | HTTP servers | Background jobs | Scheduled tasks | Static files | Internal services |
+
+## Choosing the Right Service Type
+
+**Use Web Service when:**
+- Your app handles HTTP requests
+- Users need to access it via URL
+- You need load balancing and scaling
+
+**Use Worker Service when:**
+- Processing background jobs
+- Consuming from message queues
+- Running long-lived processes without HTTP
+
+**Use Cron Job when:**
+- Running scheduled tasks
+- Processing doesn't need to be always-on
+- Tasks run periodically (hourly, daily, weekly)
+
+**Use Static Site when:**
+- Serving pre-built HTML/CSS/JS
+- No backend processing needed
+- Want CDN caching and fast delivery
+
+**Use Private Service when:**
+- Service only accessed by other services
+- Want internal-only communication
+- Building microservice architectures

package/skills/engineering/render-deploy/references/troubleshooting-basics.md

@@ -0,0 +1,36 @@
+# Basic troubleshooting (deploy-time and startup)
+
+Use this when a deploy fails, the service crashes on start, or health checks time out.
+Keep fixes minimal and redeploy after each change.
+
+## 1) Classify the failure
+
+- **Build failure**: errors in build logs, missing dependencies, build command issues.
+- **Startup failure**: app exits quickly, crashes, or cannot bind to `$PORT`.
+- **Runtime/health failure**: service is live but health checks fail or 5xx errors.
+
+## 2) Quick checks by class
+
+**Build failure**
+- Confirm the build command is correct for the runtime.
+- Ensure required dependencies are present in `package.json`, `requirements.txt`, etc.
+- Check for missing build-time env vars.
+
+**Startup failure**
+- Confirm the start command and working directory.
+- Ensure port binding is `0.0.0.0:$PORT`.
+- Check for missing runtime env vars (secrets, DB URLs).
+
+**Runtime/health failure**
+- Verify the health endpoint path and response.
+- Confirm the app is actually listening on `$PORT`.
+- Check database connectivity and migrations.
+
+## 3) Map error signatures to fixes
+
+Use [error-patterns.md](error-patterns.md) for a compact catalog of common log messages.
+
+## 4) If still blocked
+
+Gather the latest build logs and runtime error logs, then consider the optional
+`render-debug` skill for deeper diagnostics (metrics, DB checks, expanded patterns).

package/skills/engineering/repomix/SKILL.md

@@ -0,0 +1,215 @@
+---
+name: repomix
+description: Package entire code repositories into single AI-friendly files using Repomix. Capabilities include pack codebases with customizable include/exclude patterns, generate multiple output formats (XML, Markdown, plain text), preserve file structure and context, optimize for AI consumption with token counting, filter by file types and directories, add custom headers and summaries. Use when packaging codebases for AI analysis, creating repository snapshots for LLM context, analyzing third-party libraries, preparing for security audits, generating documentation context, or evaluating unfamiliar codebases.
+---
+
+# Repomix Skill
+
+Repomix packs entire repositories into single, AI-friendly files. Perfect for feeding codebases to LLMs like Claude, ChatGPT, and Gemini.
+
+## When to Use
+
+Use when:
+- Packaging codebases for AI analysis
+- Creating repository snapshots for LLM context
+- Analyzing third-party libraries
+- Preparing for security audits
+- Generating documentation context
+- Investigating bugs across large codebases
+- Creating AI-friendly code representations
+
+## Quick Start
+
+### Check Installation
+```bash
+repomix --version
+```
+
+### Install
+```bash
+# npm
+npm install -g repomix
+
+# Homebrew (macOS/Linux)
+brew install repomix
+```
+
+### Basic Usage
+```bash
+# Package current directory (generates repomix-output.xml)
+repomix
+
+# Specify output format
+repomix --style markdown
+repomix --style json
+
+# Package remote repository
+npx repomix --remote owner/repo
+
+# Custom output with filters
+repomix --include "src/**/*.ts" --remove-comments -o output.md
+```
+
+## Core Capabilities
+
+### Repository Packaging
+- AI-optimized formatting with clear separators
+- Multiple output formats: XML, Markdown, JSON, Plain text
+- Git-aware processing (respects .gitignore)
+- Token counting for LLM context management
+- Security checks for sensitive information
+
+### Remote Repository Support
+Process remote repositories without cloning:
+```bash
+# Shorthand
+npx repomix --remote yamadashy/repomix
+
+# Full URL
+npx repomix --remote https://github.com/owner/repo
+
+# Specific commit
+npx repomix --remote https://github.com/owner/repo/commit/hash
+```
+
+### Comment Removal
+Strip comments from supported languages (HTML, CSS, JavaScript, TypeScript, Vue, Svelte, Python, PHP, Ruby, C, C#, Java, Go, Rust, Swift, Kotlin, Dart, Shell, YAML):
+```bash
+repomix --remove-comments
+```
+
+## Common Use Cases
+
+### Code Review Preparation
+```bash
+# Package feature branch for AI review
+repomix --include "src/**/*.ts" --remove-comments -o review.md --style markdown
+```
+
+### Security Audit
+```bash
+# Package third-party library
+npx repomix --remote vendor/library --style xml -o audit.xml
+```
+
+### Documentation Generation
+```bash
+# Package with docs and code
+repomix --include "src/**,docs/**,*.md" --style markdown -o context.md
+```
+
+### Bug Investigation
+```bash
+# Package specific modules
+repomix --include "src/auth/**,src/api/**" -o debug-context.xml
+```
+
+### Implementation Planning
+```bash
+# Full codebase context
+repomix --remove-comments --copy
+```
+
+## Command Line Reference
+
+### File Selection
+```bash
+# Include specific patterns
+repomix --include "src/**/*.ts,*.md"
+
+# Ignore additional patterns
+repomix -i "tests/**,*.test.js"
+
+# Disable .gitignore rules
+repomix --no-gitignore
+```
+
+### Output Options
+```bash
+# Output format
+repomix --style markdown  # or xml, json, plain
+
+# Output file path
+repomix -o output.md
+
+# Remove comments
+repomix --remove-comments
+
+# Copy to clipboard
+repomix --copy
+```
+
+### Configuration
+```bash
+# Use custom config file
+repomix -c custom-config.json
+
+# Initialize new config
+repomix --init  # creates repomix.config.json
+```
+
+## Token Management
+
+Repomix automatically counts tokens for individual files, total repository, and per-format output.
+
+Typical LLM context limits:
+- Claude Sonnet 4.5: ~200K tokens
+- GPT-4: ~128K tokens
+- GPT-3.5: ~16K tokens
+
+## Security Considerations
+
+Repomix uses Secretlint to detect sensitive data (API keys, passwords, credentials, private keys, AWS secrets).
+
+Best practices:
+1. Always review output before sharing
+2. Use `.repomixignore` for sensitive files
+3. Enable security checks for unknown codebases
+4. Avoid packaging `.env` files
+5. Check for hardcoded credentials
+
+Disable security checks if needed:
+```bash
+repomix --no-security-check
+```
+
+## Implementation Workflow
+
+When user requests repository packaging:
+
+1. **Assess Requirements**
+   - Identify target repository (local/remote)
+   - Determine output format needed
+   - Check for sensitive data concerns
+
+2. **Configure Filters**
+   - Set include patterns for relevant files
+   - Add ignore patterns for unnecessary files
+   - Enable/disable comment removal
+
+3. **Execute Packaging**
+   - Run repomix with appropriate options
+   - Monitor token counts
+   - Verify security checks
+
+4. **Validate Output**
+   - Review generated file
+   - Confirm no sensitive data
+   - Check token limits for target LLM
+
+5. **Deliver Context**
+   - Provide packaged file to user
+   - Include token count summary
+   - Note any warnings or issues
+
+## Reference Documentation
+
+For detailed information, see:
+- [Configuration Reference](./references/configuration.md) - Config files, include/exclude patterns, output formats, advanced options
+- [Usage Patterns](./references/usage-patterns.md) - AI analysis workflows, security audit preparation, documentation generation, library evaluation
+
+## Additional Resources
+
+- GitHub: https://github.com/yamadashy/repomix
+- Documentation: https://repomix.com/guide/
+- MCP Server: Available for AI assistant integration