transcript-markdown-cleanup
원문 말투와 반복을 유지한 채, 문맥상 확실한 인식 오류만 고쳐 마크다운 스크립트로 정리하고 애매한 표현은 별도 체크리스트로 분리하는 작업에 사용한다.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
원문 말투와 반복을 유지한 채, 문맥상 확실한 인식 오류만 고쳐 마크다운 스크립트로 정리하고 애매한 표현은 별도 체크리스트로 분리하는 작업에 사용한다.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Use when creating or planning weekly GitHub Issues from github-projects/week*_issues_complete.csv or similar weekly CSV files and adding them to a GitHub Project. Trigger for tasks that mention GitHub Projects, weekly issues, week_n labels, CSV issue files, sprint/week setup, repository/project issue import, or adding the corresponding week's issues to a project with gh CLI.
Use when setting up, repairing, verifying, or troubleshooting a UserPromptSubmit prompt logging hook in a target repository, including trusted mode checks, hooks.json command wiring, git user name prompt-prefix logging, and per-user prompt log file names.
Use when analyzing Codex prompt logs such as logs/{username}-prompt-log.jsonl from a target repository into cleaned CSV and markdown retrospective outputs, including git user name prefix evaluation against commit authors, timezone normalization, exclusion filtering, session grouping, and session-based context management assessment.
SOC 職業分類に基づく
| name | transcript-markdown-cleanup |
| description | 원문 말투와 반복을 유지한 채, 문맥상 확실한 인식 오류만 고쳐 마크다운 스크립트로 정리하고 애매한 표현은 별도 체크리스트로 분리하는 작업에 사용한다. |
이 스킬은 원시 전사본을 읽기 좋은 마크다운 스크립트로 바꾸되, 원문 흐름은 유지하고 음성 인식 과정에서 생긴 것으로 보이는 오류만 문맥에 맞게 바로잡아야 할 때 사용한다.
기본 산출물은 두 개다.
이 작업은 요약이 아니다. 기본 원칙은 원문에 최대한 가깝게 유지하는 것이다.
다음 기준을 순서대로 적용한다.
이런 경우는 고칠 가능성이 높다.
발그라인드 -> Valgrind말록 -> malloc이런 경우는 기본적으로 유지한다.
정리본은 대체로 아래 구조를 따른다.
# {제목} 스크립트 정리
원본: `{원본 파일명}`
정리 기준: 원문을 최대한 유지하되, 녹음 스크립트 과정에서 생긴 명백한 텍스트 인식 오류만 최소한으로 다듬었다. 반복, 말버릇, 비효율적인 문장 흐름은 유지했다.
## 00:00 {해당 구간 주제}
**화자 00:00**
발화 내용
서식 원칙:
## MM:SS 주제 형식을 사용한다.편집 전에 원본 전사본을 처음부터 끝까지 읽는다. 전체 대화 맥락을 모른 채 줄 단위로 바로 고치기 시작하면 잘못 복원할 가능성이 높다. 많은 수정은 뒤쪽 문맥을 본 뒤에야 확정된다.
첫 번째 정리본은 다음에 집중한다.
첫 번째 패스에서는 거의 확실한 오류만 고친다.
초안 전체를 다시 읽고, 앞뒤 의미와 분명히 맞지 않는 표현만 두 번째로 보정한다.
2차 보정의 대표 사례:
확신이 낮으면 억지로 고치지 말고 체크리스트로 보낸다.
보조 파일은 다음과 같은 이름을 우선 사용한다.
{제목} 애매한 표현 체크리스트.md
체크리스트에는 다음을 넣는다.
직접 수정안 선택지체크리스트 후보에는 다음 종류만 둔다.
그대로 유지예상 대체표현직접 수정안녹음 파일이나 원본 음성을 다시 들을 수 없다고 가정한다. 따라서 사용자가 나중에 확인해야 한다는 식의 대기 선택지는 만들지 않는다.
형식은 다음처럼 간결하게 유지한다.
## 4. 13:30 발표/프레젠테이션 구간
위치
- 13:30 부근
- 발표/프레젠테이션 관련 문장
현재
우리는 프리젠테이션 해봐야 인생은 거 아니죠.
의문
- 문맥상 표현이 어색함
후보
- A. 그대로 유지
- B. 프레젠테이션 해봐야 의미 없는 거 아니죠
- C. 프레젠테이션 해봐야 되는 거 아니죠
- D. 직접 수정안
체크리스트 항목은 보통 두 종류로 나눈다.
표현 애매함의미 확인 필요표현 애매함은 단어나 짧은 구절이 잘못 인식된 것 같을 때 사용한다.
의미 확인 필요는 문장은 읽히지만, 그 발화의 핵심 뜻이나 의도가 불분명할 때 사용한다.
사용자가 체크리스트에 답하면:
(반영 완료: {선택지 또는 직접 수정})을 표시한다체크리스트를 사용자에게 확인받을 때는 한 번에 모든 항목을 길게 묻기보다, 저장된 체크리스트 파일을 기준으로 순서대로 진행한다. 각 질문에는 현재 진행 상황을 함께 보여준다.
예:
체크리스트 4/17
위치
- 13:30 부근
현재
우리는 프리젠테이션 해봐야 인생은 거 아니죠.
의문
- 문맥상 표현이 어색함
후보
- A. 그대로 유지
- B. 프레젠테이션 해봐야 의미 없는 거 아니죠
- C. 프레젠테이션 해봐야 되는 거 아니죠
- D. 직접 수정안
사용자가 여러 번호의 답을 한꺼번에 주면 그 범위는 모두 반영하고, 다음 미해결 번호부터 다시 이어서 묻는다.
기본 흐름은 다음과 같다.
체크리스트 {현재 번호}/{전체 개수} 진행 상황을 표시한다.사용자에게는 이런 식으로 설명하는 편이 좋다.
기본적으로 다음은 하지 않는다.
반대로 다음은 필요하면 한다.
사용자가 달리 요청하지 않으면 보통 다음 이름을 쓴다.
{원본 제목} 스크립트 정리.md{원본 제목} 애매한 표현 체크리스트.md이미 정리본이 있다면, 사용자가 새 버전을 명시적으로 요구하지 않는 이상 중복 파일을 만들기보다 기존 파일을 업데이트한다.
이 스킬은 특정 레포 구조나 기존 예시 파일에 의존하지 않아야 한다.
항상 범용적으로 유지한다.