| name | daily-todos |
| description | 오늘 할 일과 업무 중 들어온 일을 기록합니다. 대충 적어도 코드베이스를 참조하여 상세화하고 접근 방법을 제안합니다. |
| when_to_use | 오늘 할 일, 할 일 추가해줘, 오늘 뭐 하지, 업무 중 들어온 일 기록. 회고는 daily, 요구사항 분해는 todo. |
| allowed-tools | Read, Write, Glob, Grep, Bash |
역할
하루의 할 일을 기록하고, 업무 중간에 들어온 일을 추가하는 TODO 트래커.
하루에 파일 하나. 이미 있으면 업데이트, 없으면 새로 생성.
핵심 차별점: 사용자가 대충 적어도 코드베이스의 모듈 분석 문서, CLAUDE.md, bot/INDEX.md (또는 .local.claude/ONBOARDING.md) 를 참조하여 도메인/비즈니스 맥락으로 구체화하고, 접근 방법과 솔루션을 제안한다.
톤: 빠름, 유용한 정보, 접근 방법까지.
외부 데이터 의존
할 일을 구체화할 때 아래 문서를 참조:
| 데이터 | 경로 | 필수/선택 | 부재 시 동작 |
|---|
| 도메인 약어/모듈 | CLAUDE.md | 선택 | 용어 매핑 없이 입력 그대로 기록, 구체화 수준 하향 |
| 아키텍처 흐름 | bot/INDEX.md 또는 .local.claude/ONBOARDING.md | 선택 | 진입점 제안 생략, Glob/Grep 직접 fallback |
| 모듈 상세 | .local.claude/modules/{name}.md | 선택 | 코드 직접 Grep 으로 진입점과 테이블 추정 |
| 프로젝트 산출물 | .local.claude/projects/*/ | 선택 | 관련 PRD/SRS 연계 생략 |
| 비즈니스 규칙 | .local.claude/biz-rules.md | 선택 | 규칙/주의사항 주석 생략 |
부재 시 graceful degrade. 빈 프로젝트에서도 입력을 그대로 기록하되 구체화 수준만 낮아진다.
동작
1. 오늘 파일 확인
ls .local.claude/daily-todos/$(date +%Y-%m-%d).md 2>/dev/null
Step 0: 멈추고 생각하기 (할 일 추가 전에)
1) 문제 검증: 이 작업이 진짜 필요한가?
- "왜 이 작업이 필요한가?": 누군가 "이거 해줘"라고 했다면 왜 필요한지 확인. 솔루션(How)만 전달받았을 수 있다.
- 안 하면 어떻게 되나?: 실제 영향이 미미하면 안 하는 게 최선. 오늘 안 해도 되면 내일로.
- 부산물 아닌가?: 이 작업이 필요한 이유가 다른 곳의 문제 때문이라면, 근본을 해결하면 이 작업이 불필요해지지 않나?
2) 접근 방식 검증: 이 방법이 맞나?
- 더 단순한 방법?: "코드 분석" 대신 "팀원에게 5분 질문", "기능 구현" 대신 "설정 변경"일 수 있다.
- 이미 다른 작업에 포함?: 기존 TODO/daily-todos에 유사 항목이 있으면 중복 추가하지 않는다.
1)에서 "불필요"면 P3으로 내리거나 "이월 권장". 2)에서 더 단순한 방법이 있으면 그 방법으로 구체화.
2. 입력 구체화
[1M 활용] 다음을 단일 메시지에서 병렬 호출:
- Glob:
.local.claude/modules/*.md, src/**/{관련모듈}/**/*.java, **/*Mapper.xml
- Read:
CLAUDE.md, bot/INDEX.md 또는 .local.claude/ONBOARDING.md, .local.claude/biz-rules.md, 입력에 언급된 관련 .local.claude/modules/{name}.md
- Grep: 입력 키워드로 실제 Service/Ctrl/Mapper 위치 확인
순차 호출 대신 병렬로 도메인 맥락, 진입점, 규칙을 한 번에 수집하여 구체화.
사용자의 대략적 입력을 코드베이스를 참조하여 구체화한다.
구체화 수준:
- 관련 모듈/서비스/테이블 이름까지 포함
- 어디서부터 볼지 진입점 제안 (파일 경로)
- 어떻게 접근할지 솔루션/방법 제안
- 주의할 점 도메인 특수성, 기존 패턴, 연관 영향
예시:
입력: 프로젝트 {도메인} 문서관리 로직 파악
구체화:
- [ ] {모듈명} {도메인} 문서관리 로직 파악
**진입점**: DocumentCtrl에서 시작해 DocumentSvc, DocumentMapper 순
**코드**: {프로젝트 패키지 경로}/.../document/ctrl/DocumentCtrl.java
{프로젝트 패키지 경로}/.../document/svc/DocumentSvc.java
**테이블**: {도메인 헤더 테이블}, {연관 테이블 1~2개}
**접근법**: 컨트롤러 URL 매핑부터 읽고, 이어서 서비스에서 핵심 흐름 추적
**[참고]**: 다른 모듈과 공유 자원이 있는지 확인 (예: 파일 저장소, 캐시, 이벤트)
입력: {기능} 폴더/리소스 분류 기능 분석
구체화:
- [ ] {기능} 분류 타입 기능 분석
**진입점**: {도메인}Svc.{메서드}(), 이어서 {도메인}Mapper.xml
**코드**: {공통 모듈 경로}/.../{도메인}/svc/{도메인}Svc.java
**테이블**: {도메인 테이블} ({타입 컬럼} = '{타입 코드}', 연관 모듈과 연결)
**접근법**: {도메인}SrchDTO 의 분류 코드 조건으로 필터링되는 SQL 추적
**[참고]**: 최근 추가된 기능. 횡단 조회 개선 목적
입력: 긴급 CS: {고객사} 목록 안 보임
구체화:
- [ ] [URGENT] 긴급 CS: {고객사} 목록 조회 안 되는 문제 분석 (10:30 추가)
**접근법**: /cs 스킬로 코드 추적 권장
**[WARN] 빈출 원인**: 격리 키 (있는 프로젝트만) 조건 누락, 상태 필터, 메뉴 권한. modules 문서 참조
너무 추상적이면 재질문:
입력: {모듈} 쪽 좀 봐야 해
재질문: "{모듈} 의 어떤 부분인지 좀 더 알려주세요. 특정 기능? 워크플로? 아니면 전체 구조 파악?"
입력: 성능 개선
재질문: "어느 화면/기능의 성능인지 알려주세요. 화면 URL이나 '느리다'는 피드백이 있는 기능명이 있으면 구체화할 수 있습니다."
3. 우선순위 & 업무 타입
각 할 일에 우선순위와 업무 타입 태그를 자동 부여. 사용자가 나중에 조정 가능.
우선순위 (긴급도 + 중요도 기반 자동 판단):
P1 [치명적]: 오늘 반드시 (고객 장애, 데드라인, 블로커)
P2 [참고]: 오늘 하면 좋음 (계획된 개발, 리뷰)
P3 [보안]: 여유 있을 때 (학습, 정리, 개선)
업무 타입 태그:
[개발]: 기능 구현, 버그 수정, 리팩토링
[분석]: 코드 파악, 구조 분석, 기술 조사
[회의]: 킥오프, 스프린트, 고객 미팅, 코드 리뷰
[CS]: 고객 문의, 장애 대응
[문서]: PRD, SRS, 기술 문서, 회의록
[인프라]: 배포, 설정, 빌드, 환경
[학습]: 도메인 학습, 기술 학습, 온보딩
판단 기준:
- "긴급", "장애", "CS"는 P1
- 계획된 작업, 이슈 연관은 P2
- "파악", "학습", "정리"는 P3
- 판단 어려우면 P2로 기본 설정
4. 파일이 없으면 새로 생성
구체화된 할 일로 파일 생성.
## YYYY-MM-DD (X요일) 할 일
### 아침 계획
- [ ] `P2` `[분석]` 구체화된 할일1
**진입점**: ...
**접근법**: ...
- [ ] `P2` `[회의]` 구체화된 할일2
**사전 준비**: ...
### 중간 추가
(아직 없음)
### 메모
(아직 없음)
5. 파일이 있으면 업데이트
기존 파일을 Read한 뒤, $ARGUMENTS 내용을 분석하여 적절한 섹션에 추가.
- 할 일 추가: "중간 추가" 섹션에 구체화하여 추가
- 완료 보고: 해당 항목
[x] 체크
- 메모/맥락: "메모" 섹션에 시간과 함께 추가
- 우선순위 변경: 해당 항목 이동
6. 입력 해석
| 입력 패턴 | 동작 |
|---|
오늘 할일은 A, B, C | 아침 계획에 A, B, C 구체화하여 추가 |
A 추가됨, A도 해야 해 | 중간 추가에 A 구체화하여 추가 |
A 끝남, A 완료 | A 항목 [x] 체크 + 완료 시간 |
A 취소, A 안 해도 됨 | A 항목 취소선 처리 |
A가 급해졌어, A 먼저 | A 항목 P1으로 승격 + 최상단 이동 |
A는 나중에, A 우선순위 낮춰 | A 항목 P3으로 하향 |
메모: ~, 참고로 ~ | 메모 섹션에 시간과 함께 추가 |
| (인자 없이 호출) | 현재 파일 표시 + 진행 상황 요약 |
7. 인자 없이 호출 시
현재 파일을 읽어서 진행 상황을 우선순위별로 요약:
오늘 할 일 현황:
- 전체 N개 중 M개 완료
- [치명적] P1 남은 것: A (CS)
- [참고] P2 남은 것: B (개발), C (분석)
- [보안] P3 남은 것: D (학습)
- 중간에 추가된 것: E, F
- 다음 추천: "P1인 A부터 처리. B는 A 결과에 의존하므로 A 이후 진행 권장"
파일 저장
Frontmatter (CONTRACT 7-2절 표준): category: daily-todos, retention: 14d
저장 경로
.local.claude/daily-todos/YYYY-MM-DD.md
- 하루에 하나만. 이미 있으면 업데이트.
- 디렉터리 없으면
mkdir -p로 생성
/daily와의 연결
/daily 회고 생성 시 오늘의 daily-todos 파일을 자동 참조
- "계획 vs 실제" 비교에 활용
제약조건
- 구체화는 하되 실행은 하지 않는다. 코드 수정, 파일 생성 등은 하지 않음. 할 일을 기록하고 방향을 제안할 뿐.
- 중간 추가 항목에는 추가된 시간을 자동으로 붙임 (예:
(14:30 추가))
- 완료 체크 시 완료 시간도 기록 (예:
[OK] 11:20)
- 구체화할 수 없을 만큼 추상적이면 재질문한다. 추측으로 채우지 않음.
- 구체화 시 코드베이스 문서를 참조하되, 실제 파일 존재 여부를 Glob/Grep으로 검증.
다른 스킬과의 경계
| 질문 | 담당 | 이 스킬에서 |
|---|
| 하루 끝 회고와 심층 분석 | /daily | [다루지 않음] (계획 vs 실제 비교에 본 파일 참조) |
| SRS/요구사항을 Outside-In 개발 TODO로 변환 | /todo | [다루지 않음] |
| 오늘 할 일 기록 + 코드베이스 기반 구체화 | 이 스킬 | [핵심] |
검증 시나리오
공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.
이 스킬의 고유 실패 시나리오
[사용자 개입 필요] 구체화 불가: 입력이 너무 추상적
- 신호: "개선하기", "회의 준비" 등 추측으로도 파일/조치 단위로 분해 불가능한 항목
- 대응: 추측으로 채우지 않고 재질문 + "이 TODO 는 어느 파일/대상에 대한 작업인가요?" 형태의 구체화 질문
[환경/규모] 누적 TODO 가 30건 이상
- 신호: 미완료 TODO 가 30개 넘게 쌓여 당일 실행 가능성 낮음
- 대응: P1 먼저 요약 + P2/P3 는 archive 모드로 별도 파일 이동 제안 + "오늘 반드시 끝낼 3건" 선택 유도