Files

T

DongHyeonkaandClaude Opus 5 edd45dfec6 feat(scripts): 종료 코드를 손으로 적을 수 없게 만들고 스킬에 버전을 붙인다

capture-evidence.py 는 명령을 subprocess 로 직접 돌리고 그 프로세스의 반환값을
그대로 메타에 적는다. 종료 코드를 인자로 받지 않으므로 손으로 적을 경로가 없다.
raw 원문과 실행 메타가 같은 이름으로 함께 떨어져 「raw 는 있는데 meta 가 없다」가
구조적으로 안 생긴다.

skill-versions.py 는 스킬 9개의 metadata.version 과 검사기 17개의 내용 해시를
한 장으로 낸다. 통과 판정을 검증기 버전에 묶으려면 묶을 값이 있어야 한다.
버전 칸이 없던 스킬 여덟에 1.0.0 을 붙였다. 산문은 한 줄도 안 바꿨다.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4vKjQo9KKBBokzxqXLCfk

2026-09-10 11:06:07 +09:00

2.5 KiB

Raw Blame History

name, description, metadata

name

description

metadata

refactoring-from-analysis

Use when a completed codebase analysis should be turned into one bounded, evidence-backed refactoring WorkItem and implemented in isolation.

version	language
1.0.0	ko-KR

Refactoring From Analysis

Goal

Use docs/<프로젝트> as high-value context for a bounded refactor while treating the current <분석 대상 저장소> as source truth. One execution handles at most one WorkItem.

Required sequence

Read <분석 대상 저장소>/refactor-queue.yaml and the selected docs/<프로젝트>/refactor/<project>/<item>/work-item.json.
Read the project's completed document-detail analysis and source anchors cited by the WorkItem.
Confirm the analysis queue entry is COMPLETE, its completed source revision equals current repository HEAD, and the source working tree is clean. Otherwise do not refactor.
Re-check the finding against current code. If it no longer exists, mark the item REJECTED with evidence; do not force a change.
Read references/refactor-queue-contract.md, references/work-item-contract.md, references/type-strategies.md, and references/evidence-contract.md. For PERFORMANCE, also read references/performance-evidence-contract.md.
Create/use an isolated Git worktree/branch for the WorkItem. Never implement directly in the analysis source checkout.
Follow the strategy selected by type and scope.
Preserve raw verification evidence under docs/<프로젝트>/refactor/<project>/<item>/.
Run scripts/verify-refactor-work-item.py <item-dir> before moving to WAITING_APPROVAL.

Performance ordering rule

For PERFORMANCE, the state/operation sequence is mandatory:

READY → BASELINING → baseline capture at analysisRevision → IN_PROGRESS → source change → VERIFYING → after capture under the same measurement contract → comparison → functional regression checks → WAITING_APPROVAL.

IN_PROGRESS means source-changing work is now allowed, so a performance item may not enter it until baseline raw evidence and baseline metadata exist. No source-changing refactor begins before that baseline exists. If comparable measurement conditions cannot be maintained, mark the item BLOCKED or the comparison INCOMPARABLE; never claim improvement.

Bounded change rule

If a WorkItem expands beyond its declared scope or uncovers an independent problem, stop expanding the diff. Create another candidate WorkItem instead. A large project or module is not permission for a large refactor item.

2.5 KiB Raw Blame History