hybridlabor-api memB Deep Memory Ingestion Skill
When this skill is invoked via /memb-ingest or requested, you MUST orchestrate a deep scan of the user-specified project path or conversation logs to populate the memB local vector database (~/.MemBDB/memb.db).
Core Workflow & Instructions
1. Target Path & Filter Selection
- Ask the user: "Which directory or project path would you like to scan into memB memory?" (Default: Current Workspace or active project directory)
- Ask if they would also like to include past Antigravity chat transcripts (
--transcripts) or filter specific file patterns (e.g.,*.md,agent.md,.openwiki/).
2. Execution
Locate the memb-mcp installation (e.g., ~/.gemini/config/mcps/memb-mcp/ or ~/.gemini/mcps/memb-mcp/) and execute the ingestion script via its virtual environment:
# Run ingestion with project detection & optional transcript indexing
~/.gemini/config/mcps/memb-mcp/.venv/bin/python ~/.gemini/config/mcps/memb-mcp/memb_ingest.py "<TARGET_DIRECTORY>" --transcripts
3. Verification
Query memB using search_memory or inspect ~/.MemBDB/memb.db to confirm that the project architecture and key decisions are indexed.
Execution Rules
- Never skip path confirmation: Always verify the target path before running the scan.
- Filter Noise: Ignore
node_modules,.venv,.git,dist, and temporary cache directories. - Report Summary: Present a clear count of indexed documents to the user upon completion.
1. Overview
This skill provides domain-specific logic and rules for its respective BDB pipeline component to ensure standardization across multi-agent workflows.
2. When to Use
- Use when specifically requested by the user or triggered by an orchestration agent.
- Use when the current task aligns with the skill's domain.
- Exclude when standard tool execution is sufficient.
3. Core Process
- Read the provided context and ensure preconditions are met.
- Run the required script or tool and confirm the state change.
- Verify exit codes, file modifications, or DB counts to guarantee success before reporting completion.
4. Common Rationalizations
| Rationalization | Reality |
|---|---|
| "The code change was small, so I skipped updating OpenWiki docs." | Every state change must be reflected in the relevant system records. |
| "The ingest script exited without an error, so the memB index must be updated." | Silent failures happen; explicit verification of the side effect is mandatory. |
| "I'll let the /startcycle proceed without a defined rollback path." | Proceeding without a rollback path corrupts the workflow integrity and safety. |
| "I trust the cached agent registry instead of rescanning after a skill change." | Caches stale out quickly; explicit rescans prevent ghost failures. |
5. Red Flags
- Bypassing the verification step after a script execution.
- Proceeding to the next pipeline stage without confirming the previous stage's side effects.
- Ignoring domain-specific constraints listed in this skill.
6. Verification
- Verified script exit codes are explicitly checked.
- Confirmed target files or database records reflect the expected change.
- Ensured no silent failures were ignored before reporting success.