<a id="skill-grooming-audit"></a>

스킬 Grooming 감사

<a id="shared-references"></a>

공통 참조

현재 설치된 소유 스킬에서 해당 분기 조건에 따른 기준을 읽습니다. 소유 스킬이나 자원이 없거나 일치하지 않으면 해당 행동을 중단합니다. 기억, 다른 설치본이나 승인받지 않은 설치를 이용하지 말고 tk-setup-skills를 사용합니다. 읽기만으로 workflow 실행이나 변경 권한이 생기지 않습니다.

• 사용자 소유 결정·누락된 승인·미충족 선행 조건을 질문이나 질문 도구 입력으로 제시하기 직전에 질문 라운드를 이번 작업에서 읽었는지 확인하고 누락했으면 먼저 읽습니다. 독립적인 결정과 승인은 각각 별도 질문으로 두며, 승인 선택지를 결정 질문에 섞지 않습니다.
• 사용자에게 완료 보고, 산출물 경로 인계나 여러 속성을 비교하는 채팅 응답을 전달하기 전에 채팅 전달을 읽습니다. 해당 작업의 구체적인 출력 계약이 우선합니다.

<a id="approval-continuity"></a>

승인 연속성

같은 작업에 대한 유효한 승인을 턴과 자식 단계 사이에서 재사용합니다. 변경 전 기준·변경 후 단계도 포함하며, 기존 담당자를 통해 승인된 작업만 계속합니다. 자식 단계·변경 전 기준 근거를 반환하고 승인된 담당 작업을 재개합니다. 단계 상태는 완료가 아닙니다. 새로운 중대한 결정, 범위·권한 변경이나 사용자만 제공할 수 있는 누락 입력이 있을 때만 질문합니다. 호출과 복구된 산출물은 권한을 부여하지 않습니다. 원격 행동과 파괴적 행동에는 행동·대상에 대한 명시적 승인이 필요하며, 로컬 승인에서 추론하지 않습니다.

기존 저장소·사용자 스킬, 지속 규칙이나 auto memory에 대한 명시적 호출, 명확한 감사 요청, 또는 지속 맥락을 따랐을 가능성이 있는 행동에 대한 사용자 교정이 있을 때만 적용합니다. 이들과 연결된 hook·plugin의 증상 요청이나 명시적 진단 요청도 포함합니다. 일반 정리, 구현 요청이나 지속 맥락 근거가 없는 실패에 자동으로 적용하지 않습니다. 암묵적 모드는 보고 전용입니다.

<a id="workflow"></a>

작업 절차

1. scope: 요청받은 범위, 리터럴 --apply, 대상 경로와 허용된 변경을 확인합니다. 현재 대화나 지속적으로 적용되는 근거에 명시된 제외 사항은 다시 확인하지 않고 보존합니다.
2. discovery: 기존 네이티브 스킬, 규칙과 auto-memory 경로를 읽고 요청 영역의 후보 목록을 만듭니다. 규칙, memory·자동 로드 색인이나 사용자가 교정한 행동이 범위에 있으면 지속 맥락을 읽습니다.
3. evidence: 모든 후보에 대해 영역별 관찰, 경로, 검증 상태와 소유권 근거를 기록합니다. 후보가 로컬 스크립트·참조·설정이나 이를 연결하는 agent·hook·ADR을 명시하면 구조와 의미 검증의 분리를 읽습니다. marketplace vendor 후보로 확인되면 최신성 근거를 확인합니다. 설치 스킬 의존성이 선언되어 있으면 해당 참조에 따라 최소 버전도 확인합니다. 사용자가 특정 복사 설치 외부 스킬의 출처·내용 변경 감사를 명시하면 복사 설치 감사를 읽습니다. 일반 감사에서 자동으로 확대하지 않습니다. 사용 빈도·자동 생성 산출물의 활용·비활성이 범위에 있거나 제거한 도구의 재권고를 검토하면 사용 근거를 읽습니다. 런타임·hook·plugin·기록·성능 진단을 요청했거나 감사 대상과 연결된 실행 증상이 있으면 런타임 근거를 읽고 관련 항목을 조사합니다. 호스트 런타임 전반을 감사하는 요청에는 최근 7일의 기본 진단을 포함합니다. 개별 스킬·문서의 중복·배치·트리거 검토만 요청했으면 해당 파일 범위에서 완료하며, 기록 파일이 있다는 이유로 런타임 조사로 확대하지 않습니다. 정적 감사·기록 조회 제외 등 기존 제한을 우선합니다. 암묵적 호출은 교정된 문제와 연결된 근거만 조사합니다. 감사 대상 코드·hook은 실행하지 않으며, 검증된 읽기 전용 진단과 별도로 승인된 격리 합성 재현만 해당 참조의 경계 안에서 허용합니다.
4. incident attribution: 이전 행동이 잘못되었다는 사용자 피드백이 있으면 그 행동이 인용했거나 관찰된 지침을 활성 스킬과 지속 맥락에 비교합니다. 현행 소유자와 충돌하는 것으로 입증된 폐기 지침은 stale override로 분류합니다. 파일 존재만으로 우선순위나 인과관계를 추론하지 않습니다.
5. description shortcut audit: frontmatter description을 다시 쓰기 전에 본문 로드를 대체할 수 있는 정확한 절차 요약 문구를 식별하고, 최소한의 라우팅 구분 기준을 보존하며, 이전·후보의 라우팅과 본문 동작을 비교합니다.
6. instruction economy audit: 기존 스킬이나 지속 지침 로드가 범위에 있으면 지침 경제성을 읽고 분기별 동작 비교를 적용합니다. 최신성, 충돌이나 귀속만 묻는 지속 memory 전용 사고에서는 읽지 않습니다.
7. model-fit audit: 요청이 대상 모델 적합성, 모델 변경이나 오래되었거나 지나치게 구체적인 프롬프트를 다루면 모델 적합성을 읽습니다. 지속 memory만의 최신성, 충돌이나 귀속 질문에서는 이 분기를 건너뜁니다.
8. classification/proposal: 스킬 후보에 배치 기준 표를 적용합니다. 스킬 행동은 keep | keep (vendor) | tighten | merge | split | move | deprecate | delete | fix로 분류합니다. 지속 맥락은 행동 제안 전에 duplicate | conflict | stale override를 발견 사항으로 사용할 수도 있습니다.
9. mutation tiers: 실제 변경 대상을 분류하기 전에 symlink를 해석합니다. 저장소가 범위에 있으면 git rev-parse --show-toplevel로 루트를 기록합니다. 대상이 연결된 worktree에 있으면 동일한 Git common directory인지 검증하고 해당 대상의 루트를 사용합니다. 해당 저장소 루트 밖은 T1, 안에 있지만 미추적이면 T2, 추적 대상이면 T3로 분류합니다. 소유 루트에서 git ls-files --error-unmatch -- <relative-target>를 사용합니다. 종료 0은 추적 대상, 종료 1은 일치 없음, 다른 오류는 근거 누락입니다. 저장소가 없는 사용자 전용 감사로 확인되면 Git 루트가 필요하지 않으며 대상은 T1입니다. 오류를 조용히 T1으로 취급하지 말고 그 범위와 접근 불가능한 저장소를 구분합니다. T2는 git check-ignore -v -- <relative-target>를 검사하여 ignored 파일과 일반 미추적 파일을 구분합니다. 링크 경로와 실제 경로, 공유 worktree 영향을 모두 기록합니다. 누락 경로, 깨진 링크나 실패한 Git 조회는 근거 누락이며 T1/T2가 아닙니다. tier는 변경 위치를 설명합니다. vendor 소유권과 행동 권한은 계속 적용됩니다.
10. 🔴 CHECKPOINT · 🛑 STOP: 전체 Disposition을 한 번 보여 준 다음 T1 -> T2 -> T3 순서에서 비어 있지 않은 다음 tier만 처리합니다. 정확한 항목, 근거, 대상, 공유 영향과 허용된 행동을 요약합니다. 일치하는 기존 승인을 재사용합니다. 최초의 리터럴 --apply는 검증된 기계적 범위만 사전 승인합니다. 그렇지 않으면 해당 tier만 질문합니다. 이전 tier를 적용하면 링크, 출처나 충돌이 바뀔 수 있으므로 이후 tier 승인은 질문 라운드의 종속 질문입니다. 빈 tier는 건너뛰고, 권한이 이미 다음 단계를 포함하면 체크포인트를 만들어 내지 않습니다. 현재 작업에 이미 포함되지 않은 T3는 기본적으로 추적 변경 소유자를 위한 정확한 인계 제안으로 남깁니다. 인계만을 위해 이슈, branch나 PR을 만들지 않습니다. 범위, 근거나 대상 변동은 영향을 받는 승인만 무효화합니다.
11. apply/report: 보고 전용 모드에서는 제안·결과 보고를 출력합니다. 권한이 있으면 출처를 다시 읽고, 삭제·이동 전에 참조를 검색하며, 관리·생성 표식을 보존하고, 승인된 결과 보고 범위만 수정합니다. T1/T2를 변경하기 전에 각 실제 대상을 되돌리기용 지속 백업 기준으로 복사·검증하고 절대 백업 경로를 보고합니다. 검증할 수 없으면 해당 변경을 중단합니다.
12. revalidate: 링크, 중복, frontmatter, 지속 맥락 충돌과 지침 정리의 근거가 된 모든 동작 비교를 재확인한 뒤 결과, 검증하지 못한 범위와 미해결 항목을 보고합니다. tier를 적용·검증한 후에는 나머지 tier의 경로, 소유권, 범위와 충돌 근거를 각 체크포인트 전에 다시 산정합니다. 검증이 실패하면 종속 변경을 중단합니다.

요청에서 명시하거나 관련이 드러난 저장소·사용자 스킬, 규칙과 auto-memory 영역만 조사합니다. 탐색의 실제 호스트 네이티브 경로를 사용합니다. 조건부 런타임 조사에서는 현재 호스트와 연결이 검증된 외부 memory 저장소도 읽기 전용 진단 대상으로 포함할 수 있습니다. 누락된 파일을 만들거나, memory backend를 만들어 내거나, 레거시·전역 TigerKit 상태를 이전하지 않습니다. 규칙과 memory 검사는 지속 지침의 건전성을 위한 것이며 일반 ticket, spec이나 저장소 문서 정리를 위한 것이 아닙니다.

저장소·사용자 스킬, 규칙과 auto-memory 항목은 파일 전체가 아니라 독립적으로 규범적 효력이 있는 지침·workflow 단위로 평가합니다. 정확한 네이티브 대상이 있을 때만 move를 사용하고, 독립적인 결과가 산출물 하나에 섞여 있으면 split을 사용합니다. 소유권, 종류, 범위나 의미를 바꾸지 않고 중복·모호함을 제거할 때만 tighten을 사용합니다. 그렇지 않으면 keep을 사용합니다. 경로나 소유권 근거가 없거나 충돌하면 해당 영역만 Partial/Blocked | Unverifiable로 처리합니다.

description 감사에서는 workflow 순서, 내부 라우팅, 승인 순서, 산출물 lifecycle이나 다른 절차를 본문 로드를 우회할 수 있을 만큼 요약하는 정확한 문구를 인용합니다. 스킬을 로드할지 결정하는 데 필요한 최소한의 트리거, 증상, 의도한 범위와 긍정·부정 라우팅 구분 기준만 보존합니다. 기계적으로 줄이지 않습니다. 잘못된 호출이나 필요한 호출 누락을 피하려면 더 긴 description이 필요한 경우 keep/no-op을 반환합니다.

확인된 경로와 링크 대상, 패키지 관리자 설치 위치, updater·버전 산출물과 검증 가능한 작성 이력으로 소유권을 결정합니다. 이름과 관례는 근거가 아닙니다. vendor 관리로 확인된 후보는 항상 keep (vendor)로 처리합니다. 품질상 발견 사항만 보고하고 제안이나 수정을 만들지 않습니다. 오래된 설치와 꺼진 자동 업데이트는 품질상 발견 사항으로 보고합니다. 호스트 업데이트·설정 행동은 안내만 하고 --apply를 포함하여 실행하지 않습니다. 소유권이 불확실하면 수정 제안 전에 멈추고 사용자 관리인지 외부 설치인지 질문합니다.

분류만으로 수정 권한이 생기지 않습니다. 승인 후에도 직접 담당하는 것은 의미를 보존하는 tighten, 정확한 대상을 갖는 기계적 move, 참조되지 않는 delete와 frontmatter·링크 fix뿐입니다. 규칙이나 auto-memory 삭제 또는 의미상 재작성에는 항상 정확한 항목 단위의 현재 작업 승인이 필요합니다. 의미적 merge, deprecate, workflow split과 의미적 스킬 재작성은 정확한 pending 제안으로만 남깁니다. 이 제안은 tk-retro 근거 검토에 활용할 수 있습니다. 승인된 의미 변경은 해당 구현 담당자의 소관입니다. 이 스킬은 다른 스킬을 호출하지 않습니다. 모든 적용 모드에서 vendor 관리 후보를 보고 전용으로 유지합니다.

교정된 행동과 연결할 수 있는 지속 지침이 없으면 후보를 보존하고 tk-retro 사고 검토를 권고합니다. 활성 스킬 계약 자체에 의미 변경이 필요하면 구현 담당자에게 정확한 제안을 남깁니다. 다른 스킬을 자동 호출하지 않습니다.

지식을 만들어 내거나 스킬 학습을 대신하지 않습니다.

현재 대화에서 선언한 제외 사항은 해당 대화의 이후 grooming 실행에서도 계속 제외합니다. 저장소·사용자 규칙이나 요청받은 다른 지속적 근거에 기록된 제외 사항은 세션 간에도 계속 제외합니다. 숨겨진 전역 상태를 만들거나 .tigerkit/에 제외 사항을 저장하지 않습니다.

접근, 소유권, 범위, 참조, 변동이나 검증 체크포인트가 실패하면 중단·보존·복원을 결정하기 전에 실패 처리를 읽습니다. 확인하지 않은 수정을 완료로 취급하지 않습니다.

<a id="contract"></a>

계약

근거는 요청한 각 영역의 실제 경로·내용을 기록합니다. 요청한 필수 범위에 근거가 없으면 해당 영역을 Unverifiable로 처리하며, 차단된 필수 영역이 하나라도 있으면 전체 완료를 주장할 수 없습니다. 요청 밖의 선택적 미측정 항목은 한계로 구분하고 완료 상태의 필수 조건으로 추가하지 않습니다. 범위를 줄여 실패나 누락을 숨기지 않으며, 실제 포함 범위와 남은 필수 공백을 명시합니다. Complete | Fail | Partial/Blocked | Unverifiable를 사용합니다.

<a id="output-contract"></a>

출력 계약

독립적으로 규범적 효력이 있는 각 지침·workflow에 최초 식별 순서대로 GR-01, GR-02, ...를 한 번 부여합니다. 먼저 ## Disposition 표 하나를 출력합니다.

적용한 변경과 검증에서도 같은 ID를 재사용합니다. 근거 누락, 소유권 충돌, 미해결 범위나 검증 실패가 있을 때만 ## Exceptions를 추가합니다. 변경 후에만 ## Applied와 ## Verification을 추가합니다. 표를 훑어보기 쉽게 유지합니다. 영향이 큰 발견 사항은 각각 별도 행에 두고, 영향이 작은 발견 사항은 감사한 대상 경로별로 묶되 각 항목의 ID, 행동, 대상과 근거를 유지합니다. 최소·최대 행 수를 부과하지 않습니다. 출력만을 위해 산출물·lifecycle 행동을 만들지 않습니다.

전체 report-only | applied 처리를 ## Disposition에 기록하되 표를 반복하거나 메타데이터를 덧붙이지 않습니다. 항목이 없으면 — | None | — | keep | — | no finding 행 하나를 출력합니다. vendor 행에는 keep (vendor)를 사용합니다. 분류 근거가 없으면 Tier에 Unverifiable을 사용합니다. 전체 표를 반복하지 않고 tier 체크포인트 사이에서 ID를 보존합니다. 오래된 vendor 설치는 Action을 keep (vendor)로 유지하고 설치 버전 또는 commit, 출처 버전 또는 commit과 자동 업데이트 상태를 Basis에 넣습니다. 알 수 없는 값은 Unverifiable로 표시합니다. 최신이라고 주장하지 말고 최신성 근거 누락을 보고합니다. 최신 설치이며 자동 업데이트가 켜진 것으로 확인되면 최신성만을 위한 행이나 예외를 추가하지 않습니다.

런타임 분기를 수행했으면 Disposition 바로 다음에 ## 런타임 발견 표를 추가합니다.

런타임 관찰에 Git Tier나 스킬 Action을 억지로 부여하지 않습니다. 관련 지침 변경 제안이 있으면 해당 GR ID를 연결하고, 승인·적용은 기존 Disposition과 tier 경계를 따릅니다. 진단만 있고 지침 후보가 없으면 Disposition은 기존의 항목 없음 행을 사용합니다. 측정 불가를 0으로 쓰지 않습니다. 차단된 필수 조사는 Exceptions와 전체 완료 상태에도 반영합니다.

증류 유지보수는 출처를 참조합니다. 일반 감사에는 필요하지 않습니다.

<a id="artifact-paths"></a>

산출물 경로

승인된 산출물 작성, checkout·전송·ignore 설정이나 임시 입력 소비 전에 산출물 경로를 읽습니다. 저장소 임시 작업에는 소유권이 확인된 안전한 nonsymlink 경로와 입증된 Git 제외를 사용합니다. 점검에 실패하면 해당 파일 분기를 중단합니다. 명시적인 최종 목적지와 담당자별 기본값을 보존합니다. 미리 채워진 입력은 완료된 입력이 아닙니다. 정리 대상은 기록된 리터럴 형태의 해석된 절대 경로 중 해당 실행이 소유한 경로뿐입니다. cwd 상대 경로나 glob은 사용하지 않습니다.