agentleFS
kfangwkfangw/research-ops/skills/feasibility-gate/SKILL.md

feasibility-gate

Skill0 starsChanged 29 days agoMITView on GitHub

새 연구 주제, 새 설계, 새 주장을 착수하기 전에, 그리고 틀 변경 뒤 다시 판정할 때 사용. 신규성, 현장 실재, 단순 대안, 자명성, 자료, 일정과 요건, 겹침을 결과 전에 정한 기준으로 판정한다. \"타당성 검토\", \"해볼 만해?\", \"관문\", \"착수해도 되나\", \"접을까\", \"가능성 어림\" 같은 요청에 적용.

The file

Files
SKILL.md

착수 관문

새 주제를 시작하기 전에, 그리고 틀을 바꿀 때마다 관문을 거쳐 착수해도 되는지를 판정한다. 기준은 결과를 보기 전에 정하고 사용자가 확정한다. 판정과 가능성 어림의 이력을 남기고, 접은 주제도 지우지 않는다.

문제 정의가 흐리면 problem-grill을, 신규성 증거가 없으면 literature-scout를 먼저 한다. research-session의 공통 규칙을 따른다. 착수 뒤 실험의 사양과 봉인은 preregister-seal이 맡는다.

0. 지킬 것

  • 통과 기준은 결과 전에 숫자나 판정 규칙으로 적는다. 사용자가 명시적으로 확정한 뒤에 고정한다. 관문 문서에 날짜와 함께 적어 두면 충분하고, 해시 봉인은 하지 않아도 된다. 사용자가 없는 상태에서 정한 기준은 "사용자 미확정"으로 적고, 그 관문 결과는 잠정이다.
  • 결과를 본 뒤에는 기준을 바꾸지 않는다. 결과를 나눠 보는 분석(지배적 상대 하나를 빼는 등)은 해도 되지만 판정 이유에 적는다.
  • 기준을 적고 보니 기준 설계가 틀렸다는 것을 결과에서 알게 되면(예상하지 못한 사례가 대부분을 차지함), 기준을 고치지 않고 "기준 설계의 결함"으로 기록한다. 다음 관문의 기준에 반영한다.
  • 관문 수치는 만든 쪽이 아닌 쪽이 다시 센다(독립 검산). 숫자가 맞아도 해석이 틀릴 수 있으므로 판정자는 해석도 따로 본다.
  • 판정은 총괄이나 사용자가 한다. 조사를 맡은 에이전트는 증거만 낸다.
  • 판단 유보는 통과도 반증도 아니다. "유보"로 적고 무엇이 있으면 정해지는지 쓴다.
  • 불리한 판정도 그대로 적는다. 관문 전의 가능성 어림은 낮춰 읽는다.

1. 관문 목록

관문물음기준의 꼴못 넘으면
G0 신규성같은 문제나 같은 꼴의 결과가 있는가지정 범위 전수 대조에서 거리 1 논문 0편, 같은 꼴 고전 결과는 인용으로 처리 가능 (literature-scout)접거나 차이가 분명한 부분으로 좁힌다
G1 실재문제가 현장에 있는가공개 자료에서 비율 N% 이상 또는 규모 M 이상측정 논문으로 줄이거나 접는다
G2 단순 대안가장 단순한 대안을 이기는가공정한 대조군(심사자가 고를 법한 강한 기준선)이 실패하는 조건을 실행으로 재현설계를 빼고 측정만 남긴다
G3 자명성주장이 모형의 정의에서 바로 나오는가정의상 참인 부분을 빼고도 결과(크기, 비교, 반례)가 남는다성질로 한 문단만 두고 결과를 다시 찾는다
G4 자료증거를 얻을 자료가 있는가공개되고 검증 가능, 또는 직접 만든 자료의 재현 경로와 비용(쿼리 크레딧 포함)이 정해짐범위를 자료가 있는 쪽으로 옮긴다
G5 일정과 요건마감, 투고처, 졸업이나 과제 요건에 맞는가남은 주 수 안에 핵심 결과가 나온다는 어림. research-portfolio의 투고처표와 요건계산이 있으면 그 마감과 점수를 쓴다다른 편에 흡수하거나 뒤로 미룬다
G6 겹침내 다른 프로젝트와 겹치는가research-portfolio의 연구 지도와 경계에서 같은 질문, 같은 자료, 같은 선행 연구를 쓰는 편이 없거나 경계가 한 문장으로 정해짐경계를 정하거나 한쪽에 흡수한다
G7 닫힘증명과 구현이 닫히는가정리가 서고 구현이 검사를 통과주장을 줄인다

G0, G2, G3, G6은 거의 늘 필요하다. G7은 착수 뒤 중간 관문이다. G2와 G3은 G0과 같은 날 함께 본다. 신규성만 보고 착수했다가 단순 대조군과 동률이거나 정의상 참이라는 지적을 받아 몇 주 뒤에 무너진 사례가 여럿 있다.

2. 언제 돌리나

  • 새 주제를 착수하기 전
  • problem-grill의 틀 변경(축 1, 5, 6, 7) 뒤. 바뀐 축에 걸린 관문만 다시 돌린다.
  • 지금 논문에서 새 주제가 갈라져 나올 때. "지금 논문과 별개인가, 판별 실험 하나로 확인되는가, 결과가 작으면 접는다"를 G0, G2와 함께 묻는다.
  • 투고처를 바꿀 때(G5만, research-portfolio 4절)

3. 절차

  1. 문제 정의를 읽는다. 없으면 멈추고 problem-grill을 권한다. 접은 주제(docs/접은주제.md)와 다른 프로젝트의 기록에 같은 주제가 있으면 그 기록부터 보인다.
  2. 관문을 고르고 기준과 문턱을 "안"으로 적는다. G0은 판정 규칙(무엇이 겹침인가, 판정자 둘이 다르면 어떻게 정하는가)을 문헌을 보기 전에 정한다. 사용자가 확정하면 고정일을 적고 봉인한다.
  3. 가능성 어림을 처음 값으로 어림 기록부에 적는다.
  4. 값싼 탐침부터 동시에 돌린다. G0은 literature-scout, G1은 공개 자료로 하는 작은 측정, G2는 강한 기준선의 짧은 실행, G3은 주장에서 정의상 참인 부분을 빼 보는 검토. 탐침마다 시간과 비용(쿼리 크레딧 등)의 상한과 멈춤 선을 둔다.
  5. 관문 수치를 독립 검산한다(fact-check 2절). 규칙 문서와 원자료만 주고 다시 세게 한다.
  6. 판정한다. 기준을 글자 그대로 적용한 결과(문자 판정)와 판정자의 종합 판정을 따로 적는다. 둘이 다르면 이유를 쓴다.
  7. 가능성 어림을 고친다. 이전 값, 새 값, 이유를 어림 기록부에 함께 남긴다.
  8. 기록하고 보고한다(4절, 5절).

4. 기록

관문마다 하나씩 docs/관문/<날짜>-<관문>.md(프로젝트 설정이 다른 위치를 정하면 그곳)에 쓴다. 저장소에 templates/관문.md가 있으면 그 양식을 쓴다.

관문 <번호> <제목> (날짜, 판정자)
물음:
기준(고정일, 사용자 확정 여부, 봉인 해시):
판정 규칙(G0: 겹침의 정의, 판정자 불일치 처리):
결과(근거 파일):
독립 검산: 대조 n개, 불일치 m개
문자 판정: 통과 / 미통과 / 유보
종합 판정: 통과 / 미통과 / 조건부(조건) / 유보
판정 이유와 결과 분해:
기준 설계의 결함(있으면):
가능성 어림: 이전 → 지금 (이유)
못 넘으면 할 일:
다음:

어림 기록부(docs/어림기록.md)에는 날짜, 주제, 어림값, 근거, 고친 이유를 한 줄씩 쌓는다. 지우지 않는다. 미통과 주제는 접은 주제(docs/접은주제.md)에 이유, 날짜, 자료의 행방(다른 편이 가져가는지)과 함께 남긴다. 승인기록에 사용자 결정을 적는다.

5. 보고

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

== 끝 | <프로젝트> | 관문 G0~G3: 주제 X | HH:MM (걸린 시간 n분, 어림 n분) ==
결과   : 4개 가운데 통과 1, 미통과 2, 조건부 1
         G0 신규성    미통과  거리 1 논문 1편 (차이: ...)
         G1 실재      조건부  조건 해당 99%, 상시 해당은 수백 건
         G2 단순 대안 미통과  강한 기준선이 설명 못 하는 사례 7%, 지배적 상대 하나 빼면 1% 미만
         G3 자명성    통과    정의상 참인 부분을 빼면 남는 결과: 크기 측정 1건
         가능성 어림 40~50% --> 10% 안팎
확인   : 독립 검산 대조 n개 불일치 0, 해석 검토 완료
바뀐 것: 관문 기록 4, 어림 기록부 1줄 (아래 링크)
남은 것: 결정 1건(접기, 좁히기, 측정 논문으로 줄이기, 다른 편에 흡수)
다음   : 권고는 접고 자료는 다른 편으로. 사용자 결정 필요

멈추거나 좁히는 결정은 사용자가 한다. 도구는 선택지(접기, 좁히기, 측정 논문으로 줄이기, 다른 편에 흡수)와 각 선택의 비용을 보인다. 만든 파일은 답에서 바로 열 수 있게 링크로 보인다.

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.