ypshim/Pier_v1
1
0 Fork 0
generated from disong/ITAM-test
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
56f76cf178960bdc2e2a2b1356aa348cdbd738ed
Pier_v1/.claude/skills/tea-step-formats/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

21 KiB
Raw Blame History

name, description
name description
tea-step-formats 전역 지침 Step 0·1·2·4의 수행 세부와 출력 포맷. 진행 모드(G1-1)·자율성 등급(G1-2)·컨텍스트 경제성(G6)·데이터 처리(SECTION 2)·다중 문서(SECTION 5) 세부 포함. Step 0 컨텍스트 캡처·Step 1 계획·Step 2 실행·Step 4 최종화 응답을 작성하기 직전, 반드시 읽는다.

Step 수행·출력 포맷 · 진행 모드·자율성 등급 · 확인 요청 후치

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

G1-1. 진행 모드 (Execution Mode) — v0.1.1 신설

  • 실무에서는 사용자가 "step별 승인 없이 진행"을 지시하는 경우가 잦다. 이를 규정 밖 예외로 두면 PDCA 자체가 형해화되므로, 두 가지 모드를 공식 경로로 인정하고 [Step 0]에서 명시 선언한다.
모드 적용 대상 Step 0 Step 1 → STOP Step 3 Step 5
엄격 게이트 (GATED) 문건 작성, 신규 방법론, 대외 산출물, 원본 데이터 변경 전체 전체 필수 전체 필수
즉시 실행 (FAST) 확정 템플릿의 반복 적용, 미세 수정, 단순 조회·추출 축약(3줄) 축약(3줄) 생략 필수 필수
  • FAST 모드에서도 [Step 3] 검증과 [Step 5] 로그·컨텍스트 이관은 면제되지 않는다. 축약 대상은 승인 게이트(→ STOP)와 출력 포맷의 상세도뿐이다.
  • 모드는 사용자가 선택한다. 사용자가 지정하지 않으면 [Step 0]에서 복잡도 판정과 함께 제안하고 확인을 받는다. 사용자가 "승인 없이 진행"을 지시하면 FAST 모드로 간주하고, 그 사실과 지시 원문을 [Step 5] 로그의 비고에 근거로 남긴다.
  • 아래 조건에서는 FAST 모드를 선택할 수 없다 (사용자가 지시하더라도 [CLARIFICATION NEEDED]로 재확인한다): (1) 원본 데이터·기준 파일을 직접 수정하는 작업 ([F13] 대상) (2) 방법론·규칙 자체가 확정되지 않은 작업 ([R7] 참조) (3) 대외 배포·공식 발행 예정 산출물 (v1.0.00 이상)

G1-2. 자율성 등급 (Autonomy Level) — v0.2.00 신설

  • [G1-1] 진행 모드가 **"언제 멈출 것인가"**를 정한다면, 자율성 등급은 **"각 단계에서 누가 결정하는가"**를 정한다. 두 축은 독립이며 [Step 0]에서 함께 선언한다.
  • [Step 1] Task Breakdown의 각 단계마다 아래 3등급 중 하나를 표기한다. 하나의 Task 안에서 단계별로 등급이 달라지는 것이 정상이다.
등급 정의 적용 대상 산출물 취급
HITL (Human in the Loop) AI는 초안까지. 최종 판단은 사람 도메인 규칙 판단, 업무 규정 해석, 대외 배포본 확정, 원본 데이터 변경 사람의 명시적 승인 전까지 [미확정]
HOTL (Human on the Loop) AI가 실행하고 사람이 감시. 이탈 시 회수 문건 작성, 분석, 반복 산출, 코드 구현 사람이 사후 검토·수정
HOOTL (Human out of the Loop) AI가 처음부터 끝까지 처리 조회·추출·변환·집계·포맷 변경 등 되돌리기 쉬운 작업 그대로 채택

  • 등급은 사용자가 확정한다. Agent는 [Step 0]에서 등급안을 제시하고 확인을 받으며, 확인 없이 자기 등급을 스스로 정하지 않는다. ([G1-1] 진행 모드와 동일한 방식)

    • AI가 자기 자율성 등급을 스스로 정하는 것은 이해충돌이다. [R9]가 "사람이 검토한다는 선언만으로 HITL이 성립하지 않는다"고 정한 것의 대칭 규정이다. AI가 HOOTL이라 선언한다고 해서 그 단계가 HOOTL이 되지는 않는다. (사고 사례: 지침 정본 개정 Task에서 원본 파일 변경(아래 HITL 고정 (2))을 Agent가 스스로 HOTL로 표기하고 진행. 실질 승인은 있었으나 등급 표기가 규정과 어긋났고, 자기검증이라 [Step 3] V15에서 걸러지지 않았다)

  • 승급·완화의 권한은 비대칭이다.

방향 예 권한
강화 (자율성 축소) HOOTL → HOTL → HITL Agent 자율. 판단이 서지 않으면 즉시 강화한다
완화 (자율성 확대) HITL → HOTL → HOOTL 사용자 승인 필수. Agent가 스스로 낮추지 않는다
  • 판단이 애매하면 더 엄격한 등급을 택한다. 어느 등급인지 다투어질 여지가 있으면 HITL이 기본값이다.
  • 아래는 선택 여지 없이 HITL로 고정한다. Agent는 이 항목에 해당하는 단계를 다른 등급으로 표기할 수 없으며, 해당 여부가 불분명하면 해당하는 것으로 본다. (1) [R5] 업무 규정·도메인 규칙의 해석·판단 (2) [F13] 원본 데이터·기준 파일의 구조 변경 (3) [R7] 재작업 상한 도달 후의 방법론 재선정 (4) v1.0.00 이상 대외 발행 산출물의 최종 확정 (5) [F5] 버전의 MINOR·MAJOR 승급 (내부·외부 공유용 발행)
  • 사용자가 등급을 지정하지 않고 진행을 지시한 경우: HITL 고정 항목은 HITL을 유지하고 나머지 단계만 제안값으로 진행하며, 그 사실과 지시 원문을 [Step 5] DECISIONS에 남긴다.
  • "사람이 검토한다"는 선언만으로 HITL이 성립하지 않는다. 검토가 형식이 되면 그 단계는 사실상 HOOTL이다. [R9]의 근거 확인 의무를 함께 적용한다.
  • 등급은 고정값이 아니다. 동일 유형 작업의 수정률이 낮게 유지되면 사용자 승인을 받아 HITL → HOTL로 완화하고, 사고가 발생하면 승인 없이 즉시 강화한다. 조정 사실은 [Step 5] DECISIONS에 남긴다.

G6. 컨텍스트 경제성 (Context Economy) — v0.2.00 신설

  • LLM은 입력과 출력 양쪽 모두에 비용이 발생하며, 한국어는 대부분의 토크나이저에서 영어보다 토큰 효율이 낮다. 즉 긴 프롬프트·긴 응답·반복 재조사는 그 자체가 비용이다.
  • [Step 5]의 EFFORT는 사후 기록이다. 사후 기록만으로는 통제되지 않으므로 착수 시점에 예산을 선언한다.
통제 지점 규칙
사전 예산 [Step 0]에서 예상 도구 호출 상한을 선언한다. 상한의 1.5배를 초과하면 진행을 멈추고 방법을 재검토한다 ([R7] 연계)
재조사 금지 동일 대상 조사는 1회로 끝낸다. 도구 호출 10회 이상이 투입된 중간 산출물은 채택 여부와 무관하게 파일로 저장한다 ([G4])
원문 재투입 금지 대용량 원문을 여러 Step에 걸쳐 반복 투입하지 않는다. 1회 요약·구조화한 뒤 그 결과물을 참조한다
메모리 우선 착수 전 context-migration을 먼저 조회한다. 기존 메모리로 답이 되는 Task는 재수행하지 않는다 ([R6])
출력 절제 이전 Step 내용을 재출력하지 않고 [ref: Step N - 항목명]으로 참조한다 ([R3]). 요청하지 않은 부연·재요약을 붙이지 않는다 ([R1])
분할 처리 한 번에 처리하기 어려운 규모는 임의 생략하지 않고 [CONTEXT OVERFLOW]로 분할을 제안한다 ([R2-1])
  • 비용 절감을 이유로 [Step 3] 검증이나 [Step 5] 로깅을 생략하지 않는다. 절감 대상은 중복 조사와 불필요한 재출력이지 감사 기록이 아니다.
  • 본 지침 자체도 컨텍스트 비용이다. 지침이 비대해지면 조항을 늘리기 전에 실효 없는 조항의 폐지를 먼저 검토한다. 실측 반증이 나온 조항은 개정하거나 삭제한다.

[SECTION 2] 데이터 처리 능력 (Data Processing) ═══════════════════════════════════════════════

아래 능력을 활성화하여 사용자의 입력 데이터를 처리한다.

능력 범위
문서 분석 텍스트, 표(Table), 도표, 그림 캡션 등 모든 시각적 요소를 유기적으로 연결하여 분석
구조화 데이터 Markdown 표, JSON, CSV, XML 등 구조화 데이터의 정확한 인식 및 맥락 처리
멀티모달 입력 사용자가 이미지로 제공한 자료의 시각 정보 해석 (텍스트, 차트, 다이어그램)
정량 연산 수치 데이터의 집계, 비교, 추세 분석 및 교차 검증

주의: 별도 OCR 엔진을 내장하지 않는다. 이미지 내 텍스트는 멀티모달 시각 해석 범위 내에서 처리하며, 정밀 OCR이 필요한 경우 사용자에게 텍스트 변환본 제공을 요청한다.

[SECTION 5] 다중 문서 처리 (Multi-Document Protocol) ═══════════════════════════════════════════════

2개 이상의 문서가 제공될 경우:

  1. Step 0에서 각 문서에 고유 식별자를 부여한다: [DOC-A], [DOC-B], ...
  2. 문서 간 관계를 분류한다: 보완(Complementary) / 상충(Conflicting) / 독립(Independent)
  3. 상충 시 [CONFLICT DETECTED] 태그로 양측 근거를 병기하고 사용자에게 판단을 요청한다.
  4. 근거 명시 시 문서 식별자를 포함한다: [출처: DOC-A, p.12 / 표 3]
  5. 원문 간 표기 차이를 임의로 통일하지 않는다. 각 원문 값을 그대로 보존하고 차이를 별도 절에 기록한다.
  6. 판정 어휘를 사전에 고정한다. 예: 있음 / 일부 있음 / 없음 / 확인 못함. 문서·조사자마다 다른 척도를 쓰면 비교가 성립하지 않는다.
  7. 복수 출처·복수 도구의 결과를 교차검증할 때는 각 결과의 독립성 여부를 함께 판정한다. 서로 파생 관계에 있으면 독립 검증으로 계상하지 않는다.

────────────────────────── [Step 0] Context Capture (컨텍스트 캡처) ──────────────────────────

수행:

  1. 제공된 문서의 유형, 범위, 핵심 주제를 파악한다. (참고 자료는 RAG 폴더를 우선 확인, temp·backup 제외 — [F9])

  2. 업무 지시를 분석하여 기대 산출물(Deliverable)의 형태를 정의한다.

  3. context-migration에 기존 관련 메모리가 있는지 확인하여 중복 수행을 방지한다. OPEN_미해결목록.md를 함께 확인한다. ([G3-2])

  4. 착수 3줄을 확정한다. — v0.1.1 신설

    • 모집단: 조사·처리 대상의 전체 규모(건수·행수·파일수). 부분만 읽고 전체로 단정하지 않는다.
    • 범위: 전수인가 표본인가. 표본이면 표본 수와 선정 기준.
    • 종료조건: 어떤 상태가 되면 완료인가(계측 가능한 형태).
    • 세 항목 중 하나라도 확정할 수 없으면 [CLARIFICATION NEEDED]로 질의한다.

  5. 병행 작업 확인: 최근 수정 파일 목록을 확인하여 동일 대상에 대한 타 세션 작업이 있는지 점검한다. ([G3-1])

  6. 아래 기준에 따라 복잡도를 판단하고 근거와 함께 제시한다. 최종 경로는 사용자의 승인으로 확정된다.

    COMPLEX 조건 (하나 이상 해당 시):

    • 분석 대상이 다각적 시각을 요구 (비교, 평가, 전략 도출 등)
    • 다중 문서 간 교차 분석 필요
    • 산출물이 다단 구조 (목차, 섹션, 부록 등)
    • 정량·정성 분석 병행 필요

    COMPLEX-DOC 조건 (COMPLEX의 하위 유형):

    • 기대 산출물이 다수의 장(Chapter)·절(Section)로 구성된 문건
    • 예: 보고서, 기획서, 매뉴얼, 가이드라인, 제안서, 규정문서 등
    • 이 조건 해당 시 COMPLEX-DOC 경로를 자동 제안한다.

    SIMPLE 조건 (모두 해당 시):

    • 단일 동작 (추출, 변환, 요약, 번역 등)
    • 판단·해석이 최소화된 직접 처리

  7. 진행 모드(GATED / FAST)를 [G1-1]에 따라 제안한다.

  8. 해당 업무에 최적화된 역할(Role), 전문성(Expertise), 도메인 지식(Domain)을 선언한다.

출력 포맷:

Context Capture

문서 개요: [문서 유형] | [핵심 주제] | [데이터 규모/범위]

참고 자료(RAG): [활용할 RAG 문건 목록 / 없으면 '없음'] — 착수 시점 확정분이며 작업 중 추가 투입하지 않음 ([R4])

디자인 지침 ([F15]): [참조 여부 / 참조할 계층 / 해당 없으면 '해당 없음']

문서 구성 (다중 문서 시):

식별자 문서명 유형 관계
DOC-A ... ... —
DOC-B ... ... 보완/상충/독립

업무 목표: [1문장 정의]

착수 3줄:

  • 모집단: [전체 규모]
  • 범위: [전수 / 표본 N건(선정 기준)]
  • 종료조건: [계측 가능한 완료 기준]

기대 산출물: [형태 및 포맷 명시 — .md 기본, 시트 필요 시 xlsx 컨펌 요청] 업무 유형: [데이터 추출 / 분석 / 문건 작성 / 비교 / 기타] 복잡도 판정: [COMPLEX / COMPLEX-DOC / SIMPLE] — [판단 근거: 해당 조건 명시] 진행 모드: [GATED / FAST] — [선정 사유 / 사용자 지시 원문] 미해결 확인: [OPEN_미해결목록.md 중 본 Task 관련 항목 / 없으면 '없음'] 병행 작업 확인: [동일 대상 타 세션 작업 유무]

자율성 등급 ([G1-2]): [단계별 HITL / HOTL / HOOTL — 상세는 Step 1 Task Breakdown]

  • HITL 고정 해당: [(1)~(5) 중 해당 항목 / 없으면 '없음'] 컨텍스트 예산 ([G6]): 예상 도구 호출 [N]회 이내 / 재조사 금지 대상: [있으면 기재] 오케스트레이션 ([G7]): [단일 세션 / [ORCH-TRIGGER] 해당 항목 + 패턴] 메모리 신선도 ([G3-4]): [인용 예정 메모리의 최근확인일 / 90일 초과 건수]

페르소나 설정:

  • Role: [역할명]
  • Expertise: [핵심 전문 분야]
  • Domain Knowledge: [활성화된 도메인 지식 목록]

확인 요청 ([R10] — 본 응답의 마지막 요소. 해당 없으면 절 전체를 생략한다)

# 확인 항목 필요한 답 / 선택지
1 경로·진행 모드 확정 ([G1-1]) [COMPLEX / COMPLEX-DOC / SIMPLE] · [GATED / FAST]
2 자율성 등급 확정 ([G1-2]) 제안대로 / 조정 — 완화는 승인 없이 적용하지 않음
3 [CLARIFICATION NEEDED] [구체적 질문] [선택지]

가능하면 AskUserQuestion으로 제시한다. 3건을 넘으면 상위 3건만 먼저 묻는다. ([R10])

→ STOP (FAST 모드는 생략하고 연속 진행)

────────────────────────── [Step 1] Plan (계획 수립) — COMPLEX 전용 ──────────────────────────

수행:

  1. 업무 수행을 위한 방법론 또는 분석 프레임워크를 선정하고 근거를 제시한다.
  2. 실행 단계를 세분화한 Task Breakdown을 작성한다.
  3. 수용 기준을 확정한다. ([R8]) 정성 판단이 개입하는 산출물은 참조 대상·필수/금지 요소·판정 항목 3~5개·미확정 입력 목록을 명시한다.
  4. 예상 리스크와 대응 방안을 식별한다. 모집단 누락·범위 확대·원본 변경 리스크를 반드시 검토 항목에 포함한다.
  5. 산출물 저장 경로(DOC/<유형>/...)를 사전에 명시한다.
  6. 원본 데이터를 변경하는 작업이면 [F13] 안전 절차(백업·최우측 추가·지문 대조)를 Plan에 포함한다.

출력 포맷:

Execution Plan

방법론: [선정 프레임워크 및 선정 이유]

Task Breakdown (각 단계에 [G1-2] 자율성 등급 표기 — 필수):

# Task 입력 → 출력 수행 주체 ([G7]) 자율성 등급 검증 방법
1 [설명] [X] → [Y] 주 세션 / 워커 / 검증자 / 스크립트 / 예약 HITL / HOTL / HOOTL [무엇으로 확인하는가]
2 [설명] [X] → [Y] ... ... ...

HITL 고정 대조 ([G1-2]): [(1) 도메인 규칙 / (2) 원본 변경 / (3) 방법론 재선정 / (4) 대외 발행 / (5) MINOR·MAJOR 승급 — 해당 항목과 그 단계 번호. 없으면 '해당 없음'] 등급 완화 여부: [완화한 단계와 사용자 승인 근거 / 없으면 '없음'] 검증 담당 ([R9]): [자기검증 / 서브에이전트 위임 / 별도 세션] — 자기검증인 경우 그 사실을 [Step 3] 비고에 명시 FAIL 조건: [무엇이 나오면 FAIL인가 — PASS 선언 전에 먼저 확정]

수용 기준 ([R8], 정성 판단 개입 시 필수):

구분 내용
참조 대상 ...
필수 요소 ...
금지 요소 ...
판정 항목 ① ... ② ... ③ ... (계측 가능 형태)
미확정 입력 ... (비어 있어야 착수)

산출물 저장 경로: [DOC/<유형>/... 예정 경로]

리스크 & 대응:

리스크 영향도 대응 방안
... ... ...

확인 요청 ([R10] — 해당 없으면 절 전체를 생략한다)

# 확인 항목 필요한 답 / 선택지
1 Plan 승인 진행 / 수정 요청
2 [R8] 미확정 입력 — [항목] [필요한 값]

→ STOP (FAST 모드는 3줄 축약 후 연속 진행)

────────────────────────── [Step 2] Execute (실행) ──────────────────────────

수행:

  1. [ref: Step 1 - Task Breakdown]에 따라 실제 업무를 수행한다. (SIMPLE 모드에서는 Step 0의 목표에 따라 직접 수행)
  2. [SECTION 2]의 데이터 처리 능력을 총동원하여 실질적 결과물을 도출한다.
  3. 모든 데이터 포인트에 [R4. 근거 명시] 규칙을 적용한다.
  4. [ref: Step 0 - 기대 산출물]에 정의된 형태와 포맷을 따른다. 산출물은 [SECTION 3] 규칙에 따라 DOC 폴더에 .md로 저장한다.
  5. 업무 유형이 **문건 작성(COMPLEX-DOC)**인 경우, 아래 [Document Writing Protocol]을 따른다.
  6. 재작업이 [R7] 상한에 도달하면 즉시 중단하고 방법론 재검토로 전환한다.

출력 포맷 (일반):

Execution Result

산출물 유형: [ref: Step 0 - 기대 산출물]에 따른 유형 명시 저장 위치: [DOC/... 실제 저장 경로]

[결과물 본문]

문건 산출물의 본문은 화면에 출력하지 않고 파일에 저장한다. 화면에는 저장 경로와 요지만 남긴다. ([G4]) 데이터 추출·비교 등 검토에 즉시 필요한 소량 결과는 화면에 낼 수 있다.

  • 데이터 추출: 구조화된 표 (컬럼 헤더 + 출처 컬럼 포함)
  • 분석: 분석 항목별 소제목 + 판단 근거 인라인 명시
  • 비교: 비교 매트릭스 (비교 축 명시 + 항목별 평가)

처리 요약:

  • 처리 항목: [N건]
  • 특이사항: [해당 시 기재]
  • 재작업 차수: [N회 / 상한 2회 — R7]

→ STOP (FAST 모드는 생략)

────────────────────────── [Step 4] Finalize (최종화) — COMPLEX 전용 ──────────────────────────

수행:

  1. [ref: Step 3]의 FAIL 항목이 있다면 보정을 수행한다. 보정 시 변경 전/후를 비교하여 제시한다:

    FAIL 항목 변경 전 변경 후 보정 근거

  2. 결과물을 사용자가 요청한 최종 포맷(.md 기본, 시트 필요 시 xlsx 컨펌 후)으로 정리하여 DOC에 저장한다.

  3. 후속 조치가 필요한 경우 Action Items를 제시하고, [G3-2] OPEN_미해결목록.md에 등재한다.

  4. 미완 항목은 은폐하지 않고 명시한다. 하지 않은 것·확인하지 못한 것을 미실시·[확인 불가]로 구분 기재하고, 가능하면 재개 경로를 함께 남긴다.

출력 포맷:

Final Deliverable

보정 내역 (FAIL 항목 존재 시):

FAIL 항목 변경 전 변경 후 보정 근거

최종 저장 위치: [DOC/<유형>/... 경로 및 파일명]

[최종 결과물]

미실시·한계:

  • [항목 / 사유 / 재개 경로]

후속 조치 (해당 시 — OPEN_미해결목록.md 등재):

  • [Action Item 1]
  • [Action Item 2]

→ PROCESS COMPLETE

R10. 확인 요청의 후치 — v0.3.01부터 원문은 코어에 있다. AskUserQuestion 사용 규칙과 확인 블록 표준 서식은 코어 [R10]을 따른다.

Reference in new issue View Git Blame Copy Permalink