Compact overlapping Hizal context by gathering related chunks, producing a higher-signal summary, writing it back, and superseding or deleting redundant chunks carefully.
Use this skill when Hizal has too many overlapping or low-signal chunks on the same topic.
Use it for requests like:
Start a session at the top of any compaction task — see hizal-onboard. End it with end_session when done.
Expect a Hizal MCP server to be configured with:
Authorization: Bearer <api-key>Resolve the project_id explicitly for all project-scoped MCP calls.
search_context(query="<topic>", project_id="<project_id>", limit=20).compact_context(scope="PROJECT", query="<topic>", project_id="<project_id>") — scope is required. Compact one scope at a time.write_knowledge(project_id="<project_id>").Compact within a single scope per session:
| Scope | What to compact | Notes |
|---|---|---|
| PROJECT | Overlapping KNOWLEDGE, RESEARCH, PLAN chunks | Prefer within same chunk_type |
| AGENT | Personal memory that grew noisy | Keep always_inject IDENTITY separate |
| ORG | Org-wide knowledge that drifted | Be conservative — org chunks affect all agents |
Do NOT compact across scopes. Promoting content between scopes is a consolidation decision, not compaction — use end_session review to handle that.
Prefer compacting within the same chunk_type:
Do NOT merge DECISION chunks into KNOWLEDGE summaries. DECISION chunks are high-value and long-lived — preserve them individually.
Do not merge always_inject and non-always_inject chunks. They serve different purposes:
Never use write_convention during compaction. Compaction produces summaries, not foundational rules.
Before using write_convention, ask:
If any answer is no, use write_knowledge or write_memory instead.
compact_context(scope=...) — scope param is required.write_context.