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.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Capture this into the knowledge base: $ARGUMENTS
All files live in lambda/scripts/memory/. The index is at lambda/scripts/memory/INDEX.md.
Read lambda/scripts/memory/INDEX.md to understand what's already captured and avoid duplicates.
| 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.
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.
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.
Capture knowledge when ANY of these happen during a conversation:
Do NOT capture:
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.
Add a new built-in exercise to Liftosaur end-to-end — image (gymvisual.com → S3), catalog registration, description page, and the LLM/MCP exercise list. Use when adding one or more built-in exercises to the app catalog.
The English summary is being prepared. Showing the original description.
Add a new server-rendered page to the Liftosaur website. Use when creating new public-facing pages with routing, SSR, and client hydration.
The English summary is being prepared. Showing the original description.
Create a 30%-off coupon for an affiliate or creator on iOS and Android, and draft the reply that tells them how to use it. Use when asked to create, set up or send a coupon or promo code for an affiliate, influencer or creator.
The English summary is being prepared. Showing the original description.
Interactively investigate a production Rollbar error. Accepts an occurrence id, item id, item counter, or Rollbar URL. Fetches the error data, assesses how widespread it is, drills into affected users (events, logs, storage, captured state), and works with the developer toward a fix or ignore decision. Use for collaborative debugging; use /fix-rollbar for a straight fetch-and-fix of a single occurrence.
The English summary is being prepared. Showing the original description.
Investigate a user-reported issue using server logs, user events, storage snapshots, and Rollbar. Use when given a user id or email plus an issue description (e.g. from a support email).
The English summary is being prepared. Showing the original description.
Build a feature end to end — decide worktree vs here, design the architecture and debate it with codex, get the user's approval on a one-pass-readable plan, state the API/state contract, implement with visible diffs, then run two codex reviews (bugs + architecture) and document the result. Use when asked to build/implement/add a feature or do a refactor that involves design decisions.
The English summary is being prepared. Showing the original description.