| name | kb |
| description | Capture important architectural decisions, bug patterns, feature designs, or other critical findings into the project knowledge base. Use proactively when significant technical decisions are made, non-obvious bugs are resolved, new subsystems are designed, or important product features are discussed. |
| disable-model-invocation | false |
| argument-hint | ["what to capture"] |
Knowledge Base Capture
Capture this into the knowledge base: $ARGUMENTS
Knowledge Base Location
All files live in lambda/scripts/memory/. The index is at lambda/scripts/memory/INDEX.md.
Step 1: Read the current index
Read lambda/scripts/memory/INDEX.md to understand what's already captured and avoid duplicates.
Step 2: Choose a category
| Category | Directory | When to use |
|---|
| Architecture | architecture/ | System design, infrastructure, sync protocols, data formats, tech stack choices |
| Decisions | decisions/ | "We chose X over Y because Z" — explicit tradeoff analysis |
| Features | features/ | Product feature descriptions, UX designs, user-facing behavior |
| Bugs | bugs/ | Non-obvious bug root causes, debugging patterns worth remembering |
| Future Plans | futureplans/ | Planned work not yet started — roadmap items, RFCs for future features |
| SEO | seo/ | SEO research, keyword analysis, backlink data, Core Web Vitals |
If none fit, create a new category directory and add a section to INDEX.md.
Step 3: Create the entry file
Filename: lowercase-kebab-case, descriptive. Example: watch-echo-loop-bug.md
Entry format:
---
date: YYYY-MM-DD
tags: [relevant, tags]
---
# Title
Concise description of the finding/decision/pattern.
Keep it 5-20 lines. Link to relevant source files where useful.
Focus on the WHY and the non-obvious parts — assume the reader is a developer familiar with the codebase.
Step 4: Update INDEX.md
Add a one-liner entry under the appropriate category heading:
- [filename.md](category/filename.md) — concise one-liner (max 80 chars)
Keep entries sorted by relevance within each category (most important first), not by date.
When to auto-invoke this skill
Capture knowledge when ANY of these happen during a conversation:
- An architectural decision is made (chose X over Y)
- A non-obvious bug root cause is discovered
- A new subsystem or data format is designed
- A significant refactor changes how something works
- The user discusses product strategy or feature scope
- Performance investigation reveals important findings
- A workaround for an external limitation is implemented
Do NOT capture:
- Routine code changes (rename variable, fix typo)
- Information already in the knowledge base
- Temporary debugging steps
- Anything the user explicitly says is experimental/throwaway
