problem-grill
Skill0 starsChanged 29 days agoMITView on GitHub
새 연구 주제나 흐릿한 문제를 질문으로 하나씩 파고들어 한 문장 문제 정의, 범위, 성공 기준, 반증 조건을 확정하고 잠글 때 사용. \"문제 정리해 줘\", \"grill me\", \"이 주제 말이 되나\", \"문제 정의 다시\", \"틀을 바꾸자\" 같은 요청에 적용.
In this repository20 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- english-academic-styleSkill
- fact-checkSkill
- feasibility-gateSkill
- korean-academic-styleSkill
- literature-scoutSkill
- paper-condenseSkill
- paper-framingSkill
- paper-quality-loopSkill
- paper-readabilitySkill
- paper-reviewSkill
- preregister-sealSkill
- rebuttalSkill
- research-batchSkill
- research-portfolioSkill
- research-scaffoldSkill
- research-sessionSkill
- seminar-slidesSkill
- submission-packageSkill
The file
Files
문제 다그치기
연구 주제를 정하기 전에, 또는 문제 정의가 흔들릴 때 질문을 하나씩 던져 문제를 확정하고 잠근다. 도구가 답을 대신 정하지 않는다. 사용자가 답하고, 도구는 빈 곳과 모순을 찾아 다시 묻는다.
이 스킬은 문제를 정하는 단계만 맡는다. 선행 연구 확인은 literature-scout, 착수 판정은 feasibility-gate가 맡는다. 순서는 이 스킬에서 "안"을 만들고, literature-scout로 신규성을 본 뒤, 사용자가 승인해 잠그는 것이다. 신규성을 보기 전에 승인하지 않는다. research-session의 공통 규칙을 따른다.
0. 시작 전에 읽는 것
공통 규칙 1대로 파일을 읽는다.
- 이 프로젝트의 이전 판 문제 정의, 변경 기록, 승인기록, 접은 주제(
docs/접은주제.md) - research-portfolio의 연구 지도와 경계가 있으면 다른 프로젝트의 문제 정의와 접은 주제. 같은 질문을 다른 프로젝트가 이미 다루거나 접었으면 그 기록부터 보인다.
- 이번에 다시 정의하는 것이라면 지금까지 몇 판이 나왔는지 센다(5절).
1. 묻는 방식
- 한 번에 질문 하나만 한다. 질문마다 왜 묻는지 한 줄을 붙인다.
- 가능하면 선택지 2~4개와 도구의 권고 하나를 함께 준다. 선택지 입력 도구가 있으면 쓰고, 없으면 번호 목록으로 묻는다.
- 사용자가 모른다고 하면 "미정"으로 두고 무엇을 알면 정해지는지 적는다. 억지로 답을 받지 않는다.
- 다음 말은 측정할 수 있는 말로 바꿀 때까지 다시 묻는다: 효율적, 안전한, 신뢰할 수 있는, 확장 가능한, 자동으로, 실용적인, 일반적인.
2. 다그치는 규칙
- 새 답이 앞 답과 어긋나면 두 답을 나란히 보이고 어느 쪽인지 묻는다.
- 답이 범위를 넓히면 넓어진 부분을 짚고, 넣을지 범위 밖으로 둘지 묻는다.
- 사용자가 확신하는 주장에도 반례나 가장 단순한 대안을 하나 대고 반응을 듣는다.
- 과제 제안서, 투고처 공고, 지도교수 의견 같은 외부 문서에 맞추려고 문제를 바꾸자는 답이 나오면, 그것이 연구 질문 자체의 변경인지 표현의 조정인지 묻고 따로 기록한다.
- 맞장구, 칭찬, 요약으로 시간을 쓰지 않는다. 도구의 권고와 사용자의 결정을 섞지 않는다.
3. 물을 축 (순서대로, 이미 확정된 축은 건너뛴다)
| 축 | 확정할 것 | 확정의 기준 |
| 1 문제 | 누가, 어떤 상황에서, 무엇 때문에, 무엇을 못 하는가 | 한 문장. 해법 이름이 들어가지 않는다 |
| 2 문제의 층 | 공학으로 풀 문제인가 | 법, 제도, 사회 합의로만 풀리는 부분은 범위 밖으로 옮긴다 |
| 3 실재 증거 | 문제가 현장에 있다는 증거 | 공개 자료로 확인할 수 있는 숫자나 사례 하나. 없으면 관문 G1 후보 |
| 4 단순 대안 | 지금 방법과 가장 단순한 대안이 왜 안 되는가 | 설정 하나, 짧은 시한, 우회 경로로 같은 효과가 나지 않는 이유 |
| 5 논문의 종류 | 측정, 방법(설계), 증명, 시스템 가운데 무엇인가 | 하나를 고르고 그 이유. 나중에 바꾸면 5절의 변경으로 친다 |
| 6 주장 | 이 논문이 하는 주장 | 하나. 셋 이상이면 하나로 줄인다 |
| 7 정의상 참 점검 | 주장이 모형의 정의에서 바로 나오는가 | 그렇다면 그것은 결과가 아니라 성질이다. 결과로 남길 부분(크기 측정, 비교, 반례)을 따로 적는다 |
| 8 성공과 반증 | 결과 전에 정하는 성공 기준과 접는 조건 | 숫자나 판정 규칙. 어떤 결과가 나오면 접는지 |
| 9 범위 밖 | 하지 않는 것 | 세 가지 이상, 이유와 함께 |
| 10 자료 | 무엇으로 증거를 얻는가 | 공개되어 있고 검증 가능한가, 직접 만들면 재현 가능한가와 그 비용 |
| 11 산출 | 투고처 후보, 마감, 분량, 요건 | 일정과 졸업이나 과제 요건에 맞는가. 투고처는 문제를 정한 뒤에 고른다. research-portfolio의 투고처표와 요건계산이 있으면 읽고 묻는다 |
4. 멈춤
- 열한 축이 모두 "확정" 또는 "미정(정해지는 조건 포함)"이면 멈춘다.
- 질문 20개에 닿으면 멈추고 남은 축을 목록으로 보인다.
- 같은 축에서 세 번 연속 답이 바뀌면 그 축을 미정으로 두고, 판단에 필요한 자료(선행 연구, 파일럿 측정)를 다음 할 일로 적는다.
5. 잠금과 변경
문제 정의는 쉽게 바뀐다. 결과나 심사평을 본 뒤 틀을 바꾸면 이전 관문과 문헌 조사가 무효가 되는데도, 기록 없이 판만 올라가는 일이 많다. 그래서 다음을 지킨다.
- 사용자가 승인하면 그 판을 잠근다. 파일 해시와 승인 시각을 승인기록에 남긴다.
- 잠근 뒤 축 1, 5, 6, 7 가운데 하나라도 바꾸면 "틀 변경"이다. 변경 기록에 이전 판, 새 판, 바뀐 축, 이유를 적는다. 이유는 셋 가운데 하나로 분류한다: 새 증거(실험, 문헌), 새 논점(사용자나 심사자의 의견), 외부 맞춤(과제, 투고처).
- 틀 변경 뒤에는 literature-scout와 feasibility-gate를 바뀐 축에 대해 다시 돌린다. 다시 돌리기 전까지 새 판은 "안"이다.
- 판 수를 센다. 하루에 두 번, 또는 한 주에 세 번 넘게 틀이 바뀌면 진행을 멈추고 사용자에게 숫자로 알린다(예: "이번 주 틀 변경 4회, 모두 새 논점. 새 증거에 따른 변경 0회"). 계속할지는 사용자가 정한다.
- 축 2
4, 811의 수정은 틀 변경이 아니다. 판 번호의 소수점만 올린다.
6. 산출
docs/문제정의-v<판>.md(프로젝트 설정이 다른 위치를 정하면 그곳)에 쓴다. 지난 판은 구판/으로 내린다.
# 문제 정의 v<판> (날짜) 상태: 안 / 잠금(해시)
한 문장 문제:
논문의 종류와 주장:
| 축 | 내용 | 상태(확정/미정) | 근거나 정해지는 조건 |
|---|---|---|---|
정의상 참인 부분과 결과로 남길 부분:
범위 밖:
성공 기준과 접는 조건(결과 전 고정 예정):
사용자 결정: (시각과 함께)
도구 권고 가운데 채택하지 않은 것:
틀 변경 이력: v<n> → v<n+1>, 바뀐 축, 이유 분류
다음: literature-scout(축 6), feasibility-gate(축 3, 4, 7, 8, 10, 11)사용자 결정은 승인기록에도 한 줄씩 남긴다. 만든 파일은 답에서 바로 열 수 있게 링크로 보인다.
7. 글
질문과 기록은 쉽고 짧은 한국어로 쓴다. 영어 용어와 식별자는 영문 그대로 둔다.
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
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.

