ワンクリックでManusで任意のスキルを実行

code-review-feedback-handler

スター0

フォーク0

更新日2026年2月9日 06:05

코드 리뷰 코멘트/피드백을 받아 수용·부분 수용·거절로 분류하고, 최신 코드/호출 관계/사양/문서를 근거로 비판적으로 타당성을 검증한 뒤, 수용된 변경만 구현하고 최종 보고서를 작성한다. PR 리뷰 반영, 리뷰 코멘트 처리, 리팩토링 제안 검증/적용 요청에 사용한다.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

HuveD

HuveD/agent-skillset

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

코드 리뷰 피드백 처리(검토 + 적용)

목표

리뷰 코멘트를 “변경하지 않는 것이 기본”이라는 보수적 원칙으로 검토하고, 명백한 이득이 있는 변경만 반영한다.
단기 편의보다 장기적 유지보수성/확장성/안정성을 우선하고, 단순 취향 제안은 거절한다.

입력(권장)

리뷰 코멘트 목록(COMMENT): 각 항목에 원문, 파일/라인(또는 스니펫), 배경(왜 문제인지), 원하는 결과를 포함한다.
정보가 부족하면 구현/리팩토링부터 하지 말고, 먼저 필요한 질문을 한다.

워크플로(필수)

코멘트 분석: 핵심 주장/제안/의도, 기대 효과, 전제(가정)를 분리해 요약한다.
자율 코드 조사: 언급된 파일/라인을 기준으로 최신 코드를 직접 확인하고, 호출 관계/주변 맥락/테스트 영향 범위를 함께 조사한다.
사양 및 문서 검토(필수): 변경 대상 기능과 관련된 문서를 우선 확인한다.
- docs/specs/ 관련 사양서
- docs/ 내 아키텍처/설계 문서
- (존재 시) PROJECT.md, AGENTS.md
비판적 타당성 검증: 아래 “판정 기준”으로 수용/부분 수용/거절을 결정한다.
작업 진행(수용/부분 수용): 테스트 우선(가능한 범위)으로 최소 변경을 적용하고, SRP/Result/DRY/YAGNI를 준수한다. 사양에 영향이 있으면 사양을 먼저/함께 갱신한다.
최종 보고 작성: references/final-report-template.md 형식으로 결과를 정리한다.

판정 기준

수용(Accept)

사양/아키텍처와 정합하며, 장기적 건강(Long-term Health) 또는 **실질적 가치(Practical Value)**가 명백하다.
리스크 대비 이득이 크고, 회귀 가능성을 테스트/근거로 통제할 수 있다.

부분 수용(Partial Accept)

문제 제기 자체는 타당하나, 제시된 해결책이 최선이 아니거나 범위/타이밍이 부적절하다.
핵심 의도는 반영하되, 더 안전/단순한 대안으로 조정하거나 단계적으로 적용한다.

거절(Reject)

사양 위반, 기술적 근거 부족, 비용 대비 이득 불분명, 단순 취향/스타일, 또는 현재 코드/사양에 대한 오해가 있다.

작업 원칙(요약)

“리팩토링 자체”가 목표가 되지 않게 하고, 변경의 목표/효과/리스크를 문서화한다.
큰 변경은 작은 PR/단계로 쪼개고, 불확실하면 측정(벤치/프로파일/실험)으로 근거를 확보한다.
예외/실패는 가능하면 Result 패턴으로 제어하고, 숨은 사이드이펙트를 늘리는 분기/하드코딩/복붙은 피한다.

참고

최종 보고서 템플릿: references/final-report-template.md

このリポジトリの他の Skills

同じリポジトリ

execplan-planner

HuveD/agent-skillset

Create or update a self-contained ExecPlan Markdown file under `.agent/plans/` by synthesizing the current conversation (and any extra hint) and following `.agent/PLANS.md` exactly. Use when the user asks for plan mode, an execution plan, an ExecPlan, or wants a complex feature/refactor planned with explicit steps, validation, and file-level guidance.

2026-02-090

git-ops

HuveD/agent-skillset

Git 커밋 작성/실행과 PR 생성(gh pr create) 작업을 표준화한다. "커밋해줘", "commit 해줘", "PR 생성", "pull request 만들어줘", "gh pr" 같은 요청이나 Git 변경 요약·커밋 메시지·PR 본문 작성/생성이 필요할 때 사용한다.

2026-02-090

i18n-copy-manager

HuveD/agent-skillset

UI/앱/웹의 다국어(i18n/l10n) 문구를 작성·번역·검수·정비하고, 언어별 톤앤매너(Voice)를 일관되게 유지하며, 용어집(Glossary)·스타일 가이드·locale(JSON/ARB) 품질을 관리한다. “번역해줘”, “영문/일본어 문구”, “마이크로카피 다듬기”, “톤 맞춰줘(같은 언어에서 일관되게)”, “i18n 키/locale 파일 정리/검수”, “placeholder/ICU 메시지 확인” 같은 요청에 사용한다.

2026-02-090

local-crdb-perf-checker

HuveD/agent-skillset

Local-only CockroachDB 성능 점검 자동화 스킬. 로컬 CockroachDB 단일 노드를 띄우고(선택), 프로젝트 DDL을 로컬 DB에 적용한 뒤(seed SQL 실행 포함), 실행된 쿼리(Statement Statistics)와 선택된 쿼리의 EXPLAIN ANALYZE를 기반으로 성능 진단을 수행한다. 결과는 “개선 필요 항목 + 개선 방안”이 포함된 CSV로 출력한다. 원격/클라우드 DB 연결 문자열이면 즉시 실패해야 한다(로컬 DB만 허용).

2026-02-090

performance-marketer

HuveD/agent-skillset

Evidence-based paid performance marketing operating system across Meta, Google Ads, TikTok Ads, Apple Search Ads, and optional local ad platforms. Use when the user asks to audit, plan, optimize, or scale measurable paid campaigns (acquisition, retargeting, app install, ecommerce, lead generation), design KPI trees and measurement systems, or continuously monitor platform/policy/trend changes with proactive web research and recurring optimization actions. Do not use for brand PR, pure organic/social content calendars, or awareness-only requests without conversion instrumentation.

2026-02-090

predeploy-quality-gate

HuveD/agent-skillset

배포/머지 전에 현재 Git 브랜치(HEAD) 변경사항을 품질 게이트로 검증하고, 차단(BLOCKER)/경고(WARN)/제안(SUGGEST) 항목을 리스트로 리포트하기. "배포 전 품질 점검", "quality gate", "머지 게이트", "현재 브랜치 코드 품질 검증" 요청에 사용하기. 프로젝트 유형(Flutter/Node/Python/Go/Rust 등)을 자동 탐지해 포맷/린트/타입체크/테스트를 가능한 범위에서 실행하고, 리팩터링 후 미사용/미참조 코드 제거를 제안하기. 변경 범위가 크면 sub-agent로 리뷰를 병렬화하기.

2026-02-090

name	code-review-feedback-handler
description	코드 리뷰 코멘트/피드백을 받아 수용·부분 수용·거절로 분류하고, 최신 코드/호출 관계/사양/문서를 근거로 비판적으로 타당성을 검증한 뒤, 수용된 변경만 구현하고 최종 보고서를 작성한다. PR 리뷰 반영, 리뷰 코멘트 처리, 리팩토링 제안 검증/적용 요청에 사용한다.

코드 리뷰 피드백 처리(검토 + 적용)

목표

리뷰 코멘트를 “변경하지 않는 것이 기본”이라는 보수적 원칙으로 검토하고, 명백한 이득이 있는 변경만 반영한다.
단기 편의보다 장기적 유지보수성/확장성/안정성을 우선하고, 단순 취향 제안은 거절한다.

입력(권장)

리뷰 코멘트 목록(COMMENT): 각 항목에 원문, 파일/라인(또는 스니펫), 배경(왜 문제인지), 원하는 결과를 포함한다.
정보가 부족하면 구현/리팩토링부터 하지 말고, 먼저 필요한 질문을 한다.

워크플로(필수)

코멘트 분석: 핵심 주장/제안/의도, 기대 효과, 전제(가정)를 분리해 요약한다.
자율 코드 조사: 언급된 파일/라인을 기준으로 최신 코드를 직접 확인하고, 호출 관계/주변 맥락/테스트 영향 범위를 함께 조사한다.
사양 및 문서 검토(필수): 변경 대상 기능과 관련된 문서를 우선 확인한다.
- docs/specs/ 관련 사양서
- docs/ 내 아키텍처/설계 문서
- (존재 시) PROJECT.md, AGENTS.md
비판적 타당성 검증: 아래 “판정 기준”으로 수용/부분 수용/거절을 결정한다.
작업 진행(수용/부분 수용): 테스트 우선(가능한 범위)으로 최소 변경을 적용하고, SRP/Result/DRY/YAGNI를 준수한다. 사양에 영향이 있으면 사양을 먼저/함께 갱신한다.
최종 보고 작성: references/final-report-template.md 형식으로 결과를 정리한다.

판정 기준

수용(Accept)

사양/아키텍처와 정합하며, 장기적 건강(Long-term Health) 또는 **실질적 가치(Practical Value)**가 명백하다.
리스크 대비 이득이 크고, 회귀 가능성을 테스트/근거로 통제할 수 있다.

부분 수용(Partial Accept)

문제 제기 자체는 타당하나, 제시된 해결책이 최선이 아니거나 범위/타이밍이 부적절하다.
핵심 의도는 반영하되, 더 안전/단순한 대안으로 조정하거나 단계적으로 적용한다.

거절(Reject)

사양 위반, 기술적 근거 부족, 비용 대비 이득 불분명, 단순 취향/스타일, 또는 현재 코드/사양에 대한 오해가 있다.

작업 원칙(요약)

“리팩토링 자체”가 목표가 되지 않게 하고, 변경의 목표/효과/리스크를 문서화한다.
큰 변경은 작은 PR/단계로 쪼개고, 불확실하면 측정(벤치/프로파일/실험)으로 근거를 확보한다.
예외/실패는 가능하면 Result 패턴으로 제어하고, 숨은 사이드이펙트를 늘리는 분기/하드코딩/복붙은 피한다.

참고

최종 보고서 템플릿: references/final-report-template.md