가이드와 글쓰기 스킬

한 줄로: Slima가 자기 규칙을 여러분의 AI 도구에 직접 건네주는 방식입니다. 「여기서 무엇을 할 수 있는가」에 답하는 도구, Slima 자신의 조작 가이드, 그리고 글쓰기 스킬.

이 글이 해결하는 문제

여러분의 AI 도구는 Slima가 어떻게 돌아가는지 모르는 상태로 접속합니다. 어떤 파일이 원고인지 참고 자료인지에 따라 글자 수에 잡히고 안 잡히고가 갈린다는 것도, .map은 통째로 다시 쓸 수 없다는 것도, 쓰기 한 번이 곧 커밋이라는 것도 모릅니다.

부딪혀 가며 알아낼 수도 있습니다. 잘못 쓰고, 거부당하고, 다시 시도하는 식입니다. 아니면 물어보면 됩니다. 이 도구들이 물어보는 방법입니다.

도구	돌려주는 것
get_capabilities	이 서버가 지금 지원하는 것: 쓸 수 있는 확장자, 콘텐츠 종류가 정해지는 방식, 사용 가능한 도구, 가이드 목차
list_guides	가이드 목차. 각 가이드의 이름과 「언제 불러올 것인가」
load_guide	가이드 한 편을 통째로
list_writing_skills	글쓰기 스킬 목차
load_writing_skill	글쓰기 스킬 한 편을 통째로

세션은 get_capabilities로 시작하십시오

Slima의 MCP 서버는 연결이 열리는 순간 AI에게 이렇게 알려 줍니다. 가장 먼저 get_capabilities를 호출하라고. 여기서 돌아오는 모든 항목은 서버가 실제로 집행하는 계약에서 뽑아낸 값입니다. 그래서 사람이 손으로 쓴 설명과 달리 실제 동작과 어긋날 수가 없습니다.

네 덩어리가 돌아옵니다.

• 확장자별 정책과 그 정책이 무슨 뜻인지 풀어 쓴 문장(통째 쓰기 가능 / 필드 단위 도구만 / 아예 쓰기 불가)
• 콘텐츠 종류: 어떤 값이 있는지, 새 파일에서 지정하지 않았을 때 어떻게 정해지는지(상위 폴더를 따라가고, 최상단이면 참고 자료)
• 도구 목록
• 가이드 목차

get_capabilities가 이 서버가 제공하는 모든 도구를 나열하므로, 클라이언트의 도구 설명과 서버가 어긋날 때는 그것이 기준입니다.

여기에 더해, 말해 주지 않으면 반드시 한 번은 손해를 보는 사실들이 몇 줄 붙어 옵니다. 쓰기는 전부 커밋이고 따로 저장 단계가 없다는 것, 글자 수와 연속 기록과 AI 베타 리더에 반영되는 것은 원고뿐이라는 것, 작가가 같은 파일을 고치고 있을 수 있으니 통째 쓰기보다 edit_file이 안전하다는 것, 토큰은 기기가 바뀌면 같은 신원이 아니므로 파일은 경로로 지목해야 한다는 것.

어떤 가이드가 있는가

가이드가 가르치는 것은 Slima를 다루는 법입니다. 전부 미리 불러오지 말고, 그 일을 하기 직전에 해당하는 한 편만 불러오십시오.

가이드	언제 불러오는가
getting-started	Slima 작품을 처음 맡았을 때. 지도 역할이고, 다음에 볼 가이드를 짚어 줍니다
book-structure	파일을 만들기 전에. 원고와 참고 자료의 차이, 그리고 작가의 글자 수에서 작가의 글이 사라지지 않게 하는 법
version-control-basics	크게 고쳐 쓰기 전에. 쓰기가 커밋이 되는 과정, 그리고 읽는 동안 작가가 쓴 것을 덮어쓰지 않는 법
notes-and-foreshadowing	메모를 남기거나 복선의 설치와 회수를 추적할 때
comments-review-loop	편집 왕복에 들어갈 때. 코멘트 남기기, 남이 남긴 것에 답하기, 그리고 끝까지 작가의 결정으로 남는 것
beta-reader	AI 베타 리더 리포트를 의뢰하기 전에. 무엇이 들고 얼마나 걸리며 결과를 어떻게 받아 오는지
team-knowledge-base	출판사나 스튜디오 팀 안에서 일할 때. 무엇이 공유되고 무엇은 보이지 않는지
script-studio	예전 시나리오 스튜디오 작품을 만났을 때. 무엇이 구조화 파일이고 무엇을 쓸 수 있는지
format-beats	.beats 파일에 손대기 전에
format-timeline	.timeline 파일에 손대기 전에
format-script	.script 파일에 손대기 전에
format-relationship-map	.map 파일에 손대기 전에
format-geomap	.geomap 파일에 손대기 전에

slug를 틀리게 넘겨도 그냥 「없음」이 오지는 않습니다. 진짜 목록을 함께 돌려주기 때문에, 한 번 틀린 추측도 결국 맞는 가이드에 도착합니다.

format-* 가이드는 일찍 불러올 값어치가 있습니다. 그것들은 종류 자체의 규칙(어떤 필드가 내용이고 어떤 필드가 레이아웃인지, 무언가를 지우면 무엇이 딸려 가는지)을 다루고, 구조화 편집 도구는 도구를 어떻게 호출하는지를 다룹니다.

어떤 글쓰기 스킬이 있는가

글쓰기 스킬은 Slima 조작법이 아니라 작법 절차입니다. 앱 안의 AI 코치가 따르는 것과 같은 단계별 절차입니다.

스킬	하는 일
character_develop	이미 있는 인물을 깊게: 아크, 목소리, 관계, 성장
character_create	새 인물을 맨바닥에서 만드는 과정을 작가와 함께 밟기
plot_architect	구조·시놉시스·서사 아크를 설계하거나 점검
scene_craft	신 하나를 다듬기: 완급, 감각 묘사, 긴장, 전환
tension_map	챕터 전체 또는 작품 전체의 긴장 곡선 분석
voice_polish	이 작품의 목소리와 문체를 찾아내고 강화
dialogue_coach	대사를 입말답게, 인물마다 목소리가 구분되게
consistency_audit	시간선·배경·인물·논리의 모순을 체계적으로 점검
world_build	세계관 체계 설계·점검: 마법, 문화, 정치, 경제
opening_hook	도입부를 분석하고 개선

한 줄로 나누면 이렇습니다. 글 자체에 관한 일이면 스킬을, Slima 조작에 관한 일이면 가이드를 불러오십시오.

왜 이것들을 패키지에 넣지 않았는가

버전을 고정하는 쪽이 여러분이기 때문입니다. 가이드를 클라이언트 안에 써 넣으면, 그 문서는 여러분이 고정한 버전에 그대로 멈춰 섭니다. 그러고는 서버가 더 이상 지원하지 않는 방식을 똑같이 자신만만한 말투로 계속 가르칩니다.

Slima 쪽에서 내보내면, Slima가 배포하는 순간 전부 갱신됩니다. 어느 버전을 고정해 두었든 상관없습니다.

부수적인 이점도 하나 있습니다. 그 가이드에서 파일 종류를 다루는 부분은 앱 안의 AI 코치가 읽는 것과 같은 문장입니다. 하나의 원문을 둘이 읽습니다. 그래야 같은 파일을 두고 외부 AI와 앱 안의 AI가 서로 다른 규칙을 가르치는 일이 생기지 않습니다.

실제로 쓰는 법

대화를 시작할 때 이렇게 못 박아 두는 편이 나중에 바로잡는 것보다 쌉니다.

Slima에 연결하면 먼저 get_capabilities를 호출할 것.
그다음 book-structure 가이드를 불러올 것.
연표나 비트 보드에 손대기 전에는 해당 format-* 가이드를 먼저 불러올 것.

관련 문서

• Docs: 구조화 편집 도구
• Docs: schema 리소스로 정확한 권한 확인하기
• Docs: MCP가 파일 종류별로 할 수 있는 일
• Docs: Slima MCP란 무엇인가