harness-legacy-check 감사 리포트를 읽어 항목을 risk 로 분류한 뒤,
이 플러그인에 이미 배포된 워크플로우(workflows/harness-refactor.js)를
args.changes / args.rejected 로 분류 결과만 넘겨 실행한다.
위험한 항목은 실행하지 않고 Final Report 의
"Human Approval Required" 섹션에만 남긴다.
읽기 전용이 아니라 실제로 하네스 파일을 고친다.
/harness:harness-legacy-check 를 이미 돌려 감사 리포트를 받았고, 지적된 것 중 안전하게 자동화할 수 있는 부분을 실제로 적용하려 할 때.SKILL.md + references/ 로 분리.settings.json 의 stale 권한 항목 제거./harness:harness-legacy-check 가 먼저다. 이 스킬은 감사를 대신 수행하지 않고, 리포트를 못 찾으면 Step 1 에서 그냥 중단한다.CLAUDE.md / AGENTS.md / GEMINI.md 문서 하나를 점검하거나 새로 만드는 일은 harness:ai-context 의 몫이다./harness:harness-refactor /harness:harness-refactor -h | --help | help
인자를 받지 않는 스킬이다. 대상 리포트도, 적용 범위도 위치 인자로 지정하지 않는다.
| 인자 | 기본값 | 설명 |
|---|---|---|
| (없음) | — | 리포트 경로는 고정 탐색 순서로 결정된다(아래 Step 1). 사용자가 지정하지 않는다. |
| -h / --help / help | — | references/help.md 를 그대로 출력하고 중단. 파일 변경 없음. |
고정된 순서로 찾는다: (1) .claude/reports/harness-legacy-check.md 파일이 있으면 읽어서 사용,
(2) 없으면 현재 세션에 남은 harness-legacy-check 출력을 찾는다,
(3) 둘 다 없으면 "harness-legacy-check 결과가 없습니다. 먼저 /harness-legacy-check 를 실행해 주세요." 를
출력하고 중단한다. 리포트를 지어내거나 감사를 즉석에서 대신 하지 않는다.
리포트의 각 항목을 references/classification-rules.md 기준으로 워크플로우에 넣을 것(허용 변경)과
넣지 않을 것(절대 금지)으로 가른다. 이 분류와 Step 3 의 사전 승인이 이 스킬의 안전 계약이다 — 두 목록은 아래 05 절에 그대로 있다.
분류 결과(changes 는 파일별 한 줄, rejected 는 건수와 사유)를 출력하고
"이대로 적용할까요?" 에 대한 응답을 기다린다. 승인 전에는 Workflow 를 호출하지 않고,
거부 시 [FAIL] harness:harness-refactor — 사용자 미승인 으로 중단한다. 이 시점까지
디스크에 쓴 것은 없다.
Workflow({ name: 'harness:harness-refactor', args: { changes: <Step 2 changes>, rejected: <Step 2 rejected> } }).
워크플로우 스크립트(workflows/harness-refactor.js)는 이 플러그인에 이미 배포되어 있다 —
매 실행마다 모델이 새로 작성하지 않는다. 호출마다 바뀌는 것은 Step 2 에서 분류한
args.changes / args.rejected 뿐이다. 내부적으로 4개 phase 로 진행된다:
Pre-flight(대상 파일 존재 확인 + 아카이브 디렉토리 생성, 파일 수정 없음) → Apply Changes(parallel() 로
비중첩 파일 그룹을 나눠 맡은 에이전트들이 각각 아카이브 후 수정하고 구조화된 결과를 돌려줌) → Verify(wc -l
비교와 references/ 파일 생성 여부 확인) → Final Report. Step 2 에서 금지로 분류된
rejected 항목은 워크플로우 본문에 적용되지 않고 Final Report 의 "Human Approval Required" 섹션에만 기록된다.
[OK] harness:harness-refactor — 완료 아래에 변경 파일 수, 생성된 references/ 수, 아카이브 수,
human review 필요 항목 수, 그리고 다음 행동(git diff 확인 후 /gh-pr:commit)을 적는다.
실패 시 [FAIL] harness:harness-refactor — <이유>.
리포트가 아무리 강하게 권해도 오른쪽 여섯은 워크플로우에 들어가지 않는다. Final Report 의 "Human Approval Required" 섹션에 기록될 뿐이다.
.claude/archive/harness-refactor-YYYY-MM-DD/ 로 이동
짝 스킬과 헷갈리기 쉬운 지점이다. harness-legacy-check 는 read-only 이지만,
harness-refactor 가 실행하는 워크플로우는
CLAUDE.md / AGENTS.md / SKILL.md / settings.json 을 실제로 수정한다.
호출 전에 작업 트리가 깨끗한지 확인한다. 사전 게이트는 Step 3 의 사용자 승인이고,
호출 후 git diff 검토는 그 뒤의 2차 확인이다.
제거 대상은 지우는 대신 .claude/archive/harness-refactor-YYYY-MM-DD/ 로 옮긴다.
잘못 판단한 삭제를 되돌릴 수 있게 하려는 것이므로, 워크플로우를 손볼 때도 이 아카이브 단계를 건너뛰지 않는다.
workflows/harness-refactor.js 는 이 플러그인에 체크인된 실제 파일이고,
호출마다 다시 생성되는 것이 아니다. 실행마다 바뀌는 것은 Step 2 가 분류한
args.changes / args.rejected 뿐이다. 스크립트 자체를 고치려면
플러그인 소스를 직접 편집해야 한다.
감사 리포트를 어느 경로로도 찾지 못하면 아무것도 하지 않고 멈춘다.
이때 스킬은 감사를 대신 실행하지 않으며, /harness-legacy-check 를 먼저 돌리라고만 안내한다.
Step 4 는 Claude Code 의 Workflow 도구를, 병렬 적용은 서브에이전트 오케스트레이션을 전제한다.
다른 하네스에서는 해당 기능의 대응 도구를 references/*-tools.md 매핑에서 찾아야 하고,
metadata 상 non-Claude 하네스에서는 advisory-only 다.