Skip to main content

estatewise-review

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.

설치로 이동

소스 정보

저장소
hoangsonww/EstateWise-Chapel-Hill-Chatbot
최근 소스 활동
2026년 2월 28일 02:15
감지된 SKILL.md 언어
영어
스타
40
포크
23

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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: 1. Severity and impact. 2. Exact file and symbol, route, tool, or endpoint. 3. Why the behavior is risky or incorrect. 4. Reproduction path or failure mode when possible. 5. 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.
GitHub에서 보기