growth-log

Topics in the source

• Growth Log Skill
• When to Activate
• The Three Rules
• Rule 1: Failures > Achievements
• Rule 2: The Bole Principle (伯乐原则)
• Rule 3: Must Be Transferable
• Entry Template
• Entry Types

The problem: Most people write "fixed a bug in X" as a learning log. That's a diary entry, not a learning artifact. A real growth log extracts the pattern so you recognize it next time. This skill teaches: How to write learning entries that compound across sessions. Works with any note-taking system — Markdown files, Notion, Obsidian, plain text. Templates are generic; adapt to your setup. After completing a complex task (multi-file, new feature, architecture change) After a failure, mistake, or "that was harder than expected" moment When you want to review what you've learned over a period When NOT to activate: Trivial changes (typo fixes, single-line tweaks, config value changes with no debugging). The threshold: did this task involve debugging, redoing, rollback, or a non-obvious decision? If yes → write an entry. If no → skip. A failure is nutritionally denser than a success. One bug that took 2 hours to find teaches more than 3 features that worked first try. Bad: "Successfully implemented the login flow." Good (web dev): "Login flow: session token wasn't persisting because the cookie SameSite defaulted to Lax in Chrome 128+. Pattern: always explicitly set SameSite=None; Secur

This is an excerpt. Refer to the complete source and its current requirements.