Reality Check 1.1.0 스킬 릴리스 준비: 증거 레이블, 이중 언어 트리거, 회귀 하네스

What they did

Reality Check 스킬의 1.1.0 버전이 작성되었습니다. 이 스킬은 랜딩 페이지를 감사하여 하나의 판정, 정확히 세 개의 피해 순위별 수정 사항, 그리고 1-3개의 고정 요소를 반환합니다. 핵심 구조는 유지되었고, 작업은 스킬 자체를 일곱 가지 질문에 비추어 감사한 뒤 커밋 단위로 재작성하는 것이었습니다. 먼저 루트 스킬 사본이 패키지 폴더와 바이트 단위로 동기화되었습니다. 그다음 지시문 텍스트가 재작성되었습니다. 히브리어 스크립트 트리거가 description으로 이동했고(활성화를 구동하는 유일한 부분), tests/triggers.json의 단일 정규 트리거 목록이 description, SKILL_HE.md, 두 README와 대조되어 검증되었으며, 성능 감사, 내부 페이지, 계획이나 코드에 대한 'reality check'를 위한 새로운 부정 트리거가 추가되었습니다. 진단 규칙이 추가되었습니다. 클라이언트 렌더링 JavaScript 셸에서는 판단하지 말고 중단하며, Ship 아래에서 빈 슬롯은 문제를 만들어내는 대신 'No further fix needed'로 표시됩니다. 중복된 규칙은 한 번만 기술되어, 규칙을 추가하면서도 본문이 1,646단어에서 1,511단어로 줄었습니다. 이제 모든 수정 사항에 [verified] / [observed] / [assumed] 태그가 붙고(히브리어 대응어 포함), Basis 줄이 입력과 확인하지 않은 항목을 명시하며, 'dead' 또는 'static' 주장에는 검증이 요구됩니다. 문서도 뒤따랐습니다. 전체 히브리어 SKILL_HE.md 번역, 새로운 README.he.md, 체인지로그, 그리고 두 README 모두의 실제 참조 출력입니다. 회귀 하네스와 CI가 추가되었습니다. 참조 출력이 있는 다섯 개의 케이스, 대안적 유효 답변, 반례, 계약 샘플, 단위 테스트가 있는 출력 검사기, 그리고 패키지 검사기입니다. ChatGPT Work를 위한 핸드오프 문서가 작성되었고, 그 후 Codex 리뷰 수정과 다섯 개의 검사기 버그 수정이 반영되었으며, 각각은 수정 전에 재현되고 단위 테스트로 커버되었습니다. ChatGPT Work에서의 동작 실행이 분석되었습니다. 스킬 지시 실패는 확인되지 않았으나, 검사기가 em dash와 부정 표현에 대해 너무 엄격했고, 케이스 02는 어떤 브라우저도 로컬 서버에 접근할 수 없어 차단되었습니다. 해당 케이스를 위해 gh-pages에 임시 공개 페이지가 게시되었습니다.

How it went

패키지 검사기, 출력 검사기, 19개 단위 테스트가 Python 3.11, 3.12, 3.13에서 통과했고, skills-ref가 두 복사본 모두를 검증했습니다. 병합, 태그, 릴리스는 아무것도 이루어지지 않았습니다: 작성자는 케이스 01-05의 새로운 블라인드 실행에서 FAIL 0건, BLOCKED 0건(공개 페이지에 대한 케이스 02 포함)을 릴리스 조건으로 걸었습니다. 케이스 02는 실제 브라우저 상호작용으로 실행된 적이 없으며, Grok, Codex CLI, Codex cloud는 어떤 케이스도 실행하지 않았습니다.

Worth knowing

릴리스는 명시적으로 승인되지 않았고 태그도 지정되지 않았다. Case 02의 fixture에는 여전히 의도된 결함 목록을 담은 HTML 주석이 남아 있어서, 로컬 실행만으로도 정답을 읽을 수 있다. 이를 수정하는 것은 한 줄짜리 후속 작업이지만 PR에서는 처리되지 않았다. 실행 후에는 gh-pages 브랜치를 삭제하고 Pages를 꺼야 한다. 이전의 실패 출력들은 편집되거나 통과로 재채점되지 않았으므로, 새 블라인드 실행 전까지 수정 사항은 확인되지 않은 상태다. slug 현실성 점검은 다른 퍼블리셔들의 스킬과 충돌하며, 이름을 바꾸면 설치가 깨진다.

Wiring

Repo 레이아웃: 루트에 SKILL.md가 있고, 바이트 단위로 동일하게 유지되며 CI로 강제되는 reality-check/ 패키지 폴더가 있습니다. metadata.json에는 버전과 태그가 담겨 있고, tests/triggers.json은 description, SKILL_HE.md, 그리고 두 README 전반에 걸쳐 대조되는 표준 트리거 목록입니다. 테스트는 python3 tests/check_package.py(복사본, frontmatter, metadata 형태, changelog 대비 버전, 네 개 파일 전반의 트리거와 레이블, 규칙 앵커, 히브리어 동등성, 본문 크기 예산, 케이스 파일 대비 README 예시), python3 tests/check_output.py --all(참조 출력, 대안 답변, 반례, 차단된 샘플, 계약 샘플), 그리고 python3 -m unittest discover -s tests -p 'test_*.py'로 실행됩니다. 케이스 픽스처는 tests/cases/에 있으며 alt-*.md와 counterexample-*.md 파일이 있습니다. needs_interaction으로 표시된 케이스는 페이지가 실행되지 않았을 때 BLOCKED(exit 2)를 보고합니다. skills-ref 0.1.1이 두 복사본을 모두 검증합니다. v1.1.0 태깅은 기존 attestation 워크플로를 트리거합니다.

Try it yourself

I can't perform this audit as specified, because the request asks me to read and modify files in your repository, and I don't have access to your filesystem, repository, or any of the files you named (SKILL.md, metadata.json, the READMEs, the Hebrew translation, etc.). I also can't create files like `tests/triggers.json`, a package checker, an output checker, or a CI workflow in your repo.

Here's what I can do instead, and what I'd need from you:

**To actually run this audit, paste the contents of:**
1. `SKILL.md`
2. The package copy (path + contents)
3. `metadata.json`
4. Both READMEs (root and package)
5. The Hebrew translation file

**What I'll produce once I have them:**

A gap table with columns like:

| # | Check | File(s) | Finding | Severity | Fix |
|---|-------|---------|---------|----------|-----|
| 1 | Triggers in description, not body | SKILL.md | … | … | … |
| 2 | No duplicated rules | all | … | … | … |
| 3 | Flat frontmatter, string values, description < 1,024 chars / bytes | SKILL.md | … | … | … |
| 4 | Root vs package copy byte-identical | README.md ×2 | … | … | … |
| 5 | Output claims tagged verified/observed/assumed + Basis line | all | … | … | … |

Then, after you approve the table, I'll draft:
- `tests/triggers.json` (canonical trigger list)
- A package checker script (Python) that diffs root vs package copy and validates frontmatter
- An output checker with unit tests (pytest) that enforces the verified/observed/assumed tagging and Basis lines
- A GitHub Actions workflow running all three on Python 3.11, 3.12, 3.13

**Two things I want to flag before you paste anything:**

- **Check 3 (byte count):** "under 1,024 characters and 1,024 UTF-8 bytes" — for ASCII these are identical, but Hebrew text is multi-byte in UTF-8, so a description that passes the character check can fail the byte check. I'll report both numbers separately.
- **Check 5 (Basis lines):** I'll need to know your expected format for the Basis line (e.g., `Basis: verified — ran on Python 3.12; assumed — no Windows test`) to check conformance rather than guess.

Paste the files and I'll start with the gap table.