---
name: implement
description: 앱의 요구사항과 구현 계획에 따라 코드·설정·관련 문서를 변경하고 작업 단위로 검증한다. 기능 구현, 버그 수정, 리팩토링이나 계획된 작업 실행을 요청할 때 사용한다. 기획·설계·리뷰만 요청한 경우에는 변경을 시작하지 않는다.
---

# 계획에 따른 구현

요구사항, 완료 조건, 관련 설계와 프로젝트 규칙을 입력으로 받는다. 작은 변경에 별도 계획서가 없으면 변경 위치와 확인 방법을 짧게 정한 뒤 진행한다. 버그·계약·타입 변경이나 재사용·의존성 판단이 필요하면 [변경 범위와 완결성 기준](references/change-scope.md)을 읽는다.

버그·테스트·빌드 실패·예상 밖 동작이 생기면 [원인 조사와 수정 기준](references/debugging.md)을 적용한다. 이번 변경에 맞는 전문 스킬이 현재 환경에 있으면 실제 기술·버전과 역할을 확인해 활용한다.

구현 전에 적용할 TDD·검증·자율성·Git 정책과 관련 미정·연기 항목을 확인한다. 명시적으로 채택한 정책을 따르고 미정인 핵심 선택에 의존하는 작업은 시작하지 않는다. 기존 권한·이미 받은 답은 재사용하며, 정책을 바꾸지 않고 새 작업마다 인터뷰를 반복하지 않는다.

## 구현

1. 관련 코드와 호출자, 기존 테스트를 읽고 사용자 변경이 있는지 확인한다. 계약·이름 변경은 export·fixture·설정·직렬화 등 관련 참조까지 확인한다. 요청과 관계없는 수정은 보존한다.
2. 기존 코드·컴포넌트·표준 기능을 재사용해 작업을 수행한다. 관련 없는 정리나 추측한 확장 기능을 함께 넣지 않는다.
3. 이름은 역할과 합의한 도메인을 드러내도록 짓고 기획·API·DB·코드의 의미를 맞춘다. 의미 없는 업무 변수명과 불필요한 호환 래퍼·추상화를 피하되, 기존 외부 계약을 임의로 깨지 않는다.
4. 변경한 동작과 실제 위험에 맞는 테스트·타입·린트·빌드·수동 확인을 수행한다. 테스트는 결과나 중요한 불변 조건을 확인하도록 하고, 구현 문구를 그대로 비교하는 검사는 피한다.
5. 동작 변경에 필요한 문서·설정 예시·마이그레이션을 함께 갱신한다. 비밀값은 코드·로그·작업 기록에 넣지 않는다.

새 요구나 설계 문제가 드러나면 영향을 정리하고 관련 계획을 갱신한다. 핵심 계약·범위를 바꾸는 결정을 구현 편의만으로 확정하지 않는다. 실행이 실패하면 원인을 살펴 수정하고, 환경 차단을 코드 성공으로 보고하지 않는다.

## Git 작업과 전달

커밋·푸시·PR 생성은 사용자 요청과 기존 권한 범위 안에서 수행하고 프로젝트 컨벤션을 따른다. 구현 요청만으로 배포나 PR 병합을 수행하지 않는다.

변경 파일과 동작, 완료한 작업, 실행한 검증과 결과, 미검증 영역·남은 문제를 전달한다. 체크리스트 표시만으로 전체 완료를 판단하지 않고 실제 결과를 `verify`에 넘긴다. 단독 요청이면 같은 기준으로 구현 결과를 설명한다.