LogoSkills

session-learning-extractor

세션 중에 학습한 규칙/패턴을 추출합니다. 프로젝트 고유 규칙을 문서화할 때 사용합니다.

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

항목내용
모델haiku
사용 도구Read, Glob, Grep

한마디로#

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

누가·언제 쓰나요#

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

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

무엇을 해주나요#

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

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

그리고 각 항목마다 근거(어떤 대화·실수에서 나왔는지)와 확신도(high/medium/low)를 붙여, 정해진 YAML 형식으로 깔끔하게 정리해 줍니다. 추측만으로 단정하지 않고, 불확실한 것은 낮은 확신도로 표시합니다.

안에서 무슨 일이 벌어지나요#

크게 다섯 단계로 진행됩니다.

  1. 대화 훑어보기 — 사용자 피드백, 코드 수정 이력, 오류·경고를 뽑아냅니다.
  2. 패턴 맞춰보기 — "항상", "하지 마" 같은 규칙 신호를 찾고, 반복되는 패턴을 묶고, 번복·수정 흐름을 추적합니다.
  3. 확신도 계산 — 근거가 몇 번 나왔는지, 어떤 종류의 근거인지에 따라 high/medium/low를 매깁니다.
  4. 분류하기 — 코드 스타일·구조·테스트·워크플로우 등으로 나누고, 어디에 적용되는지 꼬리표를 답니다.
  5. 결과 정리 — 정해진 YAML 형식으로 최종 정리합니다.

⚙️ 상세 옵션·실행 명세 (개발자 / AI 에이전트용)

Role#

  1. Rule Extraction: Discover explicit/implicit rules
  2. Pattern Learning: Code patterns, workflow patterns
  3. Preference Identification: Identify user preferred styles
  4. Error Patterns: Frequent errors and their solutions

Learning Types#

1. Explicit Rules#

Rules directly mentioned by the user

SignalExample
"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

SignalExample
Repeated modificationsSame pattern modified 3+ times
ReversalsClaude suggestion rejected/modified
Lint errorsSame lint error repeated

3. Project-Specific Rules#

Rules unique to this project

TypeExample
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#

ConfidenceConditions
highExplicit mention + repeated confirmation (3+)
mediumExplicit mention or repeated confirmation (2)
lowImplicit inference (1 time)

Evidence Types#

TypeDescription
user_feedbackDirect user feedback
user_instructionUser instruction
repeated_fixRepeated code modification
lint_errorLint error fix
test_failureTest failure fix
rollbackChange reversal

Learning Categories#

CategoryContent
Code styleFormatting, naming, readability
ArchitectureLayers, modules, dependencies
BLoCState management patterns
TestingTest writing rules
WorkflowWork process
ToolsBuild, lint, MCP
GitBranch, 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#

  1. Evidence-based: Include evidence for all learnings
  2. State Confidence: Mark uncertain items as low
  3. Specific Examples: Include actual code examples
  4. Categorize: Clarify scope of applicability
  5. Remove Duplicates: Consolidate identical content