목적

기술 설계가 완료되었습니다. 다음 단계는 코드를 작성하는 것입니다. 전통적인 접근 방식은 개발자가 직접 기술 설계를 읽고, 기존 코드를 검토하며, 파일 하나하나를 수동으로 작성하는 것입니다. 문제는 기술 설계에 이미 인터페이스 설계, DDL, 변경 범위 및 작업 분해가 명확히 정의되어 있음에도 불구하고, 개발자가 이 정보를 일일이 코드로 변환해야 한다는 점입니다. 이 과정은 반복적이고 오류가 발생하기 쉽습니다(매개변수 이름 오타, 인터페이스 경로 불일치, 특정 서비스의 변경 사항 누락 등).

이 스킬은 기술 설계, PRD, 프로토타입 및 코딩 지식 베이스를 읽고, 기술 설계의 작업 분해에 따라 대상 리포지토리에서 코드 파일을 직접 생성/수정합니다. '스캐폴딩'이나 '템플릿 코드'가 아닌, 완전한 비즈니스 로직을 포함한 구현 코드를 생성하여 바로 코드 리뷰(CR)에 제출할 수 있습니다.

핵심 역량은 coding-knowledge의 심층 활용에 있습니다: 코딩 지식 베이스의 심볼 인덱스, 호출 체인, DDL, 코드 규칙을 통해 생성된 코드는 명명 스타일, 계층 구조, 예외 처리 방식에서 프로젝트 기존 코드와 일관성을 유지합니다. 즉, 아웃소싱 업체가 작성한 코드처럼 보이지 않고, 프로젝트의 베테랑 직원이 작성한 것처럼 보입니다.

입력

requirements/{모듈명}/tech-design.md (주요 입력, 인터페이스 설계, DDL, 작업 분해, 변경 범위 포함)
requirements/{모듈명}/prd-draft.md (승인 기준, 비즈니스 규칙, 경계 조건)
requirements/{모듈명}/prototype/ (프론트엔드 페이지 구조 참조)
coding-knowledge/ (핵심 참조 – 코드 스타일, 아키텍처 패턴, 심볼 인덱스, 호출 체인, DDL 패턴, 코드 규칙)
대상 코드 리포지토리 경로 (사용자 지정, 또는 tech-design의 변경 범위에서 추출)

워크플로우

Phase 0: 입력 읽기, 컨텍스트 구축

0.1 tech-design.md 읽기

다음 정보를 추출하여 후속 생성을 위한 권위 있는 소스로 사용합니다:

변경 영향 범위 (관련 리포지토리, 추가/수정이 필요한 파일)
인터페이스 설계 (API 목록, 요청 매개변수, 응답 구조, 오류 코드)
데이터베이스 변경 (DDL)
개발 작업 분해 (T-01, T-02... 종속 관계 포함)
상호 작용 시퀀스 다이어그램 (서비스 간 호출 관계)
재사용 인터페이스 매개변수 설명 (매개변수 및 동작 차이 구분)

0.2 prd-draft.md 읽기

비즈니스 로직의 완전성을 보장하기 위해 다음 정보를 추출합니다:

기능 목록 및 승인 기준 (생성된 코드가 모든 기능 포인트를 커버하는지 확인)
비즈니스 규칙 및 경계 조건 (코드에 해당 검증 로직이 있는지 확인)
오류 처리 요구 사항 (구체적인 오류 메시지 텍스트)

0.3 coding-knowledge 심층 읽기 (핵심 단계)

이것이 code-gen과 일반 AI 코드 생성의 가장 큰 차이점입니다. '대충 읽고 이해'하는 것이 아니라, 코드 계층별로 구체적인 코딩 패턴을 추출합니다.

첫 번째 계층: 기본 규칙 (필독)

coding-knowledge/infra/ 아래의 파일을 읽어 전역 코딩 제약 조건을 추출합니다:

code-quality.md → 명명 규칙 (카멜 케이스 vs 스네이크 케이스, 접두사/접미사 규칙), 주석 스타일, 예외 처리 패턴, 로깅 규칙
기타 인프라 규칙 → 미들웨어 사용 방식 (MQ 생산/소비 패턴, 캐시 작업 방식)

두 번째 계층: 리포지토리 아키텍처 (관련 리포지토리별로 읽기)

tech-design에 나열된 각 리포지토리에 대해 coding-knowledge/repos/{repo}/ 아래의 파일을 읽습니다:

architecture.md → 패키지 구조 및 계층화 규칙. 새 파일 생성 시 이에 따라 패키지 위치와 클래스 이름을 결정합니다. '이 서비스는 담당하지 않음'이라는 설명에 특히 주의하여, 해당 서비스에 속하지 않는 로직을 작성하지 않도록 합니다.
symbols.md → 기존 클래스 및 메서드의 시그니처 인덱스. 이것은 '스타일 학습'의 진입점입니다. 여기에서 동일한 유형의 기존 구현(예: 기존 Controller, Service)을 찾고, 이후 Phase 1에서 이들의 전체 소스 코드를 읽습니다.
database-schema.md → 기존 테이블의 실제 DDL. 새 테이블 생성 시 필드 명명 변환 규칙(예: create_time vs createdAt), 인덱스 명명 규칙(예: idx_ 접두사), 문자 집합 및 엔진 설정을 참조합니다.
call-chains.md → 실제 서비스 간 호출 코드. tech-design이 서비스 간 호출을 포함하는 경우, 프로젝트에서 실제로 사용하는 호출 방식(Feign Client? RestTemplate? WebClient? gRPC stub?)과 오류 처리 및 타임아웃 설정 방식을 여기에서 찾습니다.

세 번째 계층: 비즈니스 도메인 (필요 시 읽기)

tech-design이 서비스 간 협업을 포함하는 경우, coding-knowledge/business/domains/{domain}/을 읽습니다:

cross-service.md → 리포지토리 간 호출 관계 및 데이터 흐름

0.4 스타일 학습 (핵심 단계)

symbols.md에서 2-3개의 동일한 유형의 기존 구현 파일을 찾고, Read 도구를 사용하여 전체 소스 코드를 읽습니다. 목적은 시그니처뿐만 아니라 프로젝트의 코딩 패턴을 학습하는 것입니다.

구체적인 방법:

생성할 코드 계층	symbols.md에서 찾은 참조 대상	학습 포인트
Entity/Model	동일 리포지토리의 기존 Entity 클래스	애노테이션 사용 방식, 필드 명명 변환, 기본 클래스 상속, 감사 필드 처리
Mapper/Repository	동일 리포지토리의 기존 Mapper/Repository	MyBatis XML vs 애노테이션, 커스텀 쿼리 메서드 명명 패턴, 페이징 구현
Service	동일 리포지토리의 기존 Service 클래스	트랜잭션 애노테이션 사용법, 예외 발생 방식, 의존성 주입 스타일 (생성자 vs @Autowired)
Controller	동일 리포지토리의 기존 Controller 클래스	통일된 반환 값 래핑, 매개변수 검증 애노테이션, 권한 애노테이션, Swagger 애노테이션 스타일
프론트엔드 API 계층	동일 프로젝트의 기존 API 파일	axios 래핑 방식, 요청/응답 인터셉터, 오류 처리
프론트엔드 페이지	동일 프로젝트의 기존 목록/폼 페이지	컴포넌트 라이브러리 사용법, 상태 관리 방식, 검색 조건 레이아웃

스타일 학습의 산출물은 암시적인 '코딩 체크리스트'입니다 – 사용자에게 출력할 필요는 없지만, Phase 2에서 모든 코드 줄을 생성할 때 준수해야 합니다. 예를 들어:

"이 프로젝트의 Controller는 모두 @RestController + @RequestMapping을 사용하며, @Controller + @ResponseBody는 사용하지 않습니다."
"Service 계층의 예외는 throw new BusinessException(ErrorCode.XXX)를 통일적으로 사용하며, 오류 코드를 반환하지 않습니다."
"모든 쿼리 메서드는 listXxx/getXxx라고 하며, queryXxx/findXxx라고 하지 않습니다."

Phase 1: 계획 수립 (사용자 확인)

코드를 작성하기 전에 반드시 사용자에게 계획을 제시하고 확인을 받아야 합니다.

Phase 0의 분석 결과를 기반으로 구조화된 생성 계획을 출력합니다:

## 코드 생성 계획

### 코드 스타일 참조
- 백엔드 참조: {symbols.md에서 찾은 참조 Controller/Service 파일 경로}
- 프론트엔드 참조: {기존 페이지에서 찾은 참조 컴포넌트 경로}
- 코딩 규칙: {coding-knowledge/infra/code-quality.md의 주요 제약 조건}

### 백엔드 ({리포지토리명})
| 번호 | 작업 | 파일 경로 | 설명 | 해당 작업 |
|------|------|----------|------|----------|
| 1 | 추가 | {architecture.md에서 도출된 정확한 패키지 경로}/XxxEntity.java | 엔터티 클래스 추가 | T-01 |
| 2 | 추가 | {패키지 경로}/XxxMapper.java | Mapper 인터페이스 추가 | T-01 |
| 3 | 수정 | {symbols.md에서 찾은 정확한 파일 경로}:L{줄 번호} | createXxx() 메서드 추가 | T-02 |
| 4 | 추가 | {패키지 경로}/XxxController.java | CRUD 인터페이스 추가 | T-03 |

### 프론트엔드 ({리포지토리명})
| 번호 | 작업 | 파일 경로 | 설명 | 해당 작업 |
|------|------|----------|------|----------|
| 1 | 추가 | src/api/xxx.js | API 호출 계층 | T-05 |
| 2 | 추가 | src/pages/xxx/index.vue | 목록 페이지 (prototype/list.html 참조) | T-05 |
| 3 | 추가 | src/pages/xxx/form.vue | 추가/수정 폼 | T-05 |

### 데이터베이스
- tech-design의 DDL 실행 (database-schema.md 참조하여 스타일 일관성 확인 완료)

### 주의 사항
- {사용자 확인이 필요한 사항}

계획의 파일 경로는 정확한 경로여야 합니다 – 추측된 경로가 아니라, architecture.md(패키지 구조)와 symbols.md(기존 파일 위치)에서 도출된 경로여야 합니다. 기존 파일 수정 작업의 경우 줄 번호를 표시합니다.

사용자 확인 후 Phase 2를 시작합니다.

Phase 2: 종속성 순서에 따라 코드 생성

생성 원칙: 종속 관계에 따라 하위 계층에서 상위 계층 순서로 생성하여 참조 관계가 올바르도록 합니다. 각 파일은 생성 직후 즉시 작성됩니다.

백엔드 생성 순서

Entity → Mapper/Repository → Service → Controller → 설정/기타 순서:

1. Entity/Model 계층

tech-design의 DDL에 따라 엔터티 클래스를 생성합니다.
Phase 0.4에서 학습한 패턴: 필드 애노테이션 방식(JPA @Column vs MyBatis-Plus @TableField), 기본 클래스 상속(BaseEntity 존재 여부), 감사 필드(createTime/updateTime 처리 방식), 논리 삭제 필드
database-schema.md 참조: 필드 명명 변환 규칙(데이터베이스 create_time → Java createTime의 구체적인 방식, 일부 프로젝트는 @TableField("create_time") 사용, 일부는 전역 설정을 통한 자동 변환)

2. Mapper/Repository 계층

Entity에 해당하는 데이터 액세스 인터페이스를 생성합니다.
Phase 0.4에서 학습한 패턴: MyBatis XML vs 애노테이션, BaseMapper<T> 상속 여부, 커스텀 쿼리 메서드 명명 규칙, 페이징 구현 방식(PageHelper? MyBatis-Plus IPage?)
tech-design에서 언급된 커스텀 쿼리 메서드를 포함합니다.

3. Service 계층

비즈니스 로직을 구현하며, tech-design의 각 인터페이스 처리 흐름에 대응합니다.
Phase 0.4에서 학습한 패턴: 트랜잭션 애노테이션 사용법(@Transactional 전파 수준 관행), 예외 처리 방식(커스텀 BusinessException? 통일된 ErrorCode 열거형?), 의존성 주입 스타일(생성자 주입 vs @Autowired), 로깅 관행
PRD 승인 기준에서 검증 로직 도출: 각 승인 조건에 해당하는 검증 분기
서비스 간 호출: call-chains.md에서 프로젝트가 실제로 사용하는 호출 방식을 찾아 그 코드 패턴을 그대로 사용합니다(새로운 호출 방식을 발명하지 않음).

4. Controller 계층

인터페이스 경로, 매개변수, 응답 구조는 tech-design의 인터페이스 설계를 엄격히 따릅니다.
Phase 0.4에서 학습한 패턴: 통일된 반환 값 래핑 클래스(Result<T>? ResponseEntity<T>?), 매개변수 검증 애노테이션(@Valid + JSR 303 vs 수동 검증), 권한 애노테이션(@PreAuthorize? 커스텀 @Permission?), Swagger/OpenAPI 애노테이션 스타일
오류 코드는 tech-design에서 정의된 비즈니스 오류 코드를 사용합니다.

5. 설정/기타

MQ Consumer/Producer (tech-design에 포함된 경우) – call-chains.md에서 기존 MQ 코드 작성법을 찾습니다.
메뉴/권한 설정 파일 (필요한 경우)
새로 추가된 상수/열거형 클래스

프론트엔드 생성 순서

API 호출 계층 → 라우트 설정 → 페이지 컴포넌트 순서:

1. API 호출 계층

tech-design의 인터페이스 목록에 따라 API 메서드를 생성합니다.
Phase 0.4에서 학습한 패턴: axios 래핑 방식(통일된 request 함수? 각 API별 독립 파일?), 요청/응답 인터셉터 처리
메서드 이름과 매개변수 이름은 tech-design의 인터페이스 번호와 대응됩니다.

2. 라우트 설정

새 페이지의 라우트를 등록합니다.
기존 라우트 파일의 구성을 참조합니다.

3. 페이지 컴포넌트

prototype/의 페이지 구조 참조: 프로토타입의 테이블 열 순서, 검색 조건 레이아웃, 모달 창 구조가 컴포넌트 코드를 직접 안내합니다.
프로젝트의 실제 기술 스택에 해당하는 컴포넌트 라이브러리를 사용합니다(coding-knowledge 또는 package.json에서 Element UI / Ant Design / 자체 개발 컴포넌트 등을 확인).
테이블 열 정의는 tech-design의 인터페이스 응답 필드에서 도출합니다.
폼 필드 및 검증 규칙은 tech-design의 인터페이스 요청 매개변수에서 도출합니다.

각 파일의 생성 흐름

새 파일인 경우:
- 대상 디렉토리가 존재하는지 확인합니다(ls 사용).
- Write 도구를 사용하여 생성합니다.
수정 파일인 경우:
- 먼저 Read로 전체 파일 내용을 읽습니다.
- Edit으로 정확히 수정합니다(주변 코드를 다시 포맷하지 않음).
생성 직후 파일 시스템에 작성합니다(마지막에 한꺼번에 쓰지 않음).

Phase 3: 보고서 생성

requirements/{모듈명}/ 디렉토리에 code-gen-report.md를 생성합니다:

---
title: "{모듈명} — 코드 생성 보고서"
tech_design_version: "{tech-design 버전}"
date: "{생성 날짜}"
---

# {모듈명} — 코드 생성 보고서

## 1. 생성 개요

| 리포지토리 | 새 파일 | 수정 파일 | 해당 작업 |
|------|---------|---------|---------|
| {리포지토리명} | {N} 개 | {M} 개 | T-01 ~ T-03 |

## 2. 코딩 스타일 참조

| 코드 계층 | 참조한 기존 파일 | 학습한 핵심 패턴 |
|--------|-------------|----------------|
| Controller | {파일 경로} | 통일된 반환 Result<T>, @Valid 검증 사용 |
| Service | {파일 경로} | 생성자 주입, BusinessException 예외 처리 |
| Entity | {파일 경로} | BaseEntity 상속, @TableField 애노테이션 |

## 3. 파일 목록

### {리포지토리명}

#### 새 파일
| 파일 경로 | 설명 | 해당 tech-design 작업 |
|----------|------|----------------------|
| src/.../XxxEntity.java | 엔터티 추가 | T-01 |

#### 수정 파일
| 파일 경로 | 수정 내용 | 해당 tech-design 작업 |
|----------|----------|----------------------|
| src/.../XxxService.java | createXxx() 메서드 추가 | T-02 |

## 4. 요구 사항 커버리지 검사

| PRD 기능 | 인터페이스 번호 | 코드 파일 | 승인 기준 커버리지 |
|----------|---------|---------|------------|
| F-01 | API-01, API-02 | XxxController.java | 전체 커버 |
| F-02 | API-03 | XxxService.java | 부분 커버 (Q-01 확인 대기 항목 미구현) |

## 5. 미커버 항목

{tech-design에 있지만 이번에 생성되지 않은 작업 및 이유}

## 6. 주의 사항

{개발자가 수동으로 처리해야 할 사항, 예:}
- 설정 센터에 추가해야 할 설정 항목
- 수동으로 실행해야 할 DDL
- 수동 확인이 필요한 비즈니스 로직
- coding-knowledge에서 발견된 tech-design과의 불일치 사항

Phase 4: 요약 출력

생성이 완료되면 사용자에게 알립니다:

코드 생성 보고서 위치
추가/수정된 파일 수 (리포지토리별 통계)
해당 tech-design 작업 커버리지
수동으로 처리해야 할 사항
/code-review를 사용하여 생성된 코드를 검토할 것을 권장

출력 디렉토리

requirements/{모듈명}/
├── prd-draft.md              ← PRD 최종본 (입력)
├── review/                   ← prd-review 산출물
├── prototype/                ← proto-gen 산출물
├── tech-design.md            ← tech-design 산출물 (입력)
└── code-gen-report.md        ← 본 스킬 산출물

실제 코드 변경 사항은 대상 리포지토리 디렉토리에 직접 작성됩니다(requirements/ 아래에 생성되지 않음).

다른 스킬과의 관계

coding-knowledge-init                         ← 0단계: 프로젝트 맵
  coding-knowledge/ 생성
        ↓ (참조)
project-import → knowledge-init → prd-draft → prd-review → proto-gen
                                                                ↓
                                              tech-design → code-gen → code-review
                                                             ↑
                                                     coding-knowledge/
                                                     (심층 활용)

선행: tech-design의 기술 설계가 주요 입력입니다. coding-knowledge-init의 코딩 지식 베이스는 핵심 참조입니다.
후속: 생성된 코드 변경 사항은 code-review에서 검토됩니다.
tech-design과의 관계: tech-design은 '무엇을 할 것인가'(인터페이스 설계, DDL, 작업 분해)를 정의하고, code-gen은 '어떻게 할 것인가'(실제 코드 생성)를 실행합니다. tech-design의 인터페이스 번호(API-XX)와 작업 번호(T-XX)는 code-gen의 직접적인 인덱스입니다.
coding-knowledge와의 관계: coding-knowledge는 code-gen의 '코딩 멘토'입니다 –
- symbols.md는 프로젝트에 어떤 클래스와 메서드가 있는지, 동일한 유형의 참조를 어디서 찾을 수 있는지 알려줍니다.
- architecture.md는 새 코드를 어느 패키지에 넣을지, 어떤 계층을 따라야 하는지 알려줍니다.
- database-schema.md는 테이블 생성 시 어떤 스타일을 사용할지 알려줍니다.
- call-chains.md는 서비스 간 호출을 어떻게 작성할지 알려줍니다.
- infra/code-quality.md는 반드시 준수해야 할 규칙을 알려줍니다.
- coding-knowledge 없이도 코드를 생성할 수 있지만, 효과는 '베테랑 직원이 작성한 코드'에서 '인턴이 작성한 코드'로 떨어집니다.

기존 코드 수정 vs 새 기능 추가

AI는 tech-design의 변경 범위에 따라 각 파일이 '기존 코드 수정'인지 '새 파일 추가'인지 자동으로 판단하고, 다른 생성 전략을 사용합니다.

기존 코드 수정 시 불문율

수정해야 할 부분만 수정하고, 건드리면 안 되는 부분은 건드리지 마십시오. 이것은 기존 코드 수정에서 가장 흔하고 심각한 문제입니다. AI가 기존 코드를 이해한 후, 주변 로직을 '덤으로' 리팩토링하여 회귀 버그를 발생시킵니다.

구체적인 요구 사항:

먼저 Read로 전체 기존 파일을 읽고 컨텍스트를 이해한 후 작업을 시작합니다.
Edit으로 정확히 수정하고, Write로 전체 파일을 덮어쓰지 않습니다.
기존 변수/메서드 이름을 변경하지 마십시오. 이름이 마음에 들지 않더라도 그것은 다른 요구 사항입니다.
기존 코드 형식을 조정하지 마십시오(들여쓰기, 빈 줄, import 순서). 새로 추가한 코드와 직접적으로 인접한 부분이 아니라면 수정하지 않습니다.
기존 로직을 '최적화'하지 마십시오 – tech-design에 "createOrder 메서드에 새 검증 로직을 추가"라고 명시되어 있다면, 검증 로직만 추가하고 createOrder의 다른 로직은 수정하지 않습니다.
새 메서드 추가 시 삽입 위치에 주의하십시오: 프로젝트의 기존 메서드 배열 관행(예: CRUD 순서, public이 private보다 앞에 오는 등)에 따라 합리적인 위치에 삽입합니다.

판단 기준

신호	판단	생성 전략
tech-design에 "수정: XxxService:L120" 표시	기존 코드 수정	Read → Edit 정확한 수정
tech-design에 "추가: {패키지 경로}/XxxController.java" 표시	새 파일	Write 전체 파일
tech-design에 "새 메서드 createXxx() 추가" 표시	기존 파일에 추가	Read → Edit 적절한 위치에 삽입

생성 원칙

스타일 일관성이 최우선입니다: 생성된 코드는 프로젝트의 기존 코드가 자연스럽게 확장된 것처럼 보여야 합니다. 방법은 '규칙을 읽고 감으로 작성'하는 것이 아니라:

symbols.md에서 동일한 유형의 기존 구현 파일을 찾습니다.
전체 소스 코드를 읽고 코딩 패턴을 추출합니다.
새 코드는 이러한 패턴을 엄격히 복제합니다 – 동일한 애노테이션 조합, 동일한 메서드 명명, 동일한 예외 처리 방식.

tech-design은 권위 있는 소스입니다: 인터페이스 경로, 매개변수 이름, 응답 구조, 오류 코드는 tech-design을 기준으로 하며, 임의로 변경하지 않습니다. tech-design에 문제가 있다고 생각되면(예: 매개변수 유형이 부적절한 경우) 보고서의 '주의 사항'에 표시하지만, 코드는 여전히 tech-design에 따라 생성합니다.

coding-knowledge는 코딩 멘토입니다: '여기는 어떻게 작성해야 할까?'라는 질문이 생기면, 첫 번째 반응은 일반적인 지식으로 추측하는 것이 아니라 coding-knowledge를 확인하는 것입니다. 예를 들어:

"이 프로젝트의 페이징은 어떻게 구현하나요?" → symbols.md에서 페이징 관련 메서드를 찾습니다.
"서비스 간 호출은 어떤 방식을 사용하나요?" → call-chains.md를 확인합니다.
"예외는 어떻게 던지나요?" → code-quality.md와 참조 Service 구현을 확인합니다.

기존 코드를 손상시키지 마십시오: 기존 파일을 수정할 때는 필요한 위치에만 코드를 추가/수정하고, 주변 코드를 다시 포맷하거나 리팩토링하지 않습니다. Edit 도구를 사용하여 정확히 수정하고, Write로 전체 파일을 덮어쓰지 않습니다.

비즈니스 로직은 완전해야 합니다: 메서드 시그니처와 TODO 주석만 생성하는 것이 아니라, 완전한 비즈니스 로직을 포함한 코드를 생성합니다. 검증 규칙은 PRD의 승인 기준에서 도출하고, 처리 흐름은 tech-design의 시퀀스 다이어그램에서 도출합니다.

일괄 생성이 아닌, 단계별 생성 및 즉시 쓰기: Phase 2의 순서에 따라 파일별로 생성하고, 각 파일 생성 후 즉시 작성합니다. 마지막에 한꺼번에 출력하지 마십시오. 중간에 오류가 발생하더라도 이미 작성된 파일은 영향을 받지 않습니다.

Common Pitfalls

스타일 학습을 건너뛰고 바로 생성: 프로젝트의 기존 Controller를 Read하지 않고 새 Controller를 생성하여 완전히 다른 애노테이션 조합과 반환 값 래핑을 사용합니다. Phase 0.4의 스타일 학습은 생략할 수 없습니다.

symbols.md만 보고 소스 코드를 읽지 않음: symbols.md에는 시그니처 인덱스만 있고, 메서드 본문의 코딩 패턴(트랜잭션 사용법, 예외 발생 방식, 로깅 방식)은 볼 수 없습니다. 반드시 2-3개의 참조 파일의 전체 소스 코드를 Read해야 합니다.

인터페이스 매개변수가 tech-design과 불일치: tech-design에 knowledgeType이라고 명시되어 있는데, 코드에 knowledge_type 또는 type이라고 작성합니다. tech-design의 매개변수 이름을 엄격히 따라야 합니다.

수정 파일 누락: tech-design이 3개의 파일을 수정해야 한다고 명시했는데, code-gen이 2개만 수정합니다. Phase 1의 계획 목록은 tech-design의 변경 범위를 완전히 커버해야 합니다.

프론트엔드 코드가 프로토타입을 참조하지 않음: prototype/의 페이지 구조는 PRD의 시각적 표현입니다. 프론트엔드 코드는 프로토타입의 레이아웃과 컴포넌트 구조를 참조해야 하며, 페이지를 직접 다시 설계해서는 안 됩니다.

시그니처만 생성하고 구현은 생략: 생성된 Service 메서드 본문에 전부 // TODO: implement가 있습니다. 이 스킬의 가치는 완전한 비즈니스 로직 구현을 생성하는 데 있으며, 개발자가 직접 채우도록 비워두는 것이 아닙니다.

기존 코드 수정 시 '덤으로' 리팩토링: 기존 메서드를 수정할 때는 필요한 로직만 추가하고, 변수 이름을 바꾸거나, 코드 형식을 조정하거나, 주변 로직을 최적화하지 마십시오. 이러한 '개선'은 회귀 버그의 주요 원인입니다.

기존 코드 수정 시 기존 로직을 중복 구현: tech-design에 "기존 흐름에 새 검증 단계를 추가"라고 명시되어 있는데, code-gen이 전체 흐름을 (기존 로직을 포함하여) 다시 작성합니다. 증분 코드만 작성하고, 기존 로직은 그대로 두어야 합니다.

coding-knowledge의 '담당하지 않음' 표시 무시: architecture.md에 "이 서비스는 XXX를 담당하지 않습니다"라고 명시되어 있는데, 코드에 해당 로직을 작성합니다. 코드를 생성하기 전에 서비스의 책임 범위를 확인해야 합니다.

서비스 간 호출 방식 불일치: 프로젝트의 기존 코드는 Feign Client를 사용하여 다른 서비스를 호출하는데, 생성된 코드는 RestTemplate을 사용합니다. call-chains.md 또는 참조 코드에서 실제 호출 방식을 학습해야 합니다.

wuyining0130/c-room

c-room란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서

목적

입력