claude-code-arcane 1.0.0

package/skills/llm-cost-optimizer/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: llm-cost-optimizer
+description: "Reduce LLM API spend by 40-80% through model routing, prompt caching, compression, and cost observability without degrading user-facing quality."
+argument-hint: ""
+category: "ai"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# LLM Cost Optimizer
+
+Expert in LLM cost engineering for reducing AI API spend at scale. Cut costs by 40-80% without degrading user-facing quality -- using model routing, caching, prompt compression, and observability to make every token count.
+
+AI API costs are engineering costs. Treat them like database query costs: measure first, optimize second, monitor always.
+
+## Before Starting
+
+**Check for context first:** If project-context.md exists, read it before asking questions. Pull the tech stack, architecture, and AI feature details already there.
+
+Gather this context (ask in one shot):
+
+### 1. Current State
+- Which LLM providers and models are you using today?
+- What is your monthly spend? Which features/endpoints drive it?
+- Do you have token usage logging? Cost-per-request visibility?
+
+### 2. Goals
+- Target cost reduction? (e.g., "cut spend by 50%", "stay under $X/month")
+- Latency constraints? (caching and routing tradeoffs)
+- Quality floor? (what degradation is acceptable?)
+
+### 3. Workload Profile
+- Request volume and distribution (p50, p95, p99 token counts)?
+- Repeated/similar prompts? (caching potential)
+- Mix of task types? (classification vs. generation vs. reasoning)
+
+## How This Skill Works
+
+### Mode 1: Cost Audit
+You have spend but no clear picture of where it goes. Instrument, measure, and identify the top cost drivers before touching a single prompt.
+
+### Mode 2: Optimize Existing System
+Cost drivers are known. Apply targeted techniques: model routing, caching, compression, batching. Measure impact of each change.
+
+### Mode 3: Design Cost-Efficient Architecture
+Building new AI features. Design cost controls in from the start -- budget envelopes, routing logic, caching strategy, and cost alerts before launch.
+
+---
+
+## Mode 1: Cost Audit
+
+**Step 1 -- Instrument Every Request**
+
+Log per-request: model, input tokens, output tokens, latency, endpoint/feature, user segment, cost (calculated).
+
+Build a per-request cost breakdown from your logs: group by feature, model, and token count to identify top spend drivers.
+
+**Step 2 -- Find the 20% Causing 80% of Spend**
+
+Sort by: feature x model x token count. Usually 2-3 endpoints drive the majority of cost. Target those first.
+
+**Step 3 -- Classify Requests by Complexity**
+
+| Complexity | Characteristics | Right Model Tier |
+|---|---|---|
+| Simple | Classification, extraction, yes/no, short output | Small (Haiku, GPT-4o-mini, Gemini Flash) |
+| Medium | Summarization, structured output, moderate reasoning | Mid (Sonnet, GPT-4o) |
+| Complex | Multi-step reasoning, code gen, long context | Large (Opus, GPT-4o, o3) |
+
+---
+
+## Mode 2: Optimize Existing System
+
+Apply techniques in this order (highest ROI first):
+
+### 1. Model Routing (typically 60-80% cost reduction on routed traffic)
+
+Route by task complexity, not by default. Use a lightweight classifier or rule engine.
+
+Decision framework:
+- **Use small models** for: classification, extraction, simple Q&A, formatting, short summaries
+- **Use mid models** for: structured output, moderate summarization, code completion
+- **Use large models** for: complex reasoning, long-context analysis, agentic tasks, code generation
+
+### 2. Prompt Caching (40-90% reduction on cacheable traffic)
+
+Supported by: Anthropic (cache_control), OpenAI (prompt caching, automatic on some models), Google (context caching).
+
+Cache-eligible content: system prompts, static context, document chunks, few-shot examples.
+
+Cache hit rates to target: >60% for document Q&A, >40% for chatbots with static system prompts.
+
+### 3. Output Length Control (20-40% reduction)
+
+LLMs over-generate by default. Force conciseness:
+
+- Explicit length instructions: "Respond in 3 sentences or fewer."
+- Schema-constrained output: JSON with defined fields beats free-text
+- max_tokens hard caps: Set per-endpoint, not globally
+- Stop sequences: Define terminators for list/structured outputs
+
+### 4. Prompt Compression (15-30% input token reduction)
+
+Remove filler without losing meaning. Audit each prompt for token efficiency by comparing instruction length to actual task requirements.
+
+| Before | After |
+|---|---|
+| "Please carefully analyze the following text and provide..." | "Analyze:" |
+| "It is important that you remember to always..." | "Always:" |
+| Repeating context already in system prompt | Remove |
+| HTML/markdown when plain text works | Strip tags |
+
+### 5. Semantic Caching (30-60% hit rate on repeated queries)
+
+Cache LLM responses keyed by embedding similarity, not exact match. Serve cached responses for semantically equivalent questions.
+
+Tools: GPTCache, LangChain cache, custom Redis + embedding lookup.
+
+Threshold guidance: cosine similarity >0.95 = safe to serve cached response.
+
+### 6. Request Batching (10-25% reduction via amortized overhead)
+
+Batch non-latency-sensitive requests. Process async queues off-peak.
+
+---
+
+## Mode 3: Design Cost-Efficient Architecture
+
+Build these controls in before launch:
+
+**Budget Envelopes** -- per feature, per user tier, per day. Set hard limits and soft alerts at 80% of limit.
+
+**Routing Layer** -- classify then route then call. Never call the large model by default.
+
+**Cost Observability** -- dashboard with: spend by feature, spend by model, cost per active user, week-over-week trend, anomaly alerts.
+
+**Graceful Degradation** -- when budget exceeded: switch to smaller model, return cached response, queue for async processing.
+
+---
+
+## Proactive Triggers
+
+Surface these without being asked:
+
+- **No per-feature cost breakdown** -- You cannot optimize what you cannot see. Instrument logging before any other change.
+- **All requests hitting the same model** -- Model monoculture is the #1 overspend pattern. Even 20% routing to a cheaper model cuts spend significantly.
+- **System prompt >2,000 tokens sent on every request** -- This is a caching opportunity worth flagging immediately.
+- **Output max_tokens not set** -- LLMs pad outputs. Every uncapped endpoint is a cost leak.
+- **No cost alerts configured** -- Spend spikes go undetected for days. Set p95 cost-per-request alerts on every AI endpoint.
+- **Free tier users consuming same model as paid** -- Tier your model access. Free users do not need the most expensive model.
+
+---
+
+## Output Artifacts
+
+| When you ask for... | You get... |
+|---|---|
+| Cost audit | Per-feature spend breakdown with top 3 optimization targets and projected savings |
+| Model routing design | Routing decision tree with model recommendations per task type and estimated cost delta |
+| Caching strategy | Which content to cache, cache key design, expected hit rate, implementation pattern |
+| Prompt optimization | Token-by-token audit with compression suggestions and before/after token counts |
+| Architecture review | Cost-efficiency scorecard (0-100) with prioritized fixes and projected monthly savings |
+
+---
+
+## Communication
+
+All output follows the structured standard:
+- **Bottom line first** -- cost impact before explanation
+- **What + Why + How** -- every finding includes all three
+- **Actions have owners and deadlines** -- no "consider optimizing..."
+- **Confidence tagging** -- verified / medium / assumed
+
+---
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Better Approach |
+|---|---|---|
+| Using the largest model for every request | 80%+ of requests are simple tasks that a smaller model handles equally well, wasting 5-10x on cost | Implement a routing layer that classifies request complexity and selects the cheapest adequate model |
+| Optimizing prompts without measuring first | You cannot know what to optimize without per-feature spend visibility | Instrument token logging and cost-per-request before making any changes |
+| Caching by exact string match only | Minor phrasing differences cause cache misses on semantically identical queries | Use embedding-based semantic caching with a cosine similarity threshold |
+| Setting a single global max_tokens | Some endpoints need 2000 tokens, others need 50 — a global cap either wastes or truncates | Set max_tokens per endpoint based on measured p95 output length |
+| Ignoring system prompt size | A 3000-token system prompt sent on every request is a hidden cost multiplier | Use prompt caching for static system prompts and strip unnecessary instructions |
+| Treating cost optimization as a one-time project | Model pricing changes, traffic patterns shift, and new features launch — costs drift | Set up continuous cost monitoring with weekly spend reports and anomaly alerts |
+| Compressing prompts to the point of ambiguity | Over-compressed prompts cause the model to hallucinate or produce low-quality output, requiring retries | Compress filler words and redundant context but preserve all task-critical instructions |
+
+## Related Skills
+
+- **rag-architect**: Use when designing retrieval pipelines. NOT for cost optimization of the LLM calls within RAG (that is this skill).
+- **senior-prompt-engineer**: Use when improving prompt quality and effectiveness. NOT for token reduction or cost control (that is this skill).
+- **observability-designer**: Use when designing the broader monitoring stack. Pairs with this skill for LLM cost dashboards.
+- **performance-profiler**: Use for latency profiling. Pairs with this skill when optimizing the cost-latency tradeoff.
+- **api-design-reviewer**: Use when reviewing AI feature APIs. Cross-reference for cost-per-endpoint analysis.

package/skills/local-database-setup/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: local-database-setup
+description: "Configura la base de datos local del proyecto: levanta Docker/Postgres, corre setup script, ejecuta migrations pendientes."
+category: "database"
+argument-hint: ""
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# Skill: local-database-setup
+
+## Trigger
+When the user says "setup database", "configurar base", "levantar la db", "inicializar db", or similar.
+
+## Workflow
+
+1. Check if Docker is running (PostgreSQL usually runs in Docker locally)
+
+2. Look for database setup scripts in the project:
+   - `db/local/init-local-db.sh`
+   - `docker-compose.yml` with postgres service
+   - `Makefile` with db-related targets
+
+3. Run the setup script:
+   ```bash
+   # For tich-cronos
+   bash db/local/init-local-db.sh
+   ```
+
+4. Verify the database is accessible:
+   - Check connection using env vars from `.env.local`
+   - Run a simple query to verify
+
+5. Run pending migrations if any exist:
+   - Check `db/migrations/` directory
+   - Run migrations using golang-migrate
+
+## Project-specific setup
+
+### tich-cronos
+```bash
+# 1. Start PostgreSQL (Docker)
+bash db/local/init-local-db.sh
+
+# 2. Run migrations
+go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@v4.12.2
+migrate -path db/migrations -database "$DATABASE_URL" up
+```

package/skills/logging-setup/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: logging-setup
+description: "Structured logging: slog/pino, Cloud Logging, Loki, correlation IDs, PII scrubbing, sampling, cost control."
+category: "observability"
+argument-hint: "[stack: go|ts|react|rn]"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit, Task
+---
+# logging-setup — Structured Logging
+
+Objetivo: **debuggable en prod, barato a escala, sin PII**.
+
+## Principios
+
+1. JSON estructurado siempre — nunca strings libres en prod
+2. Una línea = un evento — no multi-line/pretty-print
+3. Level + message + context en todo evento
+4. Correlation ID (trace_id, request_id, user_id, tenant_id) en cada línea
+5. Sin PII — scrubber en el logger
+6. Sampling en hot paths
+7. Logs ≠ errors ≠ metrics ≠ traces — cada uno su destino
+
+## Stack Decision
+
+| Destino | Cuándo |
+|---------|--------|
+| **GCP Cloud Logging** | **Default Educabot** (runtime GCP), $0.50/GiB ingest |
+| Grafana Loki | Self-host, alto volumen barato |
+| Datadog Logs | Si ya pagan DD APM |
+| ELK/OpenSearch | Compliance/SIEM full-text |
+
+Default: Cloud Logging (runtime) + Loki (alto volumen/cheap retention).
+
+## Setup por Stack
+
+**Go (slog stdlib 1.21+):** `slog.NewJSONHandler` con level configurable, ReplaceAttr para PII scrubbing, base fields (service, env, version). Middleware Gin inyecta request-scoped attrs (request_id, trace_id, route) en context.
+
+**Node/TS (pino):** level via env, base fields, `redact.paths` para PII (password, token, authorization, cookie, dni, cuit), `pinoHttp` middleware con custom props (trace_id) y serializers compactos. Pino > winston: 5x más rápido, JSON nativo.
+
+**Cloud Logging fields:** `severity` (DEBUG-CRITICAL), `logging.googleapis.com/trace` (auto-link a Cloud Trace), `httpRequest` (método/status/latency como columnas). Cloud Run/GKE: stdout se loguea automáticamente.
+
+**React/frontend:** errores → Sentry, analytics → Mixpanel/Amplitude. Si necesitás logs centralizados: buffer + batch + flush a `/api/logs`, solo warn+ en prod. Evitar loguear interacciones rutinarias.
+
+**React Native:** errores → Sentry, analytics → Mixpanel. Debug en campo: `react-native-logs` (archivos rotados), upload con consent. Nunca PII en logs del device.
+
+## Correlation / Trace IDs
+
+OTel W3C Trace Context (`traceparent`). Todo log en un request con mismo trace_id. Go: `trace.SpanFromContext(ctx).SpanContext().TraceID()`.
+
+## Log Levels
+
+| Level | Uso |
+|-------|-----|
+| DEBUG | Flujo interno. Off en prod salvo troubleshooting |
+| INFO | Eventos normales. Default prod |
+| WARN | Recuperable ("retry 2/3"). Mirar tendencias |
+| ERROR | Falla operación, sistema sigue. → Sentry también |
+| FATAL | Se muere el servicio. Raro. Page on-call |
+
+Si nadie va a hacer algo con la línea → bájala de level o sacala.
+
+## Sampling
+
+Cloud Logging ~$0.50/GiB. Estrategia: siempre errores 100%, samplear éxitos (5-10%). Con OTel tracing, bajar INFO a 1-5%.
+
+> → Read references/pii-audit-access.md for PII scrubbing fields, audit log schema, access log fields, and retention/cost tables
+
+> → Read references/anti-patterns.md for common logging anti-patterns
+
+> → Read references/checklist.md for the 12-item implementation checklist
+
+## Checklist
+
+- [ ] Log destination chosen and configured (Cloud Logging, Loki, Datadog, or ELK)
+- [ ] Correlation IDs (trace_id, request_id) injected in every log line via middleware
+- [ ] PII scrubbing in place (password, token, authorization, cookie, dni, cuit redacted)
+- [ ] Sampling strategy defined (errors 100%, success paths 5-10%)
+- [ ] Log levels set correctly per environment (DEBUG off in prod, INFO as default)
+- [ ] JSON structured format enforced — no free-form strings in production

package/skills/logging-setup/references/anti-patterns.md

@@ -0,0 +1,7 @@
+# Anti-patterns
+
+- `console.log` en prod (sin estructura/level), printf-style interpolation, multi-line logs
+- Todo a INFO (senal ahogada), sin correlation_id, PII en logs
+- Logs como sustituto de metricas, retention infinita, healthcheck spam
+- `JSON.stringify(bigObject)` en hot path, `logger.error(err)` sin contexto
+- Logger global instanciado en cada call, shipping sync (bloquea handler)

package/skills/logging-setup/references/checklist.md

@@ -0,0 +1,14 @@
+# Checklist
+
+- [ ] slog/pino JSON en prod, level configurable via env
+- [ ] Base fields: service, env, version
+- [ ] Request-scoped: trace_id, request_id, user_id, tenant_id
+- [ ] PII scrubber activo
+- [ ] Severity mapeada al provider
+- [ ] Sampling en hot paths, healthchecks excluidos
+- [ ] Audit logs separados con retention >= 1 ano
+- [ ] Access logs con latency
+- [ ] Retention policy por tipo
+- [ ] Log-based alerts configurados
+- [ ] Tests validan estructura (keys, level)
+- [ ] Cost review mensual

package/skills/logging-setup/references/pii-audit-access.md

@@ -0,0 +1,25 @@
+# PII Scrubbing, Audit Logs & Access Logs
+
+## PII Scrubbing
+
+Campos prohibidos: password, tokens, API keys, DNI/CPF/CUIT, email (hash si correlacion), direccion, telefono, contenido mensajes usuarios, tarjetas. Go: `ReplaceAttr` en slog handler. Pino: `redact.paths`. Nunca loguear `req.body` crudo.
+
+## Access Logs
+
+Fields: method, path, status, latency, user_id, tenant_id, trace_id, ip, user_agent. Excluir /health, /ready, /metrics.
+
+## Audit Logs
+
+Separados de app logs — append-only, retention larga. Eventos: login/logout/signup, password/MFA change, role/permisos change, acceso PII menores, tenant CRUD, GDPR exports, admin actions. Schema: `(id, actor_id, actor_type, action, target_type, target_id, tenant_id, ip, user_agent, metadata jsonb, created_at)`. Write-only, no update/delete. Backup off-cluster.
+
+## Retention & Cost
+
+| Tipo | Retention |
+|------|-----------|
+| Application | 30d hot, 90d cold |
+| Access (LB) | 30d |
+| Audit (auth, admin) | 1 ano min |
+| Security (SIEM) | 1+ ano |
+| Debug prod | 7-14d |
+
+Reducir costo: sampling, level >= INFO, excluir healthchecks, Loki para alto volumen, GCS para cold storage.

package/skills/ma-playbook/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: ma-playbook
+description: "M&A strategy for acquiring companies or being acquired. Due diligence, valuation, integration, and deal structure frameworks."
+argument-hint: ""
+category: "clevel-operations"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# M&A Playbook
+
+Frameworks for both sides of M&A: acquiring companies and being acquired.
+
+## When You're Acquiring
+
+### Strategic Rationale (answer before anything else)
+- **Buy vs Build:** Can you build this faster/cheaper? If yes, don't acquire.
+- **Acqui-hire vs Product vs Market:** What are you really buying?
+- **Integration complexity:** How hard is it to merge into your company?
+
+### Due Diligence Checklist
+| Domain | Key Questions | Red Flags |
+|--------|--------------|-----------|
+| Financial | Revenue quality, concentration, burn rate | >30% revenue from 1 customer |
+| Technical | Code quality, tech debt, architecture fit | Monolith with no tests |
+| Legal | IP ownership, litigation, contracts | Key IP owned by individuals |
+| People | Key person risk, culture fit, retention | Founders have no lockup/earnout |
+| Market | Market position, competitive threats | Declining market share |
+
+### Valuation Approaches
+- **Revenue multiple:** 2-15x ARR for SaaS (industry-dependent)
+- **Comparable transactions:** What similar companies sold for
+- **Acqui-hire:** $1-3M per engineer in hot markets
+
+## When You're Being Acquired
+
+### Preparation (6-12 months before)
+1. Clean up financials
+2. Document all IP and contracts
+3. Reduce customer concentration
+4. Lock up key employees
+5. Build the data room
+6. Engage an M&A advisor
+
+### Negotiation Points
+| Term | What to Watch |
+|------|--------------|
+| Valuation | Earnout traps (unreachable targets) |
+| Earnout | Milestone definitions, measurement period |
+| Lockup | Duration, conditions |
+| Employee retention | Who gets offers, at what terms |
+
+## Red Flags (Both Sides)
+
+- No clear strategic rationale beyond "it's a good deal"
+- Culture clash visible during DD and ignored
+- Key people not locked in before close
+- Integration plan doesn't exist
+
+## Integration with C-Suite Roles
+
+| Role | Contribution |
+|------|-------------------|
+| CEO | Strategic rationale, negotiation lead |
+| CFO | Valuation, deal structure, financing |
+| CTO | Technical due diligence, integration architecture |
+| CHRO | People due diligence, retention planning |
+| COO | Integration execution, process merge |
+
+## Resources
+- `references/integration-playbook.md` — 100-day post-acquisition integration plan
+- `references/due-diligence-checklist.md` — comprehensive DD checklist by domain

package/skills/ma-playbook/references/due-diligence-checklist.md

@@ -0,0 +1,148 @@
+# M&A Due Diligence Checklist
+
+Comprehensive due diligence organized by domain. Not every item applies to every deal — focus on what matters for YOUR acquisition rationale.
+
+## Financial Due Diligence
+
+### Revenue Quality
+- [ ] Revenue by customer (top 10 customer concentration)
+- [ ] Revenue by product line
+- [ ] Revenue by geography
+- [ ] MRR/ARR trend (24 months minimum)
+- [ ] Churn rate (gross and net, by cohort)
+- [ ] Revenue recognition policies
+- [ ] Deferred revenue / backlog
+- [ ] One-time vs recurring revenue split
+- [ ] Professional services vs product revenue
+
+### Profitability
+- [ ] Gross margin by product line
+- [ ] Operating expenses breakdown
+- [ ] Burn rate trend (improving or worsening?)
+- [ ] Path to profitability (realistic or aspirational?)
+- [ ] Unit economics (LTV, CAC, payback by channel)
+
+### Cash & Liabilities
+- [ ] Cash position and burn rate
+- [ ] Outstanding debt (terms, covenants)
+- [ ] Accounts receivable aging
+- [ ] Accounts payable
+- [ ] Pending or contingent liabilities
+- [ ] Tax obligations (any back taxes?)
+- [ ] Cap table (fully diluted, option pool)
+
+### Financial Controls
+- [ ] Audit history (audited vs reviewed vs compiled)
+- [ ] Financial reporting cadence and quality
+- [ ] Budget vs actual variance history
+- [ ] Key financial policies
+
+## Technical Due Diligence
+
+### Architecture
+- [ ] Architecture diagrams (current state)
+- [ ] Technology stack inventory
+- [ ] Infrastructure (cloud provider, regions, costs)
+- [ ] Scalability assessment (current capacity vs load)
+- [ ] Security architecture (encryption, access controls)
+
+### Code Quality
+- [ ] Test coverage (unit, integration, e2e)
+- [ ] CI/CD pipeline maturity
+- [ ] Technical debt inventory (estimated remediation cost)
+- [ ] Code review practices
+- [ ] Documentation quality
+
+### Data
+- [ ] Data architecture and storage
+- [ ] Data privacy compliance (GDPR, CCPA)
+- [ ] Data portability (can you migrate it?)
+- [ ] Proprietary data assets (training data, user data)
+- [ ] Data retention policies
+
+### Operational
+- [ ] Uptime history (SLA compliance)
+- [ ] Incident history (frequency, severity, resolution time)
+- [ ] Monitoring and alerting coverage
+- [ ] Disaster recovery plan and testing history
+- [ ] On-call rotation and processes
+
+## Legal Due Diligence
+
+### Intellectual Property
+- [ ] Patents (granted and pending)
+- [ ] Trademarks
+- [ ] Copyright registrations
+- [ ] IP assignment agreements (all employees/contractors)
+- [ ] Open source usage and compliance
+- [ ] Trade secrets protection measures
+
+### Contracts
+- [ ] Customer contracts (terms, renewals, termination rights)
+- [ ] Vendor contracts (key dependencies, terms)
+- [ ] Partnership agreements
+- [ ] Lease agreements
+- [ ] Employment agreements (non-competes, IP clauses)
+
+### Compliance & Litigation
+- [ ] Pending or threatened litigation
+- [ ] Regulatory compliance status
+- [ ] Government investigations
+- [ ] Insurance coverage
+- [ ] Prior legal disputes and resolutions
+
+## People Due Diligence
+
+### Team Composition
+- [ ] Org chart with roles and tenure
+- [ ] Key person dependencies (bus factor)
+- [ ] Compensation details (salary, equity, bonuses)
+- [ ] Employment agreements and non-competes
+- [ ] Contractor vs employee classification
+
+### Culture & Retention
+- [ ] Recent engagement survey results
+- [ ] Turnover rate (last 12-24 months)
+- [ ] Glassdoor/reputation assessment
+- [ ] Management quality assessment
+- [ ] Culture compatibility analysis
+
+### HR Compliance
+- [ ] Employee handbook and policies
+- [ ] HR complaints or investigations
+- [ ] Benefits programs
+- [ ] Equity plan details and administration
+
+## Market Due Diligence
+
+### Market Position
+- [ ] Market size (TAM, SAM, SOM) with sources
+- [ ] Market share estimate
+- [ ] Growth rate (market and company)
+- [ ] Competitive landscape (direct and indirect)
+- [ ] Barriers to entry / competitive moat
+
+### Customer Analysis
+- [ ] Customer segmentation
+- [ ] Win/loss analysis (why customers chose them)
+- [ ] NPS or satisfaction scores
+- [ ] Customer acquisition channels
+- [ ] Customer lifetime and expansion patterns
+
+## Red Flag Severity Guide
+
+| Severity | Examples | Action |
+|----------|---------|--------|
+| **Deal killer** | IP not properly assigned, undisclosed litigation, fraud | Walk away |
+| **Major renegotiation** | Customer concentration >40%, key person risk, technical debt >6 months | Reduce price or add protections |
+| **Integration risk** | Culture mismatch, legacy systems, manual processes | Budget for remediation |
+| **Monitor** | High churn, declining NPS, aging tech stack | Track post-close |
+
+## Due Diligence Timeline
+
+| Phase | Duration | Focus |
+|-------|----------|-------|
+| Preliminary | 1-2 weeks | Public info, financials, high-level tech |
+| Deep dive | 4-6 weeks | All domains, interviews, code review |
+| Confirmation | 1-2 weeks | Verify claims, resolve open questions |
+| Final | 1 week | Legal review, final terms negotiation |