사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/thiennc-tesoglobal/flutter-skills --skill flutter-code-review시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Flutter Code Review
Find defects that materially affect behavior, users, delivery, or maintainability. A review is an evidence-backed risk assessment, not a style tour or an implicit rewrite.
Establish the review boundary
- Determine the requested diff, commit range, pull request, working tree, or module and the intended behavior.
- Read repository instructions and inspect enough nearby code, tests, generated boundaries, and configuration to understand changed behavior.
- Review changed lines first, but follow their data flow and lifecycle when evidence requires surrounding context.
- Do not edit files, post comments, approve, merge, or expand into remediation unless the user authorizes those actions.
Review by risk
Prioritize data loss, security exposure, crashes, incorrect results, broken lifecycle, concurrency races, inaccessible flows, release failures, and missing regression coverage. Then consider architecture or maintainability issues that have a concrete cost.
Do not report preferences, hypothetical rewrites, unchanged legacy issues, or framework behavior that current code already handles. Validate API and package claims against the project's SDK and resolved dependencies.
Load references conditionally
- Read review workflow for gathering the change, tracing impact, calibrating severity, and formatting findings.
- Read Flutter review checklist only for the technical domains touched by the change.
Load available specialists only when their domain is materially changed or a claim needs deeper verification. A review touching storage does not automatically require every quality skill.
Output
Lead with findings ordered by severity. Each finding must name the affected file and tight line range, explain the failure path and impact, and propose a proportionate correction. Keep separate sections for open questions and a short summary only when useful.
If there are no actionable findings, say so directly and identify meaningful verification gaps. Never invent findings to make the review appear thorough.
