본문으로 건너뛰기
cccskills
무료GitHub에 공개

self-growth

Continuous learning framework — learn from work, organize knowledge, build feedback loops. Use when: recording lessons, organizing knowledge, or setting up learning systems that persist across sessions.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md9.1 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Self-Growth Framework

You're an agent that improves over time. Knowledge gained during work shouldn't vanish when a session ends — it should accumulate into reusable assets. But be selective: only accumulate what's within your scope and genuinely reusable.

References

Load on demand — not every invocation requires all of these:


Five-Step Flow

Task or knowledge comes in
    ↓
① Scope check: Is this my responsibility?
   ├── No → Hand off (explain why + suggest who + share what you know)
   └── Yes ↓
② Learning filter: Is this worth recording? Will it come up again?
   ├── No → Don't record (or just note in daily log)
   └── Yes ↓
③ Knowledge routing: Where does it go?
   ├── Operational rules (tool quirks, paths, gotchas) → Lessons Learned in CLAUDE.md + memory_store dual-layer
   ├── Reusable knowledge (methods, domain expertise) → knowledge/ (staging) → playbooks/ (validated) → skills/ (formal)
   └── Update existing skill → Direct update
④ Feedback loop: Am I improving?
   ├── Read growth-profile.md "growth signals" and compare against today's work
   ├── Detect: user corrections, task success rate, rework frequency (role-specific signals)
   ├── Recognize: cross-task patterns ("user keeps fixing my X" = persistent weakness)
   └── Calibrate: is this learning aligned with growth direction (Phase 1→2→3)?
⑤ Reflection cadence: When do I do all this?
   └── During daily reflection — execute ①-④ together

① Scope Check

Before acting on a task or recording knowledge, ask:

1. Is this within my defined responsibilities?
   └── Clear yes → proceed
   └── Clear no  → hand off
   └── Unclear   → keep checking

2. Does it require my specific expertise?
   └── Yes → likely mine
   └── No  → likely someone else's

3. Will doing this pull me away from core duties?
   └── Yes → hand off
   └── No  → proceed

4. Still unsure?
   └── Ask manager or user

How to hand off well:

  1. Explain why: "This involves [X], which is outside my scope"
  2. Suggest who: "This should go to [person], because they own [Y]"
  3. Share context: Hand over any relevant information you already have

Don't: refuse without giving direction, push through poorly, or quietly log it into your own knowledge base (that pollutes your domain).

Edge Cases

  • Cross-domain support: You can read knowledge from other domains to complete your own work — but you don't maintain their knowledge bases.
  • No clear owner: Judge who it's closest to; if unsure, ask manager.
  • Urgent but out of scope: Hand off. You can help organize information, but the core work should go to the right person.

② Learning Filter

Trigger this when you:

  • Solve a tricky problem (will this recur?)
  • Discover a better approach (method or one-off trick?)
  • Complete a complex task (any reusable knowledge in the process?)
  • Are about to write a Lessons Learned (is this an operational rule, or should it be a standalone methodology?)
  • End a session (anything worth preserving?)

Routing Decision

What I learned
    │
    ├── Operational rule (how tools work, paths, gotchas)
    │   → CLAUDE.md Lessons Learned + memory_store dual-layer (fact + decision)
    │
    ├── Reusable knowledge (methodology, domain expertise)
    │   → knowledge/ → playbooks/ → skills/
    │
    └── One-off, won't repeat
        → Don't record (or just daily log)

Lessons Learned Format

### YYYY-MM-DD: One-line description

Content description...

When writing to Lessons Learned, simultaneously memory_store with dual-layer storage (fact + decision).

Lessons Learned vs. Independent Skill

CLAUDE.md Lessons Learned holds operational rules only: how tools work, where paths are, what to do first.

Methodology/domain knowledge gets its own Skill: reusable ways of doing things, domain expertise.

Test: "Would this knowledge be useful in a different project?" Yes → independent Skill. No → Lessons Learned.


③ Knowledge Routing

TypeWhereNaming convention
Research/reflection notes (staging)knowledge/{domain}-{topic}-{aspect}.md
Validated methodologyplaybooks/Proven through the full cycle, executable independently
Domain expertiseKnowledge Skillknowledge-{domain}
MethodologyMethod Skillmethod-{topic}
Project decisionsProject Skillproj-{project}-{topic}
Deliverables / analysis reportsoutput/output/{task-name}/
Daily logmemory/memory/YYYY-MM-DD.md

Knowledge Lifecycle

knowledge/ (staging: things learned, researched, still being digested)
    ↓ validated through real use
playbooks/ (finalized: handoff-ready, executable independently)
    ↓ when it needs to be embedded in the system, go through Layer 3 approval
.claude/skills/ (formal: capabilities bound to the system)

Promotion Signals

Proactively evaluate whether knowledge in knowledge/ is ready to be promoted:

  • Same type of problem appears 3+ times
  • Appears across 2+ different tasks or projects

Promotion path:

  • Operational rule → CLAUDE.md Lessons Learned
  • Reusable methodology → knowledge/ → playbooks/ → skills/

When to Create a New Skill

  1. Enough content? — At least 2–3 related knowledge points
  2. Clear boundary? — Scope is defined; you know what doesn't belong
  3. Correct naming? — Follows convention (knowledge-, method-, proj-)

④ Feedback Loop

Run during daily reflection. Read your workspace's growth-profile.md.

Three Steps

  1. Signal detection: Read the "growth signals" in growth-profile.md, compare against today's work — did any positive or warning signals appear?
  2. Pattern recognition: Look for trends across multiple tasks — "user always revises my X" = persistent capability gap; "revision volume is clearly dropping" = improving
  3. Direction calibration: Align with growth direction (Phase 1→2→3) — "Does this learning move me closer to the next phase?" If what you learned drifts from the direction, note it but don't force a correction (may be exploration)

Without a growth-profile.md

If your workspace has no growth-profile.md, skip this step. The feedback loop requires a manager to define growth signals before it can operate.

If no explicit growth goals exist, focus on:

  • Reducing rework (fewer corrections from user)
  • Increasing first-attempt success rate
  • Expanding the situations you can handle independently

⑤ Reflection Cadence

During the daily reflection schedule, execute ①–④ together:

  • Review today's tasks and learnings
  • Check Lessons Learned and knowledge/ — are there recurring patterns ready to be promoted?
  • Execute knowledge routing
  • Execute feedback loop
  • Log to evolution/weekly/

Reflection Principles

  • Synthesize, don't collect — Don't repeat what happened during today's work; extract what matters
  • Search when you find gaps — When you discover a knowledge gap, actively search to fill it; don't just think about it
  • Check against user expectations — Use the "user expectations" section of CLAUDE.md as the baseline
  • Record or it didn't happen — Saying "I learned X" without writing it down = didn't learn
  • "Nothing to note" is usually wrong — Look harder; don't dismiss reflection with a one-liner

Red Lines

  1. Don't record everything — One-off facts aren't worth the overhead. Be selective.
  2. Don't build catch-all containers — Each skill/file should have clear scope. Don't dump everything in one place.
  3. Don't record outside your scope — Valuable knowledge that's not your domain? Pass it to the right owner.
  4. Don't reinvent — Check if an existing skill/file already covers this before creating new ones.
  5. Don't skip the filter — Every piece of knowledge goes through ②. No exceptions.
  6. Don't modify Layer 3 files yourself — Write a proposal to evolution/proposals/ and wait for approval.

Manager Collaboration

  1. When scope is unclear: Proactively ask your manager to clarify the boundary.
  2. When you find a gray area: Report it to the manager and let them decide ownership.
  3. When creating a new Skill: Notify the manager so they know what you've accumulated.
  4. When growth direction is in question: Report to the manager; let them update the growth-profile.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Agent Skill design knowledge base — mechanisms, philosophy, patterns, pitfalls. Use when: designing new skills, reviewing skill quality, or deciding whether something should be a skill.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

cablate/ai-toolkit162026년 4월 6일 업데이트

Claude Code 專案配置審計。觸發:review/優化 CLAUDE.md、skills、settings、定期清洗累積內容、新專案上線前檢查。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

cablate/ai-toolkit162026년 4월 6일 업데이트

Agent 配置設計指南 — 基於 Claude Code 6 個 built-in agent 的逆向分析。Use when: 設計新 agent、優化現有 agent prompt、決定工具/模型配置、撰寫 dispatch prompt。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

cablate/ai-toolkit162026년 4월 6일 업데이트

AI Agent 成本工程 — 基於 Claude Code 的成本追蹤、prompt cache 最佳化、token 預算控制逆向分析。Use when: 優化 token 消耗、設計成本控制機制、分析 cache 效率、選擇模型配置。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

cablate/ai-toolkit162026년 4월 6일 업데이트

Harness Engineering 設計模式 — 基於 Claude Code 原始碼逆向分析的 12 條可遷移原則。Use when: 設計 agent 系統架構、實作 tool orchestration、設計 context 管理策略、建構 agent loop。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

cablate/ai-toolkit162026년 4월 6일 업데이트

System Prompt 工程 — 基於 Claude Code 914 行系統提示詞的逆向分析。Use when: 撰寫 system prompt、設計 prompt 動態組裝、最佳化 prompt cache 效率、撰寫安全指令。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

cablate/ai-toolkit162026년 4월 6일 업데이트

cablate의 스킬 모두 보기

이 스킬의 문제 신고