Turn lessons from complex tasks, debugging, failures, or rollbacks into short learning entries. Capture the root cause, a reusable action, and a recognizable signal, then merge examples that share a cause with existing notes.
Write growth log entries that extract reusable patterns from completed work — root cause, transferable rule, and a recognizable signal — instead of diary-style event narration, with a 4-8 sentence template and merge-duplicates discipline. Use when capturing what was learned after a complex task, debugging session, failure, or rollback, when reviewing progress over a period, or when a delivery gate asks what was learned.
Review the instructions the agent will receive before you install.
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.
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; Secure when cross-origin. Signal to recognize: auth breaks after browser upgrade or when crossing origin boundaries."
Good (data pipeline): "CSV import failed silently on empty rows because pandas.read_csv(dropna=False) keeps zero-width rows that len() counts as valid. Pattern: always df.dropna(how='all', inplace=True) before row-count validation."
Before writing a new entry, ask: "Is this fundamentally the same as something I already recorded?"
Same root cause, different symptom → merge, don't duplicate. New root cause → new entry.
How to check: Search existing entries for keywords from your root cause before writing. If you find a match, add your new symptom as an additional example under the existing entry rather than creating a duplicate.
Example: "Forgot to update the output index after creating a file" and "Forgot to update skill ratings after a task" — same root cause (no automatic capture trigger). Merge into one entry about "post-task capture gaps."
Every entry must answer: "Next time I face a similar situation, what do I do differently?"
If you can't write that sentence, you haven't extracted the pattern yet.
How to extract a pattern from a concrete event:
Scope: One entry per distinct root cause. Typical length: 4-8 sentences. If it takes >2 minutes to write, you're narrating events. If <30 seconds, you haven't gone deep enough.
## [Title: the pattern, not the event]
### Context
- What was I trying to do?
- What went wrong / what worked surprisingly well?
### Root Cause / Core Insight
- The underlying mechanism, not just the symptom
### The Pattern (transferable)
- Next time [similar situation], I will [specific action].
- Signal to recognize: [what observable tells me this pattern is active?]
### Related
- [entry-name](../path/to/related-entry.md)
All four types use the template above. The type determines which sections carry the most weight:
| Type | When to Use | Emphasis | Example Title |
|---|---|---|---|
| Failure | Something broke, needed debugging, or required rework | Root Cause | "Config inheritance ≠ behavior inheritance across sessions" |
| Methodology | A repeatable process emerged from the work | Context / Pattern | "PPT → open-book exam study guide: three-layer structure" |
| Pattern Discovery | A reusable insight about tools, systems, or thinking | Pattern section | "PR description template: describe the gap, not the feature" |
| Capability Change | A measurable skill improvement | Context (before vs after) | "Git: from clone/push to independent PR with 12 commits" |
Before finalizing a growth log entry:
Store entries wherever you keep notes. Common patterns:
growth-log/ directory (one file per day: YYYY-MM-DD.md)Pick one convention and stick to it. Searchability matters more than format.
The delivery-gate Stop hook checks that learning files were modified today via filesystem timestamps. This skill teaches what to write — so the file that delivery-gate checks actually contains useful patterns, not empty timestamps.
Task completes → delivery-gate checks: was the learning file touched today?
→ Stale (no file modified): block — "what did you learn?"
→ Fresh (file touched): pass — this skill ensures the content is useful
Having enforcement without methodology → empty entries. Having methodology without enforcement → forgotten captures. Each is independently useful; together they close the loop.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Design and audit interfaces for Web, iOS, and Android using WCAG 2.2 accessibility guidance. Check screen-reader labels, keyboard navigation, contrast, and control sizes to identify barriers and guide implementation for people using assistive technology.
Investigate unreliable AI agents across 12 layers, including instructions, memory, tool execution, and display. Use code and logs to trace failures, rank findings by severity, and produce an ordered repair plan that prioritizes code changes.
Compare coding agents on tasks from your own codebase. Define success checks, run agents in separate Git working directories, and report pass rates, available API costs, completion time, and consistency across repeated trials.
Design and refine an AI agent’s available actions, tool inputs, and result formats. Define recovery steps for errors, manage the information kept in context, and evaluate changes through completion rates, retries, and cost per successful task.
Diagnose failed AI agent runs by capturing errors, checking likely causes, and choosing small, reversible recovery actions. The workflow produces a structured report of the failure, recovery steps, and evidence, helping explain repeated retries or stalled progress.
Diagnose AI agent runs that fail repeatedly, loop through tools, or lose track of the task. Capture errors and environment details, test a focused recovery action, and produce a report explaining the evidence and outcome.