쉽게 설명하기
목표: 읽는 사람이 1분 안에 중요한 내용을 이해하는 것. 화면에서는 텍스트의 약 20%만 읽히고, 특히 각 줄의 시작 부분이 주로 읽히므로, 중요한 내용을 먼저 배치하고 각 제목이 실질적인 정보를 전달합니다.
스타일 규칙
모든 모드에 적용됩니다:
- 첫 문장은 결정이나 답변을 말합니다. 맥락은 그 다음에 옵니다.
- 25단어 이하의 문장, 이상적으로는 15~20단어, 각 문장은 하나의 아이디어를 담습니다.
- 주어, 동사, 목적어를 능동태로, 누가 무엇을 하는지 명시합니다("서버가 재시도한다", "재시도된다"가 아님).
- 일상적인 단어 사용. 클라이언트, 세션, 알림, 서버, 데이터베이스는 괜찮습니다. 함수, 파일, 변수 이름은 사용하지 않습니다: 이들은 세부 사항에 속합니다.
- 구체적인 사례 하나가 일반적인 설명보다 가치 있습니다: 행위자, 행위, 결과.
- 내용이 있는 제목: "오늘: 알림이 유실됨", "현재 상황"이 아님. 처음 두 단어가 이 텍스트 고유의 내용을 말합니다.
- 불필요한 내용이나 홍보 금지: "기본적으로", "단순히", "아마도", "원칙적으로", "견고한", "강력한" 사용 금지.
- 목록은 병렬적인 항목에만, 중첩 금지, 문단은 최대 세 문장.
- 나쁜 점도 말합니다: 감수하는 위험, 대안과의 비교, 그리고 범위 밖의 내용.
문서 모드: 계획
정확한 형식과 제한은 planning 스킬(2단계, "쉽게 설명")에 정의되어 있으며 check-plan.sh가 검증합니다: "Decision", "Today", "After", "Risk", 선택적 "New", "Out of scope". "Today"의 각 사실은 증거로, "After"의 각 결과는 해당 단계로 연결됩니다.
"New"는 리포지토리에서 패턴을 검색(rg)한 후에만 사용합니다: 거짓된 "이것은 새로운 것입니다"는 전체 계획의 신뢰성을 떨어뜨립니다.
문서 모드: 이슈
이슈 헤더는 다른 모든 내용보다 먼저 오는 세 줄입니다. 전체 형식은 github-issues 스킬에 있습니다.
**무엇이 문제인가:** <행위자와 결과, 한 문장으로>. (또는 **무엇을 요청하는가:**)
**왜 중요한가:** <숫자나 사례가 포함된 한 문장>.
**완료 조건:** <주요 관찰 가능 결과>.
리스트 모드 (대화 기본값)
누군가 문서 없이 무언가를 설명해 달라고 요청할 때:
- 각 항목은 하나의 아이디어, 3~7개 항목; 더 많으면 그룹화.
- 모든 항목은 같은 유형의 단어로 시작(모두 동사 또는 모두 명사). 조건은 끝에 배치("...은행이 거절하면").
- 제목 없음, 굵은 글씨 없음, 전후 강제 없음: 질문에 답변합니다.
- 답변이 하나의 아이디어라면, 불릿 없이 바로 전달.
예: "결제 재시도는 어떻게 작동하나요?"
- 고객이 "결제"를 누르는 즉시 금액을 청구합니다.
- 은행이 잔액 부족으로 거절하면 "결제 재시도"를 표시합니다.
- 네트워크 오류 시 최대 세 번까지 재시도하며, 대기 시간을 점차 늘립니다.
- 각 실패한 시도를 주문에 사유와 함께 기록합니다.
산문 모드
동일한 내용을 짧은 문단으로. 요청이 있을 때만("연속해서 말해줘") 또는 이전 항목을 읽지 않으면 항목을 이해할 수 없을 때만 사용합니다.
예: 이전과 이후
이전(이해하기 어려움):
1. 현재 상황
RetryLink가 각 작업에maxRetries=3을 적용하여, 글로벌 조정 메커니즘이 없기 때문에 장애 시 부하가 크게 증폭될 수 있습니다.
이후:
결정: 앱은 API가 다운되었을 때 재시도하지 않습니다.
오늘: 장애가 부하를 증폭시킴
각 쿼리는 자체적으로 세 번 재시도합니다. API가 다운되면 복구를 시도할 때 정확히 세 배의 요청을 받습니다.