BIS 협업 · FROM 기획

기획 협업 스킬 5종

이슈·코멘트에서 결정된 내용이 기획안에 늦게 반영되면, 개발 하네스와 QA TC가 낡은 기준으로 만들어져 재작업이 됩니다. 이걸 막는 절차를 스킬 5개로 나눠 두었습니다. 에이전트에게 카드의 💬 예시처럼 말하면 실행됩니다.

1. 기획 쓰기→ 2. 검토→ 3. 이슈·코멘트→ 4. 반영→ 5. 수거
1. 기획 문서 쓸 때기획
기획-개발 경계 bs-planning-boundary

기획은 WHAT(요구·기준)만 확정합니다. "이 파일 고쳐라" 같은 침범 문장을 잡아 재서술합니다.

💬 자동 발동. 기획 문서를 쓰면 hook이 검사합니다

.claude/skills/bs-planning-boundary/ · 상세

2. 이슈 올리기 전기획
기획안 검토 bs-plan-review

미착수 오전제·모순·수용 기준 부재 같은 결함을 9개 차원으로 검토하고, CRITICAL/HIGH 0건까지 개선한 뒤에만 이슈로 갑니다.

💬 "투자심의 기획안, 이슈 올리기 전에 검토해줘"

.claude/skills/bs-plan-review/ · 상세

3. 코멘트·이슈 쓸 때팀원 전체
코멘트 작성 도우미 bs-issue-comment

태그 5종·필수 요소·표현 위생을 자동 적용해 문안을 만듭니다. 게시는 문안 확인 후 승인으로만.

💬 "#347에 기획 변경 코멘트 초안 잡아줘"

.claude/skills/bs-issue-comment/ · 상세

4. 기획이 바뀔 때QA · 기획
기획안 반영 bs-plan-update

코멘트·결정 근거 1건을 받아 기획안 반영, 버전·CHANGELOG 기록, main 머지, 완료 좌표 회신까지 묶어 처리합니다.

💬 "#347 코멘트, 기획안에 반영해줘"

.claude/skills/bs-plan-update/ · 상세

5. 한 번씩 몰아서QA · 기획
전체 수거 bs-plan-issue-sync

이슈·코멘트 전체를 기획안과 대조해 놓친 변경을 수거합니다. 태그를 깜빡한 변경도 여기서 잡힙니다.

💬 "이슈 전체 스캔해서 놓친 기획 변경 봐줘"

.claude/skills/bs-plan-issue-sync/ · 상세

스킬은 어디에 있고, 어떻게 실행되나

  • 위치 — BIS-Docs 저장소의 .claude/skills/<스킬이름>/SKILL.md. 저장소를 받으면 스킬도 함께 따라옵니다.
  • 실행 — Claude Code(에이전트)로 BIS-Docs 폴더를 열고 💬 예시처럼 요청하면 에이전트가 맞는 스킬을 찾아 절차대로 실행합니다. 스킬 이름을 외울 필요는 없습니다.
  • 정본 — 각 SKILL.md가 실행 절차의 정본이고, 이 가이드는 사람용 요약입니다. 절차 전문이 궁금하면 SKILL.md 파일을 그대로 열어 읽으면 됩니다.
스킬 상세 · bs-planning-boundary

기획-개발 경계 — WHAT은 기획, HOW는 개발

기획 문서가 "이 파일을 고쳐라", "개발은 이 방식으로 하라"까지 지정하면 개발 하네스의 판단 영역을 침범합니다. 이 스킬은 기획 문서를 쓰는 순간 자동 발동해 침범 문장을 잡고, 요구사항+수용 기준으로 재서술합니다.

이렇게 실행됩니다 ⚙️ 자동 — planning 문서를 작성·수정하면 저장 전후로 hook이 검사합니다 (따로 부를 필요 없음) 💬 수동 — "이 기획안, 경계 위반 있는지 스캔해줘"

어디까지가 기획인가

기획이 확정 (WHAT)개발 하네스가 판단 (HOW)
요구사항 · 수용 기준 · 업무 규칙 · P0 범위수정할 파일·함수·컴포넌트 선택
상태 모델 · 권한 매트릭스 · 화면 intent라이브러리·프레임워크·폴더 구조·API 시그니처
DB/데이터 논리 정의 (데이터 분석가 경유)물리 스키마·DDL·구현 순서·알고리즘

재서술은 이런 식

❌ 이렇게 쓰면✅ 이렇게 재서술
"invest-review-table.ts의 파싱 함수를 수정해 셀 병합을 처리하라" "병합 셀이 있는 표도 항목 누락 없이 추출되어야 한다 (수용 기준: 병합 셀 표본 전수 추출) — 구현 위치·방법은 개발 하네스 판단"
  • 코드 위치를 알려줘야 할 땐 05_코드근거포인터 문서로만 (위치 참조 전용).
  • 이슈 등록 전에는 기획안 검토의 R8이 같은 경계를 한 번 더 확인합니다.

위치 .claude/skills/bs-planning-boundary/ · 팀 공유 배경: docs/기획-개발하네스-경계.md

스킬 상세 · bs-plan-review

기획안 검토 — 이슈 올리기 전 결함 차단

결함 있는 기획안이 이슈로 올라가면 워커 재투입·재디스패치·오구현으로 낭비가 증폭됩니다. 등록 전에 9개 차원(R0~R8)으로 검토하고, CRITICAL/HIGH 0건까지 개선을 반복하는 필수 게이트입니다.

이렇게 말하면 💬 "투자심의 기획안, 이슈 올리기 전에 검토해줘" 💬 "/bs-plan-review" — 이슈 본문을 크게 다시 쓸 때(재기획)도 한 번 돌립니다

무엇을 잡아내나

차원잡는 결함 (대표)
R1 현실 대조이미 구현된 걸 "미착수"로 전제, 허구 파일 경로, 스택 오지정 — 타깃 레포 실제와 대조
R2 내부 정합성섹션 간 모순, 수량 불일치, 동시에 만족 불가한 지시
R4 이슈 상충같은 파일을 다루는 열린 이슈와 정면 충돌
R5 수용 기준테스트 가능한 합격 조건 부재 — 없으면 CRITICAL
R7 보안시크릿·실서버 정보 노출, 권한·개인정보 취급 미정의
R8 경계코드 수정 지시 등 기획-개발 경계 침범

이 밖에 R0 완결성 체크리스트 · R3 식별자 계약 · R6 이미 해결됐거나 중복인 요구까지 총 9개 차원.

결과는 이렇게 남습니다

  • 리포트가 <기능>/validation/bs-plan-review-YYYYMMDD.md로 커밋됩니다. 판정(PASS/CONDITIONAL/BLOCKED)과 개선 이력이 담깁니다.
  • 스킬이 개선까지 반복 적용하고, 사람이 정해야 할 것만 "결정 필요" 목록으로 분리합니다.
  • CRITICAL/HIGH 0건 + 자료 main 머지 후에만 이슈 등록으로 넘어갑니다. 이때부터 개발 요청 이슈에 기준 version + 커밋 해시를 답니다 → 기획 버전 읽는 법

근거: 2026-07-03 실측 — 이슈 99건 검토에서 stale ~25건, 수용 기준 0인 스냅샷 13건(매일 재디스패치 낭비) 등.
위치 .claude/skills/bs-plan-review/ · 배경 분석: bs-plan-review-skill/

스킬 상세 · bs-issue-comment

코멘트 작성 도우미 — 태그·필수 요소 자동

이슈 본문·코멘트는 사람만 읽는 것이 아니라 개발 하네스와 QA TC 생성기가 기준으로 파싱하는 데이터입니다. 에이전트로 쓰면 이 스킬이 태그와 필수 요소, 표현 위생을 챙깁니다.

이렇게 말하면 💬 "#347에 기획 변경 코멘트 초안 잡아줘" 💬 "권한 정책 결정 요청 올려줘 — @기획, 기한 이번 주" 💬 "#309 이슈 본문, 4줄 규칙으로 갱신해줘"

스킬이 챙기는 것

  • 상황을 분류해 태그 5종(📌 ✅ 🙋 🧪 ⚙️) 중 맞는 것을 고르고, 태그별 필수 요소를 채웁니다. 📌 기획 변경은 무엇/적용 경계/반영 상태 3요소.
  • 모호 표현("최신 버전", 로그 속 "확정" 등)을 불변 좌표(plan vN.M · #이슈번호 · dev@hash)로 교정 → 모호한 표현 피하기
  • 🙋 결정 요청의 @대상은 기획 담당자 정본에서 확인.
  • 새 이슈 본문엔 4줄(유형/착수 조건/완료 기준/스코프 밖)을 넣습니다 → 이슈·코멘트 작성법

게시는 승인으로만

완성 문안을 먼저 보여드리고, 현재 턴에서 승인해 주셔야만 게시·수정합니다. 자동으로 올라가는 일은 없습니다.

직접 쓰실 땐 📌/✅ 둘만 기억 → 이슈·코멘트 작성법.
위치 .claude/skills/bs-issue-comment/

스킬 상세 · bs-plan-update

기획안 반영 — 반영부터 완료 좌표까지 한 흐름

코멘트·결정·회의 같은 근거 1건을 받아 기획안 반영, version 증가와 CHANGELOG 기록, main 머지, 완료 좌표 회신까지 한 번에 처리합니다. 버전 판정(Major/Minor/Patch)은 스킬이 하므로 팀원은 태그만 붙이면 됩니다.

이렇게 말하면 💬 "#347 코멘트, 기획안에 반영해줘" 💬 "어제 회의에서 결정된 것 반영하고 버전 올려줘"

흐름

  1. 근거 확보 — 코멘트 링크·이슈 번호·회의록. 근거 없는 반영은 하지 않습니다.
  2. 대상 기획안 해석 — 위치 맵(plan-doc-locations) + 내용 교차확인. 키워드만으로 단정하지 않습니다.
  3. 반영(WHAT만) + 버전 판정 + 변경 이력 1행 (근거 링크 필수)
  4. feature 브랜치 → PR → main 머지 — main에 없으면 개발 하네스가 보지 못합니다.
  5. 원 코멘트에 BIS-Docs 반영: 완료(<sha>) · plan vN.M 회신 — 이게 완료 표시.

주의

  • 열린 🙋 결정 요청은 반영하지 않습니다. 결정이 먼저입니다.
  • Minor 이상이면 회신에 "영향받는 TC 재생성 필요"를 함께 남깁니다 (TC 재생성은 QA 소유) → 기획 버전 읽는 법

놓친 변경을 몰아 걷는 것은 전체 수거 몫입니다.
위치 .claude/skills/bs-plan-update/ (+ BisFramework/_guardrails/teams/plan-doc-locations.md — 도메인→기획안 위치 맵 SSOT)

스킬 상세 · bs-plan-issue-sync

전체 수거 — 놓친 변경 감사

이슈 본문·코멘트 전체를 기획 패키지와 대조해서, 태그를 깜빡했거나 반영이 누락된 변경을 걷어냅니다. 기본은 읽기 전용 스캔이라 승인 없이 기획 문서를 덮어쓰지 않습니다.

이렇게 말하면 💬 "#347·#309 스캔해서 놓친 기획 변경 있는지 봐줘" 💬 "투자심의 패키지, 이슈 반영 상태 감사해줘"

4단계 모드

모드하는 일기획 문서 수정
scan (기본)이슈·코멘트 정규화, 완료(<sha>) 좌표 실검증, 변경 후보 탐지안 함
propose검토 번들·반영 후보 생성 (blocker 0일 때만 제안)안 함
apply-approved승인된 범위만 기획안에 반영승인 범위만
qa-handoff승인된 변경에서 QA TC용 해석 입력 생성안 함

알아두면 좋은 것

  • 📌 코멘트의 완료(<sha>) 좌표를 그대로 믿지 않고, 실제 main 도달·패키지 변경 여부를 검증합니다.
  • 태그 없는 변경·상충 변경도 후보로 잡되, 자동 중재 없이 사람 검토로 분리합니다.
  • "이상 없음(NO_ACTION)"도 정상 결과입니다. 어긋남이 없다는 감사 기록을 남기는 것이 목적입니다.

위치 .claude/skills/bs-plan-issue-sync/

참고 · 이슈 등록·코멘트 작성

이슈 등록·코멘트, 이렇게 씁니다

에이전트로 쓰면 코멘트 작성 도우미가 자동으로 챙깁니다. 이 페이지는 직접 쓰실 때를 위한 요약입니다.

먼저 — 개발 하네스·QA는 뭘 기준으로 보나

주체보는 것
개발 하네스 1) 이슈 본문 (착수·완료 조건)  2) BIS-Docs 기획안 plan v1.2 기준  3) 📌 기획 변경 중 반영: 대기 코멘트만 임시 우선
QA 1) 기획안의 검수·QA 해석 기준  2) TC에 찍힌 plan v1.2 좌표 (FAIL 시 버그/기획 낡음 판정)  3) 🧪 QA 참고 코멘트

공식 기준은 위 3개입니다. 조건 변경은 본문 수정, 기획 변경은 태그가 공식 경로입니다. 단 하네스는 실제로는 모든 코멘트를 읽으므로 미확정 아이디어도 기준처럼 흡수될 수 있습니다. "미확정" 병기가 중요합니다.

코멘트 머리에 태그 하나

사실 📌 기획 변경 ✅ 결정 둘만 기억하셔도 충분합니다.

태그언제
📌 기획 변경요구사항·범위·순서를 바꾸자는 얘기
✅ 결정논의가 끝나고 확정됐을 때
🙋 결정 요청결정이 필요한데 아직 안 났을 때 — @대상 (기한) 포함
🧪 QA 참고기준 커밋·알려진 gap 등 QA가 알아야 할 정보
⚙️ 작업 보고진행 로그 — 확정·결정·승인 단어는 피해 주세요 (자동화가 결정으로 오해합니다)

📌 기획 변경 은 세 줄이면 됩니다

BisFramework #347 · 실제 코멘트 — 원문 보기 ↗
📌 기획 변경 — PRE-INFRA-01/02 실행 주체 이관 (개발단 사람 → 개발 하네스)
무엇: DB 생성 + 시크릿 주입을 개발단 사람 실행에서 개발 하네스 직접 실행으로 변경
적용 경계: #309(S1) 착수부터, 소급 없음
BIS-Docs 반영: 완료(6b2bcc8)

1) 무엇이 바뀌나  2) 어디부터 적용  3) 반영 상태 — 반영 전이면 대기(기획이 반영 후 완료(commit)로 마감), 이미 반영을 마쳤으면 처음부터 완료(commit)이어도 됩니다. 반영이 끝나면 코멘트에 plan v1.2 좌표 답글이 달립니다 → 기획 버전 읽는 법

상황별로 고르면

상황이렇게
버그 발견 (기획대로인데 동작 이상)태그 없이 그냥 — 기획 변경 아님
"이렇게 바꾸면 좋겠다" 제안합의 전 🙋 결정 요청 → 확정되면 ✅ 결정
화면이 기획서와 다르다🧪 QA 참고 — 버그/기획 낡음 판정은 기획이 합니다
개발 중 기획에 없는 케이스🙋 결정 요청 @기획 (→ 기획 담당자)
착수·완료 조건 변경코멘트보다 이슈 본문 수정이 확실합니다

이슈 본문엔 이 4줄 — 하네스가 안 헤매는 최소 조건

이슈 본문 상단 (예)
유형: 구현              ← 구현 | 결정 대기 | 트래커(허브) | QA 리포트
착수 조건: #345 병합 후    ← 없으면 "없음" — 이슈번호·링크로 기계판정 가능하게
완료 기준: 저장 후 재조회 시 값 유지
스코프 밖: 메뉴 진입 배선   ← 이 이슈 혼자 완료 가능한 단위로 자르기

근거: 열린 이슈 150개 중 104개가 완료 기준 없음, 유형 표시가 없어 QA 리포트·트래커 이슈에도 개발 하네스가 반복 투입돼 "3회 중단"이 12건+ 발생 (2026-07-16 보드 실측. 실물: #318 ↗ 코드 델타 없는 이슈 반복 투입 · #346 ↗ 스코프 밖 의존으로 완료 불가)

실물 예시 (깃 이슈)

이 페이지는 사람용 요약입니다. 기계용 정본은 코멘트 작성 도우미(bs-issue-comment 스킬)에 들어 있어 에이전트가 코멘트를 쓸 때 자동으로 지켜집니다.

참고 · 표현 위생

하네스·QA가 헷갈리는 표현들

이슈 본문·코멘트는 사람만 읽는 것이 아니라 개발 하네스와 QA TC 생성기가 기준으로 읽습니다. 아래 표현만 피하면 오독의 대부분이 사라집니다.

이렇게 쓰면왜 헷갈리나대신 이렇게
"최신 버전"·"어제 결정"·"위 코멘트"읽는 시점마다 다른 걸 가리킴 plan v1.2 (날짜) · 코멘트 링크 · dev@hash
진행 로그에 "확정·결정·승인"하네스가 결정으로 오파싱 결정은 ✅ 결정·📌 기획 변경에만, 로그는 ⚙️ 작업 보고
dev 반영 시점에 "완료·닫습니다"이슈 조기 종결로 처리됨 "dev 반영"이라 쓰고, close는 staging 확인 후 (예외: QA Report 서브태스크는 dev 머지+배포 확인 시 하네스가 자동 close — 07-18 정책)
착수 조건을 코멘트에만하네스는 본문을 기준으로 봄 이슈 본문 수정 + "본문 갱신함" 코멘트
미확정 사항을 확정처럼 인용결정으로 오독 "미확정" 병기
"S1"·트랙명 단독 지칭그 문서 밖에서는 무의미 #이슈번호로 지칭
아직 없는 것을 현재처럼 기술
"서버 그룹 매핑을 사용한다"		 하네스가 존재하지 않는 걸 찾다 착수 중단 (#305·#308 실증) 신설이면 "신설 예정" 명시, 현재 근거는 파일 경로로
완료 기준 없이 "개선해주세요" 어디까지 하면 끝인지 몰라 3회 재시도 후 중단 완료 기준(Not Done If) 1줄
결정 대기를 할 일처럼
"~확정 필요"만 적고 큐에 둠		 워커가 착수했다가 매번 사람 대기로 차단 🙋 결정 요청 @대상 (기한) — 결정 전엔 착수 큐에 안 넣기

이 표는 사람용 요약입니다. 기계용 정본은 코멘트 작성 도우미(bs-issue-comment 스킬)에 들어 있어 에이전트가 코멘트를 쓸 때 자동으로 교정됩니다.

참고 · 기획 버전

기획안은 버전으로 구분됩니다

기획 단위(패키지 / Phase·하위프로젝트)에 version 좌표가 붙고, 변경 단위 폴더의 CHANGELOG.md에 반영 이력이 쌓입니다. 반영마다 버전이 올라갑니다.

…/<변경 단위>/CHANGELOG.md
## 이력
| 버전 | 날짜  | 근거            | 변경 |
| v1.2.0 | 07-15 | #347 코멘트   | PRE-INFRA 실행 주체 이관 |
| v1.1.0 | 07-10 | #284 ✅ 결정   | HR-2 권한 전원 접근 확정 |

version 필드는 그 단위의 대표 문서(패키지=index.yaml 진입 문서, 수동=02_기획상세안) frontmatter에 있습니다. 규칙 정본은 docs/기획 운영 계약.md §4.3.

도입 시작 단계 — 아직 version·CHANGELOG가 없는 문서가 대부분입니다. 좌표는 그 문서에 첫 반영(부트스트랩)이 일어나는 시점에 붙습니다 (반영 전 문서를 열면 좌표가 없을 수 있습니다).

  • 개발 하네스·QA는 어느 version + 커밋 해시 기준인지 좌표를 갖고 시작합니다. QA FAIL이 나면 좌표 대조로 버그인지 기획이 낡은 것인지 갈립니다.
  • 인용은 "최신 버전" 말고 plan v1.2 (날짜)로 씁니다. 읽는 시점과 무관하게 같은 것을 가리킵니다.
  • 개발 요청 이슈에는 기준 version + 커밋 해시를 적습니다 (해시가 불변 스냅샷).

버전 올리기 — 판정은 스킬이 합니다

  • "이거 반영하고 버전 올려줘"(또는 직접 고친 뒤 "버전 올려줘")라고 하면, 기획안 반영 스킬이 자리(Major/Minor/Patch)를 판정해 "Minor로 올릴게요"처럼 먼저 보여줍니다. 예상이 틀리면 그 자리에서 "이건 Major야"로 정정하면 됩니다.
  • 자리 기준을 외울 필요는 없습니다. 판정 기준 상세는 bs-plan-update 스킬 정본에 있습니다.
  • 반영 1건마다 CHANGELOG에 근거 코멘트 링크가 남습니다. 버전만 올라가고 기록이 없는 일은 없습니다.

버전 자리별 의미 — Major / Minor / Patch

버전은 3자리 vN.M.K입니다. 자리마다 의미와 QA·개발 파급이 다릅니다.

자리언제 오르나QA TC · 개발 하네스 파급
Major
N.0.0		 방향·구조가 크게 바뀜 — "사실상 다른 문서" 수준. 기존 단위를 archive로 보존한 뒤 새 단위가 승계(폴더 교체 절차) TC 전면 재생성 + 하네스 재계획
Minor
x.N.0		 관련자가 다시 읽어야 하는 내용 추가·변경 — 새 섹션·정책 변경. 수치·기대값 정정 포함 (임계값·산식·기간·상태값 등 QA TC가 대조하는 값이 바뀌면 표기 실수 정정이라도 Minor) 영향받는 TC만 재생성
Patch
x.x.N		 오타·문구 등 의사결정·QA 기대값에 영향 없는 표기 수정 기존 TC 전부 유효
  • 상위 자리가 오르면 하위는 0으로 리셋 — 1.2.3 → 2.0.0. 인용은 plan vN.M까지 (Patch 생략).
  • 자리가 애매하면 더 큰 자리로 판정합니다. 판정 정본은 bs-plan-update 스킬 §4.

날짜·시간 추적 — 좌표 2개가 시각을 기록합니다

CHANGELOG의 날짜 열은 요약용입니다. 정밀 시각은 손으로 기록하지 않습니다 — 반영마다 남는 좌표 2개에 초 단위 시각이 자동 기록되며, 같은 날 여러 번 반영돼도 이 좌표로 순서를 구분합니다.

코멘트 permalink = 요청·결정 시각. 특정 코멘트 1개를 가리키는 고유 주소로, 이슈 주소 뒤에 #issuecomment-숫자가 붙은 형태입니다. 코멘트 오른쪽 위 ⋯ 메뉴 → Copy link로 복사합니다. 주소를 열면 해당 코멘트로 이동하고, 코멘트 상단의 시각에 마우스를 올리면 초 단위까지 표시됩니다.

permalink 예시 — 실물 열기 ↗
https://github.com/MAESTRO-BS/BisFramework/issues/347#issuecomment-4980485659
이슈 #347 주소 + 코멘트 고유번호 — 뒤가 붙어야 특정 코멘트(=시각)를 가리킴

CHANGELOG 근거 열 표기:  [#347 코멘트](…#issuecomment-4980485659)

완료(<sha>) = 반영 시각. sha는 반영 커밋의 해시(커밋마다 부여되는 고유 번호) 7자리입니다. 반영이 끝나면 원 코멘트에 완료 답글이 자동으로 달리고, 해시로 커밋 페이지를 열면 반영 시각이 표시됩니다.

완료 답글·커밋 시각 확인 예시 — 실물 열기 ↗
반영이 끝나면 원 코멘트에 자동으로 달리는 답글:
BIS-Docs 반영: 완료(6b2bcc8) · plan v1.2

커밋 페이지에서 시각 확인:
https://github.com/MAESTRO-BS/BIS-Docs/commit/6b2bcc8   → 2026-07-15 21:17
  • 요청·결정 시각 = 근거 permalink의 코멘트 시각 · 반영 시각 = 완료 커밋 시각 · 회신 시각 = 완료 답글의 작성 시각.
  • CHANGELOG 근거 열에는 이슈 번호(#347)가 아니라 코멘트 permalink를 기록합니다 — 이슈 번호에는 시각 정보가 없습니다. 스킬 반영 시 자동 기록됩니다.

직접(수동) 작업했다면

스킬 없이 문서를 직접 수정해도 버전 관리는 유지됩니다. 경로는 세 가지입니다.

1) 부기 위임 (기본) — 문서를 직접 수정한 뒤 에이전트에 요청합니다. 버전 판정 → CHANGELOG 기록 → main 머지 → 완료 답글까지 자동 처리됩니다.

이렇게 말하면 💬 "버전 올려줘" — 직접 고친 문서의 버전 부기만 맡길 때 💬 "#347 코멘트, 기획안에 반영해줘" — 반영부터 맡길 때

2) 완전 수작업 — 에이전트 없이 진행할 때는 아래 4단계를 수행합니다. 시각은 기록하지 않습니다 — 커밋·코멘트에 자동 기록됩니다.

  1. 대표 문서 frontmatter의 version을 올립니다 (자리가 애매하면 더 큰 자리로).
  2. CHANGELOG에 1행을 추가합니다 — 버전 · 날짜 · 근거 코멘트 permalink · 변경 요약.
  3. PR로 main에 머지합니다 (main에 없으면 개발 하네스가 보지 못합니다).
  4. PR 화면의 merged commit 해시(예: 6b2bcc8)를 복사해 원 코멘트에 BIS-Docs 반영: 완료(6b2bcc8) · plan vN.M 답글을 답니다.

3) 누락 감사 — 완료 답글이 없는 📌는 전체 수거가 찾아내고, 수기로 작성한 완료 좌표도 실제 main 반영 여부를 검증합니다.

이렇게 말하면 💬 "이슈 전체 스캔해서 놓친 기획 변경 봐줘"

Major(사실상 다른 문서 수준)는 폴더 교체 절차가 별도입니다 — 기획 담당 확인 후 기획 운영 계약 §4.3 절차로 진행합니다.

참고 · 담당자

결정 요청, 누구에게 보내나

🙋 결정 요청의 @대상과 📌 기획 변경을 처리하는 기획 담당은 업무영역별로 나뉘어 있습니다.

기획 담당업무영역
조정화투자심의평가(이민노 인수인계 예정) · 사업수지 파싱 · 에너지 · 재무·회계(손익보고 · 결산·자금 · 하자보수충당부채 · 리스마감)
이민노분양 · 공사 현장보고 · 분석(공사비지수 · 품의 분석) · 견적 · 시스템 권한 관리
공동수주관리 · 미노출 메뉴군

메뉴 단위 상세와 갱신 이력은 정본에서: BisFramework/_guardrails/teams/planning-owners.md ↗ — 이 페이지는 요약이라, 담당이 바뀌면 정본이 우선입니다.

참고 · QA 참고 경로

QA — TC 작성 때 보는 경로

QA TC는 QA팀이 기획 정본의 수용 기준을 기반으로 작성합니다 (2026-07-21 전환 — 자동 생성 TC 마스터 폐지). 기획 → QA 전달은 아래 3가지입니다. 이 페이지는 정본 경로만 안내하고, 목록·상세는 각 정본 문서에서 확인합니다.

기획 → QA 전달 3종

무엇문서 경로
1. 기획안 위치
도메인 → 패키지		 BisFramework/_guardrails/teams/plan-doc-locations.md ↗ — 도메인별 위치 표의 정본(SSOT). 패키지 안에서 QA 기준 문서는 각 index.yaml의 post_implementation_validation.qa_checklist가 가리킵니다
2. 버전·변경 이력 단위당 1개의 CHANGELOG.md — 실재 경로 목록은 위 plan-doc-locations.md의 "변경 이력(CHANGELOG) 위치" 섹션. 자리별 TC 파급은 기획 버전 읽는 법의 Major/Minor/Patch 표
3. 버전 업데이트 스킬 .claude/skills/bs-plan-update/ — 기획 변경 반영·버전 판정·완료 좌표 회신 (기획안 반영). QA가 기획 변경을 발견하면 💬 "#347 코멘트, 기획안에 반영해줘"로 요청합니다

TC에 남기는 좌표

  • TC에는 기준 plan vN.M + 커밋 해시를 기록합니다 — QA FAIL 시 이 좌표 대조로 버그인지 기획 낡음인지 판정합니다.
  • 기획 반영 회신이 Minor 이상이면 "영향받는 TC 재생성 필요" 신호가 함께 옵니다 — 자리별 파급은 기획 버전 읽는 법의 표 참조.

TC 작성 체크리스트·과거 TC 이력은 QA 내부 문서 docs/QA/BIS_Framework/QA-TC-전달-경로.md ↗ 에 있습니다 — 필요 시 참조 (기획 전달 항목 아님).