Hub Detection & Cleanup (Graph Maintenance)
2 steps
Graph maintenance specialist for detecting high-degree hub concepts that pollute BuildContext results. Identifies generic hubs, updates the WikiLink filter, and cleans existing files.
Triggers
Steps
- 1.
Hub Detection (Graph Analysis)
Identify high-degree hub concepts that pollute BuildContext results.
- Query graph for high-degree concepts using build_context with depth=1 on suspected generic terms
- Use find_similar_concepts to discover concept families and measure connection breadth
- Cross-reference results with existing .wikilink-filter.json file (read it if it exists)
- Classify each high-degree concept:
- Generic hubs (e.g., "tool", "agent", "workflow") that connect to many unrelated memories -> recommend for filter
- Specific concepts with legitimately many connections -> keep
- Create classified list of hub candidates with connection counts and recommendation
Output: Classified list of hub candidates with connection counts and recommendation Include: Concept name, degree count, classification (generic-hub / legitimate), reason
CRITICAL: Do NOT use read_memory - this phase is observation-only to preserve decay integrity.
Tools:build_context*find_similar_conceptsEffort:lowGuardrails- no_read_memory: NEVER use read_memory - graph tools do not need file content
- observation_only: This phase identifies hubs, does not modify anything
- 2.
Hub Cleanup (Filter & Strip)
Apply filter updates and strip hub WikiLinks from existing memory files.
- For confirmed generic hubs from the detection step: a. Read the existing .wikilink-filter.json (or start with {}) b. Add each confirmed hub as a key with the reason as value c. Write the updated .wikilink-filter.json
- Strip hub WikiLinks from ALL memory files using the CLI one-liner: This replaces [[concept]] with plain text concept across all memory files.
- Run sync to rebuild the graph without the stripped hub concepts
- Compile cleanup report with: hubs filtered, files modified, WikiLinks stripped
Output: Return cleanup report as workflow output - DO NOT write to memory://
CRITICAL: Do NOT use read_memory. The sed one-liner does the work - no LLM needed for stripping.
Tools:Bash*sync*Effort:lowGuardrails- no_read_memory: NEVER use read_memory - sed handles file modifications directly
- no_write_memory: NEVER use write_memory - cleanup reports are ephemeral, return as output
- filter_format: .wikilink-filter.json is a JSON object: {"concept": "reason", ...}