baratihd/skills

Treatment Backend 릴리즈 노트

소스 브랜치를 대상 브랜치(특히 stage 또는 production)로 프로모션할 때 실제 저장소 증거를 기반으로 정확하고 감사 가능한 영문 릴리즈 노트를 생성합니다. 릴리즈 노트 작성 후, 대화 내에만 별도의 페르시아어 헤드라인 요약을 작성합니다. 페르시아어 요약을 릴리즈 노트나 다른 프로젝트 파일에 추가, 포함 또는 기록하지 마십시오.

크로스 에이전트 실행 계약

• 이 스킬은 Codex, OpenCode, Claude Code 간에 이식 가능합니다. 공급업체별 도구가 필요하지 않습니다. 호출 시 이 SKILL.md와 연결된 references/ 파일을 읽으십시오.
• 정식 복사본은 .agents/skills/treatment-backend-release-note/에 보관됩니다. 번들 설치 프로그램을 사용하는 경우 .claude/skills/ 및 .opencode/skills/는 동일한 복사본을 가리킵니다. 분기된 복사본을 유지하지 마십시오.
• 도구나 권한을 사용할 수 없는 경우, 정확하게 제한 사항을 보고하십시오. Git 증거나 릴리즈 상태를 조작하지 마십시오.
• 일반 언어 호출 또는 Codex의 $treatment-backend-release-note, Claude Code 및 지원되는 OpenCode 구성의 /treatment-backend-release-note를 수락합니다. 모든 호출은 정확히 동일한 워크플로 및 출력 정책을 따릅니다.

입력 및 범위

• 필수: source_branch, target_branch (사용자가 프로젝트 규칙을 명시적으로 설정하는 경우에만 기본 대상 사용, 그렇지 않으면 실제로 사용할 수 없을 때 요청).
• 선택 사항: 릴리즈 버전, 배포 기간, 티켓 참조, 출력 파일 이름(docs/releases/ 아래 저장), 배포 방법, 소유자.
• 변경 사항을 수집하기 전에 리모트를 감지하고 refs, 작업 트리 상태 및 저장소 루트를 검증하십시오. 명시적 권한 없이 브랜치를 변경하거나, pull, fetch, commit, merge, tag, 배포하거나 애플리케이션 코드를 수정하지 마십시오.
• 소스/대상이 지정되지 않은 경우, 명확한 컨텍스트에서 추론을 시도하십시오(예: 사용자가 "release develop to stage"라고 말함). 그렇지 않으면 질문하십시오. 현재 체크아웃된 브랜치가 소스라고 묵시적으로 가정하지 마십시오.
• 두 refs 모두 로컬 브랜치 또는 원격 추적 브랜치일 수 있습니다. 분석된 정확한 해결된 refs와 커밋 해시를 명시하십시오.
• 보고서를 소스 브랜치에서 대상으로 도입된 변경 사항으로 해석하고, 소스 브랜치에서 커밋된 모든 사항이 아닙니다.

워크플로

1. 사전 점검 및 Git 증거

저장소 루트에서 다음 명령을 검사하십시오(안전하게 ref 이름을 조정하고, 신뢰할 수 없는 셸 인수를 보간하지 마십시오):

git status --short
git remote -v
git branch -a
git rev-parse --verify <source>^{commit}
git rev-parse --verify <target>^{commit}
git merge-base <target> <source>
git log --date=short --format='%h %ad %s' <target>..<source>
git diff --stat <target>...<source>
git diff --name-status <target>...<source>
git diff <target>...<source> -- <relevant-paths>

target..source는 대상에서 도달할 수 없는 커밋을 식별합니다. git diff의 target...source는 병합 기준을 소스와 비교하여 소스 브랜치가 제안하는 변경 사항을 근사합니다. 이는 분기된 브랜치, 체리픽 또는 리베이스의 경우 정확한 결과 병합 diff와 같지 않을 수 있습니다. 제안된 릴리즈의 경우, 커밋 및 diff 관점을 모두 검사하고, 이상 징후를 식별하며, 필요한 경우에만 권한을 받아 일회용 작업 트리/임시 병합을 사용하십시오. 확인되지 않은 세 점 diff를 기반으로 확정된 병합 결과를 주장하지 마십시오. 이미 완료된 릴리즈의 경우, 기록된 병합 커밋, 태그, 배포된 SHA 또는 실제 배포 전/후 refs를 선호하십시오(사용 가능한 경우).

의미 있는 소스 파일, 마이그레이션, 구성, API 스키마, 직렬 변환기, 권한, 백그라운드 작업, 통합, 테스트 및 배포 매니페스트를 검토하십시오. 커밋 제목에만 의존하지 마십시오. 적절한 경우 내러티브에서 생성/노이즈 파일을 제외하되, 영향을 미치는 생성된 마이그레이션이나 잠금 파일 변경을 숨기지 마십시오. 여러 커밋에 걸쳐 비즈니스 영향이 있는 변경 사항을 확인하십시오. 모든 변경된 파일을 나열하는 대신 비즈니스 능력별로 그룹화하십시오. 입증 가능한 경우 코드를 티켓/PR에 연결하십시오.

2. 변경 사항 및 영향 분류

다음을 분리하여 설명하십시오:

1. 비즈니스 변경 사항 — 신규 또는 변경된 워크플로, 자격 규칙, 보장 범위, 비용/청구 처리, 보고, 알림 및 관찰 가능한 동작. 코드, 테스트 또는 사용자 제공 제품 컨텍스트에서 지원되는 경우에만 작성하고, 추론 또는 확인 누락을 명확히 표시하십시오.
2. 기술 변경 사항 — API, Django 모델/마이그레이션, 작업/Celery, 데이터베이스/인덱스, 외부 통합, 설정, 보안/권한, 안정성, 성능, 관찰 가능성, CI/CD 및 리팩토링.
3. 호환성 및 소비자 — REST 엔드포인트/메서드, 요청/응답 필드, 상태 코드, 인증, 웹/모바일 클라이언트, 내부 호출자, 작업자, 타사 시스템, DB 및 이벤트. 증거와 함께 Breaking change: Yes / No / Unknown을 명시하십시오. API 호환성과 배포/데이터 호환성을 구분하십시오. 관련이 있는 경우 필수 소비자 조치 및 출시 순서를 설명하십시오.
4. 검증 및 추적 가능성 — 정확한 소스/대상 refs + SHA, 기본 SHA, 주목할 만한 커밋, 발견된 티켓/PR 링크, 테스트 및 실제 관찰된 상태, 마이그레이션 계획, 제공된 경우 승인자/상태. 테스트를 실행하거나 신뢰할 수 있는 테스트 결과를 얻지 않고 테스트 통과를 주장하지 마십시오.
5. 되돌리기 / 롤백 — 대상에 적합한 단계 및 전제 조건을 설명하고, 애플리케이션 롤백, 되돌릴 수 있는 스키마 마이그레이션, 되돌릴 수 없는 데이터 마이그레이션, 재생 가능한 작업, 메시지, 멱등성 및 타사 부작용을 구분하여 처리하십시오. 항상 Git 되돌리기와 운영 롤백을 구분하십시오. 마이그레이션 및 부작용을 확인하지 않고 롤백이 안전하다고 주장하지 마십시오.

전체 체크리스트는 references/review-checklist.md를 참조하십시오.

3. 영문 릴리즈 노트 작성 및 저장

references/release-note-template.md를 따르십시오. 릴리즈 노트에 저장된 모든 콘텐츠에는 제목을 포함하여 영어를 사용하십시오. 간결하지만 유익하고 엔지니어링 및 비즈니스 검토 모두에 적합하게 유지하십시오. 세부 사항을 지어내는 대신 "확인되지 않음", "알 수 없음" 또는 "확인 필요"를 사용하십시오.

정식 프로젝트 출력 디렉토리는 docs/releases/입니다. 모든 릴리즈 노트를 그곳에 저장하고, 루트 수준의 release-notes/ 디렉토리를 생성하지 마십시오. 기본 출력은 docs/releases/YYYY-MM-DD-<source>-to-<target>.md이며, 브랜치 슬래시는 하이픈으로 대체됩니다. 명시적으로 요청된 파일 이름을 준수하되 docs/releases/ 아래에 유지하십시오. 기존 릴리즈 노트를 덮어쓰지 마십시오. 대상이 존재하는 경우 고유한 파일 이름을 선택하거나 교체에 대한 명시적 승인을 구하십시오. 생성 날짜만 문서화 날짜로 사용하고, 조작된 배포 날짜로 사용하지 마십시오. 배포가 확인될 때까지 릴리즈 노트는 제안된 릴리즈입니다.

저장 후 파일을 다시 읽고 브랜치 방향 및 커밋 ID, 비즈니스/기술 변경 사항, 호환성, 검증, 추적 가능성, 롤백 및 페르시아어 요약 부재를 검증하십시오. 요청되지 않는 한 릴리즈 노트를 자동으로 스테이징하거나 커밋하지 마십시오. 저장된 상대 경로를 보고하십시오.

4. 채팅 전용 페르시아어 요약 (필수)

성공적인 저장 및 검증 후에만, 최종 Agent 응답에 간결한 헤드라인 스타일의 페르시아어 요약을 제시하십시오. 비즈니스에서 읽을 수 있는 결과, 의미 있는 위험, 필요한 소비자/배포 조치 및 준비 상태/미지수에 중점을 둡니다. 일반적으로 3-7개의 짧은 글머리 기호로, 필요한 경우가 아니면 낮은 수준의 구현 세부 사항은 포함하지 않습니다. 예시 형식:

خلاصه برای ارائه به بیزینس (فقط در پاسخ Agent، خارج از فایل):
- بهبود فرآیند ...
- تغییر در رفتار ...
- نیاز به هماهنگی با ...
- وضعیت اعتبارسنجی: ...
- ریسک و برنامه بازگشت: ...

검토 중에 입증된 진술만 포함하십시오. 이 요약을 파일, 로그, 커밋 메시지 또는 릴리즈 노트 부록에 저장하지 마십시오. 쓰기가 실패하면 릴리즈 노트가 등록되었다고 주장하지 말고 장애물을 설명하고, 도움이 되는 경우 임시로 명확히 표시된 임시 요약을 제공하십시오.

품질 관문

• 모든 변경 사항 및 주장은 검사된 diff, 테스트, Git 기록 또는 명시적으로 제공된 릴리즈 컨텍스트를 기반으로 하며, 확인된 사실과 추론을 구분하십시오.
• diff에서 발견된 비밀, 토큰, 암호, 개인 고객 데이터 또는 원시 자격 증명을 인쇄하지 마십시오. 예시를 수정하십시오.
• 커밋된 코드를 배포된 기능과 동일시하지 말고, 실행되지 않은 테스트를 통과한 테스트와 동일시하지 마십시오.
• 브랜치에 관련 없는 변경 사항이 포함된 경우, 중요한 수정 사항을 조용히 삭제하지 말고 범위와 위험을 문서화하십시오.
• 확인 후에만 명시적 None identified를 사용하고, 그렇지 않으면 Unknown / Not verified를 사용하십시오.
• 문서화의 일부로 마이그레이션을 실행하거나, 프로덕션 데이터를 조작하거나 롤백을 수행하지 마십시오.