Task Context Storage

Defines which persistence layer owns each kind of context. File formats, nested directory structure, and maintenance tooling are delegated to compact-directory-memory.

Persistence layers

Route to global memory()

• User identity, durable preferences, and recurring corrections.
• Stable environment facts used across unrelated tasks.
• Cross-task workflow constraints.

Do not store task progress, commits, issue numbers, transient failures, or session outcomes here.

Route to task MEMORY.md

• Expected configuration and stable conventions.
• Durable paths, interfaces, ports, ownership boundaries, and invariants.
• Facts that another session must know before changing the same task or subsystem.

Do not store momentary runtime status or chronological history here.

Route to task CHANGELOG.md

• Why one option was chosen over another.
• What was changed and where.
• Real test, build, migration, or health-check results.
• Failures, fixes, unresolved blockers, and exact next step.
• Session and phase outcomes.

Hierarchical tasks

When a task spans multiple subsystems, load compact-directory-memory and use its hierarchical layout. Root files index and synthesize cross-subsystem facts; memories/<sub-system>/ owns detailed subsystem context.

The routing rule remains unchanged at every level:

• stable expected state → MEMORY.md
• chronological observed work → CHANGELOG.md

Boundary cases

When one observation contains both a reusable preference and a task decision, split it:

• global memory() receives the durable preference;
• task CHANGELOG.md receives the local decision and its consequences;
• task MEMORY.md receives only a resulting stable fact, if one exists.

Relationship to task-framework

task-framework should reference this skill for context-routing decisions and compact-directory-memory for concrete directory management. It should not duplicate either skill's detailed rules.