build2-review

build2-review은(는) 무엇을 하나요?

ROOT 찾기

HERE는 이 SKILL.md가 포함된 디렉터리(시스템 컨텍스트의 절대 경로)입니다.

ROOT는 build2 스킬 트리입니다. 다음 후보 중 guides/packaging-guide-review.md가 존재하는 첫 번째 경로를 사용합니다:

1. HERE/../build2 (형제 레이아웃: 이 디렉터리가 build2 스킬 옆에 있는 경우, 사용자 레벨 스킬 디렉터리로 복사된 경우 포함)
2. HERE/../.. (중첩 레이아웃: 이 디렉터리가 build2 스킬의 skills/ 하위 디렉터리인 경우)

어느 것도 존재하지 않으면 중단합니다.

이후 모든 read_file 경로는 ${ROOT}/...입니다.

이것은 읽기 전용, 로컬 상태 점검입니다. 배포 전에 패키징 문제를 발견하기 위해 존재하며, cppget.org 리뷰어가 저장소에 대해 사용하는 동일한 체크리스트를 실행합니다. 절대 GitHub 이슈나 풀 리퀘스트를 생성, 댓글 달기, 병합하지 않으며, 브랜치를 푸시하지 않고, 이메일을 보내지 않으며, 리뷰 중인 저장소를 수정하지 않습니다(커밋 없음, 태그 없음, 파일 편집 없음, bdep release 없음, bdep publish 없음, git push 없음). 아래 단계에서 그러한 변경을 해야 한다면 건너뛰고 대신 보고된 결과로 전환합니다. 리뷰 대상 저장소는 이 검사가 시작될 때와 동일한 상태로 유지되어야 합니다. 보고된 결과에 대한 계획을 수립하는 것은 변경으로 간주되지 않습니다. 단, "Plan mode"에서 해당 사항이 적용되는 경우는 예외입니다.

${ROOT}/guides/packaging-guide-review.md의 체크리스트와 기준이 진리입니다. 체크리스트 항목을 복사하세요. 필요한 기준을 의역하지 마세요. 리뷰 기준을 임의로 만들지 마세요.

리뷰는 빌드 및 패키징 지원만 다룹니다. 업스트림 소스 품질, 업스트림 문서, 업스트림 C/C++ 스타일은 무시합니다.

엄격한 규칙

1. 외부에 보이는 변경 금지: 절대 GitHub 이슈나 풀 리퀘스트를 생성, 댓글 달기, 병합하지 않으며, 브랜치를 푸시하지 않고, 이메일을 보내지 않습니다. 이는 무조건적이며, 사용자가 실행 중에 명시적으로 요청하더라도 거절하고 별도의 수동 리뷰 워크플로우를 안내합니다(아래 "Stop and ask" 참조). 여기서 하지 마세요.
2. 리뷰 중인 저장소 변경 금지: 커밋, 태그, 파일 편집 없음, git push 없음, bdep release 없음, bdep publish 없음. 검사만 가능합니다(git log, git show, git diff, 파일 읽기). 항목을 확인하기 위해 빌드나 테스트가 필요하면, 리뷰 중인 저장소의 작업 트리 밖에서 임시 디렉터리에서 수행하세요.
3. 로컬 경로가 주어지면 그대로 읽기 전용으로 사용하세요. 다른 ref를 체크아웃하거나, stash하거나, 리셋하지 마세요.
4. 원격 저장소나 URL이 주어지면 /tmp/claude/ 아래 임시 디렉터리로 읽기 전용 클론하세요. 절대 푸시 가능한 리모트나 git push를 사용하지 마세요. 클론은 일회용으로 취급하세요.
5. 이번 실행에서 직접 확인하지 않고 체크리스트 항목을 체크하지 마세요.
6. 차단(blocking) 대 비차단(non-blocking)은 가이드의 기준을 따릅니다. 확실하지 않으면 개념적 buildfile 오류를 조용히 낮추지 말고 그렇게 말하세요.
7. 출력은 대화 내용의 보고서입니다(선택적으로 /tmp/claude/ 아래 임시 파일에 기록 가능). 외부에 게시하지 마세요.

필수 읽기 (결과 보고 전)

결과를 보고하기 전에 다음 파일을 read_file로 전체 읽으세요. 훑어보지 마세요.

1. ${ROOT}/guides/packaging-guide-review.md
2. ${ROOT}/guides/packaging-guide-antipatterns.md
3. ${ROOT}/HOWTO/package-naming.md
4. ${ROOT}/guides/packaging-guide-testing.md, Step 9 ("패키지 테스트")만. Step 10 ("배포")는 review를 main에 병합하며 여기서는 범위를 벗어나니 무시합니다.

필요에 따라 끝에 있는 맵에서 로드합니다. packaging-guide-review.md 내의 Initial Review Checklist가 실제로 작업할 체크리스트입니다. 그 파일이 유일한 사본입니다.

인자

$ARGUMENTS는 /build2-review (또는 /build2 review) 뒤의 텍스트입니다. 순서대로 파싱합니다. 첫 번째 일치하는 규칙이 우선합니다.

첫 번째 토큰	종류
비어 있음 / 생략	대상 확인 후 자동 감지
initial	전체 초기 제출 체크리스트
version	새 업스트림 버전, diff 기반
revision	새 패키징 리비전, diff 기반 + 추가 검사
그 외	<repo-or-local-path>로 처리하고 종류 자동 감지

나머지 토큰: <repo-or-local-path> (GitHub URL, owner/repo, 또는 로컬 클론 경로) 및 선택적 <version>. 대상이 없으면 질문하세요.

선택한 종류와 버전을 시작 전에 사용자에게 보고하세요.

저장소 가져오기

사용자가 로컬 경로를 제공하면 그대로 읽기 전용으로 사용하세요.

그렇지 않으면 임시 디렉터리로 읽기 전용 클론 (이 클론에 절대 푸시하지 않고, 다른 것의 푸시 대상으로 추가하지 않음):

git clone --recurse-submodules --shallow-submodules <url> /tmp/claude/<name>

분류

manifest의 version: 필드에서 <VERSION>을 결정합니다(여러 패키지가 있으면 최신 릴리스 태그). 종류를 결정합니다:

증거	종류
아직 릴리스 태그가 없거나, 리뷰 중인 ref가 여전히 첫 번째 bdep new 커밋	initial
vX.Y.Z 태그가 이미 존재하고 이 버전이 X.Y.Z+R	revision
이전 버전이 태그되었고 이것이 새로운 X.Y.Z	version

저장소의 첫 번째 커밋을 확인합니다(읽기 전용):

git log -p "$(git rev-list --all | tail -1)"

해당 커밋은 bdep new로 생성된 파일만 포함해야 하며, 메시지는 정확한 명령줄이어야 합니다. 편차가 있으면 결과로 기록하세요. 무시하지 마세요.

종류: initial

packaging-guide-review.md의 Initial Review Checklist 섹션에 있는 모든 항목을 저장소에 대해 작업합니다. 직접 확인한 후에만 항목을 체크합니다(트리, manifest, buildfiles, 설치 레이아웃, 테스트, 태그). 각 항목에 대해 메모리보다 링크된 HOWTO/guide를 사용하세요.

각 결과를 가이드에서 정확히 다음과 같이 분류합니다:

분류	경우
차단(Blocking)	높은 심각도 또는 영향, 많은 사용자, 개념적 오류(buildfiles의 잘못된 컴파일 옵션), 또는 호환성 깨짐 없이 나중에 수정 불가
비차단(Non-blocking)	리비전이나 다음 버전에서 수정해야 함, 검사 실패 아님
참고(Note)	관찰만

확인 중 필요 시 로드:

• 이름: ${ROOT}/HOWTO/package-naming.md
• 라이선스: ${ROOT}/guides/packaging-license.md
• 함께 제공되는 -tests 요약 / README: ${ROOT}/HOWTO/tests-extra-dependencies.md
• 비공개 헤더: ${ROOT}/HOWTO/third-party-private-headers.md
• 컴파일 옵션: ${ROOT}/HOWTO/buildfile-compile-options.md
• 하지 말아야 할 것: ${ROOT}/guides/packaging-guide-antipatterns.md
• buildfiles, manifest 또는 README의 일기 스타일 주석 또는 노트(과정 설명, 작동하지 않은 이전 접근법, 도중의 실수): ${ROOT}/guides/packaging-guide-antipatterns.md, "일기 스타일 주석이나 노트를 남기지 마세요"

"업스트림에 git 서브모듈과 심볼릭 링크 사용" 확인 시: 각 패키지 디렉터리에서 find . -type l -exec test -d {} \; -print도 실행하고 모든 결과가 해당 패키지의 <pkg>/.gitattributes에 일치하는 symlink=dir 항목을 가지고 있는지 확인합니다(${ROOT}/guides/packaging-guide-summary.md Step 5 참조). git은 심볼릭 링크 유형을 기록하지 않으므로, 이 항목이 없는 디렉터리 심볼릭 링크는 Windows 체크아웃에서 조용히 깨집니다. 누락된 항목을 차단으로 처리합니다.

설치 및 배포 테스트

체크리스트의 정적 검사만으로는 충분하지 않습니다. 또한 패키지를 out-of-tree로 빌드하여 빌드 시점에만 나타나는 문제(누락되거나 비공개 헤더가 설치 트리에 도달, buildfile 그래프에서 누락된 파일, 깨진 clean 규칙)를 잡아냅니다. /tmp/claude/ 아래 임시 디렉터리에서 이 작업을 수행하며, 절대 리뷰 중인 저장소 내부에서 하지 마세요. ${ROOT}/guides/packaging-guide-testing.md의 "Step 9: 패키지 테스트"를 따르세요:

1. 설치 버전: b install config.install.root=/tmp/claude/<name>-install, 그런 다음 설치된 복사본에 대해 out-of-source로 tests/를 빌드하고 실행합니다. 예상치 못한 것이 설치되지 않았는지 확인합니다(누락된 헤더 없음, 비공개 헤더가 실수로 설치되지 않음).
2. 소스 배포: b dist config.dist.root=/tmp/claude/<name>-dist config.dist.uncommitted=true, 그런 다음 추출된 아카이브에서 configure, update, test, clean을 실행합니다. 녹색 bdep test만으로는 충분하지 않으며, 이것이 cppget.org에서 실제로 패키지를 빌드하는 방식입니다.

이후 두 임시 디렉터리를 제거합니다. 실패를 결과로 기록합니다(설치나 배포가 올바르게 실패하는 패키지는 일반적으로 차단).

보고

가이드의 결과 코멘트와 동일한 섹션 레이아웃을 사용하여 결과를 사용자에게 제시하되, 외부에 게시하지 마세요:

차단 문제:

...

비차단 문제:

...

참고:

...

빈 섹션은 생략합니다. 임시 사본을 작성했다면 그 경로를 언급합니다.

종류: version

기준(이전에 리뷰된) 버전과 대상 버전을 비교합니다. 두 태그가 모두 클론에서 사용 가능하면 로컬 git diff <old-tag>..<new-tag>를 선호하고, 그렇지 않으면 GitHub 비교 보기를 사용합니다:

https://github.com/<owner>/<project>/compare/vOLD...vNEW

빌드 수준 호환성을 주시합니다: 이름이 바뀐 내보내진 대상이나 설정 변수는 업스트림 API가 안정적일 때에도 깨지는 변경입니다.

다음 중 하나를 보고합니다:

1. 실질적인 패키징 변경 없음, 문제 없음: 명확히 말하고 체크리스트 불필요.
2. 실질적인 패키징 변경 없음, 문제 있음: 직접 나열(체크리스트 없음).
3. 실질적인 패키징 변경 있음: 위의 전체 초기 절차 실행, 체크리스트 및 설치 및 배포 테스트 포함.

종류: revision

version과 동일하며, 다음 중 하나라도 해당하지 않으면 결과로 표시합니다:

• 변경 사항이 buildfiles, manifest 및 유사한 패키징 파일의 버그 수정으로 제한됨.
• 업스트림 소스 수정이 업스트림에서 백포트된 중요 버그로 제한됨.
• 대체하는 버전과 엄격히 하위 호환됨.
• 주요 구조적 변경 없음(소스 레이아웃, 내보내진 대상 이름, 설정 변수 이름).

Plan 모드

이 스킬은 어느 쪽이든 읽기 전용으로 유지되며, 직접 수정을 수행하지 않습니다. 변경되는 것은 보고서와 함께 필요한 변경 및 개선에 대한 계획이 초안 작성되는지 여부뿐입니다.

• 현재 세션이 plan 모드인 경우(어시스턴트가 변경을 수행하기 전에 구현 계획을 제안하고 승인을 받아야 하는 경우): 보고 후, 차단 및 비차단 결과를 해결하는 계획도 초안 작성한 다음, 환경이 제공하는 계획 승인 메커니즘을 통해 제시합니다. 계획을 차단 및 비차단 결과로 범위를 지정하고, 사용자가 요청하지 않는 한 참고는 건너뜁니다. 관련 수정을 그룹화하고, 생성된 bdep new 레이아웃, manifest 또는 buildfile 파일을 건드리는 수정이 특히 주의나 순서가 필요한 경우 이를 언급합니다.
• 그렇지 않으면 위의 확립된 보고 흐름을 따르고 거기서 중단합니다. 구현 계획을 초안 작성, 제안 또는 암시하지 마세요. 수정은 사용자 또는 별도의 워크플로우가 수행할 사항입니다.

중단 및 질문

다음 중 하나라도 해당되면 추측하지 말고 중단하세요:

• 버전이나 종류를 결정할 수 없습니다.
• 저장소에 접근할 수 없습니다(클론 실패, 로컬 경로 유효하지 않음).
• 첫 번째 커밋이 bdep new 커밋이 아니고 사용자가 이를 보고서에 어떻게 기록할지 결정하지 않았습니다.
• 호환성을 깨뜨릴 결과에 대해 차단 대 비차단이 불분명합니다.
• 사용자가 실제로 GitHub 리뷰 이슈/PR을 열거나, 무언가를 병합하거나, [email protected] 이메일을 보내달라고 요청했습니다. 이는 이 스킬이 수행하지 않는 별도의 범위 밖 워크플로우입니다.
• 사용자가 검사 대신 패키지를 생성해 달라고 요청했습니다(build2-package로 전환).

필요 시 맵

필요	파일
체크리스트 및 기준	${ROOT}/guides/packaging-guide-review.md
하지 말아야 할 것	${ROOT}/guides/packaging-guide-antipatterns.md
이름	${ROOT}/HOWTO/package-naming.md
라이선스	${ROOT}/guides/packaging-license.md
함께 제공되는 패키지	${ROOT}/HOWTO/tests-extra-dependencies.md
패키지 생성	../build2-package/SKILL.md