You are reviewing performance and observability: how the app behaves under load, what's being measured, and whether operators can see production issues coming.
Scope note: application logging — what gets recorded, at what level, with what context — belongs to /logs. Flag a logging gap if you trip over one, then point at /logs rather than designing the contract here.
Custom instructions: If the user included extra instructions when invoking this skill, treat them as overriding or extending the guidance below.
Read (as applicable):
.docs/seed.md — latency-sensitive flows, scale expectations, SLAs if any.docs/tech-stack.md — framework, hosting, suggested monitoring tools- Code: hot paths (DB queries, N+1 patterns, large payloads), caching, background jobs, API routes, client bundles
- Existing metrics, tracing, and error reporting (Sentry, OpenTelemetry, APM, etc.)
Your task:
Performance — Identify likely bottlenecks in the current implementation (not hypothetical). Prefer concrete references (file + pattern): missing indexes, unbounded queries, sync work on request thread, heavy client JS, missing pagination, etc.
Baselines — Suggest what to measure (p95 latency, error rate, job queue depth) and where — only what fits this stack.
Tracing & metrics — Gaps: no structured errors, no health check, no uptime probe, no dashboards, no trace context across service boundaries. Recommend minimal additions aligned with the tech stack.
Prioritized actions — Short list: highest impact first, each item actionable in one sitting.
RULES:
- Do not recommend a new vendor or library unless the user asks or the stack already allows it; otherwise flag once for user decision.
- Focus on shipped code paths, not future features.
Logging: On success, append to .docs/changelog.md per .docs/changelog-spec.md: - YYYY-MM-DD HH:mm ran /performance — [brief summary].
1---2name: performance3description: Review performance and observability — bottlenecks, baselines, metrics, tracing. Use only when the user explicitly asks for a performance or observability review or runs /performance.4---56You are reviewing **performance and observability**: how the app behaves under load, what's being measured, and whether operators can see production issues coming.78**Scope note:** application logging — what gets recorded, at what level, with what context — belongs to `/logs`. Flag a logging gap if you trip over one, then point at `/logs` rather than designing the contract here.910**Custom instructions:** If the user included extra instructions when invoking this skill, treat them as overriding or extending the guidance below.1112**Read (as applicable):**1314- `.docs/seed.md` — latency-sensitive flows, scale expectations, SLAs if any15- `.docs/tech-stack.md` — framework, hosting, suggested monitoring tools16- Code: hot paths (DB queries, N+1 patterns, large payloads), caching, background jobs, API routes, client bundles17- Existing metrics, tracing, and error reporting (Sentry, OpenTelemetry, APM, etc.)1819**Your task:**20211. **Performance** — Identify likely bottlenecks in the **current** implementation (not hypothetical). Prefer concrete references (file + pattern): missing indexes, unbounded queries, sync work on request thread, heavy client JS, missing pagination, etc.22232. **Baselines** — Suggest what to measure (p95 latency, error rate, job queue depth) and where — only what fits this stack.24253. **Tracing & metrics** — Gaps: no structured errors, no health check, no uptime probe, no dashboards, no trace context across service boundaries. Recommend minimal additions aligned with the tech stack.26274. **Prioritized actions** — Short list: highest impact first, each item actionable in one sitting.2829**RULES:**3031- Do not recommend a new vendor or library unless the user asks or the stack already allows it; otherwise flag once for user decision.32- Focus on shipped code paths, not future features.3334**Logging:** On success, append to `.docs/changelog.md` per `.docs/changelog-spec.md`: `- YYYY-MM-DD HH:mm ran /performance — [brief summary]`.
limonequantistico