--- name: cmds-standard description: "Apply this vault's CMDS system-file and metadata standard whenever a note is created or edited here, a new project is registered, a DEV folder is linked to a project, or a project plan is turned into a concept web page; always finish by running the bundled checker and report its summary line. Triggers: 노트 만들어줘, 정리해서 저장해줘, 새 프로젝트 등록, 기획서 넣어줘, 규격 검사, 메타데이터 맞춰줘, DEV 연결, 작업 쪼개줘, 상태 기록, 컨셉 페이지 만들어줘, 발행 준비. NOT for writing or reviewing code inside the DEV folder, for editing files under .claude/ or .obsidian/, or for publishing anything without the person's explicit approval in this session." --- # cmds-standard · 이 볼트의 규격대로 쓰고, 검사로 끝낸다 > 강사 볼트(CMDS)의 시스템 파일과 메타데이터 규격을 실습 볼트용으로 줄인 스킬이다. 규격 정본은 `.claude/rules/` 의 세 파일이고, 이 스킬은 그 규격을 **언제·어떤 순서로** 적용하고 **무엇으로 끝났다고 말하는지**를 정한다. > 1차시 키트의 스킬 골격과 같은 다섯 칸(시작 조건 · 사용하지 않을 조건 · 출력 형식 · 실패 처리 · 변경 이유)으로 읽을 수 있다. ## 시작 조건 - 이 볼트 안에서 `.md` 노트를 새로 만들거나 고칠 때 (프로젝트 노트가 아니어도) - 새 프로젝트를 등록할 때, 프로젝트에 DEV 폴더를 연결할 때 - 작업 노트를 나누거나 상태 파일에 기록할 때 - 기획서를 컨셉 페이지로 만들 때 - 시작 전에 읽을 것: `CLAUDE.md` → `.claude/rules/metadata-standard.md` · `writing-rules.md` · `project-rules.md` → `나.md` → 대상 프로젝트 기획서와 상태 파일의 **맨 아래 구역** ## 사용하지 않을 조건 - DEV 폴더 안의 코드를 쓰거나 고치는 일 (그 일은 프로젝트 규칙의 "승인과 멈춤"을 따르고, 결과 경로만 볼트에 기록한다) - `.claude/` · `.obsidian/` · 템플릿 폴더를 고치는 일 (사람이 직접 한다) - 이번 대화에서 사람이 승인하지 않은 발행·외부 전송 - 위에 걸리면: 하지 않고 "cmds-standard 사용하지 않을 조건에 해당 · 이유 한 줄"만 말한다 ## 일 세 가지 ### A. 노트 쓰기·고치기 (모든 노트) 1. 종류를 정한다: `project` · `task` · `project-log` · `note` · `people`. 해당 템플릿(`90. Settings/91. Templates/`)의 칸 순서를 따른다. 2. 프론트매터 필수 7속성 + 종류별 속성을 채운다. `description` 은 영어 1~2문장, 큰따옴표. `date modified` 를 오늘로. 에이전트가 쓰면 `model:` 을 넣는다. 3. 본문은 탭 들여쓰기, Obsidian-tight 빈 줄, 표 앞 빈 줄, 위키링크 대상 실존 확인. 콜아웃 · 임베드 문법은 `obsidian-markdown`, 보드(`.base`)는 `obsidian-bases`, 지도(`.canvas`)는 `json-canvas` 스킬을 따른다. 그 스킬들의 예시 속성(`title`, `date`, `rating`, `status: in-progress`)은 문법 예시일 뿐이고, 속성 이름과 값은 이 볼트 규격이 이긴다. 4. 고친 경우 바꾼 칸만 고친다. 관계없는 속성·문장을 손대지 않는다. 5. 검사: `python3 .claude/skills/cmds-standard/scripts/check_note.py "<파일 또는 폴더>"` 6. FAIL 이 있으면 고치고 다시 검사한다. FAIL=0 이 될 때까지 "완료"라고 말하지 않는다. WARN 은 하나씩 의도인지 판단해 보고한다. ### B. 새 프로젝트 등록과 DEV 연결 1. 사람에게 세 가지만 확인한다(이미 말했으면 묻지 않는다): 프로젝트 이름, 코드(영문 대문자 2~5자), 슬러그(영문 소문자-하이픈). 마감일은 있으면. 2. 미리보기: `python3 .claude/skills/cmds-standard/scripts/new_project.py --name "<이름>" --code --slug --due --dry-run` 3. 만들기: 같은 명령에서 `--dry-run` 을 뺀다. DEV 를 아직 원하지 않으면 `--no-dev`, 나중에 잇는 것은 `--link-dev`. 4. 사람의 기획 문서(붙여넣기·파일)를 기획서 다섯 칸에 옮긴다. **문서에 없는 내용은 지어내지 않고** `빈칸: 무엇이 필요한지` 로 남긴다. 워크플로 도식은 문서에 있으면 옮기고, 없으면 문서 내용만으로 초안을 그린 뒤 "도식 초안"이라고 밝힌다. 5. 작업 노트는 3~5개로 나눈다(`작업/-NN 제목.md`, 템플릿 `Template_작업`). 작업마다 `doneWhen` 은 파일로 확인할 수 있는 한 줄, 첫 작업만 `inProgress`. 6. 상태 파일 맨 아래에 구역을 붙인다: `### YYYY-MM-DD HH:MM · 프로젝트 등록 · 완료`. 7. 검사(A-5) → FAIL=0. ### C. 컨셉 페이지 (발행 준비) 1. 기획서 다섯 칸에 `빈칸:` 이 남아 있으면 먼저 사람에게 채울지 묻는다. 2. 만들기: `python3 .claude/skills/cmds-standard/scripts/build_concept.py "<기획서 경로>"` → `localDev/concept-site/index.html` (이미 있으면 `index.generated.html`) 3. 공개 점검이 함께 돈다. `PRIVACY_FAIL=0` 이 아니면 기획서(원본)를 고치고 다시 만든다. 페이지 HTML 만 고쳐 숨기지 않는다. 4. 사람에게 페이지를 열어 보이게 하고(`open <경로>`) 공개해도 되는 문장인지 승인을 받는다. 디자인·문장 다듬기는 DEV 의 `index.html` 에서 한다. 5. 발행은 승인 뒤 한 번. 기본은 사람의 Vercel 계정: 처음이면 사람이 직접 `! npx vercel login`, 그다음 에이전트가 `concept-site/` 에서 `npx vercel deploy --prod --yes` 를 실행하고 주소를 보고한다. 계정을 쓸 수 없으면 `concept-site` 폴더를 ZIP 으로 묶어 수업 제출처에 낸다. 6. 발행 뒤 기획서 `published: true` · `publishedUrl: "https://…"`, 상태 파일 구역 `· 발행 · 완료`, 검사(A-5). ## 출력 형식 - 대화 끝 보고는 세 줄 이상: - 만든 파일 / 고친 파일 (볼트 기준 경로, DEV 는 절대 경로) - 검사 결과 summary 줄 그대로 (`summary: FILES=… FAIL=0 WARN=…`)와 남긴 WARN 의 판단 - 다음 할 일 하나 (상태 파일의 "다음 할 일"과 같은 문장) - 실행하지 않은 검사는 "미실행"이라고 쓴다. 검사 결과를 지어내지 않는다. ## 실패 처리 - 검사기·생성기를 실행할 수 없으면(파이썬 없음, 경로 오류) → 결과를 지어내지 않고 멈춘다. 실행한 명령과 오류 한 줄을 보고한다. Windows 는 `python` 또는 `py`. - 생성기가 "이미 있다"고 멈추면 → 덮어쓰지 않는다. 다른 슬러그를 쓸지, `--link-dev` 인지 사람에게 묻는다. - 사람의 문서에 개인정보·고객 원본이 보이면 → 옮기지 않고 멈춘 뒤 알린다. - 같은 FAIL 을 두 번 고쳐도 남으면 → 세 번째로 고치지 말고, 규칙 줄(`.claude/rules/…`)과 FAIL 줄을 함께 보여 주며 사람에게 묻는다. - 실패해도 지우지 않는다. 상태 파일에 `· 실패` 구역으로 남긴다. 실패 기록은 다음 개선의 재료다. ## 변경 이유 | 날짜 | 바꾼 곳 | 바꾼 내용 | 이유 | |---|---|---|---| | 2026-11-06 | A-3 · 검사기 | kepano 문법 스킬 3종(obsidian-markdown · obsidian-bases · json-canvas)과의 경계, `.canvas` 검사 추가 | 학생이 보드 · 캔버스를 요청할 때 문법은 원본 스킬에서, 값은 규격에서 오게 하려고. 원본 예시의 `rating` · `in-progress` 가 규격과 부딪힌다 | | 2026-11-06 | 전체 | 처음 작성 (R1) | 부트캠프 1기 AI Agent Workflow 2·3차시 개인 프로젝트 실습용. 강사 볼트 규격(frontmatter-standard · wikilink · blank-line · mermaid · file-creation)을 실습 볼트에 맞게 줄임 | --- ## 이 스킬을 읽는 법 (2차시 해부용) - **description 이 트리거다.** 에이전트는 이 문장과 사람의 요청을 맞춰 보고 스킬을 켠다. 그래서 언제 쓰는지(Triggers)와 언제 쓰지 않는지(NOT for)를 함께 쓴다. - **문법 스킬과 규격 스킬은 다르다.** obsidian-markdown 은 Obsidian 이 무엇을 읽을 수 있는지, cmds-standard 는 이 볼트에서 무엇을 지켜야 하는지. 둘이 부딪히면 시스템 파일(CLAUDE.md)이 우선순위를 정한다. - **규칙은 rules 에, 순서는 스킬에, 판정은 검사기에.** 규칙을 스킬 안에 복사하지 않고 정본 파일을 가리킨다. 규칙이 바뀌어도 스킬은 그대로다. - **"완료"는 말이 아니라 summary 줄이다.** 검사기는 값이 "있나"를 본다. 값이 "맞나"(이 니즈가 진짜 니즈인가)는 사람이 본다. 검사 두 층. - 내 업무 스킬을 만들 때(3차시) 이 파일을 복제해 칸을 바꾼다: `.claude/skills/<내 스킬>/SKILL.md`.