Community라이팅 & 에디팅github.com

ayrtonvwf/skills

이식 가능한 SKILL.md 기반 에이전트 스킬로, 자동화된 LLM 평가 도구(Microsoft Waza)와 읽기 전용 모의 MCP 서버를 포함합니다. Claude Code, Copilot, Cursor, OpenCode 등 여러 플랫폼에서 사용할 수 있습니다.

skills란 무엇인가요?

이 스킬은 GitLab Merge Request(MR)의 리뷰 준비 상태를 평가하고, 그 결과를 마크다운 파일로 작성하여 MR 노트에 바로 복사할 수 있도록 돕습니다. 개발자가 MR을 검토하기 전에 컨텍스트, 범위 명확성, 테스트 지침, 리뷰어 가이드라인이 충분히 갖춰져 있는지 판단합니다. 잘 준비된 MR은 더 빠르고 정확한 리뷰를 받을 수 있으며, 이 스킬은 좋은 MR을 인정하고 부족한 MR에 구체적이고 격려적인 개선 단계를 제시합니다. 코드 자체를 리뷰하거나 수정을 제안하지 않으며, 설정 파일을 통해 출력 언어, 톤, 도구 등을 사용자 정의할 수 있습니다. Claude Code, Cursor, Copilot, OpenCode 등 다양한 AI 에이전트 플랫폼에서 실행됩니다.

지원 대상✓Claude Code~Codex CLI✓Cursor✓OpenCode
npx skills add ayrtonvwf/skills

Installed? Explore more 라이팅 & 에디팅 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

mr-feedback

GitLab Merge Request를 가져와서 리뷰할 준비가 얼마나 되었는지 평가하고, 피드백 보고서를 새 마크다운 파일로 작성하여 MR 노트에 바로 복사할 수 있도록 합니다.

수행할 작업

리뷰 준비 상태를 판단합니다. MR에 리뷰어가 효율적으로 리뷰를 시작할 수 있도록 컨텍스트, 범위 명확성, 테스트 지침, 리뷰어 가이드가 포함되어 있는지 확인합니다.

이유

잘 준비된 MR은 배려를 나타내며 더 빠르고 더 나은 리뷰를 받습니다. 보고서는 좋은 MR이 인정받고 있다는 느낌을 주고, 약한 MR에는 준비 상태를 높이기 위한 구체적이고 격려하는 단계를 제시해야 합니다.

하지 말아야 할 것

코드 자체를 리뷰하거나 비판하지 말고, 코드/로직 변경을 제안하지 마십시오.

환경 설정

다른 작업을 하기 전에, 이 스킬 기준의 reference/preferences.md를 읽으십시오. 이 파일은 출력 언어, 톤, 가져오기 방법, 허용된 도구, 출력 경로 등 구성 가능한 모든 동작의 진실 공급원입니다. 이 SKILL.md는 해당 값을 다시 기술하지 않습니다. 항상 환경 설정 파일에서 읽으십시오.

우선 순위(높은 순):

  1. 사용자의 현재 요청에 명시된 지침(예: "이번에는 포르투갈어로 작성해 주세요").
  2. reference/preferences.md.
  3. 이 스킬의 지침.

입력

사용자는 다음 중 하나를 제공합니다.

  • 전체 MR URL: https://gitlab.com/<group>/<subgroup>/<project>/-/merge_requests/<iid>
  • 프로젝트 경로 + MR iid: group/subgroup/project + 42

URL에서 다음을 파싱합니다.

  • project_id = 호스트와 /-/merge_requests/ 사이의 경로(도구 호출 시 group%2Fsubgroup%2Fproject와 같이 URL 인코딩)
  • mergeRequestIid = /-/merge_requests/ 뒤의 숫자

둘 중 하나라도 누락되었거나 모호하면 가져오기 전에 질문하십시오.

워크플로우

reference/preferences.md에 선언된 방법과 도구를 사용하십시오. 아래 단계는 어떤 정보를 수집하고 그 이유를 설명하며, 어떤 도구를 호출할지 명시하지 않습니다 - 각각에 대해 환경 설정에서 일치하는 도구를 선택하십시오.

  1. MR 메타데이터 - 제목, 설명, 작성자, 상태, 소스/타겟 브랜치, 초안 플래그, 레이블, 마일스톤, 승인, 병합 상태.
  2. 변경된 파일 목록 - 경로 + 추가/삭제 횟수; 모든 diff를 가져오지 않고 범위/크기를 제공합니다.
  3. 설명이 실제와 일치하는지 확인하기 위한 샘플 diff - 3-5개 파일씩 배치로. 범위와 테스트가 수정되었는지 확인하는 용도로만 사용하고, 코드를 비판하지 마십시오. 잠금 파일, 생성된 파일, 순수 이름 변경 파일은 건너뛰고, MR이 거대하면 샘플링하십시오.
  4. 커밋 - 커밋 위생/원자성 신호(커밋 수/추가 요약)를 위해 MR 메타데이터(1단계)에 이미 포함된 커밋 요약을 사용하십시오.
  5. CI 상태 - MR에 대한 최신 파이프라인 상태(통과/실패/없음).
  6. reference/rubric.md의 루브릭에 따라 평가합니다.
  7. reference/report-template.md를 사용하여 보고서를 새 파일에 작성합니다(출력 참조).
  8. 사용자에게 파일 경로를 알리고, 복사하여 붙여넣기 전에 톤/길이를 조정할 수 있도록 제안합니다.

점수를 매기기 전에 reference/rubric.md를 읽고, 작성하기 전에 reference/report-template.md를 읽으십시오. 데이터를 임의로 만들지 마십시오 - 특정 범주(예: 파이프라인 없음)에 대해 가져오기가 아무것도 반환하지 않으면 추측하지 말고 "사용 불가"로 표시하십시오.

각 루브릭 범주에는 작성자에게 왜 중요한지 설명하는 이유가 포함되어 있습니다. "준비 상태를 높이기 위해"에서 격차를 보고할 때는 항상 작성자에게 왜 중요한지 포함하십시오 - 피드백이 단순한 요청이 아니라 각 요청의 목적을 설명해야 합니다.

범주 이유를 그대로 복사하지 마십시오. 이유는 전체 범주를 다루는 배경 정보입니다; 발견한 정확한 문제에 맞게 다시 작성하십시오. 잘못된 특정 사항만 참조하고, 범주에서 괜찮은 측면은 언급하지 마십시오. 예를 들어, 브랜치가 master보다 뒤처져 있지만 파이프라인이 녹색이면, master보다 뒤처진 것이 왜 중요한지만 설명하고 파이프라인은 전혀 언급하지 마십시오(통과했으므로). "왜 중요한지"는 이 특정 MR의 격차에 대해 사실이어야 하며, 범주에 대한 일반적인 진술이 아니어야 합니다.

출력

reference/preferences.md에 선언된 출력 경로에 작성하고, 해당 경로의 플레이스홀더를 해결하고 필요한 모든 폴더를 만드십시오.

가드레일

  • 읽기 전용. 이 스킬은 MR에 노트를 게시하거나, 승인하거나, 수정하지 않습니다. 로컬 마크다운 파일만 작성합니다. 사용자가 그것을 붙여넣을지 결정합니다.
  • 보고서에 diff에 나타날 수 있는 비밀/토큰을 포함하지 마십시오.
  • MR이 초안이거나 아직 diff가 없는 경우에도 평가하고 보고서를 생성할 수 있지만, 그 점을 명시적으로 밝히십시오.

관련 스킬