agentleFS
kfangwkfangw/research-ops/skills/preregister-seal/SKILL.md

preregister-seal

Skill0 starsChanged 29 days agoMITView on GitHub

(선택 사항, 드물게 쓴다) 사용자가 봉인이나 사전 등록을 원할 때, 또는 다시 받을 수 없는 자료나 비용이 큰 실행을 앞두고 실험 사양과 판정 규칙을 봉인하고, 실행 중 이탈과 누설을 기록하고, 공개 자료 수집의 비용과 무결성을 관리할 때 사용. "사전 등록", "봉인", "사양 고정", "수집 계획", "자료 수집의 크레딧 장부" 같은 요청에 적용. 실험 전 기준 메모만 필요하면 이 스킬을 쓰지 않는다.

The file

Files
SKILL.md

사전 등록과 봉인

결과를 보기 전에 무엇을 어떻게 재고 어떤 결과면 무엇으로 판정할지를 적고, 그 파일의 해시와 시각을 남긴다. 실행 중 바뀐 것은 이탈로, 봉인 전에 결과를 본 것은 누설로 기록한다. research-session의 공통 규칙을 따른다. 관문의 통과 기준을 정하는 일은 feasibility-gate가 맡고, 이 스킬은 착수 뒤의 실험과 측정을 맡는다.

0. 언제 쓰나

기본은 쓰지 않는다. 실험 전에 무엇을 세고 어떤 결과면 무엇으로 볼지를 할일목록이나 맡김 지시서에 한두 줄 적어 두는 것으로 충분하다. 사용자가 원하거나 아래에 꼭 들 때만 이 스킬로 봉인한다. 에이전트가 먼저 봉인을 권하지 않는다.

  • 한 번밖에 모을 수 없는 자료(시간 창이 지나면 다시 얻을 수 없는 체인 자료, 사람 응답)
  • 판정 결과가 원고의 주장을 정하는 실험
  • 비용이 큰 수집(쿼리 크레딧, 장시간 실행)

탐색적 분석은 사전 등록 없이 해도 된다. 대신 원고와 기록에 탐색적이라고 밝히고, 그 결과로 확인적 주장을 하지 않는다.

봉인은 실험마다 해야 하는 절차가 아니다. 다음이면 하지 않아도 된다.

  • 논문의 주장이 존재와 조건이다(어떤 현상이 실제로 일어나고, 어떤 조건에서 생기고 안 생기는지). 결과표가 그것을 직접 보이므로 등록 여부와 상관없이 주장이 선다.
  • 투고처가 등록을 요구하지 않는다. 잘 쓰인 출판 보안 논문 견본 40편 가운데 본문에서 사전 등록을 말한 논문은 없었다.
  • 위의 세 경우(한 번뿐인 자료, 판정이 주장을 정하는 실험, 큰 비용)에 들지 않는다.

0.1 원고에 쓰는 법

봉인 문서는 연구 기록이다. 원고에 옮기지 않는 것이 기본이다.

  • 본문에 "등록", "봉인", "사전에 정한 예측", "판정(통과, 미통과)"을 쓰지 않는다. 방법에는 몇 번 돌렸고, 무엇을 셌고, 무엇을 뺐는지를 사실대로만 쓴다.
  • 결과를 본 뒤에 한 분석은 "탐색적 분석"이라고 밝힌다. 불리하거나 뜻밖인 결과는 빼지 않고 결과로 쓴다.
  • 본문에서 등록을 말하면 짐이 생긴다. 맞은 예측과 틀린 예측, 모든 이탈을 함께 밝혀야 하고, 대응표와 이탈 기록이 원고를 따라다닌다(paper-condense 3절).
  • 등록을 본문에 쓰는 것은 투고처가 요구할 때(registered report 등)와 사용자가 정할 때뿐이다.
  • 봉인 문서와 이탈 기록은 저장소와 재현 자료(artifact)에 그대로 둔다. 심사자가 물으면 그때 보인다.

1. 사양에 담을 것

사양 파일(experiments/<이름>/사양.md 또는 저장소의 templates/사전등록.md 양식)에 적는다.

  1. 질문과 가설, 그리고 가설에 반하는 결과가 어떤 모양인지
  2. 자료: 출처, 구간, 표본 수, 포함과 제외 규칙. 공개되어 있고 검증할 수 있는 자료를 먼저 쓴다. 직접 만드는 자료는 재현 절차를 적는다.
  3. 측정의 정의와 분석 방법
  4. 대조군: 심사자가 고를 법한 강한 기준선. 허수아비 대조군을 쓰지 않는다
  5. 판정 규칙: 통과, 미통과, 접는 조건. 표본이 부족할 때의 처리(예: 표본이 정한 수 미만이면 접는다)
  6. 비용 상한과 멈춤 선
  7. 이탈 처리 규칙: 무엇이 바뀌면 새 판 사양이 필요한가
  8. 결과를 본 뒤 적용 범위를 바꾸면 새 표본으로 다시 확인한다는 규칙
  9. 판단 유보의 처리: 유보는 반증이 아니며, 유보로 보고한다

2. 쓰는 쪽과 확정

  • 사양은 규칙 작성 역할이 쓴다. 이 에이전트는 결과 파일과 평가 구간의 자료를 보지 않는다.
  • 사용자가 사양을 확정한다. 사용자가 없는 상태에서 정한 사양은 "사용자 미확정"으로 봉인하고, 그 결과는 잠정이다.

3. 봉인

  1. 봉인 도구(seal.py seal <파일> 등)가 있으면 쓰고, 없으면 sha256sum과 시계 시각을 봉인 목록(experiments/SPEC-HASHES.txt)에 한 줄로 더한다.
  2. 사양과 봉인 목록을 같은 커밋으로 남긴다. 커밋 해시를 승인기록에 적는다.
  3. 외부 시각 증명(공개 타임스탬프 서비스, 공개 저장소 커밋)은 원하면 더한다.

4. 누설

봉인 전에 누군가(사용자, 도구, 에이전트) 평가 구간의 자료나 결과를 봤으면 누설이다.

  • 누설 기록에 누가, 무엇을, 언제 봤는지와 사양에 미쳤을 수 있는 영향을 적는다.
  • 영향이 있을 수 있으면 새 표본(다른 구간, 다른 체인)으로 확인하거나, 그 분석을 탐색적으로 낮춘다. 어느 쪽인지는 사용자가 정한다.

5. 실행 중

  • 이탈 기록 표: 무엇이 달라졌나, 왜, 언제, 누가 정했나, 결과에 미칠 영향.
  • 결과를 본 뒤 쓴 사양이나 규칙은 그렇다고 사양 머리에 적는다.
  • 실행이 실패하면 실패했다고 적는다. 실패한 실행을 지우고 다시 돌린 것으로 갈음하지 않는다.

6. 자료 수집

항목할 일
비용 장부공유 자원(쿼리 크레딧, API 한도)의 단일 장부이며 research-batch도 이 장부를 쓴다. 시작 잔량, 쿼리별 어림, 실제 사용, 남은 양, 멈춤 선. 장부와 서비스 표시가 어긋나면 기록한다
쿼리 원문쿼리, 매개변수, 실행 시각을 파일로 남긴다
무결성결과 파일의 해시를 적고, 여러 환경(맥, 클라우드)의 사본을 해시로 대조한다
보관원자료는 git 밖에 두고, 다시 받는 법을 data/README.md에 적는다
접근 장애DNS 실패, 서비스 내부 오류, 접근 차단은 날짜와 함께 적고 재시도 횟수를 정해 둔다

7. 결과가 나온 뒤

  1. 봉인을 검증한다(seal.py verify 또는 해시 비교). 결과는 "봉인 유지" 또는 "봉인 뒤 변경"이다.
  2. 판정 규칙을 글자 그대로 적용한 문자 판정과 총괄의 종합 판정을 따로 적는다.
  3. 독립 검산을 한다(fact-check 2절).
  4. 결과 방향과 관계없이 보고한다. 원고에 싣지 않기로 하면 그 결정과 이유를 승인기록에 남긴다.

8. 원고와의 짝

원고에 "결과 전에 고정했다"고 쓰면, 그 사양에서 벗어난 이탈도 함께 써야 한다. 이탈을 빼고 싶으면 고정 주장 자체를 빼고 분석을 탐색적으로 서술한다(paper-condense 3절).

9. 보고

틀은 research-session 8절(시작 안내, 진행판, 마침 보고)을 따른다. 아래는 이 스킬의 보고에 들어갈 내용의 예다.

== 끝 | <프로젝트> | 실험 E 사전 등록과 실행 | HH:MM (걸린 시간 n분, 어림 n분) ==
결과   : 사양 v2 봉인(해시 3f9c…, 2026-10-01 14:05, 사용자 확정)
         문자 판정 미통과, 종합 판정 미통과
확인   : 봉인 유지(seal.py verify), 독립 검산 불일치 0
         이탈 1건(구간 끝 하루 단축, 장애), 누설 0건
         크레딧 [######------] 1,180/2,500, 멈춤 선 2,200
바뀐 것: 사양 1, 봉인 기록 1, 이탈 기록 1 (아래 링크)
남은 것: 결정 0건
다음   : 결과를 fact-check로 대조

만들거나 고친 파일은 답에서 바로 열 수 있게 보인다.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.