Imported from maru3172/ProjectDSFD (
Work/2022184042_HSW/AGENTS.md). Install upstream withnpx skills add maru3172/ProjectDSFD --skill 2022184042_HSW. Copyright stays with the author.
# 통합 게임 기획서 최신화 작업 지침
목적과 대상
이 프로젝트는 GitHub를 통해 여러 컴퓨터에서 관리한다. 사용자가 회의록 또는 통합 기획서를 다른 컴퓨터에서 직접 수정할 수 있음을 전제로 작업한다.
- 회의록:
Document/MeetingLog/아래의 회의 기록 - 최신화 대상:
Document/통합_게임_기획서.txt - 기획 방향:
Document/게임_기획_방향.md - 원안 참고:
Document/백화점 화재 사건 제안서.pptx
기획 문서는 Document/ 폴더에 저장한다. 통합 기획서를 MeetingLog 폴더에 새로 만들거나 별도의 통합본으로 분리하지 않는다.
핵심 원칙
- 회의록에 추가되었으나 통합 기획서에 반영되지 않은 내용을 찾아 적절한 항목에 추가한다.
- 회의록에서 개발 방식이 변경되었고 통합 기획서가 이전 방식을 설명하고 있으면, 해당 부분을 최신 결정에 맞게 수정한다.
- 회의록은 통합 기획서 내용의 유일한 출처가 아니다. 사용자가 별도로 작성한 내용이 회의록에 없다는 이유로 삭제하거나 이전 내용으로 되돌리지 않는다.
- 개발 방식 변경을 반영하는 데 필요한 수정 외에 통합 기획서의 내용을 삭제하려면 반드시 사용자 확인을 먼저 받는다. 확인 전에는 원문을 보존한다.
- 문단 교체, 요약, 항목 병합 과정에서 기존 정보가 빠지는 것도 삭제로 취급한다. 표현 정리를 이유로 사용자 작성 내용을 없애지 않는다.
작업 순서
- 작업을 시작할 때 현재 파일을 다시 읽는다. 이전 대화의 기억이나 이전에 생성한 본문으로 덮어쓰지 않는다.
- Git 상태와 필요한 변경 이력을 확인하여 기존 수정 사항을 파악한다. 이 지침 자체는 자동 pull, commit, push 또는 충돌 해결을 위한 덮어쓰기 권한을 부여하지 않는다.
- MeetingLog의 신규 파일뿐 아니라 기존 회의록의 추가·수정 내용도 확인한다. 파일 수정 시간만으로 반영 여부를 단정하지 않는다.
- 회의 날짜와 결정 내용을 기준으로 통합 기획서와 대조한다. 문구가 달라도 의미가 이미 반영되어 있으면 중복 추가하지 않는다.
- 변경 내용을 다음과 같이 판단한다.
- 신규 내용: 기존 내용과 충돌하지 않으면 해당 항목에 추가한다.
- 명확한 개발 방식 변경: 근거 회의와 변경 범위를 확인하고 해당 부분을 수정한다.
- 검토안·제안·미결 사항: 확정된 방식과 구분하여 기록한다. 최신 회의에 등장했다는 이유만으로 확정 결정으로 취급하지 않는다.
- 출처가 회의록에 없는 기존 내용: 그대로 보존한다.
- 변경 의도가 불명확하거나 사용자 추가 내용과 충돌하는 내용: 기존 내용을 보존하고 필요한 확인을 요청한다.
- 전체 파일 재작성보다 해당 부분의 최소 수정을 우선한다. 사용자가 추가한 설명, 수치, 기획 요소와 문서 구조를 존중한다.
- 저장 전 현재 파일이 작업 시작 이후 바뀌었는지 확인한다. 바뀌었다면 다시 읽어 새 수정 사항을 보존한 상태로 반영한다.
- 변경 후 차이를 확인하여 누락·중복·모순과 승인받지 않은 삭제가 없는지 점검한다. 한글 인코딩을 유지한다.
- 사용자 요청으로 통합 기획서에 내용을 추가하거나 수정했다면 아래 규칙에 따라 회의 전달사항 파일을 작성한다.
- 완료 시 추가·수정한 핵심 내용과 근거 회의록, 확인이 필요한 사항을 간단히 보고하고 전달사항 파일도 안내한다.
추가·수정 내용의 회의 전달사항 작성
사용자가 요청하여 Document/통합_게임_기획서.txt의 내용을 실제로 추가하거나 수정할 때마다, 다음 회의에서 팀원들에게 공유할 수 있도록 전달사항 txt 파일을 함께 작성한다. 회의록 반영 요청과 사용자가 직접 전달한 기획 변경 요청 모두에 적용한다.
- 저장 위치와 파일명:
Document/ChangeLog/mmdd_추가및수정_전달사항.txt mmdd는 작업한 날짜의 월일을 각각 두 자리로 표기한다. 사용자 시간대인 Asia/Seoul을 기준으로 하며, 예를 들어 9월 13일은0913_추가및수정_전달사항.txt로 저장한다.- 같은 날짜의 파일이 이미 있으면 기존 내용을 읽고 보존하면서 작업별 항목을 누적한다. 기존 기록을 덮어쓰거나 같은 날짜의 별도 파일을 여러 개 만들지 않는다. 본문에는 연도를 포함한 작업 일시를 기록한다.
- 팀원이 이전 대화를 보지 않아도 이해할 수 있도록 추가한 내용, 수정 전후의 차이, 변경 이유와 근거를 구체적으로 정리한다.
- 통합 기획서의 관련 항목명과 다음 회의에서 논의하거나 확인할 사항을 함께 기록한다. 해당 사항이 없으면 억지로 만들지 않는다.
- 실제 반영한 내용과 아직 미정인 제안을 구분한다. 사용자 요청에 따른 변경을 팀 회의에서 합의된 사항처럼 표현하지 않는다.
- 이번 작업에서 변경하지 않은 기존 내용이나 다른 컴퓨터에서 사용자가 작성한 내용을 이번 작업의 변경 사항으로 보고하지 않는다.
- 통합 기획서를 변경하지 않고 지침만 수정하거나 내용을 검토한 경우에는 전달사항 파일을 만들지 않는다.
전달사항은 기획서 추가·수정 작업의 필수 산출물이다. 작성 후 실제 기획서 변경 내용과 일치하는지 확인한다.
개발 방식 변경에 따른 수정 범위
명확한 회의 결정으로 기존 개발 방식이 대체된 경우, 그 방식에 직접 해당하는 설명은 별도 삭제 확인 없이 수정할 수 있다. 예를 들어 A* 내부 비용 수정에서 원형 범위 기반 분산으로 우선 구현 방식이 바뀌었다면, 우선 구현 설명을 새 방식에 맞게 바꾼다.
이 예외는 변경과 직접 관련된 범위에만 적용한다. 주변의 세계관, 플레이 목표, 파트너와의 관계, 사용자가 별도로 추가한 기능까지 함께 삭제하지 않는다. 이전 방식이 폐기된 것인지 우선순위만 낮아진 것인지 구분하고, 후자의 경우 후속 검토안으로 남긴다.
회의 기록만으로 변경 여부나 범위를 확신할 수 없다면 이 예외를 적용하지 않는다. 기존 내용을 보존하고 사용자에게 확인한다.
삭제 확인 방법
개발 방식 변경 외의 이유로 삭제가 필요하다고 판단하면 다음 내용을 제시하고 명시적인 답변을 기다린다.
- 삭제하려는 항목 또는 구체적인 문장
- 삭제가 필요하다고 판단한 이유
- 삭제 시 없어지는 정보와 문서에 미치는 영향
응답이 없으면 승인으로 간주하지 않는다. 확인이 필요한 부분은 보존하면서, 독립적으로 진행 가능한 추가·수정 작업은 계속한다.
기획 방향 유지
캐릭터 명칭은 '파트너'로 통일한다. 과거 회의록과 원안의 동행자·조력자·동료는 같은 캐릭터를 뜻한다. 원본 기록은 보존하고 통합 기획서 및 신규 문서에 통일된 명칭을 사용한다.
파트너와 서로 의지하며 살아남는 과정에서 신뢰와 애착을 형성하는 경험을 중심에 둔다. 지속적인 경계와 대치에서 오는 공포, 제한된 시야의 분담, 게임 세계 안에서 전달하는 위험 정보를 기준으로 시스템 설명을 정리한다.
회의록의 기술 변경만으로 사용자가 확인한 게임 전체의 기획 방향이 바뀌었다고 추정하지 않는다. 확정되지 않은 수치나 기능을 임의로 확정해 추가하지 않는다.
실행 시점
이 지침은 해당 프로젝트에서 기획서 최신화 작업을 수행할 때 적용한다. 자동 감시나 주기 실행을 설정한 것은 아니며, 사용자가 최신화를 요청하거나 별도로 실행을 설정했을 때 따른다.