// Learn from corrections, mistakes, and discoveries during conversations. When the user corrects you, when something fails unexpectedly, or when you discover a project-specific pattern worth remembering — record it as a learning so future sessions benefit automatically.
When the user wants to draft tweets, plan threads, post to Twitter/X, or manage their Twitter presence
When reviewing UI/UX for quality, consistency, and polish. Use when the user says 'review the design,' 'check the UI,' 'does this look good,' 'design audit,' 'UX review,' or 'polish the frontend.' Also use after implementing any user-facing feature to catch visual and interaction issues before shipping.
Red-green-refactor cycle for test-driven development
When reviewing product decisions, feature scope, or user-facing changes from a founder/CEO perspective. Use when the user says 'does this make sense,' 'should we build this,' 'review the product,' 'is this good enough,' 'founder review,' 'product sense check,' or before any significant launch. This is the strategic taste layer — not engineering quality, but product quality.
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.
When reviewing code that involves architectural decisions, new modules, data flow changes, or system design. Use when the PR introduces new services, changes API boundaries, modifies database schemas, adds new dependencies, or restructures significant portions of the codebase. Also use when the user says 'review the architecture,' 'is this the right approach,' or 'design review.'
| name | self-improving |
| description | Learn from corrections, mistakes, and discoveries during conversations. When the user corrects you, when something fails unexpectedly, or when you discover a project-specific pattern worth remembering — record it as a learning so future sessions benefit automatically. |
You have a persistent learning system. Use it to get smarter over time.
Record a learning when ANY of these happen:
Do NOT record:
Create a markdown file in .learnings/ at the project root:
# File naming: YYYY-MM-DD-short-description.md
.learnings/2026-03-20-use-pnpm-not-npm.md
Each learning file follows this format:
# Use pnpm, not npm
**Context**: Ran `npm install` and got lockfile conflicts.
**Correction**: This project uses pnpm exclusively. The `pnpm-lock.yaml` is the source of truth.
**Rule**: Always use `pnpm` for install, add, and run commands. Never use `npm` or `yarn`.
Keep it short — 3-5 lines. One learning per file.
At the start of every conversation, check if .learnings/ exists. If it does, read all files in it before starting work. These are hard-won lessons from previous sessions — respect them.
.learnings/
├── 2026-03-18-api-auth-requires-bearer.md
├── 2026-03-19-tests-need-env-setup.md
└── 2026-03-20-use-pnpm-not-npm.md