wp-project-triage

wp-project-triage 개요

wp-project-triage가 하는 일

wp-project-triage는 WordPress 저장소를 빠르게, 그리고 결정적으로 1차 판별하는 스킬입니다. 프로젝트 유형을 추정하고, 사용 중인 도구와 테스트 체계를 감지하며, 버전 힌트를 드러내고, 구조화된 보고서를 반환해 줍니다. 덕분에 추측 없이도 다음에 어떤 워크플로를 택해야 할지 판단할 수 있습니다. Workflow Automation에서 wp-project-triage가 필요하다면, 이 스킬은 에이전트가 아무것도 수정하기 전에 다음 행동을 결정하도록 돕는 유형입니다.

누가 사용해야 하나요

WordPress 코드베이스에 갑자기 투입되어, 이 저장소가 플러그인인지 테마인지, 블록 테마인지, 사이트 저장소인지, WP core인지, Gutenberg 관련 저장소인지 알아내야 할 때 wp-project-triage skill을 사용하세요. 구현, 리뷰, 테스트에 들어가기 전에 반복 가능한 트리아지 단계를 두고 싶은 에이전트와 유지보수자에게 특히 유용합니다.

무엇이 다른가요

wp-project-triage의 핵심 가치는 서술형 요약이 아니라 의사결정 지원입니다. 저장소 신호를 읽고, 가드레일을 적용한 뒤, 일반적인 프롬프트보다 더 신뢰할 만한 JSON 보고서를 내놓습니다. 그래서 몇 개의 파일명만 보고 LLM에게 “이 저장소를 파악해 달라”고 맡기는 것보다 훨씬 적합합니다.

wp-project-triage 사용 방법

설치하고 저장소 루트에 연결하기

wp-project-triage install을 할 때는 표준 skills 명령으로 에이전트 워크스페이스에 스킬을 추가한 뒤, 저장소 루트에서 실행하세요. 그래야 탐지기가 실제 프로젝트 구조를 검사할 수 있습니다. 이 스킬은 bash와 Node가 있는 파일시스템 기반 환경을 전제로 하며, 일부 워크플로에서는 WP-CLI도 필요합니다.

먼저 이 파일들을 읽으세요

먼저 skills/wp-project-triage/SKILL.md를 읽고, 그다음 references/triage.schema.json을 확인해 보고서 구조를 파악하세요. 저장소에는 scripts/detect_wp_project.mjs도 포함되어 있는데, 분류와 신호 탐지가 어떻게 동작하는지 이해하고 싶다면 가장 중요한 파일입니다. 디렉터리 트리를 대충 훑어보는 것보다 이 세 파일이 훨씬 많은 정보를 줍니다.

모호한 목표를 유용한 프롬프트로 바꾸기

좋은 wp-project-triage usage 프롬프트는 단순히 스캔을 원한다고 말하는 게 아니라, 무엇을 판단하려는지 분명히 드러냅니다. 예를 들어 이렇게 말할 수 있습니다. “이 저장소에서 wp-project-triage를 실행하고, 플러그인인지 블록 테마인지, 어떤 도구가 들어 있는지, 코드를 바꾸기 전에 따라야 할 가드레일이 무엇인지 알려줘.” 이렇게 하면 스킬이 실행 가능한 트리아지 보고서를 만들기에 충분한 의도를 얻습니다.

보고서로 다음 워크플로를 선택하기

탐지기가 실행되면 출력 결과를 바탕으로 빌드 설정, 테스트 구성, 버전 제약, 콘텐츠 구조 중 무엇을 더 봐야 할지 정하세요. 보고서가 unknown이라면, 올바른 루트에서 실행하고 있는지 확인하거나, 저장소에 추측을 강요하기보다 탐지 규칙을 개선해야 한다는 신호로 받아들이세요. theme.json, block.json, 빌드 도구처럼 구조를 바꾸는 요소를 추가했다면 탐지기를 다시 실행하세요.

wp-project-triage 스킬 FAQ

wp-project-triage는 WordPress 저장소에만 쓰나요?

네, 원래 의도된 사용처가 그렇습니다. wp-project-triage guide는 플러그인, 테마, 블록 테마, 사이트 저장소, core, Gutenberg 같은 WordPress 프로젝트 형태를 대상으로 설계되었습니다. 이 생태계 밖에서 작업한다면, 일반적인 파일시스템 스캔이나 다른 저장소 분류 도구가 보통 더 나은 선택입니다.

사용하려면 WP-CLI가 꼭 필요한가요?

항상 그런 것은 아닙니다. 파일시스템만 있는 환경에서도 이 스킬은 도움이 되지만, 이후 워크플로 중 일부는 WP-CLI나 WordPress 관련 도구를 기대할 수 있습니다. wp-project-triage의 목적은 무엇이 있는지 알려 주어, 후속 단계가 현실적인지 판단하게 하는 데 있습니다.

AI에게 저장소를 직접 보게 하는 것보다 나은가요?

대개 첫 단계에서는 그렇습니다. 일반 프롬프트는 버전 힌트를 놓치거나, 신호를 무시하거나, 트리가 애매할 때 구조를 지어낼 수 있습니다. wp-project-triage는 반복 가능한 설치 및 실행 경로, 정의된 출력 계약, 더 좁은 작업 범위를 제공합니다. 먼저 분류하고, 그다음 행동하는 방식입니다.

언제 사용하지 말아야 하나요?

코드 리뷰, 보안 감사, 심층 아키텍처 분석의 대체 수단으로 쓰지 마세요. 이건 진단 전체가 아니라 트리아지 레이어입니다. 이미 정확한 프로젝트 유형을 알고 있고, 특정 코드 작업이 필요한 상황이라면 이 단계를 생략해도 됩니다.

wp-project-triage 스킬 개선 방법

시작 조건을 더 깔끔하게 만들기

wp-project-triage 결과를 가장 확실하게 개선하는 방법은 진짜 저장소 루트에서 실행하고, 부분 체크아웃이나 중첩된 작업 디렉터리를 피하는 것입니다. 탐지기가 잘못된 폴더를 스캔하면 보고서는 바로 덜 유용해집니다. 이는 복잡한 프롬프트보다 훨씬 중요합니다.

판단을 바꾸는 컨텍스트를 제공하기

더 나은 wp-project-triage usage 결과를 원한다면, 필요한 구체적 결과를 언급하세요. 예를 들어 플러그인 vs 테마 분류, 빌드 도구 탐지, 테스트 준비 여부 같은 것들입니다. 그러면 다음 단계에 쓸 만큼 보고서가 충분한지 판단하기 쉬워집니다. 좋은 후속 프롬프트는 “전체를 요약해 줘”보다 “가장 안전한 최소 수정 경로를 알려줘”처럼 물어보는 방식입니다.

흔한 실패 모드를 점검하기

가장 흔한 실패 모드는 신호가 부족하거나, 저장소 배치가 특이하거나, 무시된 디렉터리 때문에 unknown 또는 과도하게 느슨한 분류가 나오는 경우입니다. 또 다른 실패는 생성된 파일은 많지만 소스 힌트가 약한 저장소에서 첫 보고서를 지나치게 신뢰하는 것입니다. 이런 경우에는 즉흥적으로 추측하지 말고 탐지 입력을 개선하거나 ignore 규칙을 확장하세요.

첫 실행 후 반복하기

첫 보고서로 빈틈을 찾은 다음, theme.json, block.json, 테스트 설정, 버전 메타데이터처럼 빠진 힌트를 추가한 뒤 wp-project-triage를 다시 실행하세요. 이 스킬은 탐지, 검증, 조정, 재탐지라는 반복형 가드레일로 쓸 때 가장 잘 작동합니다.