HusDev/preferences-logger

선호 기록기 (Preferences logger)

사람들은 어시스턴트와 작업하면서 수많은 작은 결정을 내립니다. 색상, 라이브러리, 명명 규칙, "X를 하지 마세요", "옵션 B" 등이죠. 대부분은 기록되지 않아서 다음 세션이 다시 묻거나 조용히 되돌려 버립니다. 이 스킬은 PREFERENCES.md라는 하나의 파일에 결정이 내려지는 즉시 기록하여, 세션, 도구, 협업자 간에 일관되게 유지되도록 합니다.

적용 시점

읽기: 프로젝트에 PREFERENCES.md가 있다면 첫 번째 작업을 시작하기 전에 읽고, 디자인, 옵션 또는 파일이 이미 정리한 내용을 제안하기 전에 다시 읽으십시오. 파일에 적힌 내용을 따르십시오. 파일에 기록된 사항에 대해 사용자가 언급하지 않는 한 다시 묻지 마십시오.

쓰기: 사용자가 다음 중 하나를 수행할 때 작업과 동일한 턴에 파일에 기록하십시오.

• 선호나 규칙을 말할 때 ("탭이 좋아요", "항상 영국식 철자를 쓰세요", "절대 메인 브랜치에 커밋하지 마세요")
• 당신이 제시한 옵션 중 하나를 선택할 때 ("A", "두 번째 걸로 할게요", "A와 C를 섞어요")
• 작업 방식을 수정하거나 거부할 때 ("이상해요", "아니요, 오른쪽에 두세요", "틀렸어요, ~할 때만") 단, 수정 내용이 어떻게 해야 하는지 설명하는 경우에 한함
• 이전 결정을 변경하거나 번복할 때
• 시험적으로 무언가를 시도할 때 ("한번 해볼게요"): 시험 중임을 표시하여 기록

기록하지 말아야 할 것:

• 현재 작업에만 적용되는 일회성 지시사항 ("이 변수 이름을 바꾸세요")
• 코드나 히스토리에 이미 있는 사실 (파일 구조, 설치된 라이브러리)
• 비밀번호, 자격 증명, 토큰 또는 개인 데이터 (주소, 주민등록번호, 건강 정보). 결정 자체는 기록하되, 민감한 개인 값은 기록하지 마십시오. 예: "푸터에 사용자의 실명을 사용한다" (실명 자체가 민감한 경우 기록 금지)
• 사용자가 수락하지 않은 당신의 제안

지속적인 결정인지 확실하지 않다면 기록하십시오. 짧은 한 줄을 추가하는 것이 잊힌 결정보다 비용이 적습니다.

파일 위치

PREFERENCES.md는 프로젝트 루트에 위치합니다. 단, 프로젝트의 에이전트 지침(CLAUDE.md, AGENTS.md 등)에서 다른 경로를 명시한 경우는 예외입니다. 프로젝트 없이 일회성 채팅인 경우 파일을 생성하지 말고 사용자가 말하는 대로 따르십시오.

파일이 아직 없다면, templates/PREFERENCES.md(이 파일 옆에 있음)를 템플릿으로 사용하여 첫 번째 결정과 함께 생성하십시오. 그런 다음 프로젝트에 CLAUDE.md 또는 AGENTS.md가 있다면, 상단 근처에 다음 한 줄을 추가하여 모든 향후 세션이 이 파일을 읽도록 하십시오:

PREFERENCES.md를 먼저 읽고 최신 상태로 유지하십시오. 결정이 내려지거나 변경될 때마다 해당 줄을 편집하고 날짜가 있는 변경 로그 항목을 동일한 턴에 추가하십시오.

형식

# <프로젝트 이름> — 결정 사항

이 파일이 무엇에 대한 것인지 한 줄 설명.

## <주제>
- **<결정의 짧은 이름>:** 결정된 내용, 간단한 말로. 이유(사용자가 이유를 말한 경우). (이전: 대체된 내용과 날짜.)

## 변경 로그
- 2026년 10월 17일 — <결정되거나 변경된 내용, 한 줄로> (사용자 말: "…").

유용하게 유지하기 위한 규칙:

1. 결정당 한 줄, 주제별로 그룹화. 프로젝트에 맞는 주제를 선택하십시오 (제품, 디자인, 스택, 워크플로, 글쓰기 등). 적은 수로 시작하고 어떤 주제에도 맞지 않는 결정이 생기면 새 주제를 추가하십시오.
2. 제자리 편집. 결정이 변경되면 해당 줄을 현재 상태를 나타내도록 다시 쓰고, 이전 선택은 짧게 "이전: …" 메모로 남기십시오. 서로 다른 두 줄이 남아 있어서는 안 됩니다.
3. 모든 변경에 대해 변경 로그 항목을 추가하고, 가장 최근 항목이 아래에 오도록 하며, 절대 날짜("2026년 10월 17일", "오늘" 또는 "어제" 사용 금지)를 사용하십시오. 상대 날짜는 기록할 때 변환하십시오.
4. 중요한 부분은 사용자의 말을 그대로 짧게 인용하여 보존하십시오. 이는 나중에 의도했던 바를 명확히 해줍니다. 사용자의 말을 왜곡하거나 발언을 실제보다 강하게 만들지 마십시오.
5. 사용자가 이유를 말했다면 이유를 기록하십시오. 이유가 있으면 나중 세션이 규칙이 예측하지 못한 경우를 처리할 수 있습니다.
6. 결정이 가리키는 대상에 연결하십시오: 디자인, 이슈, 목업, 커밋.
7. 시험 및 미확인 사항 표시: "(시험 중)", "(최종 아님)". 확인되면 표시를 제거하십시오.
8. 간결하게 작성하십시오. 짧은 문장, 사용자가 사용하지 않은 전문 용어 사용 금지. 사용자의 이름이나 "그/그녀"를 사용하거나, 사용자가 지칭할 대명사를 말하지 않은 경우 추측하지 마십시오.

요청이 파일과 충돌할 때

가장 최근의 명시적 진술이 우선합니다. 사용자가 파일이 금지하는 것을 요청하면, 그 요청대로 수행하고 해당 줄과 변경 로그를 업데이트하십시오. 사용자가 규칙을 변경하려는 것인지 모호하다면, 기록된 줄을 인용하여 하나의 짧은 질문으로 물어보십시오.

사용자에게 간략히 알리기

파일을 업데이트한 후, 답변 끝에 짧은 절로 언급하십시오 ("PREFERENCES.md에 기록했습니다"). 파일 전체를 요약하지 마십시오. 전체 파일은 요청이 있을 때만 보여주십시오.

예시

사용자가 보여준 세 가지 사이드바 디자인 중에서 고르며 "A, 하지만 버튼은 아이콘이어야 해"라고 답합니다. 이를 구현하는 동일한 턴에:

## 디자인
- **사이드바:** 간결한 메뉴; 폴더 목록이 남은 높이를 채우고 스크롤됨; 설정 및 개인정보 보호 스위치는 하나의 하단 행에 아이콘 버튼 (세 가지 옵션 중 A 선택, 아이콘 버튼 적용).

## 변경 로그
- 2026년 10월 17일 — 사이드바: 옵션 A, 하단 동작은 아이콘 버튼 (사용자 말: "A, 하지만 버튼은 아이콘이어야 해").

일주일 후 사용자가 "그 버튼들에 레이블을 다시 넣어줘"라고 말합니다:

- **사이드바:** … 설정 및 개인정보 보호 스위치는 하나의 하단 행에 레이블이 있는 버튼. (이전: 아이콘만, 2026년 10월 17일.)

- 2026년 10월 24일 — 사이드바 하단 버튼에 레이블이 다시 추가됨 (사용자 말: "그 버튼들에 레이블을 다시 넣어줘").