Files
Pier_v1/.agents/skills/tea-logging/SKILL.md
T
ahnyongjooandClaude Sonnet 5.5 964a841de1 chore(rebar): Pier_T_rebar 작업 폴더 초기 구성 및 외부 의존 파일 통합
- Code\rebar_pipeline, review_pipeline, pier-program을 정션에서 실제 폴더로 전환
- Code\rhino_mcp 및 CLAUDE_rhino배경.md 추가, .mcp.json은 PYTHONPATH로 새 위치 사용
- pier-program 내부 .git 제거(이력은 backup\pier-program_20261028.bundle에 보관)
- worktree 가이드 반영(CLAUDE.local.md, HANDOFF.md)
- D:\Rhino-MCP 경로 참조를 새 위치로 치환

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-28 11:20:18 +09:00

13 KiB

name, description
name description
tea-logging 전역 지침 Step 5 컨텍스트 이관·프롬프트 로깅 — 로그 서식·INPUT 원문 기재·STATUS 4값, 담당자 식별(F4), 로그 입도(F8), 정본 선언·미해결 목록·메모리 신선도(G3-1·G3-2·G3-4), 메모리 저장(R6). Step 5 착수 시, context-migration 메모리나 OPEN_미해결목록.md를 쓸 때, 담당자를 확정할 때, 산출물 계열이 분기할 때 반드시 읽는다.

컨텍스트 이관·로깅 (Step 5) · 메모리 관리

전역 지침 스킬 — 코어 taskexecutionagent.md(v0.3.01) [스킬 지도]에서 호출된다. 담긴 조항: Step 5, F4, F8, G3-1, G3-2, G3-4, R6 아래는 v0.2.08 이전 코어의 조항 원문이다(무손실 이관). 조항 ID·번호는 코어와 공통이다. 코어의 요약과 어긋나 보이면 이 원문을 따르고, 그 사실을 [Step 5] 비고에 적는다.

────────────────────────── [Step 5] Context-Migration & Prompt Logging (컨텍스트 이관 및 프롬프트 기록) ──────────────────────────

이 Step은 아래 트리거 조건 중 하나라도 충족되면 무조건 수행한다. 진행 모드(GATED/FAST)와 무관하며, 세션 분리·규모와도 무관하다. (T1) 개별 Task가 PROCESS COMPLETE에 도달했을 때 (T2) 사용자가 다음 Task를 요청했을 때 — 직전 Task가 PROCESS COMPLETE까지 진행되지 않았더라도 반드시 수행한다. (T3) 사용자가 Context-Migration 진행을 명시적으로 요청했을 때

수행:

  1. Context-Migration 저장

    • Task 진행 과정(Step 0~4)에서 누적된 컨텍스트를 프로젝트의 context-migration 폴더에 메모리 파일(.md)로 저장한다.
    • 중복 메모리는 [G3. Single Source of Truth]에 따라 기존 파일을 갱신한다. 신규 생성 전 기존 파일을 전수 확인한다. ([R6])
    • OPEN_미해결목록.md의 신규 항목 추가·기존 항목 상태 갱신을 함께 수행한다. ([G3-2])
    • 산출물 계열이 분기했다면 정본 선언 메모리를 생성·갱신한다. ([G3-1])
  2. Prompt 로깅

    • 담당자를 [F4. 담당자 식별]에 따라 확정한다. (담당자ID 주키)

    • 아래 경로에 로그 파일을 저장한다: prompt/<담당자>/<YYYY-MM-DD>/<Task식별자>.md (신규 폴더 생성이 불가한 환경에서는 [F7] 절차를 따른다)

    • 로그 파일명은 Task_[핵심주제]_[YYYY-MM-DD]_v[버전].md 형식을 권장하며, 한국어로 작성한다. ([G2])

    • 로그에는 아래 항목을 기록한다:

      필드 내용
      담당자 [F4]에 따라 확정한 담당자명 (필수)
      일자 실제 작업 일자 (필수)
      Task 식별자 로그 파일명과 동일 (필수)
      선행 Task 연속 Task인 경우 직전 로그 경로 (권장)
      경로·복잡도·모드 COMPLEX / COMPLEX-DOC / SIMPLE, GATED / FAST
      INPUT 사용자가 입력한 프롬프트를 원문 그대로 저장한다. 요약·축약·편집·재구성하지 않고 입력된 전체 텍스트를 원본 그대로 기록한다.
      PROCESS 해당 프롬프트에 대한 LLM 수행 내용의 요약
      DECISIONS v0.2.00 신설. 결정 지점 / 채택안 / 기각안과 기각 사유 / 근거. 기각안을 적지 않으면 재개 세션이 같은 오답을 반복한다. 자율성 등급 조정·위임 결과 기각도 여기에 남긴다. 결정이 없었으면 —
      OUTPUT 생성된 산출물명 / 저장 경로 / 버전 — 표 형태로 기재
      MODEL 해당 Task 수행에 사용된 LLM 모델명·버전 (Task 중간에 모델을 전환했다면 전환 시점과 사유를 함께 기재)
      EFFORT 대화 턴 수 / 도구 호출 횟수 (필수). 토큰 사용량은 실행환경이 제공하는 경우에만 추가 기재한다. 예: 턴 12 / 도구호출 27 (서브에이전트 2회 포함)
      STATUS 아래 4값 중 하나 (임의값 금지)
      비고 FAST 모드 사유, 규정 이탈 근거, 한계, AI 산출물 수정률([R9]) 등
    • INPUT 기재 규칙 — v0.1.1 강화

      • 턴별로 ### [1] ~ ### [N]으로 분리하고 각각 코드블록으로 감싼다. 표 셀 안에 압축하지 않는다(줄바꿈·백슬래시가 깨진다).
      • 원문 / 시스템 응답 / 작성자 주석을 3자 분리 표기한다: [원문] / [시스템응답] / [주석]
      • 원문을 외부 파일에 위임하지 않는다. 별도 파일에 프롬프트를 두더라도 로그에는 전문을 복사해 넣는다. (대화 로그 참조·전문 생략 금지)
      • 이미지·파일 첨부는 [첨부: 파일명] 형태로 원문 위치에 표기한다.
      • 오탈자·구어체를 교정하지 않는다.
    • STATUS 허용값 (4값) — v0.1.1 개정

      값 의미
      PROCESS COMPLETE 목표 전량 달성. 치명 FAIL 0건
      PROCESS PARTIAL (사유) 일부 완료 + 일부 미착수/미달성. 미달성 범위를 사유에 명시
      중단(미완료) (사유) 목표 미달성 상태로 종료
      보류 (대기사유) 사용자 결정·외부 입력 대기로 진행 정지
      • 위 4값 외 임의 표현(ARCHITECTURE SELECTED, Phase N COMPLETE, 철회 등)을 사용하지 않는다. 단계·범위 정보는 사유 괄호 또는 비고란에 넣는다.
      • [Step 3] V9 확인 결과 산출물이 부재하면 중단(미완료)로 표기한다.
      • 목표를 달성하지 못한 Task를 PROCESS COMPLETE로 표기하지 않는다.

출력 포맷:

Context-Migration & Log

Context-Migration:

  • [메모리명].md: [저장된 메모리 내용 요약] (신규/갱신)
  • OPEN_미해결목록.md: [추가 N건 / 상태 갱신 N건]

Prompt Log 저장: prompt/<담당자>/<YYYY-MM-DD>/<Task식별자>.md

항목 내용
담당자 [담당자명]
일자 [YYYY-MM-DD]
Task 식별자 [식별자]
선행 Task [경로 / 없으면 '—']
경로·모드 [COMPLEX-DOC / GATED]
INPUT [턴별 코드블록 원문 — 요약·편집 없음]
PROCESS [수행 내용 요약]
DECISIONS [결정 지점 / 채택안 / 기각안·사유]
OUTPUT [산출물 / 경로 / 버전 표]
MODEL [사용 모델명·버전]
EFFORT [턴 N / 도구호출 M]
STATUS [4값 중 하나]
비고 [FAST 사유·규정 이탈 근거·한계·수정률]

OUTPUT 실재성 확인: [ls 결과 / 버전 대조 / 핵심 항목 확인]

→ Context-Migration COMPLETE

F4. 담당자 식별

  • 담당자는 담당자ID(성명)를 주키로 식별한다. IP 주소는 보조 확인 수단이다. — v0.1.1 개정
  • 담당자명은 매 Task 착수 프롬프트에 명시한다(예: task: … (담당자: 홍길동)). 명시되지 않으면 최초 1회 질의하여 확정하며, 이전 Task의 담당자명을 자동 승계하지 않는다.
  • prompt/README.md의 매핑 표는 담당자 | IP(있는 경우) | 비고 구조로 유지하며, 활동 중인 담당자는 IP 확보 여부와 무관하게 전원 등재한다.
  • 사용자가 대화 중 IP를 밝히면 그 즉시 매핑 표에 반영한다.
  • 동일 IP를 다수 담당자가 공유하는 환경에서는, IP 일치만으로 담당자를 자동 확정하지 않는다. 세션 시작 시 사용자가 밝힌 담당자명이 매핑 표상 해당 IP의 기존 담당자명과 다르면 반드시 재확인 질의를 거친 뒤 진행하며, 매핑 표의 해당 IP 행을 다른 사람 이름으로 덮어쓰지 않고 prompt/<담당자>/ 로그 폴더만 담당자별로 분리해 사용한다.
  • 타인 명의 문서를 정정할 때는 정정자·정정일·근거를 병기한다. 예: > [정정 2026-08-05 / 홍길동] 원문은 A로 기재했으나 B가 맞다. 근거: …

F8. 로그 입도 기준 (Log Granularity)

  • Prompt 로그의 최소 단위는 1개 Task(Step 0~5, 또는 FAST 경로 1회 완주) 이다. 사용자 발화 1턴 = 로그 1건이 아니며, 반대로 서로 다른 여러 Task를 하나의 로그로 뭉뚱그리지도 않는다.
  • 하나의 대화 세션에서 복수 Task가 순차 수행되면, Task별로 로그 파일을 분리 생성한다.
  • 판단 기준: 1 Task = 1 산출물 계열. 같은 산출물에 대한 연속 수정은 한 로그에 턴을 누적하고, 산출물이 바뀌면 새 로그를 만든다.
  • 하나의 로그가 2일 이상에 걸치거나 사용자 지시 20턴을 초과하면 분할한다. 로그 파일은 실제 작업 일자의 날짜 폴더에 둔다(작성 시점이 아니라 작업 시점 기준).

G3-1. 정본 선언 (Canonical Declaration) — v0.1.1 신설

  • 동일 목적의 산출물이 2개 이상의 계열·버전으로 분기하면, 그 즉시 context-migration에 정본 선언 메모리 1건을 만들고 다음을 기록한다.
    • 현행 정본 파일명·경로 / 담당자 / 확정 일자
    • 병행 분기 목록과 각각의 처리 방침(폐기 예정 / 실험 보존 / 통합 예정)
    • 정본 교체 시 이 메모리를 갱신한다(새 파일을 만들지 않는다).
  • 실험·분기 산출물은 별도 하위 폴더(experiment/, draft/ 등)로 격리하고, 표준 폴더 루트에는 정본만 둔다.
  • 세션 착수 시 최근 수정 파일 목록(ls -lt 등)을 확인하여 병행 세션의 중복 투입을 방지한다. (사고 사례: 하루 10개 파일 파생 후 정본 미결 상태로 계열 전체 폐기 / 동일 문제를 두 세션이 독립 해결 후 정확도 낮은 쪽 폐기)

G3-2. 미해결 항목 단일 창구 (Open Items Registry) — v0.1.1 신설

  • 미해결·보류·확인 필요 항목은 개별 메모리에 분산 기록하지 않고, 프로젝트별 단일 파일 context-migration/OPEN_미해결목록.md에 모은다.
  • 각 항목은 항목 / 제기일 / 최근확인일 / 상태(미해소·해소·무효) / 원출처 [ref:] 를 갖춘다.
  • 매 Task [Step 0]에서 이 파일을 확인하고, [Step 5]에서 신규 항목 추가·기존 항목 상태 갱신을 수행한다.
  • 대상이 삭제·폐기되어 무효화된 항목은 무효로 명시 표기한다(삭제하지 않는다). (사고 사례: 최장 10일+ 이월, 동일 항목이 6개 로그에 연속 이월, 대상 파일 삭제로 자동 무효화된 항목이 유효한 것처럼 잔존)

G3-4. 메모리 신선도 관리 (Memory Freshness) — v0.2.00 신설

  • 메모리는 쌓을수록 좋아지는 자산이 아니라 관리하지 않으면 조용히 노후화되는 자산이다. 낡은 메모리는 없느니만 못하다.

  • context-migration의 모든 메모리 파일은 상단에 아래 4필드를 필수로 둔다.

    소유자: [담당자명]
    확정일: [YYYY-MM-DD]
    최근확인일: [YYYY-MM-DD]
    재확인 조건: [이 사실이 무효가 되는 조건 — 예: 팀 인원 변동 시 / 해당 폴더 구조 변경 시]
    
  • 메모리를 근거로 인용할 때 최근확인일을 함께 본다. 확정일로부터 90일이 지난 메모리는 인용 전 재확인하고, 재확인했으면 최근확인일을 갱신한다.

  • 메모리가 파일·경로·조항·인원을 특정하는 경우, 인용 전에 그 대상이 아직 존재하는지 확인한다. 존재하지 않으면 갱신하거나 무효로 표기한다. ([G3-3])

  • 오류로 판명된 메모리는 삭제한다. 단, 그 오류가 재발 가능한 유형이면 삭제 대신 기술 노트로 전환하여 "이 방식은 틀렸다"를 남긴다. ([F13])

  • [Step 0]에서 관련 메모리를 조회할 때 90일 초과 메모리가 3건 이상 발견되면 사용자에게 정리를 제안한다.

R6. 메모리의 저장과 공유 (Memory & Context)

  • 프로젝트의 context-migration에 저장된 메모리를 먼저 확인하여, 기존 수행된 Task와 중복된 Task 요청 시 토큰 사용량을 최소화한다.
  • 개별 Task가 종료되면, Task 진행 과정에서 획득한 컨텍스트를 context-migration에 저장한다. (상세 절차: [Step 5])
  • Task 입력/수행/출력 이력은 prompt 폴더에 별도 기록한다. (상세 절차: [SECTION 3] 및 [Step 5])
  • 메모리는 재사용 가능한 형태로 작성한다. 결론뿐 아니라 재계산·재조사가 불필요함을 명시하고(예: ## 검증 근거 (재확인 불필요)), 실패한 접근은 동일 방식 재시도 금지로 남긴다.
  • [Step 5]에서 메모리를 신규 생성하기 전 기존 파일을 전수 확인하여, 갱신으로 충분한 경우 새 파일을 만들지 않는다. ([G3])