implement

name

implement

description

Use when writing or modifying code in this project — 구현 착수, 플랜 실행, 버그 수정, 리팩토링 등 코드 diff를 만들기 시작하는 모든 시점. 직접 수정이든 서브에이전트 dispatch 구현이든 무관 — 코드는 서브에이전트가 만지고 메인 세션은 브리프만 쓰는 경우에도 첫 dispatch 전에 invoke한다. 플랜 파일 유무와 무관하게 적용. superpowers 코딩 절차(test-driven-development·executing-plans·subagent-driven-development)를 대체하지 않는 컴패니언 — 프로젝트 종속 절차(변경 경로→테스트 스킴 계산, tuist generate 시점, 짝지어진 두 위치, rules·구조 패턴 확인, 리팩터 게이트, 완료 판정)를 주입한다. Triggers on "구현하자", "플랜 실행하자", "고치자", "리팩토링하자", "서브에이전트 시켜서 구현하자" 등 코드 수정이 시작될 때 — superpowers 코딩 스킬과 함께 invoke. Does NOT trigger on 코드 조회·분석·설계 논의만 할 때.

Implement — TodoCalendar 구현 컴패니언

superpowers 절차의 대체가 아니다. TDD 사이클·플랜 실행 흐름은 superpowers 스킬이 이끈다. 이 스킬은 그 위에 TodoCalendar 종속 지식과 게이트를 주입한다.

채점 4축 좌표계 (#690)

작업 결과물(코드) 채점은 4축 순차 관문이다 — 이 스킬이 축13 관문을 집행하고, 축4는 review 스킬 소관. 축4에서 잡힌 finding은 "축13 중 어디서 잡혔어야 했나" 누수 태깅(axis_leak 레코드, review 스킬)의 좌표로 이 축 번호를 쓴다.

축	질문	관문
1 명세의 TC 표현	TC가 명세를 나타내는가	RED 직후 한 줄 선언 (§구현 중)
2 동작 무오류	동작 무오류가 TC로 드러나는가	GREEN — 무조건 통과
3 구현 품질	효율(복잡도)·역할 분배·협업이 합리적인가	리팩터 게이트
4 종합 검사	기획 홀·엣지케이스·논리 모순·false positive test·보안·축1~3의 논리적 완결성	PR 리뷰 — 이 스킬 밖

축1~3 실시간 관문은 통과 선언만 남기고 레코드는 쌓지 않는다 — 기록은 소비자(누수 분석)가 있는 축4 쪽에서만.

착수

플랜 파일 유무로 흐름만 갈리고 절차는 동일하다:

• 플랜 있음 → superpowers executing-plans/subagent-driven-development가 태스크 순서를 이끈다. 각 태스크에 아래 절차를 적용한다.
• 플랜 없음 (즉흥 수정) → superpowers TDD + 이 스킬만으로 진행한다. 플랜 단계만 빠질 뿐, rules 확인 → 패턴 파악 → 구현 → 완료 판정은 동일하게 탄다.
• 페어 프로그래밍 모드 (유저가 명시 선언한 세션) → 턴 규칙·TDD 수준·커밋 시점은 pair-programming 스킬이 이끈다. 이 스킬은 프로젝트 종속 규칙(rules·tuist generate·짝지어진 두 위치·콜사이트 grep) 공급자로만 동작한다.
• 서브에이전트 dispatch 구현 (subagent-driven-development·병렬 dispatch 등) → 서브에이전트는 이 스킬을 스스로 invoke하지 못한다. dispatch하는 메인 세션이 첫 브리프 작성 전에 이 스킬을 invoke하고, 아래 절차를 브리프로 승계시킨다. "내가 직접 코드를 안 만지니 해당 없음"은 성립하지 않는다 — 코드 diff가 시작되는 주체가 누구든 발동한다. 갭 보고 루프(rules·플랜)의 유저 반문은 메인 세션이 중계한다 — 브리프에 "갭 발견 시 추측으로 채우지 말고 보고 후 중단"을 명시한다.

시작할 때:

• 베이스 브랜치 — 브랜치 지정 지시가 없으면 최신 develop을 pull(git pull origin develop)한 뒤 거기서 features/ 브랜치를 딴다. 이미 지정된 작업 브랜치에 있으면 유지.
• 변경 대상 경로에 걸리는 .claude/rules/*.md 조항을 확인하고, 구현 결정 시점에 해당 조항을 적극 invoke한다.
• child CLAUDE.md가 있는 프레임워크(Domain·Repository·각 Presentation 등)를 수정할 땐 해당 child CLAUDE.md를 확인하고, 수정 후 그 규칙과 어긋남이 없는지 재점검한다.
• 동종 컴포넌트를 grep해 구조 패턴(상태관리·합성·추상화 수준)을 파악하고 그 패턴을 따른다. 요구사항만 보고 즉흥 구현하지 않는다.
• 서브에이전트에 구현을 dispatch할 땐 프롬프트에 적용 rules 조항·대상 테스트 스킴·따라야 할 구조 패턴을 명시한다.
• (선택) 기존 타입을 수정하는 작업이면 복잡도 baseline을 측정해둔다 — 아래 "복잡도 측정" 참조. 생략 조건에 걸리면 그냥 건너뛴다.

구현 중

• RED 직후 축1 선언 — 방금 쓴 TC가 표현하는 명세 항목(플랜 태스크 성공 기준·이슈 스펙 조항)을 축1: <TC명> ⇢ <명세 항목> 한 줄로 선언한다. 명세를 못 담는 TC면 GREEN으로 가지 않고 TC부터 재작성한다.
• 파일 추가/삭제/이동 직후 mise exec -- tuist generate --no-open — 미루면 빌드·테스트가 이전 프로젝트 구조로 돈다.
• 객체 시그니처(특히 init) 변경 시 콜사이트 전수 grep — 수정 전에 참조처를 확인한다. 이 짝은 스크립트가 못 잡는다.
• Query/Command 분리 유지 — 읽기와 사이드이펙트를 한 흐름에 섞지 않는다.

Rules 갭 보고 루프

지금 하려는 결정이 rules·기존 패턴 어디에도 커버되지 않으면(선례 없는 컴포넌트 유형, 조항 간 충돌, 조항이 모호해 두 구현이 다 성립) 추측으로 채우지 말고 유저에게 보고한다.

• 유저가 준 해결책으로 구현을 잇는다.
• 그 해결책은 rules 고도화 후속으로 예약한다 — 잃어버리지 않는 것이 불변 조건. 형태(이슈 따기 / 같은 PR 내 rules 커밋 / 별도 커밋)는 그 시점에 유저와 결정한다.

플랜 갭 보고 루프

플랜(또는 유저 지시)이 커버하지 않는 상황을 실행 중 만나면 — 예상 밖 의존 발견, 플랜에 없는 결정 분기, 범위 밖 결함 — 추측으로 채우지 말고 유저에게 선택을 반문한다.

• 유저 답으로 실행을 잇는다.
• 범위 밖 작업으로 드러난 것은 후속 이슈로 따거나 같은 이슈 내 추가 할일로 정리한다 — 형태는 그 시점에 유저와 결정. 잃어버리지 않는 것이 불변 조건.
• 이 루프는 우발상황의 escape hatch다. 빈발하면 플랜 단계의 범위 명확성이 부실했다는 신호 — 그 사실도 유저에게 함께 보고한다.

리팩터 게이트 (축3) — 매 GREEN 직후

superpowers TDD의 REFACTOR 단계를 이 게이트로 수행한다. 아래 선언 없이 다음 단계(다음 RED 또는 완료 판정)로 넘어가지 않는다.

스멜 스캔 — 이번 diff가 만진 코드 + 그 중복 상대까지만:

• 중복 — 같은 지식이 두 곳에. Rule of Three: 세 번째 중복은 무조건 제거
• 의도 은폐 — 이름이 처리 케이스를 드러내는가, 함수가 한 추상화 수준을 유지하는가
• 조건 분기 반복 — 같은 분기가 여러 곳 → enum exhaustive switch·다형성으로 한 곳에
• Feature Envy·Data Clumps — 로직은 데이터 곁으로, 항상 같이 다니는 값 묶음은 타입으로
• Speculative Generality — 소비자 없는 추상·안 쓰는 파라미터 제거 (YAGNI)
• 프로젝트 축 — Query/Command 섞임, imperative loop → functional, mutable var 수동 합성 → CombineLatest 선언적 합성

종료 판정 = Simple Design 4규칙 (우선순위순). 전부 만족해야 "불필요" 선언 가능:

1. 테스트 전부 통과
2. 의도가 드러남 — 본문을 안 열어도 뭘 하는지 앎
3. 중복 없음
4. 요소 최소 — 위 셋을 만족하는 한에서 타입·프로토콜·간접층이 가장 적은 상태

선언 형식:

리팩터: <스멜 → 처치>
또는
리팩터 불필요 — 테스트 ✓ / 의도 ✓ / 중복 ✓ / 최소 요소 ✓

경계: 리팩터 중 동작 추가 금지(두 모자), 테스트 그린 유지. 이 게이트는 세션 내 절차일 뿐 커밋 단위에 대응시키지 않는다 — 커밋은 리팩터 반영이 끝난 결과를 논리 단위로 묶는다.

복잡도 측정 — 선택 참고 신호 (강제 아님)

기존 타입 수정 작업이면 before/after 측정으로 리팩터 판단을 정량 보강할 수 있다:

cd tools/complexity-analyzer
./.build/release/complexity-analyzer --source-root ../../<모듈> --scope "type:<대상타입>"

• 수정 전(착수 시점) 대상 타입 측정 → baseline 기록. 수정 후 태스크의 리팩터가 정리된 시점에 1회 재측정 → 총점·축별 변화를 스멜 스캔·종료 판정의 참고로 쓴다. 매 GREEN마다 돌리지 않는다.
• 분석기는 빌드가 남긴 index를 읽는다 — 재측정은 반드시 테스트(빌드) 통과 후. 런당 ~15초.
• 생략 조건 (하나라도 해당하면 측정 없이 진행 — 세워두고 기다리는 상황을 만들지 않는다): 신설 타입(비교 대상 없음) / 사소한 변경 / release 바이너리 미빌드·스테일(재빌드는 수 분) / index 부재·에러.
• 점수는 참고 신호일 뿐 게이트 기준이 아니다 — 종료 판정은 여전히 Simple Design 4규칙.

완료 판정 — 커밋 전

아래 전부 충족해야 "구현/수정 끝"으로 판정한다:

1. bash .claude/skills/implement/scripts/impact-check.sh [--base <ref>] (기본 develop) 실행 후 3섹션을 순서대로 처리:
   • tuist generate — "필요"인데 아직 안 돌렸으면 mise exec -- tuist generate --no-open 먼저. 원칙은 파일 추가/삭제/이동 직후 이미 실행돼 있는 것이고, 여기는 누락 안전망. 테스트는 반드시 generate 반영 후에 돈다
   • 테스트 스킴 — 출력된 스킴 전부 테스트 통과
   • 짝지어진 두 위치 — 각 경고를 해소(대응처 수정)하거나 오탐임을 확인하고 유저에게 보고. 경고를 무시한 채 커밋하지 않는다
2. 마지막 리팩터 게이트 선언 완료
3. Rules 갭·플랜 갭이 있었다면 후속 정리(rules 예약 / 후속 이슈·추가 할일)까지 완료

커밋

커밋 메시지는 [#이슈번호] 동작 변화 요약 — 파일 목록이 아니라 동작이 어떻게 달라졌는지 (CLAUDE.md §5). 커밋·PR 구성 상세 절차는 commit·pr 스킬이 다룬다 — 해당 시점에 함께 invoke한다.

종료 기록 — skill_end (#712)

• 시점: commit 또는 pr 스킬로 전이하는 순간 — 완료 판정을 통과하고 더 만들 diff가 없어 커밋·PR 절차로 넘어갈 때, 해당 스킬 invoke 직전에 log-record.py skill_end를 기록한다 (명령·compliance 규칙은 CLAUDE.md §1).
• 동반 superpowers 코딩 스킬도 같은 시점에 각각 기록 (#715) — superpowers:subagent-driven-development·superpowers:executing-plans·superpowers:test-driven-development는 자체 종료 조항이 없어 여기가 기록 주체다. 이 런에 실제 발동(invoke)된 것만, 발동 레코드와 동일한 superpowers: prefix 포함 이름으로 기록한다 (집계가 문자열 완전일치 버킷팅). compliance는 스킬별 따로 판정 — implement가 full이어도 동반 스킬 절차 이탈이 있으면 그 스킬만 partial.
• 런당 1회 — 기준은 한 작업 단위(플랜 실행 전체·이슈 단위 즉흥 수정)다. 세션 재개·컨텍스트 복원·SDD 태스크 진행으로 이 스킬이 여러 번 재발동돼도, 이어진 런이면 종료 기록은 런을 마무리하는 전이에서 한 번만 남긴다. SDD 중간 태스크의 커밋 전이는 런의 끝이 아니므로 기록하지 않는다.