feat: add connector and dashboard builder skills

skills/api-connector-builder/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: api-connector-builder
+description: Build a new API connector or provider by matching the target repo's existing integration pattern exactly. Use when adding one more integration without inventing a second architecture.
+origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# API Connector Builder
+
+Use this when the job is to add a repo-native integration surface, not just a generic HTTP client.
+
+The point is to match the host repository's pattern:
+
+- connector layout
+- config schema
+- auth model
+- error handling
+- test style
+- registration/discovery wiring
+
+## When to Use
+
+- "Build a Jira connector for this project"
+- "Add a Slack provider following the existing pattern"
+- "Create a new integration for this API"
+- "Build a plugin that matches the repo's connector style"
+
+## Guardrails
+
+- do not invent a new integration architecture when the repo already has one
+- do not start from vendor docs alone; start from existing in-repo connectors first
+- do not stop at transport code if the repo expects registry wiring, tests, and docs
+- do not cargo-cult old connectors if the repo has a newer current pattern
+
+## Workflow
+
+### 1. Learn the house style
+
+Inspect at least 2 existing connectors/providers and map:
+
+- file layout
+- abstraction boundaries
+- config model
+- retry / pagination conventions
+- registry hooks
+- test fixtures and naming
+
+### 2. Narrow the target integration
+
+Define only the surface the repo actually needs:
+
+- auth flow
+- key entities
+- core read/write operations
+- pagination and rate limits
+- webhook or polling model
+
+### 3. Build in repo-native layers
+
+Typical slices:
+
+- config/schema
+- client/transport
+- mapping layer
+- connector/provider entrypoint
+- registration
+- tests
+
+### 4. Validate against the source pattern
+
+The new connector should look obvious in the codebase, not imported from a different ecosystem.
+
+## Reference Shapes
+
+### Provider-style
+
+```text
+providers/
+  existing_provider/
+    __init__.py
+    provider.py
+    config.py
+```
+
+### Connector-style
+
+```text
+integrations/
+  existing/
+    client.py
+    models.py
+    connector.py
+```
+
+### TypeScript plugin-style
+
+```text
+src/integrations/
+  existing/
+    index.ts
+    client.ts
+    types.ts
+    test.ts
+```
+
+## Quality Checklist
+
+- [ ] matches an existing in-repo integration pattern
+- [ ] config validation exists
+- [ ] auth and error handling are explicit
+- [ ] pagination/retry behavior follows repo norms
+- [ ] registry/discovery wiring is complete
+- [ ] tests mirror the host repo's style
+- [ ] docs/examples are updated if expected by the repo
+
+## Related Skills
+
+- `backend-patterns`
+- `mcp-server-patterns`
+- `github-ops`
+

skills/dashboard-builder/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: dashboard-builder
+description: Build monitoring dashboards that answer real operator questions for Grafana, SigNoz, and similar platforms. Use when turning metrics into a working dashboard instead of a vanity board.
+origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# Dashboard Builder
+
+Use this when the task is to build a dashboard people can operate from.
+
+The goal is not "show every metric." The goal is to answer:
+
+- is it healthy?
+- where is the bottleneck?
+- what changed?
+- what action should someone take?
+
+## When to Use
+
+- "Build a Kafka monitoring dashboard"
+- "Create a Grafana dashboard for Elasticsearch"
+- "Make a SigNoz dashboard for this service"
+- "Turn this metrics list into a real operational dashboard"
+
+## Guardrails
+
+- do not start from visual layout; start from operator questions
+- do not include every available metric just because it exists
+- do not mix health, throughput, and resource panels without structure
+- do not ship panels without titles, units, and sane thresholds
+
+## Workflow
+
+### 1. Define the operating questions
+
+Organize around:
+
+- health / availability
+- latency / performance
+- throughput / volume
+- saturation / resources
+- service-specific risk
+
+### 2. Study the target platform schema
+
+Inspect existing dashboards first:
+
+- JSON structure
+- query language
+- variables
+- threshold styling
+- section layout
+
+### 3. Build the minimum useful board
+
+Recommended structure:
+
+1. overview
+2. performance
+3. resources
+4. service-specific section
+
+### 4. Cut vanity panels
+
+Every panel should answer a real question. If it does not, remove it.
+
+## Example Panel Sets
+
+### Elasticsearch
+
+- cluster health
+- shard allocation
+- search latency
+- indexing rate
+- JVM heap / GC
+
+### Kafka
+
+- broker count
+- under-replicated partitions
+- messages in / out
+- consumer lag
+- disk and network pressure
+
+### API gateway / ingress
+
+- request rate
+- p50 / p95 / p99 latency
+- error rate
+- upstream health
+- active connections
+
+## Quality Checklist
+
+- [ ] valid dashboard JSON
+- [ ] clear section grouping
+- [ ] titles and units are present
+- [ ] thresholds/status colors are meaningful
+- [ ] variables exist for common filters
+- [ ] default time range and refresh are sensible
+- [ ] no vanity panels with no operator value
+
+## Related Skills
+
+- `research-ops`
+- `backend-patterns`
+- `terminal-ops`
+