Capture Convention or Instruction
capture_thoughtSave coding conventions, instructions, corrections, or preferences for future reference. Each capture is classified by type, scope, and topics for easy retrieval.
Instructions
Save a coding convention, standing instruction, correction, or workflow preference for future reference — e.g. style rules ('always use 2-space indent'), standing directives ('never force-push to main'), a correction after getting something wrong, or a stated preference for how work should be done. Call this whenever the user states a rule or preference for how you should work, corrects your approach, or explicitly asks you to remember something — don't wait to be asked to 'save' it. Occasional non-coding notes are fine too, but this store is primarily for conventions and instructions that should carry across future sessions and projects. Classify it yourself using the type/scope/topics/projectSpecific fields below, based on the conversation the thought came from. If a single message states multiple distinct rules, call this once per rule — don't merge them into one capture — and relay each one individually the same as a single capture, not summarized together. After every successful call, state the captured content verbatim and its scope back to the user (the response text already contains both) — this is how they catch a misinterpreted rule and correct or delete it immediately, rather than discovering it wrong much later.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Classify using the conversation this thought came from: 'convention' — a specific coding style/pattern rule; 'instruction' — a standing directive on how to work/behave; 'correction' — a past mistake and the corrected approach; 'preference' — a softer preference, not a hard rule; 'other' — anything else that still belongs in this store. | |
| scope | Yes | The language, framework, or general topic this applies to (e.g. 'PHP', 'SQL', 'git') — or 'global' if it isn't tied to a particular language/framework. | |
| topics | Yes | 1-3 short topic tags (e.g. 'git', 'testing', 'naming'). | |
| content | Yes | The convention, instruction, or thought to capture — a clear, standalone statement that will make sense when retrieved later, in a different session, with no other context | |
| projectSpecific | Yes | True ONLY if this explicitly names one project/codebase or is obviously about its specific files/architecture — false (the default assumption) for anything that could apply across projects. |