개요
ASD-STE100 간명 기술 영어 규칙을 적용하여 모호한 영어를 재작성해 다운스트림 AI 에이전트가 오독하지 않도록 하는 Claude Code 스킬입니다. 문장별로 위반 사항을 표시하고 사실을 잃지 않으면서 재작성하며, 구조 검증을 위한 결정적 Python 검사기를 함께 제공하고, 엄격한 절차 모드와 설명적 텍스트 모드 두 가지를 지원합니다.
README 미리보기
# ASD-STE100 Skill — Simplified Technical English for Agent Output\n\nA Claude Code skill that rewrites dense, ambiguous English into [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/) (STE) — the controlled-language standard the aerospace and defense industry built so aircraft maintenance instructions cannot be misread.\n\nThis skill repurposes that same discipline for a different reader: an **AI agent** parsing another agent's output, a tool description, an error message, or an inter-agent instruction, with no human in the loop to resolve ambiguity.\n\n## Why STE, and Why for Agents\n\nSTE exists because a misread instruction on an aircraft can kill people, and the intended readers were often not native English speakers with no author to call for clarification. The standard's fix: one meaning per word, active voice, simple tenses, one instruction per sentence, short sentences, no dropped words.\n\nAn LLM agent parsing another agent's output is in a strikingly similar position — no back-channel, no way to ask "did you mean X or Y?" The same rules that keep a mechanic from misreading a torque spec keep a downstream agent from misreading a tool description or an inter-agent message.\n\n## Before / After\n\n| Before | After |\n|---|---|\n| "This tool will attempt to synchronize state across the various backends that have been configured, and if a conflict is detected it may resolve it automatically depending on the strategy that has been set, or otherwise it will surface the conflict for manual review." | "The tool tries to synchronize state across the configured backends. If it finds a conflict, it reads the configured strategy. If the strategy allows automatic resolution, the tool may resolve the conflict without a user. If the tool does not resolve the conflict, it reports the conflict for manual review." |\n| "An error may have occurred while processing your request due to a possible mismatch in the expected data format, which could be caused b
FAQ (3)
문제 해결왜 ASD-STE100 linter는 markdown 테이블을 지나치게 긴 문장으로 플래그하나요?
이것은 스플리터 버그였으며, PR #14에서 수정되었습니다. 린터가 산문 스트림에서 마크다운 표를 제거하지 않았습니다. 표 행이 종결 구두점 대신 |로 끝나기 때문에 헤더 + 구분선 + 데이터 행이 하나의 '문장'으로 붙어 버렸고, 모든 | 및 --- 토큰이 단어로 계산되어 단어 수가 25단어 문장 제한을 초과하도록 부풀려졌습니다(예: 일반적인 표가 122개의 '단어'로 계산됨). 최신 버전으로 업데이트하세요. 표의 구조적 토큰은 더 이상 계산되지 않으며 셀 내부의 실제 위반은 여전히 감지됩니다. 이전 버전에서의 해결 방법: (1) 스플리터가 행 단위로 분리되도록 모든 행의 마지막 셀을 마침표로 끝내거나, (2) 표를 행당 마침표로 끝나는 항목 하나씩으로 구성된 세로형 불릿 목록으로 변환하는 것입니다. ASD-STE100은 어차피 항목이 두 개를 초과하는 목록에는 이 방식을 선호합니다.
문제 해결examples/before-after.md의 단어 수가 예제 텍스트와 일치하지 않는 이유는 무엇인가요?
나열된 네 개의 개수 중 세 개가 틀렸습니다. 공백 분할 기준으로 올바른 개수는 다음과 같습니다: 예시 A(도구 설명) = 55가 아니라 44단어; 예시 C(에이전트 간 지시) = 42가 아니라 36단어; 예시 D(README 산문) = 36이 아니라 34단어. 예시 B(오류 메시지)만 28단어로 정확합니다. 모든 판정은 여전히 유효합니다 — 모든 예시가 인용된 상한(25단어 설명 상한, 20단어 지시 상한)을 여전히 초과하므로, 'After' 텍스트가 아니라 숫자만 수정하면 됩니다. Python에서 len(text.split())로 직접 개수를 확인해 보세요. 해당 파일에는 계수 방법이 명시되어 있지 않다는 점에 유의하세요. 이 숫자들은 구두점을 세지 않고 공백으로 구분된 토큰을 가정하므로, 'lock-in'과 같이 하이픈으로 연결된 단어를 분할하는 토크나이저는 다른 결과를 낼 것입니다. 관련하여, 같은 파일의 43행(PR #7에서 남겨진 프로젝트 자체의 산문)에는 저장소 자체의 Rule 8.1을 위반하는 세미콜론이 포함되어 있으며, 이는 제거해야 합니다.
문제 해결왜 README의 Before/After 표가 examples/before-after.md와 모순되나요("may have failed" 같은 완곡한 표현이 "failed"로 재작성됨)?
README 테이블(README.md:17-18)은 PR #4가 examples/before-after.md에 modality-preservation 규칙을 추가할 때 업데이트되지 않았으므로, 두 "After" 셀 모두 이 스킬이 금지하는 바로 그 안티패턴(hedge를 삭제하면 주장이 바뀜)을 보여줍니다. 수정: 두 "After" 셀을 examples/before-after.md의 수정된 재작성문으로 교체하세요.
행 1 — hedge 유지: Example A의 "After"를 사용하세요: "The tool tries to synchronize state across the configured backends." "will attempt to"를 "synchronizes"로 재작성하지 말고, "the tool resolves the conflict" 대신 "may resolve"를 유지하세요.
행 2 — Example B의 "After"를 사용하세요: "Your request may have failed. The cause may be a data format that does not match what the server expects. An outdated client can cause this mismatch. Check your client version." "The request failed... an outdated client is the most common cause"는 사용하지 마세요 — 첫 번째는 시스템이 추측만 하는 실패를 단정하고, 두 번째는 입력에 없는 빈도 주장을 지어냅니다.
참고: 모순되는 Before/After 쌍은 없는 것보다 더 나쁩니다. 두 파일을 모두 읽는 모델이 테이블을 가장 강력한 신호로 간주하기 때문입니다.