eduardopin/writing

writing: 독자는 5분밖에 없습니다. 모든 문장은 제 몫을 해야 합니다

이 방법이 방지하는 실패: 많은 단어로 적은 내용을 말하고, 모든 모델이 생산하는 리듬(알리는 도입부, 세 항목으로 구성된 본문, 반복하는 결론)을 따르며, 그 과정에서 숫자를 바꾸거나, '아마도'를 빼거나, 출처를 지어내는 텍스트. 두 번째 실패는 텍스트를 매끄럽게 다듬으면서 작성자의 목소리를 제거하는 재작성입니다.

0. 프로젝트가 결정합니다

프로젝트를 위해 글을 쓰기 전에 CLAUDE.md / AGENTS.md를 읽고 .claude/skills/에서 프로젝트 자체 스킬을 찾으세요. 프로젝트의 규칙과 스킬이 이 스킬보다 우선합니다: PR 템플릿 및 게이트, 커밋 규칙, 선언된 언어, 음성 가이드, 디자인 시스템. 이 스킬은 프로젝트에 자체 규칙이 없을 때 기본값입니다. 언어, 등록체, 목소리는 프로젝트(섹션 10)에서 가져오며, 고정된 프로젝트나 사람에서 가져오지 않습니다.

사용자: 사람을 위해 텍스트를 작성하는 모든 스쿼드 에이전트 (랜딩 페이지, 카드, 핸드오프, PR, 보고서, 커밋, README). 스킬이 작성합니다. 전송, 게시, 게시는 항상 소유자에게 속합니다. $WRITING은 이 스킬의 디렉토리입니다 (~/.claude/skills/writing). 스크립트는 Python 표준 라이브러리이며, python3 -I로 실행합니다.

1. 다섯 가지 작업: 시작하기 전에 하나를 선택하세요

작업	트리거	출력
작성 (기본값)	당신이 텍스트를 생성합니다: 문서, 메시지, PR, 답변	텍스트 자체, 텍스트에 대한 설명 없음
편집	소유자가 수정할 초안을 넘깁니다	수정된 초안과 짧은 변경된 사항
감지	"이게 AI처럼 읽히나?", "이걸 감사해줘", "지적만 하고 다시 쓰지는 마"	명명된 패턴, 각 패턴에 대해 인용된 한 줄, 몇 단어로 된 수정 사항. 재작성, 점수, 작성자 주장 없음
보정	두 개 이상의 샘플: "나처럼 써줘", "제품의 목소리"	references/voice-profile.md 형식의 음성 프로필, 편집 및 보관용
압축	"CLAUDE.md 압축", "메모리 트림", "이 핸드오프에서 토큰 줄여"	모든 사실이 포함된 더 작은 파일과 fidelity_check.py의 결과

감지에서 명명된 패턴은 소유자가 확인할 수 있는 증거입니다. AI 탐지기는 추측합니다. 음성 프로필은 세션의 모든 후속 작업에 유지되며, --profile로 린터에 전달되고 기계적 패턴만 변경하며, 사실이나 금지된 구문은 절대 변경하지 않습니다.

2. 의례 수준

프로세스는 위험을 따릅니다. 모든 수준은 규칙을 따릅니다. 게이트만 변경됩니다.

수준	텍스트	프로세스
0	채팅 응답, 터미널 상태, 커밋 메시지, 코드 주석, 한 줄 카드	메모리 규칙. 스크립트, 보고서, 메타 코멘트 없음
1	PR 본문, AgenFK 카드, 핸드오프, Slack/WhatsApp 게시글, 이메일, 체인지로그, 짧은 README	규칙 및 기계적 검사(섹션 9)
2	제3자가 읽는 약 400단어 이상: 스펙, ADR, 제안, 보고서, 포스트모템, 아키텍처 문서	전체 프로세스. 완료했다고 말하기 전에 두 스크립트 모두 통과

린 모드. "린 모드", "원시인", "간결하게", "토큰 줄여"가 나오면 "일반 모드"까지 수준 0이 더 엄격해집니다: 먼저 답변, 제로 의례, 관사는 선택 사항이고 부정은 절대 사용하지 않음, 문장당 최대 20단어로 하나의 아이디어, 페이로드(코드, 명령어, 경로, 오류)는 그대로, 도구 상태는 짧게 유지, 모드를 수행하지 않음. 보안 경고, 되돌릴 수 없는 작업, 단계 순서, 혼란스러운 요청자, 사용자에 대한 질문, 채팅 외부에 기록되는 모든 것에 대해서는 전체 문장으로 되돌아갑니다. 커밋 메시지는 저장소의 규칙을 따릅니다 (먼저 git log를 읽으십시오). 규칙이 없으면, 명령형의 Conventional Commits, 본문에는 이유만 포함합니다. 전체 규칙 및 전송 전 확인: references/lean.md.

수준 0은 예외가 아닙니다: 규칙은 세션의 모든 응답에 적용됩니다. 몇 번의 대화 후에 기본 케이던스가 돌아오기 때문입니다. 수준 0 및 1에 대한 메모리 자체 점검: eval.md의 마지막 블록.

3. 심각도

발견 사항의 가중치는 동일하지 않으며, 순서가 무엇을 먼저 수정할지, 무엇이 절대 배포되지 않을지 결정합니다. 구조가 어휘보다 더 중요합니다: 깨끗한 단어 목록과 알림-본문-요약 구조를 가진 문서는 여전히 슬롭이며, 목록에 있는 정확한 용어는 그렇지 않습니다.

수준	대상	게이트
차단	지어낸 사실, 이름, 숫자, 날짜, 인용문, 출처. 약화, 강화, 삭제된 한정사. 변경된 결정, 숫자, 요구사항. 수정된 코드, 표, 링크, 프론트매터. 출처와의 모순	절대 배포 불가. allow 지시문이 적용되지 않음. fidelity_check.py가 0이 아니거나, 적용 범위 목록 항목 누락
수정	린터 ERROR: 금지된 어휘나 구문, 일반적인 제목, 이모지, 산문 대신 목록, 챗봇 잔여물. 구조적: 빈 도입부, 요약하는 결론, 동일한 틀의 문단	수정하거나, 한 줄 설명이나 인라인 allow와 함께 유지. 발견 사항이 포함된 사실을 절대 삭제하지 않음
선호 수정	린터 WARN: 약한 구성, 리듬, 밀도, 전환, 확실성, 명사화, 이식성	사실을 잃지 않는 경우 수정. 그렇지 않으면 그대로 두고 진행
조언	eval.md 판단: 15% 절단, 제목, 매체, 대칭	선택 사항. 남긴 것을 말하세요

4. 무엇보다 우선하는 세 가지 규칙

충실함이 가독성보다 우선합니다. 문장을 매끄럽게 만들기 위해 요구사항, 결정, 숫자, 이름, 위험, 수용 기준 또는 사실을 절대 변경하지 마십시오. 사실이 읽기 어렵다면, 사실을 변경하지 말고 그 주변의 문장을 변경하십시오. 사실, 이름, 숫자, 날짜, 인용문 또는 출처를 절대 지어내지 마십시오. 코드, 명령어, 다이어그램, 링크, 표, 프론트매터, 기술 식별자는 그대로 유지하십시오.

목소리가 다듬기보다 우선합니다. 문제를 해결하는 최소한의 수정을 가하십시오. 먼저 초안의 어휘, 운율, 직설성, 유머, 불확실성, 탈선을 기록하고 유지하십시오. 모든 문단을 동등하게 정리하지 마십시오. 강한 의견, 욕설, 정직한 인정은 작성자에게 속할 때 유지됩니다. 텍스트를 열어 보는 것은 내용을 바보로 만드는 것이 아닙니다. 개성은 게시글과 의견 글에 적합합니다. 참고 자료, 법률, 사건 텍스트는 중립을 유지합니다.

불확실성은 사실입니다. "~일 수 있다", "추정된", "추론된", "아직 측정되지 않음"은 작성자가 얼마나 알고 있는지를 말합니다. 쌓인 헤지를 잘라내면 하나의 헤지만 남고 무엇이 불확실한지 이름을 붙입니다. 주장을 강화하지 않습니다. 보안, 법률, 재무, 의료, 사건 텍스트에서 한정사는 내용이며, 문장이 없을 때 더 잘 읽히더라도 유지됩니다. 그 반대도 마찬가지로 잘못되었습니다: 출처가 명시하는 사실을 절대 헤지하지 마십시오.

5. 문장 테스트

모든 문장은 정보, 추론, 필요한 맥락 또는 행동을 전달합니다. 역할이 강조, 의례 또는 패딩뿐인 문장: 삭제하세요, 다시 쓰지 마세요.

기술 및 운영 문서에서는 기준이 더 높습니다. 그 이유는 추론이 일반적으로 짧기 때문입니다: 모든 문장은 사실, 숫자, 명령어, 이름, 결정 또는 위험을 전달합니다. 경영 산문과 대화는 원인과 프레이밍을 위한 공간을 얻으며, 이를 잃는 것은 또 다른 실패입니다.

이식성 테스트. 문장을 변경하지 않고 다른 사람, 회사, 국가 또는 제품으로 옮길 수 있다면, 그것은 패딩입니다. 자르거나, 주제에 특화된 사실, 메커니즘, 결과 또는 판단으로 교체하십시오.

보여주세요, 말하지 마세요. 사실, 행동, 결과가 강조를 전달합니다. 요점을 중요하다고, 놀랍다고, 미묘하다고 레이블링하는 주석을 보여주지 말고 자르십시오.

측정값을 넣으세요. 숫자 없는 측정 가능한 형용사는 증거 없는 주장입니다. 기술 분류는 그렇지 않습니다: public endpoint, private subnet, external dependency, manual approval, reversible migration, immutable tag는 정확한 용어이며 유지됩니다.

단어	대체어
robust / robusto	견디는 것: 재시도, 장애 조치, N에서 테스트됨
scalable / escalável	얼마나: RPS, 노드, GB, 테넌트
significant / significativo	숫자
fast / rápido	지연 시간 또는 기간
many / vários	개수
recently / recentemente	날짜
best practice / boa prática	누구의, 어떤 문서

6. 구조

1. 먼저 답변하세요. 결정, 수정, 숫자 또는 명령어가 첫 번째 줄입니다.
2. 문서가 다루는 내용을 알리는 도입 문단, 반복하는 결론 문단이 없습니다. 각 결론은 한 번만. 독자는 방금 읽었습니다.
3. 제목은 내용의 이름을 지정합니다 ("롤백"). 질문을 하지 않으며, 그 아래 첫 번째 문장이 반복하지 않습니다. 금지된 형식: 개요, 주요 내용, 마지막 생각, 결론, 소개, 앞으로의 길, 종합 개요, 전략적 하이라이트, 구현 여정.
4. 문단은 추론을 전달합니다. 목록은 정말 집합인 경우에만 사용합니다. 표는 독자가 행과 열을 비교할 때만 사용합니다.
5. 문장과 문단의 길이를 다양하게 하세요. 세 개가 완전하게 들린다고 세 개의 그룹을 절대 만들지 마세요.
6. 세 줄에 들어맞으면, 세 줄입니다.

파일과 함께 제공되는 메시지는 한 줄로 변경된 사항을 말하며, "여기 문서가 있습니다"나 도움을 제공하지 않습니다. 문서 유형별 형태: references/shapes.md.

7. 가장 명확한 매체

기본적으로 산문으로 시작하지 마세요. 긴 섹션 전에 독자가 이해해야 할 관계의 이름을 지정하고 의미를 유지하는 가장 작은 매체를 선택하세요. 전체 규칙: references/visuals.md.

독자가 필요로 하는 것	사용
3개 이상의 항목을 2개 이상의 속성으로 비교하거나 정확한 매핑을 읽기	표
순서, 토폴로지, 계층 구조, 소유권, 상태 또는 종속성을 따라가기	다이어그램
화면, 위치, 레이아웃, 이전/이후 인식	주석이 달린 그림
절차 실행	번호가 매겨진 단계와 붙여넣을 준비가 된 코드
인과 관계, 뉘앙스, 결정 이유 이해	산문

시각 자료는 출처에서 확인된 자료에서만 오며, 한 줄 결론과 alt 텍스트가 있고, 산문에서 중복되지 않습니다. 생성된 이미지는 정확한 토폴로지, 데이터, 값 또는 아키텍처에 사용되지 않습니다. 크고 빈 다이어그램은 슬롭입니다.

아키텍처 또는 클라우드 다이어그램은 실제 시스템에 대한 주장입니다: cloud-diagram 스킬을 따르세요 (인벤토리가 기하학보다 먼저, 현재 또는 제안, 편집 가능한 소스, 렌더링 프로브). 이 스킬은 그 주변의 산문만 처리합니다.

렌더링된 문서 (HTML, 아티팩트, PDF): 외관은 프로젝트에 속합니다. templates/document.html에서 시작하여 상단의 --ds-* 블록을 python3 -I ~/.claude/skills/design-reference/scripts/sweep.py <root> --css의 출력으로 교체하세요 (프로젝트에 디자인 시스템이 없는 경우, 스쿼드의 중립 팔레트 유지). 기본적으로 한 언어. 이중 언어는 이중 언어 청중 또는 요청 시에만, templates/document-bilingual.html에서 <html data-languages="en pt">와 함께 사용합니다. 전달 전: python3 -I "$WRITING/scripts/artifact_check.py" <file>. PR, 카드, 커밋 및 docs/의 마크다운은 이 중 어떤 것도 필요하지 않습니다. 규칙: references/rendered-document.md.

프레젠테이션: 프레젠테이션 스킬이 설치된 경우, 슬라이드를 계획하기 전에 호출하세요. 프레젠테이션 스킬은 구조, 레이아웃, 렌더링을 소유하고, 이 스킬은 산문과 충실함을 소유합니다. 요청하지 않는 한 README, ADR, 런북, 카드 또는 이메일을 슬라이드로 만들지 마세요.

풀 리퀘스트: 본문은 30초 안에 diff를 열지 여부를 결정해야 하는 검토자를 위한 것입니다: 무엇이 변경되었는지, 왜, 무엇이 제외되었는지, 어떻게 검증되었는지, 위험 및 롤백. 에이전트의 작업을 설명하지 않고 커밋을 반복하지 마세요. 구조: pull-request 스킬 (또는 프로젝트의 스킬). 30초 테스트: references/pull-requests.md. github만 PR을 열며, verifier의 SHIP 이후에.

8. 자를 패턴과 단어

수정 사항, 이전/이후 쌍 및 두 언어의 단어 목록이 있는 카탈로그는 references/patterns.md에 있습니다 (빠른 요약은 파일을 엽니다). 세션당 한 번 읽으세요. 가장 빈번한 것: 이진 대비 ("단순한 X가 아니라 Y입니다"), 콜론 계시, 목청 가다듬기 ("주목할 가치가 있습니다"), 가짜 통찰, 알림 ("자세히 알아봅시다"), 끝의 얕은 -ing 절, 허풍, 모호한 출처, 메타 담론, 숨은 행위자, 끝의 잘린 부정 ("드라마 없음"), 챗봇 잔여물, 쌓인 헤지, 극적인 조각의 행.

플래그된 단어 (leverage, seamless, delve, robust; alavancar, robusto, jornada, ecossistema)는 동의어로 교체되지 않고 삭제됩니다. 일부는 맥락에서 정확한 단어입니다 (전략 문서에서 "strategic decision"; gate, harness, pipeline, realm은 기술 용어로): 유지하려면 한 줄 설명 또는 <!-- writing: allow <term> -->이 필요하며, 절대 침묵하지 않습니다. 빈 부사 (just, actually, simply; só, literalmente, na verdade)는 아무것도 추가하지 않을 때 제거되고, 강조, 불확실성 또는 작성자의 리듬을 전달할 때 유지됩니다.

9. 기계적 검사

최종 텍스트에서, 수준 1부터: 엠 대시나 엔 대시 없음 (작성자의 샘플이 사용하는 경우 제외), 직선 따옴표, 문장 케이스 제목, 콜론 뒤 소문자, 이모지 없음, 정의된 용어나 경고에만 굵게, 굵은 레이블 목록 없음, 붙여넣는 모든 것에 대해 코드 블록. 전체 목록: references/process.md.

10

…