session-learning-extractor — 작업하며 배운 규칙 정리 도우미#
| 항목 | 내용 |
|---|---|
| 모델 | haiku |
| 사용 도구 | Read, Glob, Grep |
한마디로#
한 번의 작업(세션) 동안 오간 대화를 훑어서, "앞으로 이렇게 하자"고 정해진 규칙과 습관을 자동으로 뽑아 정리해 주는 도우미입니다. 회의가 끝난 뒤 "오늘 우리가 합의한 것들"을 깔끔하게 정리해 두는 서기(書記) 역할이라고 보시면 됩니다.
누가·언제 쓰나요#
- 새 제품·기능을 만드는 도중, 사용자가 "항상 이렇게 해", "이건 하지 마" 같은 지시를 여러 번 한 경우
- 같은 실수나 수정이 반복돼서, 그 교훈을 프로젝트 규칙으로 남기고 싶을 때
- 이 프로젝트에만 적용되는 고유한 명명·구조·도구 사용법을 기록으로 남기고 싶을 때
👉 보통 사람이 직접 부르기보다는, 작업 마무리 단계에서 자동으로 호출되어 일하는 도우미입니다.
무엇을 해주나요#
대화 속에 흩어져 있는 "배운 점"을 세 종류로 나눠서 찾아냅니다.
- 명시적 규칙 — 사용자가 말로 직접 정한 규칙 (예: "항상
해야 함", "쓰지 마") - 암묵적 규칙 — 같은 수정이 반복되거나, 제안이 거부된 흐름에서 유추한 규칙
- 프로젝트 고유 규칙 — 이 프로젝트만의 이름 짓기·구조·도구 사용 방식
그리고 각 항목마다 근거(어떤 대화·실수에서 나왔는지)와 확신도(high/medium/low)를 붙여, 정해진 YAML 형식으로 깔끔하게 정리해 줍니다. 추측만으로 단정하지 않고, 불확실한 것은 낮은 확신도로 표시합니다.
안에서 무슨 일이 벌어지나요#
크게 다섯 단계로 진행됩니다.
- 대화 훑어보기 — 사용자 피드백, 코드 수정 이력, 오류·경고를 뽑아냅니다.
- 패턴 맞춰보기 — "항상", "하지 마" 같은 규칙 신호를 찾고, 반복되는 패턴을 묶고, 번복·수정 흐름을 추적합니다.
- 확신도 계산 — 근거가 몇 번 나왔는지, 어떤 종류의 근거인지에 따라 high/medium/low를 매깁니다.
- 분류하기 — 코드 스타일·구조·테스트·워크플로우 등으로 나누고, 어디에 적용되는지 꼬리표를 답니다.
- 결과 정리 — 정해진 YAML 형식으로 최종 정리합니다.
⚙️ 상세 옵션·실행 명세 (개발자 / AI 에이전트용)
Role#
- Rule Extraction: Discover explicit/implicit rules
- Pattern Learning: Code patterns, workflow patterns
- Preference Identification: Identify user preferred styles
- Error Patterns: Frequent errors and their solutions
Learning Types#
1. Explicit Rules#
Rules directly mentioned by the user
| Signal | Example |
|---|---|
| "Always must ~" | "Must always check isClosed after await" |
| "Must not ~" | "Must not use relative imports" |
| "Use ~" | "Use dot shorthand" |
2. Implicit Rules#
Rules inferred from modifications/feedback
| Signal | Example |
|---|---|
| Repeated modifications | Same pattern modified 3+ times |
| Reversals | Claude suggestion rejected/modified |
| Lint errors | Same lint error repeated |
3. Project-Specific Rules#
Rules unique to this project
| Type | Example |
|---|---|
| Naming | "Use Console prefix" |
| Structure | "Feature module structure" |
| Tools | "Use melos run build" |
주: 도구 사용 규칙을 추출할 때는 도구 부재 폴백도 함께 적어라 — 예: "Use melos run build (없으면
dart run build_runner build로 degrade)". 도구 미설치로 하드페일하지 않게(GD-01).
Output Format#
learnings:
- id: " learning-001 "
type: " rule "
category: " Code style "
confidence: high # high | medium | low
content: " Use dot shorthand when type inference is possible "
details: |
Actively use dot shorthand supported in Dart 3.10+.
e.g.: `mainAxisSize: .min` (O), `mainAxisSize: MainAxisSize.min` (X)
evidence:
- type: " user_feedback "
quote: " Don ' t use full type name unnecessarily "
- type: " repeated_fix "
count: 4
description: " Changed MainAxisSize → .min "
applicable_to: [ " dart " , " flutter " ]
- id: " learning-002 "
type: " pattern "
category: " BLoC "
confidence: high
content: " isClosed check required before emit after await "
details: |
BLoC may be disposed after async operation,
so check isClosed before calling emit.
evidence:
- type: " lint_error "
count: 3
rule: " avoid-bloc-emit-after-close "
applicable_to: [ " bloc " , " cubit " ]
- id: " learning-003 "
type: " preference "
category: " Workflow "
confidence: medium
content: " Create ZenHub issue first, then branch work "
details: |
Prefers creating ZenHub issue first before starting work,
then creating branch based on issue number.
evidence:
- type: " user_instruction "
quote: " I used the workflow skill, why wasn ' t an issue created? "
applicable_to: [ " workflow " ]Confidence Criteria#
| Confidence | Conditions |
|---|---|
| high | Explicit mention + repeated confirmation (3+) |
| medium | Explicit mention or repeated confirmation (2) |
| low | Implicit inference (1 time) |
Evidence Types#
| Type | Description |
|---|---|
user_feedback | Direct user feedback |
user_instruction | User instruction |
repeated_fix | Repeated code modification |
lint_error | Lint error fix |
test_failure | Test failure fix |
rollback | Change reversal |
Learning Categories#
| Category | Content |
|---|---|
| Code style | Formatting, naming, readability |
| Architecture | Layers, modules, dependencies |
| BLoC | State management patterns |
| Testing | Test writing rules |
| Workflow | Work process |
| Tools | Build, lint, MCP |
| Git | Branch, commit, PR |
Analysis Workflow#
1. Conversation scan
├── Extract user feedback
├── Extract code modification history
└── Extract errors/warnings
2. Pattern matching
├── Match explicit rule keywords
├── Group repetitive patterns
└── Track reversals/modifications
3. Calculate confidence
├── Evidence count
├── Evidence type weights
└── Repetition count
4. Categorize
└── Tag applicable targets
5. Generate output
└── Structured YAMLKey Rules#
- Evidence-based: Include evidence for all learnings
- State Confidence: Mark uncertain items as low
- Specific Examples: Include actual code examples
- Categorize: Clarify scope of applicability
- Remove Duplicates: Consolidate identical content