keelson 이식

keelson 이식은(는) 무엇을 하나요?

규율 있는 이슈 기반 워크플로우 — 프레임 → 계획 → 구현 → 변경 열기 → 게이트 → 종료를 전술적 자율성(에이전트가 기계적인 작업 수행)과 전략적 인간 루프(원래 설계, 계획, 전략을 건드리는 순간 에스컬레이션)와 함께 이 리포지토리, 해당 트래커와 SDLC에 맞게 이식합니다.

대상 리포지토리에서 두 가지를 생성합니다:

1. AGENTS.md — 설문지 형식으로 구성된 기반 자료로, 스킬들이 참조합니다.
2. 생애주기 스킬 팩 — 이식된 아이디어를 리포지토리 고유의 스킬로 평이한 언어로 작성합니다(동작 이름 지정, AGENTS.md에서 트래커 바인딩 읽기, 하드코딩 금지).

필요한 모든 것은 이 스킬 폴더에 있습니다: templates/AGENTS.client.md, templates/lifecycle/*.md, references/tracker-notes.md. 채우기만 하고, 창작하지 마세요.

1 · 인터뷰 진행 방법

이는 구성 세션이지, 빠른 예/아니오가 아닙니다. 약 8–20 라운드 예상 — 단순한 리포지토리는 적게, 복잡한 리포지토리는 더 많이; 흐름이 명확해질 때까지 필요한 만큼 사용하세요. 서두르지 마세요; 결과물은 사용자가 실제로 동의한 AGENTS.md입니다.

• 라운드당 하나의 주제. 참조 흐름이 무엇을 하는지 설명한 후, 사용자가 자신의 리포지토리에 대해 결정하도록 하세요. 중요한 결정을 조용히 기본값으로 넘기지 말고 — 선택지를 표면화하고 진행하기 전에 명시적인 승인을 받으세요.
• 사용자가 흐름을 소유합니다. keelson의 기본값은 시작점이지 정답이 아닙니다. 사용자가 확신하지 못하면 보수적인 옵션을 제시하고, 재검토 표시를 하며, 묻어두지 마세요.
• 제안하기 전에 발견하세요. 발견 라운드를 먼저 실행하여 무엇이 있고, 무엇이 부족하거나 원하는지 파악한 후 — 격차에 맞는 아이디어만 제안하세요.
• 진행하면서 기록하고, 마지막에 확인하세요. 최종 라운드는 모든 결정을 재생하여 한 번의 승인을 받은 후 작성합니다.

2 · 라운드

먼저 발견, 그다음 기둥별 라운드, 발견에서 드러난 선택적 패밀리, 표준 + 전달, 그다음 확인. 각 라운드는 구성하는 스킬과 채우는 자리표시자(§3)를 명명합니다. 단순한 리포지토리는 라운드를 병합하고, 복잡한 리포지토리는 분할하세요.

발견

• D1 · SDLC 맵. 개방형 질문: 현재 존재하는 전달 단계/기둥은 무엇인가(인입 → 분류 → 설계 → 구축 → 검토 → QA → 릴리스 → 운영)? 어떤 것이 견고하고, 어떤 것이 임시방편이거나 누락되었으며, 어떤 것을 keelson이 확립하거나 강화하기를 원하는가? 이는 나중에 제안할 아이디어를 결정합니다 — 처방하기 전에 경청하세요.
• D2 · 트래커 및 용어. 트래커; 작업 항목 / 변경 / 보드를 무엇이라고 부르는지; {{status_field}} 열과 각각이 매핑되는 생애주기 시점.
• D3 · 리포지토리 및 브랜칭. {{default_branch}}, {{branch_pattern}}, {{isolation}}(워크트리 또는 브랜치 전용), {{merge_style}}, 모노 vs 폴리 리포지토리.

기둥 — 각각이 어떻게 작동할지 결정(스킬 채택 + 규칙 포착)

• P1 · 인입 / 프레이밍(frame-the-change) — 모든 변경이 추적되는 {{issue}}로 시작하는가? 무엇을 포함해야 하는가(컨텍스트 / 범위 외 / 승인 기준)?
• P2 · 계획 및 계획이 위치하는 곳(plan-the-work) — 계획이 필요한 시점, 어디에 제출되는가: {{issue}} 댓글, 리포지토리 내 설계 문서, 위키 페이지, 또는 {{change}} 본문? → {{plan_location}}.
• P3 · 문서 및 결정 기록 — 문서 저장소: 리포지토리 내 {{docs_root}}, 외부 위키(예: Confluence/Notion), 또는 혼합 → {{docs_system}}; ADR 사용 여부 및 위치({{adr_dir}})? 문서 업데이트 규칙(어떤 변경이 어떤 문서를 업데이트해야 하는지, 동일 {{change}} 내).
• P4 · 구현 규율(implement-the-change) — 코드 + 문서 + 테스트를 함께? 절대 하드코딩 금지(구성에 표면화)? 범위를 {{issue}}로 제한?
• P5 · 변경 열기(open-the-change) — {{change_title_format}}, 본문에 {{issue}} 링크, {{size_cap}} + {{oversize_label}}, 자체 검토.
• P6 · CI 품질 게이트(tune-gates G1을 통해) — {{quality_gates}}; CI 소유(열기 전에 사전 실행 금지), 빨간 CI 디버깅 중 로컬 검증 예외 허용.
• P7 · 상태 흐름(track-status) — 상태 이동 시점과 이동 주체; 진실 공급원으로 보드 vs. 레이블; 인용 증거와 함께 종료.
• P8 · 선택 규칙(pick-next-work) — 다음 {{issue}}를 선택하기 위한 백로그/우선순위 순서.

선택적 패밀리 — D1이 표면화한 것만 제안; 사용자와 함께 채택 또는 건너뛰기

• O1 · 마일스톤 / 릴리스(close-a-milestone) — 종료 기준이 있는 단계/마일스톤/에픽/스프린트? 릴리스 모델? → {{milestone}}.
• O2 · 검증 게이트(tune-gates G2를 통해) — 검토 가능한 산출물 → review-gate; 표준 {{source_of_truth}} → source-change-gate + source-sync-gate 쌍; 다중 {{targets}} → parity-gate. tune-gates가 게이트 라운드, 선택 규칙 및 템플릿을 소유합니다 — 이 기둥에 대해 실행하면 통합 작성(§4)을 위해 채택된 세트를 반환합니다.
• O3 · 문서 일관성 및 소스 업데이트 — sync-docs(배치 후 조정) 및 update-source-of-truth(진실 공급원 변경을 루프를 통해 흐르게 함).

규율 — 인간 루프

• H1 · 전술적 vs. 전략적 경계 — 핵심. 사용자가 선을 그리도록 하세요: 에이전트가 자율적으로 수행하는 이동 vs. 승인을 위해 에스컬레이션해야 하는 이동.
• H2 · 불확실성 및 우선순위(respond-to-uncertainty) — 모호성 및 문서 충돌 해결; 묻기 vs. 보수적으로 진행.
• H3 · 후속 조치, 선례, 운영(carve-out-followup, check-prior-art, automate-or-runbook) — 각각 채택?

표준 및 전달

• S1 · 엔지니어링 표준 — templates/AGENTS.client.md → Engineering standards에 포함된 InnoVestrum 표준 제시; 그대로 채택, 축소 또는 확장.
• S2 · 스킬 작성 위치 — Claude .claude/skills/, Codex .agents/skills/ 또는 둘 다; 기존 AGENTS.md가 있으면 덮어쓰지 말고 병합.

확인

• C1 · 재생 및 확인. 모든 결정, 채택된 아이디어 vs. 건너뛴 아이디어, 사용자가 열어두기로 선택한 격차를 요약. 최종 승인 한 번 받은 후 채우고 작성.

3 · 자리표시자(채우는 유일한 것)

리포지토리 규칙만 자리표시자입니다; 동사는 평이하게 유지. 모든 것을 해결하고, 채우지 않은 채로 두지 마세요.

• 용어 — {{tracker}}, {{issue}} / {{issues}}, {{change}}
• 보드 — {{board}}, {{status_field}}, 사용된 열: {{status.planning}} · {{status.in_progress}} · {{status.in_review}} · {{status.done}} · {{status.blocked}} · {{status.deferred}} (사용하지 않는 것은 생략)
• 브랜치 / 변경 — {{default_branch}}, {{branch_pattern}}, {{change_title_format}}, {{merge_style}}, {{isolation}}
• 문서 / 결정 — {{docs_system}} (리포지토리 내 / 위키 / 혼합), {{docs_root}}, {{plan_location}}, {{adr_dir}} (어느 것이든 없음 가능)
• 범위 / 게이트 — {{size_cap}} + {{oversize_label}}, {{milestone}}, {{source_of_truth}}, {{target}} / {{targets}}, {{quality_gates}} (어느 것이든 없음 가능)

4 · 채우고 작성

1. 클라이언트 AGENTS.md. templates/AGENTS.client.md를 렌더링: 모든 자리표시자를 대체하고, 채택된 섹션만 유지하며, S1의 표준을 포함하고, references/tracker-notes.md에서 선택한 트래커의 섹션을 ## Tracker notes 아래에 접습니다. 리포지토리 루트에 작성(또는 기존 파일에 병합).
2. 생애주기 스킬. 채택된 각 아이디어에 대해 templates/lifecycle/<name>.md(자리표시자 + 프론트매터 설명)를 렌더링하고 각 클라이언트 스킬 디렉토리에 <dir>/<name>/SKILL.md로 작성합니다. 게이트 스킬 + §8/§3 기반은 tune-gates §4를 따릅니다 — 그 선택(P6/O2)이 어떤 게이트가 채택될지 결정하며, 해당 게이트만 렌더링합니다.
3. 건너뛴 아이디어 → 스킬을 작성하지 말고, 해당 AGENTS.md 섹션도 남기지 마세요.

5 · 검증 및 반환

• 작성된 파일에서 {{을 grep — 남은 자리표시자 0개.
• 채택된 모든 아이디어는 AGENTS.md 섹션과 작성된 스킬이 모두 있으며, 작성된 모든 스킬의 {{status.*}} / {{change}} / {{plan_location}} 등이 인터뷰와 일치해야 합니다.
• 요약: 트래커, 채택된 SDLC 기둥 vs. 사용자에게 맡긴 것, 작성된 파일, 재검토로 표시된 결정. 사용자에게 새 AGENTS.md를 먼저 읽도록 안내하세요.

주의사항

• 사용자가 결정하게 하세요; 중요한 호출을 자동 기본값으로 설정하지 마세요. 용어, 상태 열, 계획 및 문서 위치, 전술적/전략적 경계 — 이는 사용자가 설정할 것입니다. 조용히 기본값으로 설정된 AGENTS.md는 아무도 동의하지 않은 것입니다.
• 팩은 선택 가능하며, 게이트가 가장 중요합니다. 채택된 아이디어만 작성하세요; 표준 진실 공급원이 없고 대상이 하나인 백엔드 리포지토리는 소스 + 패리티 게이트를 완전히 건너뜁니다. 게이트 선택 규칙 — 그리고 "널 바인딩이 있는 게이트 작성 금지" 함정({{source_of_truth}}가 없음이면 source-change/source-sync-gate 없음; 하나의 {{target}}에 대해 패리티 없음) — 은 tune-gates에 있습니다; 이를 적용하고, 여기서 다시 유도하지 마세요.
• 트래커의 명령을 스킬에 기록하지 마세요. 동작 이름을 지정하고, 바인딩은 AGENTS.md → Tracker notes에 한 번만 존재합니다. 스킬에 gh/glab을 쓰려고 하나요? 중단하고 트래커 노트로 푸시하세요.
• 표준은 바닥이지 장식이 아닙니다 — 팩은 코드 품질을 위해 표준을 참조하며, 스킬 내에서 다시 설명하지 마세요.
• 모든 작성된 줄을 황금률(keelson AGENTS.md)에 맞추세요: 격차, 주의사항, 포인터만. 일반적으로 PR을 여는 방법을 설명하는 채워진 스킬은 잘못되었습니다; 단계를 이름 짓고 나머지는 위임하세요.