samykabu/github-wiki-publish

GitHub Wiki Publish

요청된 자료를 저장소의 기존 위키에 게시합니다. 콘텐츠 생성과 게시를 분리하여 유지하세요: 제공된 페이지, 보고서 및 에셋을 사용하고 필요에 따라 링크와 탐색을 조정합니다. 다른 프로젝트의 규칙을 가져오지 말고 대상 프로젝트의 규칙을 따릅니다.

대상 및 범위 설정

• 요청 및 저장소 컨텍스트에서 GitHub 호스트, 저장소, Wiki URL, 소스 파일 및 의도된 페이지 이름을 확인합니다. 자료에 영향을 미치는 선택 사항에 대해서만 질문하세요.
• 준비와 게시를 구분하세요. 게시에 대한 명시적 요청은 명명된 위키 업데이트를 승인합니다. 동일한 작업에 대해 다시 묻지 마세요. 초안 또는 평가 요청만으로는 푸시를 승인하지 않습니다.
• 먼저 관련 커넥터 기능을 파악하세요. 위키 콘텐츠와 에셋을 적절히 관리할 수 없는 경우 위키의 별도 Git 저장소를 사용하세요. 대체 방법을 간략히 설명하세요. 일반 저장소 Contents API는 위키 저장소를 다루지 않습니다.
• 기존 인증된 연결 또는 Git 자격 증명을 사용하여 액세스를 확인하세요. 자격 증명을 URL, 페이지 또는 보존된 증거에 포함하지 마세요. 인증되지 않은 404는 비공개 위키가 없음을 증명하지 않습니다.
• 위키 Git 저장소가 없는 경우 위키가 비활성화되었는지 또는 GitHub를 통해 첫 페이지를 만들어야 하는지 확인하세요. 저장소 기능을 활성화하거나 액세스를 변경하는 부작용을 발생시키지 마세요. 가능하면 권한 있는 첫 페이지 생성을 사용하고, 그렇지 않으면 특정 누락 전제 조건을 보고하세요.

제한된 업데이트 준비

Git 게시의 경우 Git 절차를 읽으세요. 새로운 임시 클론을 사용하고 실제 기본 브랜치를 발견하며 쓰기 전에 기존 대상 페이지, Home 및 사이드바를 읽으세요.

• 각 소스 파일을 대상 페이지 또는 에셋에 매핑하세요. 관련 없는 페이지, 수동 작성 섹션 및 탐색을 보존하세요. 소스 파일이 없다고 해서 삭제 명령이 아닙니다. 요청된 업데이트에 속하는 경우에만 전체 페이지를 교체하고 공유 Home/사이드바 콘텐츠에는 좁은 편집을 사용하세요. 기존 링크를 유지하고 반복 실행 시 중복 탐색 항목을 피하세요.
• 텍스트를 명시적으로 UTF-8로 읽고 쓰세요. 바이너리 에셋은 바이트 단위로 복사하세요. 소스 사실을 조용히 수정하거나 다른 데이터 세트에서 보고서를 새로 고치지 마세요. 실제 날짜, 출처 및 제한 사항을 보존하고, 다시 생성이 범위 내에 있는 경우에만 적절한 업스트림 생성기를 사용하세요.
• Wiki의 실제 대상에 맞게 링크를 다시 작성하세요. 저장소-상대 링크는 페이지를 이동한 후 깨질 수 있습니다. 참조된 에셋을 복사하거나 접근 가능한 저장소 개정판에 링크를 걸고 로컬 경로, 게시되지 않은 브랜치 링크 또는 접근 불가능한 외부 리소스를 남기지 마세요.
• Wiki는 페이지 파일 이름을 제목으로 표시하므로 자체 H1으로 시작하는 페이지는 두 번 표시됩니다. 해당 H1을 삭제하고 페이지 이름을 파일 이름으로 지정하며 H1이 페이지 이름과 다른 경우에만 유지하세요(예: Home). 파생된 이름으로 탐색을 업데이트하세요. Home은 /wiki에서 제공되므로 상대 링크는 Wiki 외부에서 확인됩니다: 이미지, 페이지 링크 및 사이드바에 절대 Wiki URL을 사용하세요.
• 의미 있는 대체 텍스트와 함께 지원되는 인라인 이미지를 사용하세요. HTML 보고서 또는 애니메이션/대화형 다이어그램의 경우 Wiki가 렌더링할 수 없을 때 유용한 정적 미리보기와 원본 아티팩트에 대한 링크를 제공하세요. 다운로드 가능한 HTML을 Wiki 내에서 제공되는 애플리케이션으로 설명하지 마세요. 새 아티팩트 생성이 범위 내에 있는 경우 프로젝트별 다이어그램 도구를 따르세요. 이 스킬은 특정 생성기를 요구하지 않습니다.
• 로컬 링크 및 에셋, 대표적인 비ASCII 텍스트, 정확한 변경된 경로를 확인하세요. 최종 diff에서 의도하지 않은 삭제, 덮어쓰기된 콘텐츠, 자격 증명 및 생성된 잔해를 검사하세요. 사용자 또는 프로젝트가 소스 유지를 요구하지 않는 한 임시 클론 및 로컬 증거를 애플리케이션 저장소 외부에 보관하세요.

게시 및 검증

사용자의 기존 권한 내에서만 게시를 적용하세요. Wiki 업데이트는 애플리케이션 브랜치 푸시, 이슈 변경, 사이트 배포, 동기화 예약 또는 CI 설치를 승인하지 않습니다.

• 의도된 Wiki 경로만 커밋한 다음 Git 절차에 설명된 대로 동시 변경 사항을 가져와 조정하세요. 발견된 Wiki 기본 브랜치로 정상적으로 푸시하세요. 다른 작성자를 극복하기 위해 강제 푸시하지 마세요.
• 거부 시 한 번 가져와서 검사하세요. 호환 가능한 편집을 통합하고 전체 diff를 다시 확인하세요. 동일한 충돌이 반복되거나 의도를 확인할 수 없거나 액세스가 실패하면 재시도를 중지하고 정확한 차단기와 함께 복구 가능한 클론을 유지하세요. 실패 시 삭제하지 마세요.
• 게시된 커밋을 라이브 원격과 비교하여 확인하세요. 깨끗한 작업 트리만으로는 로컬 커밋이 푸시되었음을 증명하지 않습니다.
• 사용 가능한 경우 인증된 브라우저를 통해 실제 제공된 페이지를 검사하세요: 페이지 텍스트, 대표 유니코드, 탐색, 링크, 이미지 로딩 및 가독성. 차트의 경우 렌더링된 결과를 소스 사실과 비교하세요. 인라인 미리보기에서 레이블이 가려지는 경우 전체 크기 이미지를 확인하세요. 범위 내에서 관찰된 결함을 수정하고 영향을 받는 콘텐츠를 다시 확인하세요.
• 인증된 렌더링 검증을 사용할 수 없는 경우 게시 및 원격 검증을 실행되지 않은 브라우저 검사와 별도로 보고하세요. 로컬 파일, HTTP 응답 또는 성공적인 푸시에서 렌더링된 통과를 주장하지 마세요.

페이지 URL, 게시된 개정판, 자료 변경 사항, 수행된 검사 및 해결되지 않은 제한 사항을 보고하세요. 작업이 게시되지 않은 상태로 남아 있을 때 복구 경로를 유지하세요. 새로운 승인 게이트, 콘텐츠 스키마, 프로젝트 수명 주기 또는 테스트 체계를 추가하지 마세요.