القائمة
오래된 inbox 문서(type=inbox, status 미소비)를 읽고 frontmatter의 type/status/project/layer/tags를 적절히 승격시켜 지식으로 편입시킨다. "inbox 정리", "문서 정리", "para", "/para" 등 inbox 관리 의도가 보이면 사용. inbox 문서가 쌓여있을 때 주기적으로 사용을 제안해도 좋다.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Refactor frontend source trees so layer/slice/segment(role) hierarchy stays clear. Treat FSD names such as shared/entities/features/widgets/app as examples, not as the required target. Use when the user asks to reorganize src, separate app-owned code from reusable packages, remove layer smells, or clarify 책임 경계.
요청이 모호하거나 '왜 하는지'부터 정리가 필요할 때 사용. /discuss, $discuss, 숨은 의도 정렬, 전략 선택, 실행 전 확인 요청, 프로젝트 작업과 개인 도구 작업의 범위 분리가 필요할 때 사용한다. TOC 13요소와 FRT 게이트로 이해도를 순서대로 올린 뒤 goal로 실행 가능한 액션 플랜을 만든다. 질문만 던지는 소크라틱 대화가 아니라, AI가 먼저 범위 안 맥락을 조사하고 추론한 뒤 판단과 근거를 밝히고 필요한 갭 질문만 얹는다.
Use when the user invokes /doubt or $doubt, asks Codex to deliberately reduce unnecessary complexity before introducing a new concept, component, flag, type, file, branch, workflow, document, or procedure, or requests cleanup/review after implementation. Triggers include "이거 다 필요해?", "정리 좀 해줘", "새로 만들어야 할까?", "불필요한 거 없나?", "코드 줄여줘", "why do we need this?", or any review where existence, fit, volume, and efficiency should be challenged before adding or keeping structure.
Use when refactoring frontend entity folders, FSD feature/entity boundaries, exported type names, prefix alignment, or cohesive entity/viewModel/value-object props so files and UI interfaces are grouped by real domain or UI concepts instead of role labels, generic names, or shredded field props. Trigger on requests such as entities 응집도, 접두어 정렬, 인터페이스 중심 폴더링, FSD 위치 점검, feature/entity 경계 리팩토링, props drill, entity shredding, viewModel props, 엔티티를 그대로 넘기기.
파일이나 기능의 개방-폐쇄 원칙(OCP)을 점검하고 리팩토링한다. "OCP", "/ocp", "개방 폐쇄", "switch 너무 많다", "if 분기 정리", "분기 흩어짐", "선언적 맵", "registry", "descriptor", "새 타입/variant 추가마다 여러 곳 수정" 같은 요청에서 사용한다. 열린 집합의 분기가 여러 소비자에 산재해 동반 변경 지점이 2곳 이상인지 분석하고, 확장 시 기존 코드 수정 지점을 0~1곳으로 줄이는 구조를 설계·전환한다.
사용자 발화를 액면 그대로 수행하지 않고 숨은 조사 의도, 배경, 목표를 먼저 추론한 뒤 비교 대상의 범주와 피어셋을 잠그고, 내부 맥락을 감사하고 standard, best practice, de facto, frontier trend를 비교해 읽히는 reference narrative를 만든다. "reference", "레퍼런스", "BP 찾아줘", "best practice", "사실상 표준", "de facto", "요즘 트렌드", "최근 시도", "업계는 어떻게 해", "표준 뭐야", "research", "리서치", "/reference", "/research"처럼 외부 수렴 흐름을 알고 싶을 때 사용한다. 단순 링크 목록이나 표 보고서가 아니라, 소스를 대신 읽고 같은 범주의 BP/de facto와 얼마나 가까운지, 결이 얼마나 비슷한지, 차이가 있다면 더 가까운 유사 레퍼런스는 무엇인지 문단 중심으로 설명하고 필요한 근거 표는 appendix로 내린다.
| name | para |
| description | 오래된 inbox 문서(type=inbox, status 미소비)를 읽고 frontmatter의 type/status/project/layer/tags를 적절히 승격시켜 지식으로 편입시킨다. "inbox 정리", "문서 정리", "para", "/para" 등 inbox 관리 의도가 보이면 사용. inbox 문서가 쌓여있을 때 주기적으로 사용을 제안해도 좋다. |
mddb 쿼리 type=inbox 문서는 빠르게 기록하기 위한 임시 상태이다. 시간이 지나면 쌓이고, 찾기 어려워지고, 사용되지 않는다. 이 스킬은 inbox 문서를 읽고 frontmatter를 승격 분류(resource/area/archive/prd 등)로 갱신해 지식을 찾을 수 있는 의미 필드로 옮긴다.
모든 inbox를 다 승격시키는 것이 목표가 아니다. 판단이 애매하거나, 아직 진행 중이거나, pending 액션이 남아있는 문서는 type: inbox 그대로 둔다. 확실히 역할이 끝났거나 명확히 다른 범주에 속하는 것만 승격한다.
폴더는 이미 날짜(생성일)로 고정되어 있다. 이동은 없고 frontmatter만 갱신한다.
| 승격 대상 | frontmatter 변경 | 기준 |
|---|---|---|
| Area (지속 갱신 living doc) | type: area + layer: <layer> 또는 project: <project> | 모듈/레이어 문서, 아키텍처 비전, 설계 원칙 |
| Resource (참고 자료) | type: resource + 관련 tags | 외부 조사, 방법론, 디자인 토큰 분석, 패턴 비교 |
| Archive (역할 종료) | status: archived 또는 type: archive | retro(액션 추출 완료), 기각된 제안, 완료된 일회성 분석 |
| Inbox 유지 | 그대로 | 아직 판단 불가하거나, 진행 중인 논의의 일부 |
내용을 읽고 최종 판단한다. 아래는 출발점.
| 시그널 | 경향 | 판단 포인트 |
|---|---|---|
| retro 관련 | Archive | 파생된 backlog(type=backlog) 항목이 모두 생성됐으면 → status: archived. 아직이면 backlog부터 추출 |
| 모듈/개념 해설 | Area | 해당 layer/project의 기존 area 문서가 있는지 확인. 있으면 병합 후 원본은 status: archived |
| vision/방향 | Area | 현행 방향이면 type: area. 기각/대체됐으면 status: archived |
| decision (설계 결정) | Area 또는 별도 유지 | 해당 모듈 area에 병합 또는 type: decision 독립 유지 |
| 일회성 예시/샘플 | Archive | 참고 가치가 높으면 type: resource로 |
| 외부 조사/자료 | Resource | 거의 항상 type: resource |
mddb 쿼리 type=inbox로 inbox 문서 전체를 얻고 분류 테이블을 만든다.
| # | 파일 | 현재 tags | 제안 type | 추가 필드 | 근거 |
|---|------|----------|-----------|-----------|------|
| 1 | docs/2026/.../historyDelta.md | [retro] | archive (status: archived) | — | 파생 backlog 전부 추출 완료 |
| 2 | docs/2026/.../useAriaExplain.md | [explain] | area | layer: primitives | useAria 모듈 해설 |
| ... | | | | | |
분류 판단 시 확인할 것:
type=backlog인 항목 중 이 retro를 출처로 하는 것이 모두 있는지 확인type=area, layer=<layer>로 대응 area 존재 확인 → 있으면 병합 후보테이블을 보여주고 사용자 피드백을 받는다. 행 단위 수정 가능.
"제안대로 frontmatter 갱신할까요? 수정할 항목이 있으면 번호로 알려주세요."
승인된 항목의 frontmatter를 Edit으로 갱신한다. 파일 이동은 없다.
type: area + layer 또는 project 필드 추가. 기존 area 문서와 내용 병합 가능한 경우 병합 후 원본은 status: archivedtype: resource + 분류 tags 보강status: archived 또는 type: archive 설정status: archived, consumed_by: <대상 파일>완료: 15건 frontmatter 갱신 (Area 4, Resource 3, Archive 8)
남은 inbox (type=inbox): 12건