菜单
payment-platform의 docs/context/ 영구 문서를 현재 코드베이스 상태에 맞게 갱신한다. "컨텍스트 업데이트", "context 문서 갱신", "docs/context 최신화", "아키텍처 문서 업데이트", "문서 동기화", "context 맞춰줘" 등을 말할 때 반드시 이 스킬을 사용한다. workflow ship 단계에서도 호출된다.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
코드 변경(diff, 브랜치, 커밋 범위, PR)을 배경–직관–코드–퀴즈 4섹션의 자기완결 인터랙티브 HTML 페이지로 풀어 설명한다. "diff 설명해줘", "이 PR 설명 페이지 만들어줘", "변경 내용 인터랙티브로 정리", "이 브랜치에서 뭘 바꿨는지 학습용으로 설명" 등 변경 사항의 리치 설명을 요청하면 HTML을 직접 언급하지 않아도 반드시 이 스킬을 사용한다. workflow ship 단계의 리뷰 통과 직후(A5)에도 자동 호출된다. 문제점을 찾는 검토 요청은 review 스킬, 대화 내 짧은 텍스트 요약은 일반 응답으로 처리한다.
payment-platform 워크플로우의 discuss 단계를 실행한다. 사용자가 새 기능/버그/개선의 설계를 논의하거나, "discuss 시작", "설계 논의", "어떻게 구현할지 얘기해보자", "방법 고민" 등을 말할 때 이 스킬을 사용한다. 구현 전에 결정해야 할 사항을 명확히 하는 것이 목적이다.
payment-platform 워크플로우의 execute 단계를 실행한다. docs/<TOPIC>-PLAN.md가 존재하고 사용자가 "execute 시작", "구현 시작", "코딩 시작", "태스크 실행", "다음 태스크" 등을 말할 때 이 스킬을 사용한다. TDD로 태스크를 하나씩 구현하고 커밋하는 것이 목적이다.
payment-platform 워크플로우의 ship 단계(코드 리뷰 + 마무리)를 실행한다. execute 완료 후 "ship 시작", "리뷰 시작", "코드 리뷰", "리뷰하고 마무리", "검증하고 마무리", "아카이브", "PR 만들어줘" 등을 말할 때 이 스킬을 사용한다. 리뷰 → 수정 → 최종 검증 → 문서 동기화 → 아카이브 → PR 흐름이다.
payment-platform의 discuss → plan → execute → ship 워크플로우 오케스트레이터. docs/STATE.md에 활성 토픽이 있거나, 사용자가 "discuss 시작", "plan 작성", "execute 시작", "워크플로우로", "다음 단계", "세션 재개", "이어서 진행", "어디까지 했지" 등을 말할 때 반드시 이 스킬을 사용한다. 단순 질문, 빠른 수정, 일회성 코드 변경에는 사용하지 않는다.
사용자가 "포트폴리오 수정", "포트폴리오 사이트", "payment-flows", "포트폴리오 페이지", "포트폴리오 배포", "index.html 고쳐", "포트폴리오 확인" 같은 표현으로 결제 플랫폼 포트폴리오 페이지를 참조·수정하라는 신호를 줄 때 반드시 사용한다. 이 포트폴리오(구 `docs/site/payment-flows.html`)는 payment-platform이 아니라 **별도 blog 저장소**(`notes/blog`, Astro)에서 관리되며 payment-platform 트리 안엔 존재하지 않으므로, 이 스킬이 정본 페이지(`src/pages/payment-platform-portfolio/index.astro` — CSS·데이터·로직은 각각 `src/styles/`·`src/data/paymentPortfolio/`·`src/scripts/portfolio/` 모듈로 분리)와 dev 툴 위치를 자동으로 찾아 Read / Grep / Edit 으로 접근하게 해준다. "포트폴리오" 단어가 없어도 결제 플랫폼 소개 페이지·시스템 아키텍처 다이어그램·시나리오 극장·섹션 밴드/모션 같은 그 페이지의 콘텐츠를 손봐야 하는 맥락이면 사용을 고려한다.
| name | context-update |
| description | payment-platform의 docs/context/ 영구 문서를 현재 코드베이스 상태에 맞게 갱신한다. "컨텍스트 업데이트", "context 문서 갱신", "docs/context 최신화", "아키텍처 문서 업데이트", "문서 동기화", "context 맞춰줘" 등을 말할 때 반드시 이 스킬을 사용한다. workflow ship 단계에서도 호출된다. |
docs/context/ 디렉토리의 영구 문서들은 미래 세션에서 코드베이스 탐색 비용을 줄이는
핵심 자산이다. 이 스킬의 목적은 문서가 실제 코드 구조와 어긋나는 부분을 찾아
정확하게 맞추는 것이다.
브랜치에서 변경된 파일 목록이 이미 파악되어 있다면 그것을 출발점으로 삼는다.
git diff main...HEAD --stat
변경된 파일 유형을 보고 어떤 context 문서가 영향을 받을지 빠르게 추릴 수 있다. 변경 범위가 명확하므로, 연관 없는 문서는 탐색하지 않아도 된다.
변경 범위가 불명확하므로 전체 context 문서를 점검 대상으로 본다. 각 문서를 읽은 뒤 현재 코드베이스와 대조해 stale한 부분을 찾는다.
| 파일 | 담당 내용 | 코드에서 대조할 것 |
|---|---|---|
ARCHITECTURE.md | 헥사고날 레이어 구조, 포트/어댑터 목록, 모듈 경계 | 실제 패키지 구조, 포트 인터페이스, 어댑터 구현체 |
STACK.md (+ stack/flyway-operations.md) | 기술 스택, 의존성 버전, Flyway 운영 가이드 | build.gradle, docker-compose.yml, db/ 마이그레이션 |
INTEGRATIONS.md | 외부 연동(Toss / NicePay), 벤더 어댑터, cross-service HTTP | 벤더 Strategy, HTTP 어댑터, contract test |
PAYMENT-FLOW.md | end-to-end 결제 플로우 (브라우저 → DONE/FAILED) | 컨트롤러·use case·Kafka 토픽·status 폴링 |
CONFIRM-FLOW.md | payment-service 측 비동기 confirm 사이클 deep dive (분석 + Mermaid 다이어그램 통합) | 진입 use case, AFTER_COMMIT 리스너, 폴백 워커, consumer, two-phase lease, 상태 머신 |
TESTING.md | 테스트 전략, Fake/Mock 패턴, JaCoCo | 테스트 클래스 패턴, 설정 파일 |
CONVENTIONS.md (인덱스) + conventions/ 하위 | code-style(Lombok/Naming/주석/안티패턴) · error-logging(예외/LogFmt/AOP) · transactions · kafka · testing | 실제 코드 관례 |
STRUCTURE.md | 디렉토리 트리, 모듈 의존, 패키지 컨벤션 | settings.gradle, src 트리 |
PITFALLS.md | 학습된 도메인 함정 인덱스 | archive briefing 의 핵심 결정 |
CONCERNS.md | 알려진 우려 / 한계 | Phase 4 후속 항목 |
TODOS.md | 향후 처리 항목 | 활성 작업 외부 |
PAYMENT-FLOW-GUIDE.md | 사람 독자용 end-to-end walkthrough (도메인 언어 + 시퀀스/플로우차트) | ⚠️ ship 단계에서만 갱신 — 독립 호출 시 제외. 결제 흐름 코드 변경 시 PAYMENT-FLOW/CONFIRM-FLOW 와 함께 사람 친화 서술로 반영 |
호출 맥락에 따라 점검할 문서 목록을 먼저 정한다. 연관성이 없는 문서는 건너뛴다 — 모든 문서를 항상 업데이트할 필요는 없다.
점검 대상 문서를 읽고, 문서가 언급하는 구성요소(클래스, 인터페이스, 패키지 등)가 실제 코드베이스에 존재하는지, 내용이 맞는지 확인한다.
확인 방법:
갱신이 필요한 경우:
갱신하지 않는 경우:
완료된 항목은 ✅ 마킹으로 쌓아두지 않고 3분류로 삭제한다.
갱신한 문서의 헤더 "최종 갱신" 시점은 본문 최신 내용과 항상 동기화한다.
사실 서술의 근거는 소스 파일:라인만 인정한다. 다른 문서나 archive briefing 을 인용해 사실을 확정하지 않는다 — 문서끼리 서로 인용하면 stale 서술이 정본으로 굳어질 위험이 있다.
갱신이 완료되면 다음 형식으로 보고한다:
## Context 문서 갱신 완료
**점검한 문서**: ARCHITECTURE.md, INTEGRATIONS.md
**수정한 문서**: ARCHITECTURE.md (ImmediateEventHandler 어댑터 추가)
**변경 없는 문서**: INTEGRATIONS.md (내용 일치)
갱신한 파일이 없으면 "모든 문서가 현재 코드와 일치합니다"라고 알린다.