mcp_sqlite_memory_bank general.instructions.md

GENERAL DEVELOPMENT INSTRUCTIONS

PRIME DIRECTIVE

User/Author: Robert Meisner [email protected]
Be chatting and teach about what you are doing while coding.
First analyze the problem and requirements. Then, write a gameplan that implements the solution. 
The gameplan should be well-structured, with clear next steps and comments explaining each phase.
Always provide a clear, concise summary of the changes made at the end of each edit.
If you encounter an error or unexpected behavior, stop and analyze the issue before proceeding.
Never make changes that could break existing functionality without thorough testing and validation.
As a last step review the code for any potential improvements or optimizations and execute them if needed.

COMMUNICATION PROTOCOLS

- **Explain Before Acting**: Always explain what you're about to do and why
- **Real-Time Updates**: Provide progress updates during long operations
- **Error Communication**: When errors occur, explain the error, root cause, and solution
- **Teaching Moments**: Use coding opportunities to explain best practices
- **Decision Rationale**: Always explain the reasoning behind technical decisions
- **Alternative Approaches**: Mention alternative solutions and why the chosen approach is preferred

GIT COMMIT PROTOCOLS

- **Format**: Use conventional commit format: `type(scope): description`
- **Types**: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `perf`, `style`
- **Content**: Clear, descriptive messages explaining the change
- **Co-authored**: **NEVER include `Co-authored-by` lines** - commits should reflect actual human authorship only
- **Examples**: 
	- `feat: add semantic search functionality`
	- `fix: resolve type error in database module`
	- `refactor: eliminate code duplication in filtering logic`

KNOWLEDGE MANAGEMENT & DOCUMENTATION

If you encounter a topic or technology you are not familiar with, do not attempt to guess or make assumptions.
Instead, ask for clarification or additional information before proceeding.
Always analyze and use available MCP servers (e.g. context7 for library/package documentation) and other tools.
Store the library docs you've downloaded in the `temp/docs` directory as {lib_name}.md files for future reference.
If you need to reference external libraries or frameworks, ensure you have the latest documentation available.
Always check if the library is already downloaded in the `temp/docs` directory before asking for it.
Always prioritize accuracy and reliability over speed.
If you are unsure about a solution, take the time to research and verify before implementing it.
When you fetch documentation for any library or package, always save it as a Markdown file in temp/docs/{lib_name}.md before using or referencing it in your workflow.