Imported from Ryokuman/new_human_ochestrator (system/20-skills/user-personality-adaptive-response/SKILL.md). Install upstream with npx skills add Ryokuman/new_human_ochestrator --skill user-personality-adaptive-response. Copyright stays with the author.

사용자 성향 기반 응답 조정

이 스킬의 목적은 사용자를 심리 분석하는 것이 아닙니다. 목적은 사용자의 실제 업무 방식에 맞는 응답 계약을 유지하는 것입니다.

핵심 원칙:

1. 사용자가 명시한 피드백과 반복 행동에서 업무 관련 선호만 추론합니다.
2. 다음 행동, 승인 단위, 진행 여부, 저장 위치, 범위, 검증 범위가 걸리면 보기 3개를 제공합니다.
   • main-v3/main의 저위험 build 흐름에서는 보기 3개가 구현을 막는 gate가 되지 않게 합니다.
   • 사용자가 이미 진행을 선택했거나 빠른 실행을 요구하면, 먼저 만들고 결과 보고에서 다음 선택지를 제시합니다.
3. 응답이 빗나간 경우, 변명보다 놓친 신호와 수정된 규칙을 짧게 정리합니다.
4. 응답 계약에 영향을 주는 feedback 사건은 장기 반영 여부와 무관하게 로컬 feedback으로 반드시 남깁니다.
5. 안정적인 패턴만 사용자 승인 후 장기 규칙으로 반영합니다.
6. 장기 규칙 갱신은 대상 브랜치 정책을 따릅니다. 이 프로젝트에서는 main 기준 별도 worktree를 만들지 않고 main-v3/main 기준으로 처리합니다.
7. 사용자가 보기 밖 답변을 하면 먼저 feedback을 남기고, 보고서 작성과 장기 반영은 사용자 주도 검토 세션에서 판단합니다.
8. 실제 퍼스널리티 업데이트는 사용자 승인 후에만 실행합니다.

기본 동작

실질적인 답변, 리뷰, 계획, 상태 보고를 할 때마다 다음을 확인합니다.

1. 현재 사용자의 실제 목표가 무엇인지 먼저 복원합니다.
2. 지금 필요한 것이 직접 실행인지, 추천인지, 선택지인지 판단합니다.
3. 다음 행동이나 승인 경계가 있으면 보기 3개를 제시하고 추천안을 표시합니다. main-v3/main에서는 secret/production/destructive/data/protected branch 위험이 없으면 실행을 멈추지 않습니다.
4. 사용자가 중요하게 보는 기준으로 절충점을 설명합니다.
   • 영향 범위
   • 검증 부담
   • 되돌리기 쉬운지
   • source/generated/runtime 영향
   • 승인 경계
5. 사용자가 응답이 빗나갔다고 말하면 feedback 루프를 실행하고 feedback을 남깁니다.
6. 사용자가 보기 1~3 대신 직접 답변하면 보기 밖 선택 루프를 실행하고 feedback을 남깁니다.

Repo-local skill 확인

사용자가 이 스킬 자체, 퍼스널리티 업데이트, 선택지 정책, 보고 방식, 승인 경계 누락을 지적했는데 세션의 외부 skill 목록에 user-personality-adaptive-response가 없으면 바로 "없다"고 단정하지 않습니다.

먼저 현재 repo 또는 workspace의 repo-local skill 위치를 확인합니다.

system/20-skills/user-personality-adaptive-response/SKILL.md
system/20-skills/<관련-skill>/SKILL.md

repo-local skill이 있으면 해당 SKILL.md와 직접 연결된 references를 읽고 이 스킬 기준으로 처리합니다. 그래도 없을 때만 사용 불가 사유를 말하고 fallback으로 feedback을 남깁니다.

태스크 실행 사일로 기본값

사용자가 task 실행, 태스크 진행, task 수행을 요청하면, 이는 단순 계획 요청이 아니라 사일로 준비 실행 요청입니다.

별도 확인 없이 아래까지 한 번에 수행합니다.

project SSoT 원본 task/issue 상태 갱신 PR 생성 및 project-{projectName} 머지 확인
-> task-xxxx/ 생성
-> goal.md 작성
-> 필요한 repo clone
-> repo별 작업 브랜치 생성

기본 규칙:

• 사일로는 현재 workspace 루트에 보이는 task-xxxx/ 디렉토리로 만듭니다.
• task/issue 사일로라면 사일로 root, goal.md, repo clone, 작업 브랜치 중 하나라도 만들기 전에 project 계층 작업 브랜치에서 원본 task/issue 상태를 in_progress로 바꾸는 상태 갱신 PR을 만들고 project 계층 메인 브랜치에 머지된 것을 확인합니다. 목표 모델에서는 project-{projectName}/{taskname}과 project-{projectName}/main, 현재 호환 상태에서는 project-{projectName}-{taskname}과 project-{projectName}을 사용합니다.
• 상태 갱신 PR이 머지되기 전에는 사일로 root 생성, goal.md 작성, repo clone, 작업 브랜치 생성을 시작하지 않습니다. 상태 갱신 PR 생성 또는 머지 확인을 할 수 없으면 사일로 진행을 멈추고 이유를 보고합니다.
• 사용자가 직접 지정하지 않으면 /tmp, 홈 디렉토리, 숨김 디렉토리, 에이전트 전용 임시 경로를 사일로 위치로 쓰지 않습니다.
• goal.md에는 task 목표, 필요한 repo, 보호 브랜치, 작업 브랜치명, 개발자/QA/리뷰 역할, 금지선, 검증 기준, PR 본문 필수 항목을 적습니다.
• 기능 task는 프론트/백엔드를 별도 소유권으로 나누지 않고 사용자 목적과 완료 경로 기준의 풀스택 단위로 봅니다.
• 소비 API, schema, store method, route가 아직 없다는 사실은 단독 위험으로 단정하지 않고, 같은 task 안에서 백엔드 계약을 먼저 만들고 프론트가 소비하는 순서로 goal.md에 적습니다.
• 사용자가 좁은 스코프의 처방과 판단 근거의 위치를 지적하면, 먼저 system SSoT가 상황별 행동표가 아니라 판단 근거와 계층 분류 기준을 담는 하네스라는 점을 기준으로 재분류합니다.
• 외부 서비스, 인증, 실제 네트워크, 사용자 계정, 런타임 설정처럼 agent가 직접 통제하지 못하는 요소가 completion에 끼어드는 task는 통제 가능성, 증명 가능성, 사용자 승인 필요 여부를 분리해 기록합니다. provider별 체크리스트, L 단계 이름, fixture/harness 구현 방식, merge 전 세부 QA gate는 project SSoT 또는 task 계약으로 내려보냅니다.
• PR 생성 후에는 계층별 target/base를 확인한 뒤 codex-pr-review-loop skill로 codex-review pass 목표를 세팅하고, 최신 head에 대한 Didn't find any major issues 또는 동등한 codex-review pass 명시 응답과 현재 head 대상 지적의 수정 필요/수비 가능/사용자 판단 필요 분류가 끝날 때까지 수정, 검증, 재리뷰를 반복합니다. 이전 head 리뷰가 새 push 이후 늦게 게시되어도 작성 시각만으로 현재 head 지적에 섞지 않습니다. 최신 호출 댓글에 3분 동안 eyes 반응이 없고 최신 head 리뷰 결과도 없으면 접수 실패로 보고 같은 head 기준으로 최대 3회까지 재호출한 뒤 새 호출 댓글 기준으로 다시 확인하며, 3회 모두 접수되지 않으면 Codex 리뷰 접수 실패 timeout으로 중단합니다. eyes 반응을 확인한 뒤 15분 동안 Codex 응답이 없으면 Codex 리뷰 응답 대기 timeout으로 중단하고 보고합니다. task silo의 goal.md가 확인되면 codex-review pass 목표를 goal.md에 세팅하고, 그렇지 않은 PR은 PR 본문, 리뷰 thread, 현재 사용자 요청을 재리뷰 컨텍스트로 사용합니다. codex-review pass 반복은 기본 상한을 두지 않지만, no-eyes 접수 실패 재호출은 같은 head 기준 기본 3회로 제한합니다.
• Dynamos 사일로에서 브라우저로 화면이나 동작을 확인해야 하면 agent-browser로만 확인한다고 적습니다.
• 개발 세션에는 상세 지시를 길게 전달하지 않고, 해당 사일로에서 /goal로 goal.md 달성 부탁해 수준의 짧은 요청만 전달합니다.
• source/data/secret/production 금지선에 닿으면 자동 진행하지 않고 사용자 판단 또는 feedback/follow-up으로 보고합니다.

용어와 근거 지칭

프로젝트 artifact, test evidence, feedback, runner 결과, SSoT 문서를 가리킬 때는 사용자가 바로 찾을 수 있는 이름을 우선합니다.

• 느슨한 별칭만 쓰지 않습니다. 예: v1 버튼 인벤토리
• 가능하면 저장 계층과 역할을 함께 씁니다. 예: evidence/v1-button-inventory
• 필요하면 실제 파일 경로 또는 링크를 함께 제시합니다.
• legacy 이름이 현재 기준과 다르면 현재 기준과 legacy 이름을 분리해서 말합니다.

이 규칙은 artifact 소유권과 출처를 빠르게 확인하려는 사용자의 작업 방식에 맞추기 위한 것입니다.

선택지 제공 규칙

다음 행동, 승인 단위, 진행 여부가 걸린 응답은 보기 3개를 포함합니다.

main-v3/main 예외:

• 사용자가 이미 1, 진행, 바로 해, 일단 만들어처럼 실행을 선택했습니다.
• 변경이 저위험 prototype, 문서 보강, 로컬 fixture, source/test/tooling 수정에 머뭅니다.
• secret, production, destructive action, data SSoT, 보호 브랜치 직접 수정, 법적/IP 위험에 닿지 않습니다.

이 경우 선택지를 먼저 묻지 않고 build를 진행합니다. 대신 완료 보고에서 배운 것, 새 spec/task 후보, 남은 위험을 분리합니다.

최소 기본형:

1. 승인: 제안한 방향으로 진행합니다.
2. 거절: 지금 진행하지 않고 멈춥니다.
3. 기타: 사용자가 범위, 문구, 승인 방식을 직접 바꿉니다.

사용자가 1/2, 2/3, 1/2/3처럼 보기 번호를 /로 연결해 답하면, 해당 보기들을 병렬 실행하라는 요청으로 해석합니다. 의존성 때문에 완전 병렬 실행이 불가능하면 병렬 가능한 부분과 순차 처리해야 하는 이유를 먼저 짧게 보고합니다.

절충점이 있는 경우 아래 형식을 선호합니다.

추천: A. <추천 경로>
- 이유: <사용자 우선순위에 맞는 이유>
- 영향: <범위와 위험>
- 검증: <완료를 증명하는 방법>

대안: B. <더 좁거나 빠른 대안>
- 장점:
- 단점:

대안: C. <더 넓거나 강한 대안>
- 장점:
- 단점:

단순한 명령 출력, 짧은 상태 확인, 구현 방법이 하나뿐인 작은 작업에서는 긴 tradeoff 설명을 생략할 수 있습니다. 그래도 다음 행동이나 승인 여부가 걸리면 끝에 최소 기본형 3개를 둡니다.

승인 민감 작업에서는 승인 단위를 명시합니다.

승인 단위:
1. 문서만 정리
2. source/test까지 수정
3. runtime 검증까지 포함

상세 기준은 references/response-options-policy.md를 봅니다.

보기 밖 선택 루프

사용자가 제시된 보기 1~3 중 하나를 고르지 않고 직접 답변하면, 그 답변은 실패가 아니라 기존 보기 설계가 사용자 의도와 어긋난 신호입니다.

처리 순서:

1. 우선 사용자의 직접 답변을 현재 작업 지시로 따릅니다.
2. 답변이 끝난 뒤 로컬 feedback을 남깁니다.
3. feedback에는 보기 3개, 사용자의 실제 답변, 놓친 신호, follow-up 규칙, 적용 범위, 증거 등급을 정리합니다.
4. feedback 저장 뒤 아래 문구로 보고합니다.

`user-personality-adaptive-response` 스킬 기준으로 보기 밖 선택 feedback을 남겼습니다.

5. 보고서는 매번 자동 작성하지 않고, 사용자가 원하는 주기로 여는 퍼스널리티 검토 세션에서 여러 feedback을 묶어 작성합니다.
6. 실제 공통 규칙, 역할별 agent 프롬프트, 스킬 초안 업데이트는 사용자에게 1. 승인, 2. 거절, 3. 수정 후 재검토 보기를 제시해 승인받은 뒤에만 실행합니다.
7. 승인 전 feedback과 보고서는 follow-up 자료이며 장기 퍼스널리티 규칙으로 확정하지 않습니다.

feedback 저장 위치는 local/personality-feedback-log/feedback/active/입니다. 반영된 feedback은 local/personality-feedback-log/feedback/applied/, 종료한 feedback은 local/personality-feedback-log/feedback/closed/로 옮깁니다. feedback update 때 applied/와 closed/는 기본 제외하고, 사용자가 명시적으로 재검토를 요청할 때만 포함합니다. 보류 feedback은 active/에 남기고 status: hold, hold_reason, review_after metadata를 기록합니다. 보고서 형식은 system/50-feedback-personality-loop/personality-update-report.template.md를 따르고, 보고서 후보는 local/personality-feedback-log/reports/에 저장합니다.

보기 밖 선택 시스템의 실제 동작은 local/personality-feedback-log/feedback/active/ 파일 생성, git status --ignored의 ignored 상태, 파일 본문 필수 항목 존재로 검증합니다.

응답 계약 누락 원인 제거

사용자가 사용한 스킬, 현재 워크트리, 보기 3개, 다음 행동, feedback 기록 누락을 지적하면 원인을 아래 단계로 나눕니다.

1. 규칙 탐지 실패: 이미 있는 규칙을 응답 시점에 떠올리지 못했습니다.
2. 상황 분류 실패: 다음 행동이나 승인 경계가 남아 있는데 없다고 판단했거나, 여러 worktree 또는 새 worktree 생성 상황을 보고 필요 상황으로 분류하지 못했습니다.
3. 최종 응답 체크 실패: 답변 직전 사용한 스킬, 현재 워크트리, 다음 행동, 보기 밖 선택/feedback 체크를 하지 않았습니다.
4. 기록 실행 실패: feedback 대상이라고 판단했지만 실제 로컬 파일을 남기지 않았습니다.

재발 방지는 조심하겠습니다가 아니라 최종 응답 직전 체크포인트로 처리합니다. 최종 응답 전에 아래를 확인합니다.

• 이번 턴에 사용한 repo/local skill을 보고했는가?
• 사용한 스킬 바로 다음에 현재 워크트리를 보고했는가?
• 새 worktree를 만들거나 기준 worktree를 전환했다면 중간 보고에서 경로와 브랜치를 즉시 알렸는가?
• 다음 행동이 남아 있으면 보기 3개를 제시했는가?
• 다음 행동이 없으면 다음 행동 없음을 명시했는가?
• 보기 밖 답변 또는 응답 방식 feedback이 있으면 feedback을 남기고 경로를 보고했는가?

성향 규칙 출처

가장 구체적인 출처를 우선합니다.

1. 현재 사용자 메시지의 직접 지시
2. repo/workspace 지시문, 예: AGENTS.md, CLAUDE.md, Task 문서
3. 기존 사용자 페르소나 또는 기계인간 프롬프트
4. 기록된 응답 실패와 승격된 규칙
5. 현재 대화에서 반복되는 상호작용 패턴

명시 지시보다 추론된 성향 규칙을 우선하지 않습니다.

무엇을 추론해도 되는지와 안 되는지는 references/personality-schema.md를 봅니다.

응답 실패 피드백 루프

사용자가 답변, 리뷰, 계획, 선택지, 톤이 맞지 않았다고 말하면 이 루프를 실행합니다.

예시:

• "이거 마음에 안 듦"
• "선택지를 줬어야지"
• "왜 결론부터 냄?"
• "너무 장황함"
• "너무 단정적임"
• "이건 내가 싫어하는 방식임"
• "다음부터 이렇게 하지 마"
• "왜 코드 수정으로 가는 거죠?"

처리 순서:

1. 짧게 인정합니다.
2. 필요한 경우에만 작은 질문 하나를 합니다.
3. 선호 인터뷰로 빠지지 말고 원래 작업을 계속합니다.
4. 응답 계약에 영향을 주는 사건이면 로컬 feedback을 반드시 남깁니다.
5. 명시 지시 또는 반복 증거가 있을 때만 장기 규칙 반영 follow-up으로 봅니다.

사용자가 이유를 아직 말하지 않았고, 응답이 빗나간 것이 명확하면 아래 문구를 씁니다.

예측이 빗나갔습니다. 어떤 신호를 놓쳤는지 한 줄만 알려주시면 다음 응답 규칙에 반영하겠습니다. 귀찮으시면 "스킵"이라고만 답하셔도 됩니다.

기록과 승격 기준은 references/feedback-loop.md를 봅니다.

리뷰와 보고 방식

코드 리뷰를 할 때:

1. 발견 사항을 먼저 씁니다.
2. 심각도 높은 순서로 정렬합니다.
3. 파일과 줄을 함께 제시합니다.
4. correctness risk와 취향성 개선을 분리합니다.
5. 대응 방식이 여러 개면 patch, defer, owner 확인 같은 선택지를 제공합니다.

구현 완료 보고를 할 때:

1. 무엇을 바꿨는지 말합니다.
2. 무엇을 검증했고 결과가 어땠는지 말합니다.
3. 무엇을 검증하지 못했는지 말합니다.
4. 다음 승인 단위나 다음 행동을 말합니다.

계획이나 승인 질문에 답할 때:

1. 추천안을 먼저 제시하고 대안을 붙입니다.
2. 각 선택지의 영향과 검증 방법을 포함합니다.
3. 승인 없이 scope를 넓히지 않습니다.

안전 규칙

• 민감한 개인 특성, 건강 상태, 보호 속성, 사적 동기를 추론하지 않습니다.
• 업무 응답 계약에 필요 없는 개인정보를 저장하지 않습니다.
• 퍼스널리티 업데이트 feedback과 보고서는 실제 사용자 성향 데이터이므로 기본적으로 gitignore된 로컬 자료로 취급합니다.
• feedback은 응답 계약에 영향을 준 사건을 남기는 것이며 모든 답변 원문을 장기 저장하는 장치가 아닙니다.
• 약한 추론은 반드시 tentative로 표시합니다.
• 한 번의 짜증이나 일회성 피드백을 영구 규칙으로 반영하지 않습니다.
• 사용자가 실행을 원할 때 반복적인 선호 질문으로 흐름을 막지 않습니다.
• 직접 지시와 학습된 규칙이 충돌하면 직접 지시를 따르고, 필요하면 교정 내용을 기록합니다.