codehava-agent-kit 1.0.1 → 3.0.0

package/templates/.agent/skills/vercel-automation/SKILL.md

@@ -0,0 +1,230 @@
+---
+name: vercel-automation
+description: "Automate Vercel tasks via Rube MCP (Composio): manage deployments, domains, DNS, env vars, projects, and teams. Always search tools first for current schemas."
+risk: unknown
+source: community
+date_added: "2026-02-27"
+---
+
+# Vercel Automation via Rube MCP
+
+Automate Vercel platform operations through Composio's Vercel toolkit via Rube MCP.
+
+## Prerequisites
+
+- Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
+- Active Vercel connection via `RUBE_MANAGE_CONNECTIONS` with toolkit `vercel`
+- Always call `RUBE_SEARCH_TOOLS` first to get current tool schemas
+
+## Setup
+
+**Get Rube MCP**: Add `https://rube.app/mcp` as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.
+
+
+1. Verify Rube MCP is available by confirming `RUBE_SEARCH_TOOLS` responds
+2. Call `RUBE_MANAGE_CONNECTIONS` with toolkit `vercel`
+3. If connection is not ACTIVE, follow the returned auth link to complete Vercel OAuth
+4. Confirm connection status shows ACTIVE before running any workflows
+
+## Core Workflows
+
+### 1. Monitor and Inspect Deployments
+
+**When to use**: User wants to list, inspect, or debug deployments
+
+**Tool sequence**:
+1. `VERCEL_LIST_ALL_DEPLOYMENTS` or `VERCEL_GET_DEPLOYMENTS` - List deployments with filters [Required]
+2. `VERCEL_GET_DEPLOYMENT` or `VERCEL_GET_DEPLOYMENT_DETAILS` - Get specific deployment info [Optional]
+3. `VERCEL_GET_DEPLOYMENT_LOGS` or `VERCEL_GET_RUNTIME_LOGS` - View build/runtime logs [Optional]
+4. `VERCEL_GET_DEPLOYMENT_EVENTS` - Get deployment event timeline [Optional]
+5. `VERCEL_LIST_DEPLOYMENT_CHECKS` - View deployment check results [Optional]
+
+**Key parameters**:
+- `projectId`: Filter deployments by project
+- `state`: Filter by deployment state (e.g., 'READY', 'ERROR', 'BUILDING')
+- `limit`: Number of deployments to return
+- `target`: Filter by environment ('production', 'preview')
+- `deploymentId` or `idOrUrl`: Specific deployment identifier
+
+**Pitfalls**:
+- Deployment IDs and URLs are both accepted as identifiers in most endpoints
+- Build logs and runtime logs are separate; use the appropriate tool
+- `VERCEL_GET_DEPLOYMENT_LOGS` returns build logs; `VERCEL_GET_RUNTIME_LOGS` returns serverless function logs
+- Deployment events include status transitions and are useful for debugging timing issues
+
+### 2. Create and Manage Deployments
+
+**When to use**: User wants to trigger a new deployment
+
+**Tool sequence**:
+1. `VERCEL_LIST_PROJECTS` - Find the target project [Prerequisite]
+2. `VERCEL_CREATE_NEW_DEPLOYMENT` - Trigger a new deployment [Required]
+3. `VERCEL_GET_DEPLOYMENT` - Monitor deployment progress [Optional]
+
+**Key parameters**:
+- `name`: Project name for the deployment
+- `target`: Deployment target ('production' or 'preview')
+- `gitSource`: Git repository source with ref/branch info
+- `files`: Array of file objects for file-based deployments
+
+**Pitfalls**:
+- Either `gitSource` or `files` must be provided, not both
+- Git-based deployments require proper repository integration
+- Production deployments update the production domain alias automatically
+- Deployment creation is asynchronous; poll with GET_DEPLOYMENT for status
+
+### 3. Manage Environment Variables
+
+**When to use**: User wants to add, list, or remove environment variables for a project
+
+**Tool sequence**:
+1. `VERCEL_LIST_PROJECTS` - Find the project ID [Prerequisite]
+2. `VERCEL_LIST_ENV_VARIABLES` - List existing env vars [Required]
+3. `VERCEL_ADD_ENVIRONMENT_VARIABLE` - Add a new env var [Optional]
+4. `VERCEL_DELETE_ENVIRONMENT_VARIABLE` - Remove an env var [Optional]
+
+**Key parameters**:
+- `projectId`: Target project identifier
+- `key`: Environment variable name
+- `value`: Environment variable value
+- `target`: Array of environments ('production', 'preview', 'development')
+- `type`: Variable type ('plain', 'secret', 'encrypted', 'sensitive')
+
+**Pitfalls**:
+- Environment variable names must be unique per target environment
+- `type: 'secret'` variables cannot be read back after creation; only the ID is returned
+- Deleting an env var requires both `projectId` and the env var `id` (not the key name)
+- Changes require a new deployment to take effect
+
+### 4. Manage Domains and DNS
+
+**When to use**: User wants to configure custom domains or manage DNS records
+
+**Tool sequence**:
+1. `VERCEL_GET_DOMAIN` - Check domain status and configuration [Required]
+2. `VERCEL_GET_DOMAIN_CONFIG` - Get DNS/SSL configuration details [Optional]
+3. `VERCEL_LIST_PROJECT_DOMAINS` - List domains attached to a project [Optional]
+4. `VERCEL_GET_DNS_RECORDS` - List DNS records for a domain [Optional]
+5. `VERCEL_CREATE_DNS_RECORD` - Add a new DNS record [Optional]
+6. `VERCEL_UPDATE_DNS_RECORD` - Modify an existing DNS record [Optional]
+
+**Key parameters**:
+- `domain`: Domain name (e.g., 'example.com')
+- `name`: DNS record name/subdomain
+- `type`: DNS record type ('A', 'AAAA', 'CNAME', 'MX', 'TXT', 'SRV')
+- `value`: DNS record value
+- `ttl`: Time-to-live in seconds
+
+**Pitfalls**:
+- Domain must be added to the Vercel account before DNS management
+- SSL certificates are auto-provisioned but may take time for new domains
+- CNAME records at the apex domain are not supported; use A records instead
+- MX records require priority values
+
+### 5. Manage Projects
+
+**When to use**: User wants to list, inspect, or update project settings
+
+**Tool sequence**:
+1. `VERCEL_LIST_PROJECTS` - List all projects [Required]
+2. `VERCEL_GET_PROJECT` - Get detailed project information [Optional]
+3. `VERCEL_UPDATE_PROJECT` - Modify project settings [Optional]
+
+**Key parameters**:
+- `idOrName`: Project ID or name for lookup
+- `name`: Project name for updates
+- `framework`: Framework preset (e.g., 'nextjs', 'vite', 'remix')
+- `buildCommand`: Custom build command override
+- `rootDirectory`: Root directory if not repo root
+
+**Pitfalls**:
+- Project names are globally unique within a team/account
+- Changing framework settings affects subsequent deployments
+- `rootDirectory` is relative to the repository root
+
+### 6. Team Management
+
+**When to use**: User wants to view team info or list team members
+
+**Tool sequence**:
+1. `VERCEL_LIST_TEAMS` - List all teams the user belongs to [Required]
+2. `VERCEL_GET_TEAM` - Get detailed team information [Optional]
+3. `VERCEL_GET_TEAM_MEMBERS` - List members of a specific team [Optional]
+
+**Key parameters**:
+- `teamId`: Team identifier
+- `limit`: Number of results per page
+- `role`: Filter members by role
+
+**Pitfalls**:
+- Team operations require appropriate team-level permissions
+- Personal accounts have no teams; team endpoints return empty results
+- Member roles include 'OWNER', 'MEMBER', 'DEVELOPER', 'VIEWER'
+
+## Common Patterns
+
+### ID Resolution
+
+**Project name -> Project ID**:
+```
+1. Call VERCEL_LIST_PROJECTS
+2. Find project by name in response
+3. Extract id field for subsequent operations
+```
+
+**Domain -> DNS Records**:
+```
+1. Call VERCEL_GET_DNS_RECORDS with domain name
+2. Extract record IDs for update/delete operations
+```
+
+### Pagination
+
+- Use `limit` parameter to control page size
+- Check response for pagination tokens or `next` fields
+- Continue fetching until no more pages are indicated
+
+## Known Pitfalls
+
+**Deployment States**:
+- States include: INITIALIZING, ANALYZING, BUILDING, DEPLOYING, READY, ERROR, CANCELED, QUEUED
+- Only READY deployments are live and serving traffic
+- ERROR deployments should be inspected via logs for failure details
+
+**Environment Variables**:
+- Secret type vars are write-only; values cannot be retrieved after creation
+- Env vars are scoped to environments (production, preview, development)
+- A redeployment is needed for env var changes to take effect
+
+**Rate Limits**:
+- Vercel API has rate limits per endpoint
+- Implement backoff on 429 responses
+- Batch operations where possible to reduce API calls
+
+## Quick Reference
+
+| Task | Tool Slug | Key Params |
+|------|-----------|------------|
+| List projects | VERCEL_LIST_PROJECTS | limit |
+| Get project details | VERCEL_GET_PROJECT | idOrName |
+| Update project | VERCEL_UPDATE_PROJECT | idOrName, name, framework |
+| List deployments | VERCEL_LIST_ALL_DEPLOYMENTS | projectId, state, limit |
+| Get deployment | VERCEL_GET_DEPLOYMENT | idOrUrl |
+| Create deployment | VERCEL_CREATE_NEW_DEPLOYMENT | name, target, gitSource |
+| Deployment logs | VERCEL_GET_DEPLOYMENT_LOGS | deploymentId |
+| Runtime logs | VERCEL_GET_RUNTIME_LOGS | deploymentId |
+| List env vars | VERCEL_LIST_ENV_VARIABLES | projectId |
+| Add env var | VERCEL_ADD_ENVIRONMENT_VARIABLE | projectId, key, value, target |
+| Delete env var | VERCEL_DELETE_ENVIRONMENT_VARIABLE | projectId, id |
+| Get domain | VERCEL_GET_DOMAIN | domain |
+| Get domain config | VERCEL_GET_DOMAIN_CONFIG | domain |
+| List DNS records | VERCEL_GET_DNS_RECORDS | domain |
+| Create DNS record | VERCEL_CREATE_DNS_RECORD | domain, name, type, value |
+| Update DNS record | VERCEL_UPDATE_DNS_RECORD | domain, recordId |
+| List project domains | VERCEL_LIST_PROJECT_DOMAINS | projectId |
+| List teams | VERCEL_LIST_TEAMS | (none) |
+| Get team | VERCEL_GET_TEAM | teamId |
+| Get team members | VERCEL_GET_TEAM_MEMBERS | teamId, limit |
+
+## When to Use
+This skill is applicable to execute the workflow or actions described in the overview.

package/templates/.agent/skills/vercel-deployment/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: vercel-deployment
+description: "Expert knowledge for deploying to Vercel with Next.js Use when: vercel, deploy, deployment, hosting, production."
+risk: safe
+source: "vibeship-spawner-skills (Apache 2.0)"
+date_added: "2026-02-27"
+---
+
+# Vercel Deployment
+
+You are a Vercel deployment expert. You understand the platform's
+capabilities, limitations, and best practices for deploying Next.js
+applications at scale.
+
+## When to Use This Skill
+
+Use this skill when:
+- Deploying to Vercel
+- Working with Vercel deployment
+- Hosting applications on Vercel
+- Deploying to production on Vercel
+- Configuring Vercel for Next.js applications
+
+Your core principles:
+1. Environment variables - different for dev/preview/production
+2. Edge vs Serverless - choose the right runtime
+3. Build optimization - minimize cold starts and bundle size
+4. Preview deployments - use for testing before production
+5. Monitoring - set up analytics and error tracking
+
+## Capabilities
+
+- vercel
+- deployment
+- edge-functions
+- serverless
+- environment-variables
+
+## Requirements
+
+- nextjs-app-router
+
+## Patterns
+
+### Environment Variables Setup
+
+Properly configure environment variables for all environments
+
+### Edge vs Serverless Functions
+
+Choose the right runtime for your API routes
+
+### Build Optimization
+
+Optimize build for faster deployments and smaller bundles
+
+## Anti-Patterns
+
+### ❌ Secrets in NEXT_PUBLIC_
+
+### ❌ Same Database for Preview
+
+### ❌ No Build Cache
+
+## ⚠️ Sharp Edges
+
+| Issue | Severity | Solution |
+|-------|----------|----------|
+| NEXT_PUBLIC_ exposes secrets to the browser | critical | Only use NEXT_PUBLIC_ for truly public values: |
+| Preview deployments using production database | high | Set up separate databases for each environment: |
+| Serverless function too large, slow cold starts | high | Reduce function size: |
+| Edge runtime missing Node.js APIs | high | Check API compatibility before using edge: |
+| Function timeout causes incomplete operations | medium | Handle long operations properly: |
+| Environment variable missing at runtime but present at build | medium | Understand when env vars are read: |
+| CORS errors calling API routes from different domain | medium | Add CORS headers to API routes: |
+| Page shows stale data after deployment | medium | Control caching behavior: |
+
+## Related Skills
+
+Works well with: `nextjs-app-router`, `supabase-backend`

package/templates/.agent/skills/vibe-code-auditor/SKILL.md

@@ -0,0 +1,334 @@
+---
+name: vibe-code-auditor
+description: Audit rapidly generated or AI-produced code for structural flaws, fragility, and production risks.
+risk: safe
+source: original
+date_added: "2026-02-28"
+metadata:
+  version: 2.0.0
+---
+
+# Vibe Code Auditor
+
+## Identity
+
+You are a senior software architect specializing in evaluating prototype-quality and AI-generated code. Your role is to determine whether code that "works" is actually robust, maintainable, and production-ready.
+
+You do not rewrite code to demonstrate skill. You do not raise alarms over cosmetic issues. You identify real risks, explain why they matter, and recommend the minimum changes required to address them.
+
+## Purpose
+
+This skill analyzes code produced through rapid iteration, vibe coding, or AI assistance and surfaces hidden technical risks, architectural weaknesses, and maintainability problems that are invisible during casual review.
+
+## When to Use
+- Code was generated or heavily assisted by AI tools
+- The system evolved without a deliberate architecture
+- A prototype needs to be productionized
+- Code works but feels fragile or inconsistent
+- You suspect hidden technical debt
+- Preparing a project for long-term maintenance or team handoff
+
+---
+
+## Pre-Audit Checklist
+
+Before beginning the audit, confirm the following. If any item is missing, state what is absent and proceed with the available information — do not halt.
+
+- **Input received**: Source code or files are present in the conversation.
+- **Scope defined**: Identify whether the input is a snippet, single file, or multi-file system.
+- **Context noted**: If no context was provided, state the assumptions made (e.g., "Assuming a web API backend with no specified scale requirements").
+
+**Quick Scan (first 60 seconds):**
+- Count files and lines of code
+- Identify language(s) and framework(s)
+- Spot obvious red flags: hardcoded secrets, bare excepts, TODOs, commented-out code
+- Note the entry point(s) and data flow direction
+
+---
+
+## Audit Dimensions
+
+Evaluate the code across all seven dimensions below. For each finding, record: the dimension, a short title, the exact location (file and line number if available), the severity, a clear explanation, and a concrete recommendation.
+
+**Do not invent findings. Do not report issues you cannot substantiate from the code provided.**
+
+**Pattern Recognition Shortcuts:**
+Use these heuristics to accelerate detection:
+
+| Pattern | Likely Issue | Quick Check |
+|---------|-------------|-------------|
+| `eval()`, `exec()`, `os.system()` | Security critical | Search for these strings |
+| `except:` or `except Exception:` | Silent failures | Grep for bare excepts |
+| `password`, `secret`, `key`, `token` in code | Hardcoded credentials | Search + check if literal string |
+| `if DEBUG`, `debug=True` | Insecure defaults | Check config blocks |
+| Functions >50 lines | Maintainability risk | Count lines per function |
+| Nested `if` >3 levels | Complexity hotspot | Visual scan or cyclomatic check |
+| No tests in repo | Quality gap | Look for `test_` files |
+| Direct SQL string concat | SQL injection | Search for `f"SELECT` or `+ "SELECT` |
+| `requests.get` without timeout | Production risk | Check HTTP client calls |
+| `while True` without break | Unbounded loop | Search for infinite loops |
+
+### 1. Architecture & Design
+
+**Quick checks:**
+- Can you identify the entry point in 10 seconds?
+- Are there clear boundaries between layers (API, business logic, data)?
+- Does any single file exceed 300 lines?
+
+- Separation of concerns violations (e.g., business logic inside route handlers or UI components)
+- God objects or monolithic modules with more than one clear responsibility
+- Tight coupling between components with no abstraction boundary
+- Missing or blurred system boundaries (e.g., database queries scattered across layers)
+- Circular dependencies or import cycles
+- No clear data flow or state management strategy
+
+### 2. Consistency & Maintainability
+
+**Quick checks:**
+- Are similar operations named consistently? (search for `get`, `fetch`, `load` variations)
+- Do functions have single, clear purposes based on their names?
+- Is duplicated logic visible? (search for repeated code blocks)
+
+- Naming inconsistencies (e.g., `get_user` vs `fetchUser` vs `retrieveUserData` for the same operation)
+- Mixed paradigms without justification (e.g., OOP and procedural code interleaved arbitrarily)
+- Copy-paste logic that should be extracted into a shared function (3+ repetitions = extract)
+- Abstractions that obscure rather than clarify intent
+- Inconsistent error handling patterns across modules
+- Magic numbers or strings without constants or configuration
+
+### 3. Robustness & Error Handling
+
+**Quick checks:**
+- Does every external call (API, DB, file) have error handling?
+- Are there any bare `except:` blocks?
+- What happens if inputs are empty, null, or malformed?
+
+- Missing input validation on entry points (HTTP handlers, CLI args, file reads)
+- Bare `except` or catch-all error handlers that swallow failures silently
+- Unhandled edge cases (empty collections, null/None returns, zero values)
+- Code that assumes external services always succeed without fallback logic
+- No retry logic for transient failures (network, rate limits)
+- Missing timeouts on blocking operations (HTTP, DB, I/O)
+- No validation of data from external sources before use
+
+### 4. Production Risks
+
+**Quick checks:**
+- Search for hardcoded URLs, IPs, or paths
+- Check for logging statements (or lack thereof)
+- Look for database queries in loops
+
+- Hardcoded configuration values (URLs, credentials, timeouts, thresholds)
+- Missing structured logging or observability hooks
+- Unbounded loops, missing pagination, or N+1 query patterns
+- Blocking I/O in async contexts or thread-unsafe shared state
+- No graceful shutdown or cleanup on process exit
+- Missing health checks or readiness endpoints
+- No rate limiting or backpressure mechanisms
+- Synchronous operations in event-driven or async contexts
+
+### 5. Security & Safety
+
+**Quick checks:**
+- Search for: `eval`, `exec`, `os.system`, `subprocess`
+- Look for: `password`, `secret`, `api_key`, `token` as string literals
+- Check for: `SELECT * FROM` + string concatenation
+- Verify: input sanitization before DB, shell, or file operations
+
+- Unsanitized user input passed to databases, shells, file paths, or `eval`
+- Credentials, API keys, or tokens present in source code or logs
+- Insecure defaults (e.g., `DEBUG=True`, permissive CORS, no rate limiting)
+- Trust boundary violations (e.g., treating external data as internal without validation)
+- SQL injection vulnerabilities (string concatenation in queries)
+- Path traversal risks (user input in file paths without validation)
+- Missing authentication or authorization checks on sensitive operations
+- Insecure deserialization (pickle, yaml.load without SafeLoader)
+
+### 6. Dead or Hallucinated Code
+
+**Quick checks:**
+- Search for function/class definitions, then check for callers
+- Look for imports that seem unused
+- Check if referenced libraries match requirements.txt or package.json
+
+- Functions, classes, or modules that are defined but never called
+- Imports that do not exist in the declared dependencies
+- References to APIs, methods, or fields that do not exist in the used library version
+- Type annotations that contradict actual usage
+- Comments that describe behavior inconsistent with the code
+- Unreachable code blocks (after `return`, `raise`, or `break` in all paths)
+- Feature flags or conditionals that are always true/false
+
+### 7. Technical Debt Hotspots
+
+**Quick checks:**
+- Count function parameters (5+ = refactor candidate)
+- Measure nesting depth visually (4+ = refactor candidate)
+- Look for boolean flags controlling function behavior
+
+- Logic that is correct today but will break under realistic load or scale
+- Deep nesting (more than 3-4 levels) that obscures control flow
+- Boolean parameter flags that change function behavior (use separate functions instead)
+- Functions with more than 5-6 parameters without a configuration object
+- Areas where a future requirement change would require modifying many unrelated files
+- Missing type hints in dynamically typed languages for complex functions
+- No documentation for public APIs or complex algorithms
+- Test coverage gaps for critical paths
+
+---
+
+## Output Format
+
+Produce the audit report using exactly this structure. Do not omit sections. If a section has no findings, write "None identified."
+
+**Productivity Rules:**
+- Lead with the 3-5 most critical findings that would cause production failures
+- Group related issues (e.g., "3 locations with hardcoded credentials" instead of listing separately)
+- Provide copy-paste-ready fixes where possible (exact code snippets)
+- Use severity tags consistently: `[CRITICAL]`, `[HIGH]`, `[MEDIUM]`, `[LOW]`
+
+---
+
+### Audit Report
+
+**Input:** [file name(s) or "code snippet"]
+**Assumptions:** [list any assumptions made about context or environment]
+**Quick Stats:** [X files, Y lines of code, Z language/framework]
+
+#### Executive Summary (Read This First)
+
+In 3-5 bullets, state the most important findings that determine whether this code can go to production:
+
+```
+- [CRITICAL/HIGH] One-line summary of the most severe issue
+- [CRITICAL/HIGH] Second most severe issue
+- [MEDIUM] Notable pattern that will cause future problems
+- Overall: Deployable as-is / Needs fixes / Requires major rework
+```
+
+#### Critical Issues (Must Fix Before Production)
+
+Problems that will or are very likely to cause failures, data loss, security incidents, or severe maintenance breakdown.
+
+For each issue:
+
+```
+[CRITICAL] Short descriptive title
+Location: filename.py, line 42 (or "multiple locations" with examples)
+Dimension: Architecture / Security / Robustness / etc.
+Problem: One or two sentences explaining exactly what is wrong and why it is dangerous.
+Fix: One or two sentences describing the minimum change required to resolve it.
+Code Fix (if applicable):
+```python
+# Before: problematic code
+# After: corrected version
+```
+```
+
+#### High-Risk Issues
+
+Likely to cause bugs, instability, or scalability problems under realistic conditions.
+Same format as Critical Issues, replacing `[CRITICAL]` with `[HIGH]`.
+
+#### Maintainability Problems
+
+Issues that increase long-term cost or make the codebase difficult for others to understand and modify safely.
+Same format, replacing the tag with `[MEDIUM]` or `[LOW]`.
+
+#### Production Readiness Score
+
+```
+Score: XX / 100
+```
+
+Provide a score using the rubric below, then write 2-3 sentences justifying it with specific reference to the most impactful findings.
+
+| Range  | Meaning                                                                |
+| ------ | ---------------------------------------------------------------------- |
+| 0-30   | Not deployable. Critical failures are likely under normal use.         |
+| 31-50  | High risk. Significant rework required before any production exposure. |
+| 51-70  | Deployable only for low-stakes or internal use with close monitoring.  |
+| 71-85  | Production-viable with targeted fixes. Known risks are bounded.        |
+| 86-100 | Production-ready. Minor improvements only.                             |
+
+**Scoring Algorithm:**
+
+```
+Start at 100 points
+For each CRITICAL issue: -15 points (security: -20)
+For each HIGH issue: -8 points
+For each MEDIUM issue: -3 points
+For pervasive patterns (3+ similar issues): -5 additional points
+Floor: 0, Ceiling: 100
+```
+
+#### Refactoring Priorities
+
+List the top 3-5 changes in order of impact. Each item must reference a specific finding from above.
+
+```
+1. [P1 - Blocker] Fix title — addresses [CRITICAL #1] — effort: S/M/L — impact: prevents [specific failure]
+2. [P2 - Blocker] Fix title — addresses [CRITICAL #2] — effort: S/M/L — impact: prevents [specific failure]
+3. [P3 - High] Fix title — addresses [HIGH #1] — effort: S/M/L — impact: improves [specific metric]
+4. [P4 - Medium] Fix title — addresses [MEDIUM #1] — effort: S/M/L — impact: reduces [specific debt]
+5. [P5 - Optional] Fix title — addresses [LOW #1] — effort: S/M/L — impact: nice-to-have
+```
+
+Effort scale: S = < 1 day, M = 1-3 days, L = > 3 days.
+
+**Quick Wins (fix in <1 hour):**
+List any issues that can be resolved immediately with minimal effort:
+```
+- [Issue name]: [one-line fix description]
+```
+
+---
+
+## Behavior Rules
+
+- Ground every finding in the actual code provided. Do not speculate about code you have not seen.
+- Report the location (file and line) of each finding whenever the information is available. If the input is a snippet without line numbers, describe the location structurally (e.g., "inside the `process_payment` function").
+- Do not flag style preferences (indentation, naming conventions, etc.) unless they directly impair readability or create ambiguity that could cause bugs.
+- Do not recommend architectural rewrites unless the current structure makes the system impossible to extend or maintain safely.
+- If the code is too small or too abstract to evaluate a dimension meaningfully, say so explicitly rather than generating generic advice.
+- If you detect a potential security issue but cannot confirm it from the code alone (e.g., depends on framework configuration not shown), flag it as "unconfirmed — verify" rather than omitting or overstating it.
+
+**Efficiency Rules:**
+- Scan for critical patterns first (security, data loss, crashes) before deeper analysis
+- Group similar issues by pattern rather than listing each occurrence separately
+- Provide exact code fixes for critical/high issues when the solution is straightforward
+- Skip dimensions that are not applicable to the code size or type (state "Not applicable: [reason]")
+- Focus on issues that would cause production incidents, not theoretical concerns
+
+**Calibration:**
+- For snippets (<100 lines): Focus on security, robustness, and obvious bugs only
+- For single files (100-500 lines): Add architecture and maintainability checks
+- For multi-file systems (500+ lines): Full audit across all 7 dimensions
+- For production code: Emphasize security, observability, and failure modes
+- For prototypes: Emphasize scalability limits and technical debt
+
+---
+
+## Task-Specific Inputs
+
+Before auditing, if not already provided, ask:
+
+1. **Code or files**: Share the source code to audit. Accepted: single file, multiple files, directory listing, or snippet.
+2. **Context** _(optional)_: Brief description of what the system does, its intended scale, deployment environment, and known constraints.
+3. **Target environment** _(optional)_: Target runtime (e.g., production web service, CLI tool, data pipeline). Used to calibrate risk severity.
+4. **Known concerns** _(optional)_: Any specific areas you're worried about or want me to focus on.
+
+**If context is missing, assume:**
+- Language/framework is evident from the code
+- Deployment target is production web service (most common)
+- Scale expectations are moderate (100-1000 users) unless code suggests otherwise
+
+---
+
+## Related Skills
+
+- **schema-markup**: For adding structured data after code is production-ready.
+- **analytics-tracking**: For implementing observability and measurement after audit is clean.
+- **seo-forensic-incident-response**: For investigating production incidents after deployment.
+- **test-driven-development**: For adding test coverage to address robustness gaps.
+- **security-audit**: For deep-dive security analysis if critical vulnerabilities are found.