session-learning-extractor

Extracts rules/patterns learned during sessions. Used for documenting project-specific rules

항목	내용
Tools	Read, Glob, Grep
Model	haiku

session-learning-extractor — 작업하며 배운 규칙 정리 도우미#

한마디로#

한 번의 작업(세션) 동안 오간 대화를 훑어서, "앞으로 이렇게 하자"고 정해진 규칙과 습관을 자동으로 뽑아 정리해 주는 도우미입니다. 회의가 끝난 뒤 "오늘 우리가 합의한 것들"을 깔끔하게 정리해 두는 서기(書記) 역할이라고 보시면 됩니다.

누가·언제 쓰나요#

새 제품·기능을 만드는 도중, 사용자가 "항상 이렇게 해", "이건 하지 마" 같은 지시를 여러 번 한 경우
같은 실수나 수정이 반복돼서, 그 교훈을 프로젝트 규칙으로 남기고 싶을 때
이 프로젝트에만 적용되는 고유한 명명·구조·도구 사용법을 기록으로 남기고 싶을 때

👉 보통 사람이 직접 부르기보다는, 작업 마무리 단계에서 자동으로 호출되어 일하는 도우미입니다.

무엇을 해주나요#

대화 속에 흩어져 있는 "배운 점"을 세 종류로 나눠서 찾아냅니다.

명시적 규칙 — 사용자가 말로 직접 정한 규칙 (예: "항상 ~~해야 함", "~~ 쓰지 마")
암묵적 규칙 — 같은 수정이 반복되거나, 제안이 거부된 흐름에서 유추한 규칙
프로젝트 고유 규칙 — 이 프로젝트만의 이름 짓기·구조·도구 사용 방식

그리고 각 항목마다 근거(어떤 대화·실수에서 나왔는지)와 확신도(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 YAML

Key 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