| name | estatewise-review |
| description | Review EstateWise changes for correctness, regressions, security issues, contract mismatches, operational risk, and missing tests. Use for PR review, diff review, bug hunts, and branch-vs-main analysis. Do not use for implementation tasks unless the user asks for fixes after findings are reported. |
EstateWise Review
Use this skill when the task is review-oriented rather than implementation-oriented.
Output Contract
Lead with findings ordered by severity. Keep summaries brief and secondary.
Each finding should include:
- Severity and impact.
- Exact file and symbol, route, tool, or endpoint.
- Why the behavior is risky or incorrect.
- Reproduction path or failure mode when possible.
- Missing tests or docs if that increases risk.
If no findings are discovered, say so explicitly and mention residual risks or validation gaps.
Severity Guide
critical: auth bypass, data loss, production outage risk, destructive deployment risk.high: broken contract, guaranteed runtime failure, clear regression, unsafe infra behavior.medium: correctness hole, flaky behavior, edge case failure, missing validation or tests.low: maintainability issue likely to cause defects later.
Do not lead with style-only comments unless they hide a real defect or maintenance trap.
EstateWise Review Checklist
Backend
- Did route or middleware order change in
backend/src/server.ts?
- Did auth or cookie behavior change unintentionally?
- Did a response shape change without updating frontend or MCP consumers?
- Are
/metrics, /status, /swagger.json, and /api-docs still coherent?
- Are graph endpoints still guarded correctly when Neo4j is disabled?
Frontend
- Were shared API assumptions updated everywhere they are duplicated?
- If
frontend/lib/api.ts changed, do direct page-level fetches still agree?
- If chat changed, do streaming, title generation, rating, and conversation CRUD still fit together?
- If map or insights changed, are marker/query limits and graph-failure handling still sane?
MCP
- Do tool names, descriptions, and schemas still match implementation?
- Are outputs still text-first and MCP-client-friendly?
- If backend endpoints changed, do MCP wrappers still parse and format correctly?
- If A2A changed, are MCP bridge tools still aligned with the agentic AI server?
Agentic AI
- Do orchestrator, LangGraph, CrewAI, and HTTP/A2A paths still agree where they overlap?
- If
/run, /run/stream, or A2A task semantics changed, do docs and MCP bridge tools stay aligned?
gRPC
- Was the proto changed first?
- Are handlers and server wiring aligned with the proto?
- Were proto lint and tests updated where needed?
Deployment Control / Infra
- Did the change increase blast radius for rollout or scale commands?
- Are job status, output capture, and command construction still safe?
- Is the no-auth assumption still documented and respected?
High-Risk Repo Patterns
- Frontend backend URLs are duplicated across multiple files and often drift.
- MCP changes often require agentic-ai and docs follow-up even when TypeScript compiles.
backend/src/services/geminiChat.service.ts can hide regressions behind prompt or retry changes.- Deployment-control and infra changes can be syntactically valid but operationally unsafe.
Evidence Standards
- Prefer exact file references over vague statements.
- Read the consumer side for every contract claim.
- If a test is missing, explain what failure it would have caught.
- When you are inferring from naming or docs rather than code, say so.
